Why software exposure answers now require source-built evidence

At a glance

What this is: This analysis says software exposure questions are becoming harder to answer because disclosure-to-exploitation windows are collapsing faster than declaration-based tooling can keep up.

Why it matters: That matters to IAM and broader security programmes because inventory, accountability, and proof of remediation now need source-built evidence, not assumptions, especially where software dependencies intersect with identity, access, and control boundaries.

By the numbers:

• Cembalest puts the median time between vulnerability disclosure and first confirmed exploitation at one day in 2026, down from roughly a year in 2021.
• The report says 95% of open source vulnerabilities live in the transitive dependency layer.
• Only 26% of vulnerabilities on the CISA KEV list were fully remediated last year, according to the report.
• 45% of KEV-listed vulnerabilities remain unpatched after a, npatched after a full year.

👉 Read Kusari's analysis of why software exposure now requires source-built evidence

Context

Software exposure management fails when teams rely on declarations instead of evidence. A manifest tells you what code was supposed to be present, but not what was actually resolved, vendored, pinned, or hidden in transitive layers. In regulated environments, that gap turns a technical question into an accountability problem because examiners, allocators, and boards want a defensible answer, not an approximation.

The primary identity security implication is that modern software inventories increasingly overlap with workload identity, secrets exposure, and access governance. If teams cannot prove what is in an application, they also struggle to prove what credentials, tokens, services, and dependencies can reach it. That makes source-built inventory a control issue, not just a developer tooling issue.

Key questions

Q: What breaks when software inventories rely on manifests instead of source-built evidence?

A: Manifests capture intent, not reality. They miss transitive dependencies, vendored code, pinned revisions, and anything introduced outside the declared file, so the inventory can look complete while still missing the vulnerable component that matters. That creates false confidence and slows exposure response when proof is needed.

Q: Why do disclosure-based vulnerability workflows fail so often in regulated environments?

A: They assume advisories will exist and arrive quickly enough to guide action. In practice, many findings never make it into public advisory feeds, and exploitation can begin before a published record appears. That leaves security teams with an evidence gap at exactly the moment they need a defensible answer.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

Q: How do security teams prove software is trustworthy to auditors and boards?

A: They need evidence beyond scanner output: approved provenance, continuous verification, remediation timelines, and enforceable policy gates. Trust is demonstrated by showing how code was introduced, how it was reviewed, how quickly defects were closed, and whether the production state still matches the approved one.

Technical breakdown

Why manifest-based software inventories fail under real exposure pressure

Manifest-based inventory reads declared dependencies rather than the software that was actually built and deployed. That leaves blind spots for transitive packages, vendored code, pinned commits, and dependencies introduced outside the manifest. Advisory-fed scanners then inherit a second limit because they can only match what has been disclosed publicly. The result is a system that often answers a different question than the one security leaders are asked after a vulnerability lands.

Practical implication: build inventory from source and build outputs, not from declarations alone.

How source-built graphs change remediation and exposure proof

A source-built graph resolves dependencies from the code as it is compiled or packaged, so it can show what is present, where it came from, and whether the application actually reaches it. That matters because reachability determines whether a vulnerable library is exposure or just inventory noise. When teams add confidence markers and a stated reason for exclusion, they create evidence that survives challenge from audit, legal, or risk teams.

Practical implication: attach provenance and reachability evidence to every removal from the remediation queue.

Why advisory feeds lag the reality of exploitation

Advisory pipelines are structurally slower than attacker behaviour. New vulnerabilities may be discovered, reported, acknowledged, patched upstream, and finally published as advisories only after the exploitation window has narrowed or closed. If a security programme waits for an advisory before acting, it is already behind the attacker and often behind the regulator or examiner as well. This is why the control question shifts from 'do we scan?' to 'can we prove exposure and remediation now?'

Practical implication: treat advisory feeds as one input, not the source of truth for exposure decisions.

Threat narrative

Attacker objective: Exploit a vulnerable software path before defenders can produce a defensible exposure answer or remediation record.

1. Entry occurs when attackers target vulnerable software before teams can verify whether the affected package is actually present or reachable in their environment.
2. Escalation follows when transitive dependencies, stale components, or untracked build inputs expand the blast radius beyond what manifest-based tools can see.
3. Impact arrives when organisations cannot prove exposure status, remediation history, or dependency provenance fast enough to satisfy examiners, boards, or customers.

NHI Mgmt Group analysis

