nexB
Have consistent labels in UI and API and models for affected and fixed
Today we have this (problematic entries are in bold)
-
Package
- UI- affected by vulnerabilities, fixed by vulnerabilities -> replace by fixing vulnerabilities
- Models- affected_by, fixing -> do nothing for now, rename to be consistent with UI and API in the future
- API- affected_by_vulnerabilities , fixing_vulnerabilities
-
Vulnerability
- UI-affected packages, fixed by packages
- Models- affected_packages, fixed_by_packages
- API- affected_packages , fixed_packages -> do nothing for now as renaming to fixed_by_packages would break the API. We should do it when we rev up the API though.
We have several older issues that are closed in favor of this main issue:
- https://github.com/nexB/vulnerablecode/issues/1301
- https://github.com/nexB/vulnerablecode/issues/524
- https://github.com/nexB/vulnerablecode/issues/1501 and its PR https://github.com/nexB/vulnerablecode/pull/1519
A survey of other DBs was never reported:
- OSV: tracks Vulnerabilities first. See https://ossf.github.io/osv-schema/
- for a package: affected, then inside a list of version events with "introduced" and "fixed"
- GitHub: tracks Vulnerabilities first
- for a package: Affected versions, and Patched versions. Multiple subranges exist in their model and the data is also available in the OSV format
- example: OSV format 1.4: https://github.com/github/advisory-database/blob/3ebdaecac1a9b2e5db0f2a2e78dd58c02cec1a1e/advisories/github-reviewed/2024/04/GHSA-mj35-2rgf-cv8p/GHSA-mj35-2rgf-cv8p.json#L7 and in the UI https://github.com/advisories/GHSA-mj35-2rgf-cv8p
- Snyk: tracks package first, they list "vulnerable versions" for a package
- GitLab: by package, then by vulnerability. Use "affected_range", "fixed_versions", "affected_versions"
- CVE schema: track vulnerabilities first. See https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json
- Use "Affected products" , and 'affected' and 'unaffected' as the vulnerability status of a given version or range of versions of a product.
from https://github.com/nexB/vulnerablecode/issues/1301#issuecomment-1725946310 by @mjherzog
It seems that the affect/fix terminology is well-established. I recommend slight changes in wording as follows:
- A vulnerability is "fixed by" a package.
- A vulnerability "affects" a package.
- A package "fixes" a vulnerability.
- A package is "affected by" a vulnerability.
From https://github.com/nexB/vulnerablecode/issues/1501#issuecomment-2218688529 by @mjherzog :
The terminology is very context dependent as explained by @johnmhoran . So if we are talking about just the Results page context, then changing "Fixed by vulnerabilites" to "Fixes vulnerabilities" make sense. On the Essentials page that changes to:
- Vulnerabilities affecting this package
- Vulnerabilities fixed by this package which makes sense in this context
From https://github.com/nexB/vulnerablecode/issues/1501#issuecomment-2243895598 by @pombredanne
What I see most commonly is "fixed vulnerabilities" from a package point of view, not "fixes vulnerabilities". Juts removing the "by" should be enough
For the record:
- @johnmhoran pointed that Package "fixing vulnerabilities" is not proper English and we should have used "fixes vulnerabilities", but for now and for the sake of consistency between the API, UI and DB models, we will go with "fixing vulnerabilities".