search

google / osv.dev

Open source vulnerability DB and triage service.
https://osv.dev
Apache License 2.0
1.47k stars 178 forks source link

Blogpost Discussion: Intermediate VEX #1080

Open lumjjb opened 1 year ago

lumjjb commented 1 year ago

This issue is a place for discussion for the blog post on Intermediate VEX (https://osv.dev/blog/posts/automating-and-scaling-vex-generation/) on the osv.dev blog.

fridex commented 1 year ago

AFAIK, Chainguard is also putting some effort into VEX - maybe it would worth a sync (if not done already) so the industry could consolidate. CC @dlorenc @puerco

The approach looks interesting, it might open a question how reliable and trusted the proposed intermediate VEX files will be. I could imagine the proposed intermediate VEX files helping creating trust in the industry. If a community/company reviews VEX files then they could sign it and create a public record about the review.

fridex commented 1 year ago 
$ cat .vex  
libfoo, CVE-2022-123456, NOT_AFFECTED, inline_mitigations_already_exist  
libbar, CVE-2022-654321, NOT_AFFECTED, vulnerable_code_not_in_execute_path

A link to the security analysis done might be valuable here (eg. a GitHub issue) - if others want to review VEX, they can see how the security analysis was done together with additional reasoning.

EDIT: Also, assuming that all the repos adopt .vex is somehow an ideal state. Some projects might not be open to maintain VEX information (lack of security knowledge, not familiar with the approach, unmaintained, ...). It might be worth to offer a way to include VEX information also for transitive deps for such cases.

lumjjb commented 1 year ago

Hey @fridex ! Thanks for the heads up! Yep - we are in sync and have a hand in OpenVEX maintenance! This motivation was a bit more on thinking through the automation and distribution once we have a VEX document standard :).

A link to the security analysis done might be valuable here (eg. a GitHub issue) - if others want to review VEX, they can see how the security analysis was done together with additional reasoning.

+1 on this, that would be helpful!

Also, assuming that all the repos adopt .vex is somehow an ideal state. Some projects might not be open to maintain VEX information (lack of security knowledge, not familiar with the approach, unmaintained, ...). It might be worth to offer a way to include VEX information also for transitive deps for such cases.

Yep! i'd also imagine that there would be some kind of policy as well to reconcile, like if there are two vex statements with conflicting affected statuses, the user would be able to pick which one they trust more.

github-actions[bot] commented 1 week ago

This issue has not had any activity for 60 days and will be automatically closed in two weeks