Repository navigation
Create a VEX file for Node.js #1517
Description
Info on vex https://cyclonedx.org/capabilities/vex/
I was thinking that a lot of companies find CVEs in the Node.js distribution that do not actually apply to Node.js:
There is a long list of them in https://github.com/nodejs/nodejs-dependency-vuln-assessments/issues but recently I came across the NPM one on Node v20.
Since we have a list of valid vulns https://github.com/nodejs/security-wg/tree/main/vuln it would be trivial to
generate a vex file, and whenever we get a report of a CVE in the Node.js dependencies that we don't think it is valid we can just include it in the vex file, so we avoid getting requested about it, and companies are happy because they are compliant.
Whenever we do a security release we have to update the vex file, this can be done with an automation.
@nodejs/security-wg wdyt?
Activity
RafaelGSS commentedon Sep 4, 2025
How does it work with dependencies of our dependencies? For instance, npm.
dwelch2344 commentedon Sep 4, 2025
Just chiming in as a long time consumer, this would be amazing. The biggest problem with SCA/SAST is noise, and vex enables localized controls.
Happy to contribute to whatever the solution looks like!
marco-ippolito commentedon Sep 4, 2025
we simply add in the vex file that CVE-XYZ does not apply to Node.js (with proper justification) and scanners will ignore it
Orrison commentedon Nov 12, 2025
Going to chime in that I also think this would be a great addition. It would help audits immensely
marco-ippolito commentedon Nov 22, 2025
PR #1537
Orrison commentedon Feb 11, 2026
@marco-ippolito looking back on this I am just curious if y'all have any experience or evidence that this statement is true? Do y'all have experience of compliance audits accepting a VEX file to resolve/ignore CVE reports?
As far as I understand it, VEX is relatively new, and though it was created and maintained by NTIA and CISA there isn't actually third-party verification that a statement in a VEX file is true.
So a downstream user of a package like Node would need to be essentially stating to audit that they believe the VEX statement made by Node is true and the CVE is not exploitable, which though possibly acceptable, is certainly a risk. And potentially not acceptable from an audit perspective.
Furthermore, though newer scanners like Trivy DO support VEX files experimentally (https://trivy.dev/docs/latest/supply-chain/vex/) more long standing scanners like AWS Inspector DO NOT support ingestion of VEX files. Though understandably, a VEX file could potentially be provided alongside the report containing the CVEs, I suppose.
A worry I have is, if a VEX file statement was deemed not acceptable in an audit. But Node felt the VEX file statement resolved a reported CVE from their perspective and therefore planned to not take steps to patch in the foreseeable future, it could put folks in a tough spot.
Of course, I don't mean to imply that Node and it's maintainers would intentionally make a false statement of "Not affected" in the VEX file. Nor that y'all are in any way responsible for the passing of the audits of your downstream users. And I may be naive in how wide-spread VEX file usage and acceptance is.
Just trying to understand the potential impacts of an addition like this as a user and dependent of the software.
marco-ippolito commentedon Feb 11, 2026
As a project we already put some effort into triaging whether a downstream CVE affects Node.js into https://github.com/nodejs/nodejs-dependency-vuln-assessments.
Vex file is just a machine readable way for consumers to access this data. It's up to the consumer decide whether to trust this data or not, at the end of the day there is no absolute truth and our analysis could be wrong. It's not our place to provide a "certification" for companies to use in audit
Orrison commentedon Feb 11, 2026
Of course, makes sense. Thank you!