Consider using well defined syntax for denoting vulnerable releases

[sbs2001]

At https://github.com/nexB/vulnerablecode we consume the istio advisories from https://github.com/istio/istio.io/tree/master/content/en/news/security .

These advisories have a field called releases for denoting istio releases which are affected by the particular vulnerability. Currently it has unstructured values like

• All releases 1.5 and later from istio-security-2021-004
• 1.4 to 1.4.8, 1.5 to 1.5.3 from stio-security-2020-005

Using such unstructured values make it hard to parse the advisories programmatically. It would be extremely useful and easy for us as well as other projects to use istio data if the releases used proper version ranges instead.

Notes: Doing something like All releases x and later is especially bad, since that means any versions in future would be vulnerable.

Examples: https://github.com/RustSec/advisory-db/blob/main/crates/truetype/RUSTSEC-2021-0029.md

Some considerations while using version ranges: https://github.com/RustSec/advisory-db/discussions/831

[ericvn]

@brian-avery No tag for product security team. Maybe change later to prior to make that more understandable.

[brian-avery]

Thanks @ericvn. We have the label in istio/istio, but not here. I'll check why.

Thanks for the feedback @sbs2001. I can see how this would be a challenge to parse. We're working on finding a better way to report both the supported Istio versions that have been patched and older versions of Istio that have not been tested so should be assumed vulnerable. Would it be easier if we were to separate these into two different front-matter fields? Looking at the Rust vulnerabilities you linked, it seems like that's what Rust does.

[sbs2001]

@brian-avery re two different front-matter fields

That's actually one front matter, they are using toml instead of yaml. In any case taking any approach would be fine. IMHO single frontmatter might be simple to maintain wrt to serving it at frontend.

The main issue however is the version ranges wrt making advisories machine readable. It's really a two fold problem.

1. Machine readable version ranges are not provided. In the above example 1.4 to 1.4.8 is manageable, but >=1.4 && <=1.4.8 is effortless.
2. Version ranges need to be actively maintained. For eg there's https://security.openstack.org/ossa/OSSA-2013-011.html#affects which essentially says all versions of keystone are vulnerable. Which is probably wrong, since that vulnerability is 6+ year old.

It must be a burden on your side to enumerate vulnerable and non-vulnerable versions, but if there's testing done it shouldn't be wasted by having less-specific ranges. FWIW there is a project by SAP https://github.com/SAP/project-kb/tree/vulnerability-data/statements they are enumerating vulnerable/patched packages wrt vulnerabilities ranging from the latest CVEs to 6+ year old CVEs. In the end someone has to verify these things, IMHO the "verification" should be shared via more specific ranges, to avoid redundant work.

[ericvn]

Since Brian is not in the Istio community anymore, I'll tag some others on the Product Security WG (I don't know who the WG lead is at the moment): @jacob-delgado @GregHanson

[Rana-KV]

Hello @ericvn and @sbs2001, I'm interested in addressing this issue. My background in Product Security has given me insight into the importance of implementing these changes. If this issue is unassigned, I'm willing to work on it.