Source-built evidence is becoming the new baseline for software exposure governance. Declaration-based inventories no longer match the speed or structure of modern exploitation. When vulnerability windows shrink to days or hours, the question is not whether a scanner exists but whether the organisation can prove what was actually shipped. Practitioners should treat evidence quality as the control, not a reporting afterthought.

Blind spots in software inventories now overlap with identity and secrets risk. If a team cannot enumerate what is in an application, it also struggles to govern the credentials, tokens, certificates, and service identities that application consumes. That creates an NHI governance problem inside what looks like a software supply chain problem. The right framing is provenance plus privilege, because unresolved dependencies often travel with unresolved access.

Patch velocity matters less when exposure provenance is incomplete. Many programmes still optimise for how fast they can apply a fix, but the harder problem is proving whether the fix addressed the right component. In regulated environments, defensible exposure management requires source traceability, reachability analysis, and reconstruction of why a component was removed from scope. Security leaders should expect auditors to ask for evidence, not intent.

Regulators are forcing a shift from inventory policy to inventory proof. The article’s core point is not just that disclosure is faster. It is that the burden of proof now sits with the organisation, whether the question comes from an examiner, allocator, or customer due diligence request. That makes software exposure management a governance discipline, not a tooling preference. Teams should align their operating model with evidence retention, not spreadsheet reconciliation.

Dependency sprawl is now a named governance debt. Modern software stacks contain so many indirect components that no human review process can track them reliably at scale. This is the same structural pattern identity teams see in NHI sprawl: control quality collapses when the estate grows faster than the governance model. The practical conclusion is simple. If the organisation cannot explain the estate, it cannot defend the estate.

What this signals

Source-built software governance will increasingly look like identity governance. As estates grow, the hardest problem is no longer detecting individual weaknesses but proving ownership, provenance, and scope across every component that can execute or consume access. That is why software inventory discipline now belongs alongside NHI lifecycle management, secrets governance, and workload identity controls.

Dependency sprawl is a governance debt, not just a supply-chain headache. The operational lesson for security leaders is to stop treating inventory as a periodic reporting exercise and start treating it as a continuously verifiable control. Where identity programmes already depend on asset accuracy, the same logic now applies to applications, packages, and the credentials they carry.

Provenance, not patch speed, will define mature exposure management. Organisations that can show where each component came from, whether it is reachable, and how remediation was validated will move faster under pressure than teams that only track backlog counts. That is the practical control shift the market is moving toward, and it aligns closely with the evidence-first model used in identity assurance.

For practitioners

• Implement source-built software inventory Resolve dependencies from build and source outputs so the inventory reflects what was actually shipped, including transitive and vendored components, not just what manifests declared.
• Tag every unresolved dependency explicitly Mark incomplete resolution, unknown components, and ambiguous provenance as first-class states so teams can see where the inventory boundary ends and where confidence drops.
• Attach reachability evidence to triage decisions Remove a vulnerable component from the remediation queue only when the code path, call graph, or package reachability is documented and reproducible.
• Preserve remediation provenance for audit Keep the rationale, build evidence, and verification history for every exposure decision so a later examiner can reconstruct why the issue was or was not treated as in scope.
• Map software inventory to identity-adjacent assets Include service accounts, tokens, certificates, and other credentials that live inside or alongside the application so software evidence and access evidence stay aligned.

Key takeaways

• Software exposure management is shifting from declaration-based scanning to source-built proof of what actually shipped.
• The scale of transitive dependencies and advisory lag means attackers can exploit gaps before many teams can answer basic exposure questions.
• Security leaders should treat provenance, reachability, and remediation evidence as core controls, not post-incident reporting artefacts.

Key terms

• Source-built inventory: An inventory produced from source code, build artefacts, or deployment outputs rather than from declared manifests alone. It shows what software was actually assembled and shipped, which is essential when dependency trees, vendored code, or pinned versions make declarations incomplete.
• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.
• Remediation evidence: Remediation evidence is the record that shows an access issue was identified and corrected. It usually includes the reviewer, the decision, the change request, and the completed revocation or adjustment, which allows auditors to verify that the control actually closed the gap.

What's in the full article

Kusari's full analysis covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of how source-built dependency graphs are generated from build artefacts and code.
• Operational examples of reachability-based triage and why some vulnerable components can be removed from scope with evidence.
• The compliance mapping behind DORA, PCI DSS 4.0, NYDFS, CISA SBOM elements, and the EU Cyber Resilience Act.
• Examples of how examiners, allocators, and board requests translate into evidence and remediation timelines.

👉 Kusari's full post covers the dependency graph, disclosure timing, and remediation proof model in more depth.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader assurance and evidence model their programmes depend on.