They break at the point where the declared dependency list diverges from the shipped artifact. Manifests miss transitive, pinned, or vendored components, and advisories often lag disclosure. The result is a false sense of certainty that cannot survive a challenge from an examiner, client, or incident reviewer.
Where manifest-based checks stop matching reality
Software exposure checks that rely only on manifests and advisories assume the declared dependency list is the same thing as the shipped artifact. That assumption fails as soon as build steps add transitive packages, vendored code, repackaged libraries, backported fixes, or embedded components that never appear cleanly in the manifest. The check still produces an answer, but the answer is no longer anchored to what is actually deployed.
Once that gap opens, the exposure workflow becomes more about documentation hygiene than software reality. A manifest can be accurate for procurement or build intent while still missing what is present at runtime, and an advisory can be technically correct while failing to reflect the exact version, packaging, or distribution path in use. That is why the resulting confidence often outpaces the underlying evidence.
Exposure review should therefore be treated as an artifact-verification problem, not just a list-matching exercise. For release managers, security reviewers, and incident responders, the important question is whether the check can still survive scrutiny against the binary, container image, or deployed package when the declared bill of materials is incomplete.
Why advisories and manifests fail together
Manifests and advisories fail in different ways, which is why using them alone creates blind spots instead of compensating controls. Manifests are only as complete as the build and packaging process that produced them, so they routinely miss nested dependencies, copied source, and components introduced after declaration. Advisories, meanwhile, depend on disclosure, naming, versioning, and matching rules that often lag the moment a weakness becomes exploitable.
Gravity SMTP CVE-2026-4020 API Keys Exposure is a good example of why declared inventories can miss the real exposure surface when shipped code or embedded secrets are not represented in the manifest. The State of NHI & AI Agent Breach Report 2026 shows the broader pattern that compromise often starts with what operators did not inventory correctly: leaked keys, stolen tokens, and other hidden access paths.
Practically, the weak point is the join between declared state and observed state. If your workflow trusts the manifest first and the artifact second, you can end up clearing software that still contains vulnerable code, or flagging software that was already remediated downstream. That mismatch is especially painful in audits, where the reviewer is not asking what your pipeline intended to ship, but what was actually present.
What a trustworthy exposure check has to verify
A reliable exposure check has to verify package provenance, artifact contents, and runtime composition, not just the top-level dependency file. That usually means comparing manifests with build outputs, lockfiles, container layers, SBOMs where available, and direct inspection of the deployed artifact. Without that second view, transitive dependencies and vendored code remain effectively invisible.
CISA cyber threat advisories are useful for understanding disclosed issues, but they do not replace a local view of what your software actually contains. NIST SP 800-53 Rev 5 Security and Privacy Controls supports the same operational conclusion: inventory, integrity, and continuous monitoring controls only help when they are tied to the real asset, not just the declared one.
Where teams get the most value is in treating manifest checks as one input to exposure analysis, then validating against the artifact before they conclude whether a finding is present, exploitable, or already remediated. That approach reduces both false negatives and the false confidence that comes from a clean-looking report with no artifact-level evidence behind it.
Risk and Threat Considerations
The risk is not only missed vulnerabilities, but missed trust in the entire review process. When the check cannot reconcile declared dependencies with the shipped artifact, attackers, auditors, and clients can all challenge the result, and the organisation may not be able to prove either coverage or absence of exposure.
Failure mechanism: The workflow trusts manifest and advisory matching even when the package graph is incomplete, stale, or materially different from the deployed binary, container, or vendored source.
Impact: Vulnerabilities remain undiscovered, remediation is misprioritised, and reviewers lose confidence in the exposure process because the evidence does not survive challenge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Exposure checks depend on trustworthy software inventory and validation. |
| Recommendation — Validate shipped software content against inventory before trusting exposure results. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Checks need an accurate component inventory to compare against actual artifacts. |
| SI-2 — Flaw Remediation | Advisories only help when flaws are tracked and remediated against the real asset. | |
| Recommendation — Maintain an accurate component inventory and reconcile it with deployed artifacts. Track flaws against the deployed software state and verify remediation at the artifact level. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Manifests missing embedded or vendored code reflect supply-chain and architecture verification gaps. |
| Recommendation — Verify build and packaging paths so shipped code matches declared dependencies. | ||
| SLSA | Supply chain integrity | Artifact provenance and build integrity are central when manifests diverge from shipped software. |
| Recommendation — Prove build provenance and artifact integrity before relying on exposure findings. | ||
Practitioner Guidance
What to verify: Check that your exposure method can reconcile manifest data with the actual shipped artifact, including lockfiles, build outputs, and any vendored or embedded code. If it cannot, treat the result as advisory only, not as a defensible exposure decision.
Decision rule: If the manifest and the artifact disagree, prioritise artifact inspection and provenance tracing before deciding whether the finding is real, already fixed, or still exploitable. The more the software is repackaged or assembled from multiple sources, the less you should trust manifest-only conclusions.
Practitioner takeaway: Exposure checks are only as strong as the evidence they can reconcile; if they cannot prove what was shipped, they can neither prove safety nor reliably prove vulnerability.
Related resources from NHI Mgmt Group
- What breaks when organisations rely only on static vulnerability checks for software supply chain security?
- What breaks when software inventories rely on manifests instead of source-built evidence?
- What breaks when teams rely on dependency checks without securing the rest of the software supply chain?
- What breaks when organisations rely on visual inspection alone for ID checks?