A newly disclosed vulnerability (CVE) affects a popular npm package. Your team doesn't use it directly, but it's buried several layers deep as a transitive dependency across dozens of services.
In Wiz's State of Code Security report, actions/setup-node appeared in roughly 78% of organizations, illustrating why software composition analysis (SCA) has become essential for understanding where vulnerable dependencies exist and which ones actually pose a risk.
What is software composition analysis, and why does it matter?
Software composition analysis (SCA) identifies the open-source components and third-party dependencies an application uses, then evaluates each one for security, licensing, and compliance risk.
Most cloud-native applications rely on hundreds or thousands of external libraries, placing much of their risk outside custom code.
SCA plays a distinct role in a broader DevSecOps and code security program. The table below compares it against other common testing techniques.
| Security technique | Primary focus | Purpose |
|---|---|---|
| SCA | Open source and third-party components | Identifies vulnerable or noncompliant dependencies |
| SAST (static application security testing) | Custom source code | Finds security flaws in proprietary code before build |
| DAST (dynamic application security testing) | Running applications | Detects exploitable vulnerabilities during execution |
| Secrets scanning | Source code and version control | Identifies exposed credentials and tokens |
| Container scanning | Container images and runtime artifacts | Surfaces vulnerabilities in base images and packaged software |
SAST, DAST, and container scanning examine how an application behaves or how your team writes custom code. SCA focuses instead on the risks introduced by reusing open-source software, a distinct challenge that grows as software supply chains become more complex.
SCA and AI-generated code
AI coding assistants introduce another layer of dependency risk. Because these tools predict likely package names rather than confirming that a package exists, they can recommend dependencies that were never published.
A 2025 USENIX study tested 16 code-generating models and found they referenced hallucinated, nonexistent package names in 19.6% of cases on average, with commercial models around 5% and open-source models closer to 21%.
Because of findings like these, development teams should use SCA to validate AI-suggested dependencies before they reach a manifest file.
How software composition analysis works
Effective SCA continuously discovers software components, analyzes them for risk, and enforces policy throughout the development lifecycle. Modern tools integrate with CI/CD pipelines to identify issues early and track risk from code to runtime.
The process generally follows three stages.
Discovery maps dependencies across source code, builds, and artifacts.
Analysis checks each component for known vulnerabilities, license conflicts, and supply chain risk.
Reporting surfaces findings and enforces policy so teams can prioritize remediation without slowing delivery.
Scanning methods for source code, containers, and binaries
SCA relies on three main scanning methods to cover the software supply chain.
Manifest scanning analyzes dependency manifest files (such as package.json, requirements.txt, and pom.xml) alongside lock files to identify open-source dependencies before they reach production.
Container image scanning analyzes container images to surface vulnerabilities in both application dependencies and the base image layers underneath them.
Binary scanning identifies components in compiled artifacts, including packaged AI models and inference binaries that aren't visible through manifest scanning. This helps identify dependencies packaged into AI models and build artifacts that traditional manifest scanning may miss.
Combining these methods with continuous monitoring gives security and development teams a consistent view of dependency risk as applications and AI workloads evolve.
Security risks that software composition analysis helps teams mitigate
Modern applications depend heavily on open-source libraries and third-party components. SCA helps teams manage the resulting software supply chain risks.
Vulnerability detection in third-party dependencies: SCA detects known vulnerabilities in open source and transitive dependencies so teams can prioritize upgrades or replacements as part of a broader vulnerability management practice, reducing time spent investigating false positives. AppSec teams typically guide that prioritization while development teams handle remediation.
Outdated or unmaintained components: SCA flags libraries that no longer receive security updates, increasing risk over time. Development teams usually own the upgrade or refactor work, with security teams weighing in on severity.
Software supply chain attacks: By checking package metadata and version history, SCA flags unexpected sources or abrupt changes that can signal an attacker has compromised a repository or pipeline, as seen in the Shai-Hulud 2.0 npm campaign, which affected more than 25,000 GitHub repositories. Incident response teams typically lead the response, working closely with CloudSec and engineering.
Lack of visibility into software composition: SCA solves this by generating and maintaining a software bill of materials (SBOM) that gives teams a reliable inventory of every component in use, supporting faster decisions, audits, and governance.
Zero-day and newly disclosed vulnerabilities: When a public zero-day surfaces, SCA lets teams search quickly across repositories and binaries to find every affected component. SecOps teams typically coordinate the response while development teams apply the fix.
License compliance and legal exposure
License compliance carries legal exposure, not just policy risk. SCA identifies the open source license attached to each dependency and flags conflicts, such as copyleft licenses in proprietary code, before software ships.
Finance and healthcare organizations often face contractual, regulatory, and disclosure obligations, making license compliance especially important. A single noncompliant dependency can trigger audit findings or contractual issues.
Legal and governance teams typically define license policies, while security teams enforce them through automated checks in the software development lifecycle (SDLC).
How to evaluate a software composition analysis approach
Modern environments span multiple clouds, languages, repositories, and CI/CD pipelines, so an effective SCA approach should fit naturally into developer workflows while managing that complexity. Look for the following capabilities.
Accurate SBOM generation in a widely accepted format like SPDX (Software Package Data Exchange) or CycloneDX, covering source code, build artifacts, container images, and deployed workloads.
Automated vulnerability scanning that continuously correlates dependencies against trusted sources such as the National Vulnerability Database (NVD) and vendor advisories, enriched with severity, exploitability, and runtime context. Some platforms also use machine learning to reduce false positives.
License compliance detection that flags policy conflicts early and suggests alternative packages or a legal review before code reaches production.
Actionable remediation guidance surfaced directly in developer workflows, including recommended upgrades, patched versions, or safe alternatives.
Reachability analysis and runtime context
Reachability analysis confirms whether an application actually invokes a vulnerable code path at runtime, instead of flagging every library version match and generating false positives. That helps teams focus on vulnerabilities that are actually exploitable rather than every dependency match.
Wiz, for example, connects SCA findings to whether a vulnerable component is actually running in a cloud workload, combining source code, container image, and binary scanning with runtime context so teams prioritize real exposure instead of noise.
CI/CD integration and developer workflow fit
Adoption depends on how well SCA fits existing developer workflows. The strongest approaches surface findings directly in pull requests and IDEs (integrated development environments), alongside secrets detection, so developers can remediate dependency risks while code is still fresh.
Effective policies favor guardrails over rigid gates. For example, a pipeline might block a build only for a critical, actively exploited vulnerability while letting lower-risk issues pass with a warning, helping teams enforce security without slowing development.
How Wiz approaches software composition analysis
Software composition analysis is most effective when dependency findings are connected to the cloud environments where applications actually run.
Wiz extends SCA beyond identifying vulnerable components by adding the runtime context needed to distinguish the vulnerabilities that require immediate attention from those that can be deprioritized.
Connecting SCA findings to cloud runtime exposure
The Wiz Security Graph connects code-level findings to deployed workloads by correlating software dependencies with runtime exposure, cloud identities, misconfigurations, and attack paths.
Rather than treating every vulnerable dependency as equally urgent, teams can see whether a component is running in a production workload, exposed to the internet, or unlikely to be exploitable in its current context. That's one reason more than 50% of the Fortune 100 use Wiz to help prioritize cloud risk at scale.
SCA as part of Wiz's CNAPP
Software composition analysis is built into Wiz Code and works alongside Wiz Cloud and Wiz Defend as part of Wiz's Cloud Native Application Protection Platform (CNAPP). Together, these capabilities provide continuous visibility from source code and build pipelines through cloud infrastructure and runtime.
By correlating code, cloud, and runtime findings in a single platform, Wiz helps security and development teams prioritize dependency risk throughout the software development lifecycle.
Want to understand where dependency risk exists across your own cloud environment? Try Wiz's cloud security assessment to see how code-level findings map to runtime exposure.
How to get started with software composition analysis
These practices help teams build an SCA program that scales with development and connects dependency risk to real cloud exposure.
1. Integrate SCA into your CI/CD pipeline
Scanning dependency manifests and lock files as soon as code enters version control catches risky packages before they spread across services. CI/CD pipelines provide a natural enforcement point, allowing automated scans at the pull request and build stages to identify vulnerabilities, license issues, and unapproved dependencies before code merges.
Guardrails work better than rigid gates. Blocking builds only for critical, exploitable issues while letting lower-risk findings through with a warning supports a shift-left approach without slowing development.
2. Generate and maintain SBOMs for every build
Generating an SBOM for every build creates a consistent, auditable record of what shipped and when. Automated generation removes manual effort and keeps the record accurate, and platforms like Wiz extend SBOM coverage beyond source code to what actually runs in your cloud environment.
That inventory also supports incident response, allowing teams to quickly determine whether a newly disclosed CVE affects production instead of manually searching repositories and build artifacts.
3. Prioritize findings using runtime context
Raw SCA findings can overwhelm teams with volume, but prioritization turns that information into actionable decisions. Prioritizing severity, exploitability, and exposure delivers more value than counting vulnerabilities because a critical CVE in a public-facing workload needs immediate attention while a medium-severity issue in unused code can wait.
The Wiz Security Graph adds runtime context automatically, helping teams focus remediation where risk is highest.
4. Build governance around SCA findings
SCA succeeds long-term only with shared ownership across security, development, and platform teams.
Clear governance defines who sets severity thresholds and license policy, who triages incoming findings, and who owns remediation when a fix spans multiple services.
Regular policy reviews matter too, since a new language, framework, or AI coding tool can introduce scanning gaps that last quarter's policy didn't anticipate.
Tracking metrics like time to remediate keeps the program accountable.
