Blogpost Discussion: Intermediate VEX

[lumjjb]

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]

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]

$ 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]

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]

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