Software Composition Analysis
Software composition analysis identifies the third-party components in software and compares them with vulnerability and policy information. It helps you decide which component risks affect a specific product and release.
itOffensive security and application security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Software Composition Analysis
Software composition analysis, or SCA, is the disciplined business of finding the components inside software and asking what risks arrived with them. Modern software is not assembled from a single heroic pile of source code. Direct dependencies bring transitive dependencies. Builds add pieces. Containers, binaries, plugins, and runtime downloads arrive like guests who were not on the original invitation.
The first job is inventory. Give each component a name, version, and relationship. An SBOM, or software bill of materials, is the machine-processable record of that inventory. It is useful evidence, which is gratifying, but it is not a certificate of innocence. A list can be accurate and still tell you nothing about whether a component is vulnerable, reachable, or exposed.
Then comes the part that stops the scanner from becoming an oracle with excellent branding: triage. SCA can match a component identity against advisory and policy data. The match is evidence, not a verdict. Check that the package and affected version are correct. Check that it is in the released artifact. Then ask whether the application can execute the vulnerable behavior, whether an attacker can reach it, and what asset or privilege is involved.
That produces an action: update, remove, mitigate, or record a time-bounded exception with evidence, an owner, and a review date. The loop does not retire after one scan. New advisories, builds, and deployments alter the answer, which is mildly inconvenient but preferable to discovering your inventory was a historical novel.
SCA has boundaries. It does not replace source review, build integrity, provenance, signing, or incident response. It makes component risk visible so those controls have something concrete to work with. The intro explains the full loop and the difference between SCA and an SBOM. The slides compress the decisions. The cheatsheet keeps the finding and exception checklists nearby. The practice reference and exercise turn one image into an SBOM, a match, and an evidence packet.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://owasp.org/www-community/Component_Analysis
Supports
- Component analysis identifies potential risk from third-party and open-source components
- SCA is the software-only subset of component analysis
- Accurate component inventory is necessary for risk identification
- https://devguide.owasp.org/en/05-implementation/02-dependencies/01-dependency-check/
Supports
- Dependency-Check provides command-line SCA
- The tool identifies third-party libraries and checks known vulnerabilities
- https://www.cisa.gov/sites/default/files/2024-08/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_RECOMMENDED_PRACTICES_FOR_SOFTWARE_BILL_OF_MATERIALS_CONSUMPTION-508.pdf
Supports
- SBOM data supports software supply chain risk decisions
- SCA and scanning tools can verify SBOM accuracy and support vulnerability analysis
- Component relationships and inventory inform enterprise workflows
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- Secure development includes acquisition and maintenance of well-secured third-party components
- Vulnerability information requires assessment and remediation through the software lifecycle
- https://pages.nist.gov/nccoe-devsecops/notational-reference-model.html
Supports
- DevSecOps development practices can run SCA before source-control changes
- https://github.com/bureado/awesome-software-supply-chain-security
Supports
- Curated ecosystem entries include Syft, Grype, and OWASP Dependency-Track
- https://github.com/anchore/syft
Supports
- Syft generates software bills of materials from container images and other sources
- Syft supports CycloneDX JSON output
- https://github.com/anchore/grype
Supports
- Grype scans SBOM files for known vulnerabilities
- https://spdx.dev/about/overview/
Supports
- SPDX history includes releases from version 1.0 through version 3.0
- SPDX became ISO/IEC 5962 in 2021
- https://cyclonedx.org/about/history/
Supports
- CycloneDX history documents its 2018 initial release and later specification milestones
- https://owasp.org/blog/2023/01/10/Celebrating-10-years-of-Dependency-Track
Supports
- Dependency-Track began in 2013 and analyzes bill of materials data
- https://semgrep.dev/blog/2022/introducing-semgrep-supply-chain/
Supports
- Semgrep describes alert fatigue in dependency scanning and reachability analysis
- https://asankhaya.github.io/pdf/The-Dynamics-of-Software-Composition-Analysis.pdf
Supports
- Static call graph construction can create false positives and false negatives in SCA reachability analysis
- https://dependencytrack.org/
Supports
- Dependency-Track analyzes SBOMs and tracks component risk across projects
- https://snyk.io/product/open-source-security-management/
Supports
- Snyk provides open-source dependency security management
- https://www.mend.io/mend-sca/
Supports
- Mend provides software composition analysis workflows
- https://www.blackduck.com/software-composition-analysis.html
Supports
- Black Duck provides software composition analysis for open-source components
- https://www.sonatype.com/products/sonatype-lifecycle
Supports
- Sonatype Lifecycle applies component policy during development and delivery
- https://jfrog.com/help/r/jfrog-security-user-guide/jfrog-xray
Supports
- JFrog Xray provides artifact-focused security analysis
- https://github.com/security/advanced-security
Supports
- GitHub Advanced Security includes dependency security workflows