Software composition analysis is now core to application risk

At a glance

What this is: Software composition analysis scans source code and software artifacts to identify open source and third-party components, then builds an SBOM and flags known vulnerabilities and licensing issues.

Why it matters: It matters because modern application risk often sits in dependencies the team did not write, so AppSec, DevOps, and compliance teams need continuous visibility into what is actually shipping.

Context

Software composition analysis is the practice of inventorying third-party software inside an application so teams can see what they depend on and whether it is safe to ship. The control exists because dependency sprawl, transitive libraries, and fast-moving build pipelines make manual review unreliable at modern development speed.

For identity and governance teams, the relevance is indirect but real: software supply chain risk often becomes access, trust, and assurance risk once packages are allowed into build systems and release pipelines. This article is about application security first, but the governance question is the same one that appears in NHI and agentic AI programmes: what is trusted, on what basis, and for how long?

Key questions

Q: What breaks when software composition analysis does not identify all dependencies accurately?

A: When SCA misses components, security teams can receive an incomplete bill of materials and underestimate exposure. That creates blind spots in vulnerability management, license compliance, and remediation planning. Manual tracking may still be needed for specialized or less common libraries, especially when scanners cannot recognize files, subdependencies, or code copied from outside sources.

Q: Why do vulnerable open source components create application risk?

A: They create risk because third-party code inherits the trust of the application even when the team did not author it. If a vulnerable package is loaded at runtime or reachable from application paths, an attacker can use that weakness to compromise the app, steal data, or affect the build chain. The risk rises when dependency inventories are stale or incomplete.

Q: How do you know if SCA is actually working?

A: SCA is working when the SBOM stays current, vulnerable dependencies are identified before release, and findings are prioritised by exploitability rather than volume. If scans only generate long static reports, or if dependency changes outpace the inventory, the control is not delivering decision value. Effective SCA should shorten the time between dependency change and security action.

Q: How should security teams decide between SAST and SCA?

A: Use SAST for code your organisation wrote and SCA for software it imported. If the application has both custom logic and third-party packages, you need both controls because they answer different questions. The correct decision model is coverage, not replacement, especially when runtime exposure and privilege change the impact of each finding.

Technical breakdown

How SCA builds a software inventory from code and artifacts

Software composition analysis works by comparing source code and packaged artifacts against component and vulnerability databases such as the NVD. It identifies direct dependencies, transitive dependencies, version metadata, and license information, then assembles that into an SBOM. The important point is that the SBOM is not just a document for auditors. In practice, it is the control surface that lets teams answer what is in the build, where it came from, and whether a known weakness is present in the shipped artifact.

Practical implication: run SCA against both source and build outputs so the inventory reflects what will actually ship.

Why vulnerability reachability changes SCA triage

A dependency match alone does not tell you whether the risk is exploitable. More mature SCA tools check whether the vulnerable library is loaded at runtime, whether the affected function is reachable, and whether a safe upgrade exists. That separates theoretical exposure from present exposure and reduces alert fatigue. It also helps teams prioritise remediation based on exploitability rather than raw vulnerability counts, which is the only way SCA remains usable at scale across large codebases and fast release cycles.

Practical implication: rank dependency findings by runtime exposure and reachable code paths, not by CVE count alone.

How continuous monitoring keeps SBOMs useful

An SBOM becomes stale as soon as code changes, package versions drift, or build processes shift. Continuous monitoring keeps the component inventory current by rescanning commits, builds, and deployments so teams can see new exposure as soon as it appears. That matters operationally because modern software risk is temporal: a clean build today can become vulnerable after a package update tomorrow. Continuous SCA turns the SBOM from a snapshot into an ongoing control over software change.

Practical implication: tie SCA to CI/CD events so dependency risk is updated whenever the software changes.

Threat narrative

Attacker objective: The attacker aims to turn trusted software dependencies into a path for code execution, data access, or wider supply chain compromise.

1. Entry occurs when a vulnerable or compromised open source component enters the codebase, package tree, or build artifact.
2. Credential or control abuse follows when the dependency’s weakness gives attackers a path to execute malicious code, expose sensitive data, or manipulate the build pipeline.
3. Impact is realised when the vulnerable software is shipped and used in production, creating application exposure, audit gaps, and possible downstream compromise.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dependency visibility is now a governance control, not a tooling feature. Once open source components are embedded across build pipelines, the question is no longer whether teams can scan them, but whether they can maintain trustworthy inventory and decision-making over time. That is why SCA belongs in application governance alongside vulnerability management and release approval. Practitioners should treat the SBOM as a control object, not a report artifact.

Software composition analysis closes the gap between code ownership and risk ownership. Teams do not write most third-party dependencies, yet they inherit the security and compliance consequences when those packages enter production. This creates a governance burden that spans engineering, AppSec, legal, and release management. The practical conclusion is that dependency risk has to be owned where software change is approved, not after the fact.

Runtime context is what separates useful SCA from noise. A list of vulnerable packages does not tell you which risks matter first, especially in large codebases with transitive dependencies. When SCA evaluates runtime loading and reachability, it becomes a prioritisation control rather than a volume generator. Practitioners should use that distinction to reduce false positives and keep remediation focused on exploitable exposure.

Open source dependency drift is a supply chain version of posture drift. The underlying problem is that the software base changes faster than many teams update their records, policies, and mitigation decisions. That creates a persistent mismatch between what security teams think is in the build and what is actually deployed. Practitioners should treat continuous dependency monitoring as an operational requirement, not a periodic hygiene task.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Dependency visibility is becoming a release-governance problem. As build pipelines absorb more third-party code, the security question shifts from whether a scanner exists to whether the organisation can keep an accurate software inventory at the speed of change. That is why SBOM quality matters as much as vulnerability detection for release confidence.

Open source supply chain risk and identity governance intersect at trust boundaries. The same governance logic that applies to NHI inventory and lifecycle control applies to packages, build artefacts, and pipeline inputs. When trust is not explicitly bounded, software change becomes a standing exposure instead of a controlled event.

Software composition analysis should be treated as a change-control signal, not a compliance afterthought. The operational goal is to know when dependency drift creates a new security decision, then route that decision to the team that owns the release. In practice, that means SCA has to sit inside CI/CD rather than behind it.

For practitioners

• Instrument SCA at every build stage Run scans at commit, build, and deployment points so the SBOM updates as dependencies and artifacts change.
• Triage findings by runtime reachability Prioritise vulnerable components that are actually loaded at runtime or reachable from application paths instead of treating every CVE equally.
• Maintain an auditable SBOM baseline Keep a current component inventory that records version, origin, and license data for every shipped application release.
• Align remediation with disclosed vulnerabilities Use SCA alerts to quickly identify which applications carry newly disclosed component risk and assign fixes before business teams lose track of exposure.

Key takeaways

• Software composition analysis is now part of application governance because dependency inventories, SBOMs, and vulnerability data have to stay aligned as code changes.
• The core operational problem is not just finding open source components, but distinguishing exploitable dependency exposure from theoretical noise.
• Teams that embed SCA into CI/CD and pair it with runtime context can reduce release risk without slowing development.

Key terms

• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.

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 practitioners connect identity control to the broader security decisions their programmes depend on.