Vendor said "not affected". Prove it, apply it, and pass it on.
Scanners flag thousands of CVEs; most do not apply to how the code is actually used. Vendors send VEX documents saying so, your own reviews produce more, and the decisions end up in tickets and spreadsheets where nobody can trace who decided what, for which version, on what evidence.
VEX is just another artifact
Attach a CycloneDX-VEX or OpenVEX document to a release from the UI, the CLI or your pipeline. ReARM matches every statement against the release's SBOM inventory, so a claim only lands where the affected component actually is.
↳ SBOM/XBOM ManagementTrust depends on who is talking
A vendor's "exploitable" is accepted at once; a vendor's "not affected" is staged for your review, because that is where downplaying happens. Your own analyses auto-accept; third-party claims always wait. Import mode and issuer trust compose, and the least permissive wins.
↳ Findings AggregationOne decision, the right scope
A claim can apply to one release, a branch, a whole component, or the entire portfolio. ReARM records it once at the scope you choose, and stages any claim that contradicts an existing broader decision for review instead of silently overriding it.
↳ Findings AggregationConditional claims wait for evidence
"Not affected, protected at perimeter" is only true while the perimeter holds. ReARM defers such decisions until someone attests the mitigation is in place, with the evidence recorded; waive it and the decision is never written.
↳ Release PoliciesReview with the original in view
Every staged statement is reviewed next to the verbatim VEX it came from and any existing analysis it would touch. Accept, modify, or reject with a required comment; who decided what, and when, stays on record.
↳ Audit EvidenceExport VEX for your customers
Your decisions re-emit as CycloneDX-VEX or OpenVEX per release, so the VEX you ship downstream carries the same provenance you demanded upstream, and survives a round trip.
↳ Distribution