Which VEX justification fits an appliance whose vulnerable XML parser ships only inside an offline migration tool?

## The situation An advisory lands against an XML parser. Your appliance image contains that parser, but only because an offline migration utility bundled in the image links against it. The appliance's running services never call the utility; an operator invokes it by hand, off-line, during an upgrade. A customer's procurement scanner has already matched the advisory against the inventory you publish and opened a ticket. You have to publish a statement. ## Rule out the claims that are false **`component_not_present`** is the one people reach for because it closes the question hardest. It is false. The parser is in the image. Worse, it is *checkably* false: you publish a component inventory for that image, the customer already has it, and the component is listed in it. A VEX statement that contradicts your own inventory is the most damaging thing you can publish in this format, because it converts a technical dispute about one vulnerability into a credibility dispute about every statement you have ever issued. Audit truth is the asset at stake, and it does not recover quickly. **`vulnerable_code_not_present`** is equally false here unless you actually stripped the vulnerable code path at build time. "We do not use that part of the library" is not the same claim as "that part of the library is not in the binary." If you genuinely built the parser without the affected feature, this becomes the right and stronger answer — but you have to be able to point at the build configuration that made it true, not at an intention. ## The claim you can actually defend **`vulnerable_code_not_in_execute_path`**: the code is there, and in the product as it runs, nothing reaches it. That is the honest description of an appliance whose services never invoke the migration utility. Notice what this label costs you. It is a contingent claim, true of a configuration rather than of a binary. Three things break it, and a senior answer names them before the interviewer does: - A later release wires the utility into a startup path, an upgrade hook, or a diagnostics endpoint. The statement is now false and nobody noticed, because nothing in the release process re-validates published VEX claims against the code. - An operator runs the utility, which is exactly what it exists for. - The utility is exposed indirectly — a support bundle generator, a remote upgrade orchestrator, a management API that shells out to it. ## Scope is the real answer The reason this question separates people is that the interesting move is not picking a label, it is picking the *product identifier the statement is about*. A statement binds a status to a product, and you choose what the product is. The clean shape here is two statements: - For the appliance firmware image: `not_affected`, `vulnerable_code_not_in_execute_path`, with a note that the finding is confined to an operator-invoked offline utility that the running system never calls. - For the migration utility, if you identify it as a component or a product in its own right: the truthful status. If the utility parses files an attacker could plausibly place — a backup archive, an exported configuration, anything arriving from outside — then it is `affected` and it gets an action statement (upgrade before running it, or run it only on operator-supplied files from a trusted path). If the input is genuinely only ever hand-placed by an administrator, `vulnerable_code_cannot_be_controlled_by_adversary` is arguable, but you have just made a threat-model assumption on the customer's behalf, and that assumption belongs in a written impact statement where they can see it and disagree. Splitting like this is not evasion. It is what makes the document useful: the customer's scanner can honour the firmware statement and still route the utility one to a human, which is exactly the triage they need. ## What you owe alongside the statement - **A pointer to the assumption.** The label alone says "not on the execute path." The impact statement or status note is where you say *why* — offline utility, operator-invoked, not reachable from any listening service. A customer with a different operational model reads that and knows immediately whether your claim survives their deployment. - **A trigger for re-validation.** Contingent justifications go stale silently. Whatever process you have for release sign-off has to include "does this published not_affected still hold?" for the claims that depend on invocation patterns, or you will be defending a false statement in an audit two releases later. - **A version scope.** The claim is about the releases you name. Say which, rather than letting a reader assume it covers the whole product line. ## The instinct to take away Publish the strongest justification that is *true*, never the strongest that is *convenient*. Every label above the true one is a statement a customer can disprove using documents you handed them yourself, and the cost of that is not one reopened ticket — it is that your entire exploitability channel stops being believed, which is the only thing it was ever worth.