What Is SCA?
What Software Composition Analysis is, how it identifies third-party components and evaluates associated vulnerability and license information, and where its conclusions end.
Primary question: What is Software Composition Analysis, and how does it identify and evaluate software components?
Direct answer
SCA identifies software components and evaluates the known risks associated with them
SCA identifies third-party and open-source components in software and evaluates the identified components against known vulnerability, license, and supply-chain information. [owasp-component-analysis][derscanner-sca]
An SCA result establishes component identity and associated known-risk evidence; it does not by itself prove that vulnerable functionality is reachable or exploitable in the application. [cisa-sbom][derscanner-hybrid]
Definitions
Software Composition Analysis (SCA)
Analysis that identifies third-party and open-source software components and evaluates associated vulnerability, license, and supply-chain information.
Component identity
Evidence used to distinguish a software component, such as its name, version, supplier, package coordinates, hash, and dependency relationship.
Component risk finding
A reported association between an identified component and relevant vulnerability, license, or supply-chain information that requires contextual review.
The engineering problem
Software can inherit known vulnerabilities and license obligations from third-party components even when the application's proprietary code does not contain the underlying defect. [owasp-component-analysis][nist-ssdf]
An incomplete or inaccurate component inventory makes it difficult to determine whether newly disclosed component vulnerabilities affect an application. [cisa-sbom][nist-ssdf]
A component-level vulnerability association can be overinterpreted when teams do not separately assess version accuracy, application usage, reachability, and environmental context. [cisa-sbom][derscanner-hybrid]
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Component identification
Software Component Identification- Artifact
- Dependency manifests, lockfiles, resolved packages, source archives, binaries, repositories, or supplied SBOM data supported by the analyzer.
- Risk
- Components remain unknown or are attributed to the wrong package or version.
- Output
- A component inventory with identity, version, supplier, and dependency information where available.
Evidence: OWASP Component AnalysisCISA Software Bill of MaterialsDerScanner software composition analysis documentation
Component risk matching
Software Composition Analysis- Artifact
- Identified components correlated with vulnerability records, license data, and supported supply-chain indicators.
- Risk
- Known component vulnerabilities, license conditions, or supply-chain indicators are not surfaced for review.
- Output
- Component-level findings with the matched risk information and supporting component identity.
Evidence: OWASP Component AnalysisDerScanner software composition analysis documentation
Contextual component triage
Component Risk Validation- Artifact
- SCA findings together with dependency usage, reachability, deployment, and compensating-control evidence.
- Risk
- A component association is mistaken for proof of application exploitability or dismissed without adequate context.
- Output
- A documented disposition and remediation priority for each material component finding.
Evidence: NIST Secure Software Development FrameworkDerScanner hybrid SAST and SCA scan documentation
Verification workflow
- Select the software revision and dependency inputs to assess.
- Resolve or collect component evidence using the package ecosystems and artifact types supported by the analyzer.
- Identify components and retain an inventory or SBOM for the analyzed revision.
- Correlate identified components with current vulnerability, license, and supply-chain information.
- Validate material findings against version, usage, reachability, and deployment context.
- Update, replace, remove, or otherwise mitigate confirmed component risks.
- Re-run SCA and retain the result with the release evidence.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides software-composition analysis and a separate hybrid SAST and SCA mode for documented component-risk and reachability workflows.
DerScanner SCA identifies dependencies and evaluates documented vulnerability, software-supply-chain, and license risks. [derscanner-sca]
DerScanner documents hybrid SAST and SCA analysis for correlating supported dependency findings with application code usage. [derscanner-hybrid]
Limits of verification
- Identification coverage depends on the package ecosystem, artifact type, resolver, and analyzer support.
- Vulnerability and license conclusions depend on the accuracy and freshness of component identity and external data.
- A component's presence does not by itself prove that vulnerable functionality is reachable or exploitable.
- SCA does not replace analysis of security weaknesses in proprietary application logic.
- An SBOM is an inventory artifact and should not be treated as equivalent to a completed risk assessment.
Related knowledge
SAST vs SCA
How component-risk analysis differs from source-code analysis
Relationship: related-toSBOM vs SCA vs Hybrid Analysis
Distinguish component inventory, component-risk evaluation, and code-level reachability evidence
Relationship: related-toHybrid SAST + SCA Analysis
Add supported code-usage evidence to component findings
Relationship: related-toDerScanner
Product line providing SCA and hybrid analysis capabilities
Relationship: related-toCanonical terms used: Software Composition Analysis; SCA; component identification; component risk; software dependency; Software Bill of Materials.
Evidence and references
- OWASP Component AnalysisComponent analysis identifies potential cyber-supply-chain risk from third-party and open-source components, and describes SCA as its software-focused subset.
owasp-component-analysis - CISA Software Bill of MaterialsAn SBOM is a nested inventory of software components; CISA distinguishes inventory from separate vulnerability-affectedness information such as VEX.
cisa-sbom - NIST Secure Software Development FrameworkSecure software practices include maintaining provenance for components, reviewing reused software, remediating vulnerabilities, and retaining evidence.
nist-ssdf - DerScanner software composition analysis documentationDerScanner documents dependency identification and analysis of component vulnerabilities, software-supply-chain indicators, and license risks.
derscanner-sca - DerScanner hybrid SAST and SCA scan documentationDerScanner documents hybrid analysis for supported code-level dependency reachability conditions and its limitations.
derscanner-hybrid
Identify and assess dependencies