Should you republish a supplier's VEX not_affected claims under your own name for a composed product?

## Who is allowed to say it The format deliberately does not restrict authorship. A component maintainer, a product vendor, a systems integrator, an operator running someone else's image, or a coordinating body can all author a statement. There is no accreditation, no registry of who may speak. What the format does insist on is that the author is *named* in the document metadata, because trust is a consumer-side decision: a consuming organisation maintains a set of authors whose statements it will honour automatically, and everything else goes to a human. That design has an obvious consequence and a less obvious one. The obvious one: your customers must choose to trust you. The less obvious one: **authorship is accountability**. Once your name is on a statement, the claim is yours. "Our supplier said so" is not a position you can hold in an audit conversation, because the document your customer read did not have your supplier's name on it. ## Why an inherited justification is not automatically true A justification is not a property of a vulnerability. It is a property of a product's build and its invocation pattern, and composition changes both. **Usually survives composition** — these are structural claims about the artifact: - `component_not_present`: the supplier does not ship it. But your build might. If you add a transitive dependency that pulls the component back in, the inherited claim is now false about your product while remaining true about theirs. - `vulnerable_code_not_present`: the supplier compiled it out. This survives as long as you ship the supplier's binary unmodified. Rebuild from source with different flags and you may have re-introduced it. **Usually does not survive composition** — these are claims about behaviour: - `vulnerable_code_not_in_execute_path`: the supplier never calls the flawed code. Your product's entire reason for integrating that component may be to call the very API surface the supplier left dormant. This is the single most common way an inherited claim becomes a false one. - `vulnerable_code_cannot_be_controlled_by_adversary`: the supplier's threat model said the input was operator-supplied. In your composition it may arrive over a network boundary the supplier never had. - `inline_mitigations_already_exist`: the supplier's mitigation may be a default you turn off, or a wrapper you bypass by calling the library directly. The integrator's characteristic failure is re-publishing the middle three unchanged because they were true when the supplier evaluated them, and true statements feel safe to copy. They were true of a different product. ## The organisational problem, which is the real question An integrator with a composed product may inherit hundreds or thousands of statements across dozens of suppliers, arriving in different formats on different cadences. Re-evaluating every one by hand is not a plan. So the decision is about policy, not about any single statement: 1. **Tier by justification class.** Structural justifications get a cheap mechanical check — does my build contain the component, did I rebuild it — and pass through. Contingent justifications go to a queue for human evaluation against your own integration. That alone collapses the workload by a large fraction, because the structural claims are usually the bulk. 2. **Attribute rather than launder.** Where you pass a claim through, keep the original author visible. Referencing the supplier's document, or recording the provenance of the assertion in a status note, preserves the audit trail. Silently absorbing the claim into a document that carries only your name destroys the one piece of evidence that would let anyone reconstruct where the reasoning came from — and audit truth is exactly the asset you are being asked to protect when a customer demands these documents. 3. **Make the supplier state their preconditions.** The reason inheritance is hard is that a label compresses an argument into one token. Contract terms that require suppliers to state the configuration assumptions behind contingent justifications — in an impact statement, in prose, anywhere machine-readable or not — turn a re-evaluation from "reverse-engineer what they meant" into "check whether this precondition holds for us." This is a procurement lever, and it is far cheaper than the engineering it replaces. 4. **Decide what you do about the gaps.** Some suppliers will publish nothing. Your options are to evaluate it yourself and author the statement in your own name, to pass the finding through to your customer unanswered, or to treat the silence as a supplier-risk signal. All three are legitimate; having no position is not, because your customer's scanner will surface the finding whether or not you have an answer for it. ## The standing question from the other direction The mirror case is an operator rather than an integrator: you run a vendor's image and your own tenants' procurement scanners flag it. Can you issue `not_affected` for something you did not build? Yes — nothing in the format stops you, and you may genuinely know something the vendor does not, such as that the flagged code path is unreachable in the configuration you deploy. Two caveats. Your claim is only credible for the deployment you control, so scope it to that and say so. And your tenants' tooling has to be configured to accept you as an author, which is a conversation, not a document. Publishing a statement nobody has agreed to honour changes nothing at all. ## The line to hold Sign what you have evaluated. Cite what you have not. The value of the whole channel rests on the assumption that a named author checked something, and an integrator who reflexively re-signs upstream claims is quietly converting a chain of evaluations into a chain of copies.