A not-affected disposition needs a reason that can be reviewed: for example, the component is absent, the vulnerable code was excluded, or the code cannot be reached in the deployed product. The assertion must identify the product version or digest and the vulnerability. Rebuilding the image, changing configuration, or learning of a new attack path can invalidate the reasoning even when the package name stays the same.
Make this comfortable
VEX decisions: bind a not-affected claim to evidence and expiry
Operational decision
A claims parser includes a library flagged for a parsing flaw, but the shipped binary excludes the affected module. The owner records the exact image digest, build flags, code-path evidence, vulnerability identifier, status, justification, and reviewer. A second reviewer checks the final runtime image and a test that would fail if the excluded module were enabled. The policy permits a not-affected disposition for that digest only, with a planned revisit after the next rebuild or advisory update. Build a second image that enables the module; its scan must not inherit the first image's suppression. If evidence is inconclusive, use an investigating state and a bounded release decision rather than fabricating a not-affected reason. If the product is affected, record mitigation and patch work separately. Keep the assessment alongside the SBOM and release digest so downstream scanners can read it without mistaking it for the scanner's own finding. Limit who may issue these statements and audit changes; an unsigned text note in a ticket should not silently disable a deployment gate.
Claims parser exploitability record
Product: exact image digest and architecture
Vulnerability: identifier and affected component
Status: not affected
Reason: vulnerable module absent from shipped binary
Evidence: build flags, binary inspection, regression test
Review trigger: new digest, config change, advisory update
Approval: named owner and independent reviewerCost and verification
A disposition review is O(1) per finding only when evidence is already linked; across F findings, review effort grows with F and with the number of distinct product digests. Narrow statements cost more to maintain but prevent old suppressions from hiding new risk. Measure stale assertions, findings reopened after rebuild, unsupported not-affected claims, and time to revisit an investigating state. A VEX record changes triage, not the underlying shipped bytes.
Common Mistakes
- Do not apply one not-affected claim to every future image tag.
- Do not suppress a finding without a product identity and testable reason.
- Do not leave investigating status without an owner and review date.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Package identity: verify advisory matches before changing a release
- SBOM binding: keep the inventory attached to the tested digest
- Policy exceptions: make a temporary bypass expire and prove its scope
- Dependency patch campaigns: update, test, and prove the running image
Practice and check
devops
supply-chain