VEX: vulnerability decisions

VEX, the Vulnerability Exploitability eXchange, is your recorded answer to "does this vulnerability actually affect our release?": not affected (and why), affected, fixed, or under investigation. Scanners flag far more than is exploitable. Decide once, keep the decision on later releases with the same component, and send customers an answer their own tools can read.

Why you would use it

A customer's security team scans your image and sends back a spreadsheet of forty findings. Most are in code your product never runs: a TLS server library you only use as a client, a command-line tool in the base image that nothing calls. Without a record, someone researches each one, writes a reply, and does it all again for the next release and the next customer.

With VEX decisions, each finding is answered once, with a justification and a name. The next release that ships the same component shows nothing new to triage. And the customer receives an OpenVEX or CSAF document their scanner applies automatically, so the findings you have ruled out disappear from their report instead of coming back as questions.

When you don't need it

If nobody outside your team scans your software, and your team fixes every finding rather than assessing it, decisions have little to record. Once customers scan what you ship, or you carry findings you have judged harmless, you need somewhere to keep the reasoning.

How it works in Logmarq

• Four statuses. Each finding is decided not affected (with the reason in OpenVEX's terms, such as "the vulnerable code is not in the execute path"), affected (with what to do about it), fixed, or under investigation. Every decision keeps its author, the release it was made on, and its history.
• Carried forward only where nothing changed. A decision holds for every later release that ships the same component at the same version, and for any release with the same digest. A component upgraded to a version that is still vulnerable is new to triage.
• Several at once. Findings that call for the same answer, across artifacts and releases, can be decided in one act; each still gets a decision of its own.
• Exported in the formats tools read. A release's decisions export as OpenVEX, which scanners such as Grype apply, and as CSAF 2.0 VEX. An artifact's CycloneDX export carries the decisions beside its findings.

Vendor VEX

Vendor VEX is the same kind of answer, published by a supplier about their component. It lets you adopt the supplier's answer in one decision instead of researching it yourself.

Your releases ship software you did not write, such as a base image or a supplier's SDK, and the scanner flags vulnerabilities in it. Many suppliers publish whether their product is affected, in an OpenVEX, CycloneDX VEX, or CSAF 2.0 VEX document, usually beside their security advisories. Import the document into the project, and each statement shows beside the finding it speaks about, as the supplier's word.

Nothing is decided for you. A supplier's statement never counts as your decision and never leaves in your exports until someone adopts it, and adopting a "not affected" statement still asks for your own justification.

What it will not claim

• A decision is a person's judgment, recorded. Logmarq never decides a finding on its own.
• Decisions do not move to changed artifacts. A changed component or digest is asked about again, never silently inherited.
• Not yet used by an outside team. Vendor VEX has not yet been run on a document a vendor published. The CSAF export has not yet been validated against the official schema or a CSAF validator. The OpenVEX export built from real scanner output validates against its schema, and Grype applies it.

Get started

Open a release's Supply chain section and decide a finding, or tick several and Decide selected. Import a supplier's document from the project's page. From the server:

docker exec logmarq logmarq vex decide <project>@<version> <artifact> <vulnerability> <component> \
  --status not_affected --justification vulnerable_code_not_in_execute_path
docker exec logmarq logmarq vex export <project>@<version> --format csaf

Related pages

Vulnerability scanning · Bills of materials · Customer-response packages