## TL;DR
"Not present" is a strong claim and vendored code is how it goes wrong: the component is there, just under a different directory or package name. Withdraw the bad statement, re-triage the CVE, and require every future not_affected to cite positive absence evidence covering vendored dirs, renamed forks, and statically linked copies.

```text
the agent's VEX statement said "not_affected" with justification "component_not_present" but the component was vendored under a different name
```

## Use this when
- A not_affected VEX statement exists but the component is found vendored, renamed, or statically linked.
- Auditors or customers question a component_not_present justification.
- The SBOM and the actual artifact disagree about what is inside.

## Not for this skill when
- The component is genuinely absent and you can prove it. Then the statement stands; this skill is about the proof bar.
- The VEX status is "affected" or "fixed". Those have different evidence rules.

## Steps
1. Withdraw or supersede the incorrect VEX statement immediately; a wrong not_affected is worse than no statement. Verify: consumers of the VEX document see the corrected status.
2. Search the artifact properly: vendored directories, renamed packages, static linking, bundled copies. Verify: you find the vendored copy and can name its path.
3. Re-triage the CVE against the vendored copy: is the vulnerable code reachable, and is the vendored version in the affected range? Verify: the new verdict cites the vendored path as evidence.
4. Set the evidence bar: every not_affected with component_not_present must link the SBOM plus the vendored-dir search results. Verify: a new statement without evidence is rejected by review.
5. Audit the other not_affected statements from the same agent run; the same blind spot likely produced more. Verify: the audit lists each statement with its evidence or a re-triage ticket.

## Variant phrasings
### VEX not_affected component vendored
The short phrasing.
### component_not_present wrong
The justification phrasing.
### VEX statement vendored dependency missed
The cause phrasing.

Compatibility: CycloneDX and SPDX VEX; the evidence bar is format-independent.

## Why it happens
The agent checked the package manifest, did not find the component name, and concluded absence. Vendored code never appears in manifests under its upstream name, so the check was structurally incapable of finding it. Absence of a manifest entry is not absence of the code.

## Edge cases / pitfalls
- Renamed forks are the hardest case: the code is present but the name gives no hint. Content hashing or known-file signatures beat name matching.
- Statically linked libraries leave no runtime dependency trace; check build inputs and linker maps, not just the final artifact's manifest.
- A corrected statement needs a new revision, not a silent edit; VEX consumers cache, so version the document.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LJFORcrhnZa_r4lwcvt3nQ