Software Composition Analysis and Open Source

Why This Topic Matters
Modern applications are assembled more than they are written. Industry studies consistently show that 70–90% of the code in a typical application is open source or third-party components pulled in through package managers such as npm, Maven, PyPI, NuGet, and Go modules. Every one of those components carries its own vulnerabilities, license obligations, and maintenance risks. High-profile incidents such as Equifax (an unpatched Apache Struts library), Log4Shell (CVE-2021-44228 in Log4j), the event-stream and ua-parser-js npm hijacks, and the protestware incidents in 2022 have made it clear that the software supply chain is a primary attack surface. The CSSLP exam places Software Composition Analysis (SCA) within Domain 5: Secure Software Implementation, alongside secure coding practices, SAST, DAST, and build security, and also links it to Domain 7 (Supply Chain) and Domain 3 (Requirements, for license and policy requirements). Expect questions that test whether you understand what SCA finds, where it fits in the SDLC, how it differs from other testing types, and how to govern open source use responsibly.

What Is Software Composition Analysis?
Software Composition Analysis is an automated process that identifies the open source and third-party components present in a codebase or binary, and then evaluates those components for:
1. Known security vulnerabilities – matching component versions against databases such as the National Vulnerability Database (NVD), GitHub Advisory Database, OSV, Snyk, Sonatype, and vendor advisories, typically referenced by CVE identifiers and scored with CVSS.
2. License compliance – identifying each component's license (MIT, Apache 2.0, BSD, GPL, LGPL, AGPL, MPL, etc.) and flagging licenses that conflict with organizational policy or the product's distribution model.
3. Operational and quality risk – component age, end-of-life status, abandoned projects, number of maintainers, release frequency, and known malicious packages.
4. Inventory and transparency – generating a Software Bill of Materials (SBOM) that lists every component, version, supplier, and dependency relationship.

SCA is sometimes called Origin Analysis or Dependency Analysis. The key distinction to remember for the exam: SAST analyzes the code you write for coding flaws; DAST tests the running application from the outside; SCA analyzes the code you didn't write – the third-party and open source components – for known issues.

Key Terminology
Direct dependency – a library your code explicitly declares (e.g., listed in package.json or pom.xml).
Transitive dependency – a library pulled in by one of your dependencies, often several levels deep. Most vulnerable components in real applications are transitive, and developers are often unaware of them. Log4j was frequently a transitive dependency.
Dependency tree / graph – the full hierarchy of direct and transitive dependencies.
SBOM (Software Bill of Materials) – a formal, machine-readable inventory of components. Common formats are SPDX (Linux Foundation, ISO/IEC 5962) and CycloneDX (OWASP). US Executive Order 14028 (2021) and NTIA minimum elements made SBOMs a federal procurement expectation.
VEX (Vulnerability Exploitability eXchange) – a companion document to an SBOM stating whether a given vulnerability actually affects a product (e.g., "not affected because the vulnerable function is not called").
CVE – Common Vulnerabilities and Exposures, a unique identifier for a publicly known vulnerability. CWE – Common Weakness Enumeration, a category of weakness type. CVSS – Common Vulnerability Scoring System, the severity score (0–10). CPE – Common Platform Enumeration, the naming scheme used to match products to CVEs. Package URL (purl) – a standardized identifier for packages across ecosystems, used by CycloneDX.
EPSS – Exploit Prediction Scoring System, estimating probability of exploitation in the wild; used to prioritize alongside CVSS. KEV – CISA's Known Exploited Vulnerabilities catalog.
Reachability analysis – determining whether the vulnerable code path in a library is actually invoked by your application, reducing false positives.
Typosquatting – publishing a malicious package with a name similar to a popular one (e.g., "crossenv" vs "cross-env").
Dependency confusion – tricking a build system into pulling a public package with the same name as an internal private package but a higher version number.
Lockfile / pinning – fixing exact dependency versions (package-lock.json, Pipfile.lock, Gemfile.lock) so builds are reproducible and not silently upgraded.
Copyleft vs. permissive licenses – permissive licenses (MIT, BSD, Apache 2.0) impose minimal obligations; strong copyleft (GPL, AGPL) requires derivative works to be released under the same license, which can conflict with proprietary distribution. LGPL is weak copyleft, generally allowing dynamic linking without infecting the whole product. AGPL extends copyleft obligations to software accessed over a network (SaaS).

How SCA Works
Step 1 – Discovery and identification. The tool scans one or more sources: manifest files (package.json, requirements.txt, pom.xml, build.gradle, Gemfile, go.mod, .csproj), lockfiles, source code, compiled binaries, container images, and even file hashes or code snippets ("fingerprinting") to detect copy-pasted open source code. Binary analysis is important when source isn't available or when you receive vendor-supplied artifacts.

Step 2 – Dependency resolution. The tool builds the full dependency graph, including transitive dependencies, and records exact versions.

Step 3 – Matching against intelligence feeds. Each component and version is matched against vulnerability databases (NVD, GHSA, OSV, vendor proprietary research), license databases, and malicious-package feeds. Good tools also curate data to fix the frequent inaccuracies in raw NVD CPE matching.

Step 4 – Risk analysis and prioritization. Findings are scored using CVSS, enriched with EPSS/KEV exploitability data, reachability analysis, and the component's context (is it in production code or just a dev/test dependency?). License findings are evaluated against policy (e.g., "no AGPL in distributed products").

Step 5 – Policy enforcement. Policies-as-code define what breaks a build: e.g., fail on any CVSS ≥ 7.0 with a fix available, fail on any copyleft license in a shipped product, warn on components with no releases in 24 months. Enforcement can occur in the IDE, pre-commit, pull request, CI build, artifact repository (quarantine), and container registry admission.

Step 6 – Remediation. Options include upgrading to a patched version, applying a vendor patch or backport, replacing the component, removing unused dependencies, applying compensating controls (WAF rules, configuration changes such as disabling JNDI lookups), or formally accepting the risk with documented justification and expiry. Many tools auto-generate pull requests (Dependabot, Renovate, Snyk).

Step 7 – Continuous monitoring. A component safe today may have a CVE disclosed tomorrow. SCA must re-evaluate deployed SBOMs continuously, not just at build time. This is the critical difference between point-in-time scanning and ongoing supply chain monitoring.

Step 8 – Reporting and SBOM generation. Produce SBOMs per release, store them with the artifact, and make them available to customers and regulators as required.

Where SCA Fits in the SDLC and DevSecOps Pipeline
Requirements/Design: Define open source policy, approved license list, approved component sources (internal artifact repository/proxy such as Artifactory or Nexus rather than direct internet pulls), and SBOM requirements.
Implementation: IDE plugins warn developers as they add dependencies; pre-commit hooks block known-bad packages.
Build/CI: SCA runs on every build; pipeline fails on policy violations; SBOM is generated and signed.
Testing: SCA complements SAST, DAST, and IAST; results feed into a unified vulnerability management process.
Release/Deployment: Container image scanning, artifact signing (Sigstore/cosign), provenance attestations (SLSA levels, in-toto).
Operations/Maintenance: Continuous monitoring of deployed SBOMs for new CVEs; incident response playbooks for supply chain events like Log4Shell.

Open Source Governance Program Elements
1. Open Source Policy – who may introduce components, under what review, with which licenses.
2. Open Source Review Board / Program Office (OSPO) – cross-functional (security, legal, engineering) body approving components and handling license questions.
3. Approved component repository – a curated, proxied internal registry so that only vetted components enter builds.
4. Component selection criteria – active maintenance, responsive security disclosure process, number of contributors, OpenSSF Scorecard results, signed releases, known CVE history.
5. License compliance – attribution notices, source distribution obligations for copyleft, tracking of modifications.
6. Vulnerability response SLAs – e.g., critical fixed within 7 days, high within 30 days.
7. Contribution policy – rules for employees contributing back upstream (IP, security of contributed code).
8. End-of-life management – plans for components that stop receiving security updates.

Related Standards and References
OWASP Top 10 A06:2021 – Vulnerable and Outdated Components (previously A9 "Using Components with Known Vulnerabilities"); OWASP Dependency-Check and Dependency-Track (open source SCA tools); OWASP CycloneDX; OWASP Software Component Verification Standard (SCVS); NIST SP 800-161 (Cybersecurity Supply Chain Risk Management); NIST Secure Software Development Framework (SSDF, SP 800-218) practice PW.4 "Reuse Existing, Well-Secured Software When Feasible" and PS.3 archiving/provenance; ISO/IEC 5230 (OpenChain – open source license compliance); ISO/IEC 18974 (OpenChain security assurance); SLSA framework; CISA SBOM guidance; Executive Order 14028.

Strengths and Limitations of SCA
Strengths: Fast, highly automatable, low false-positive rate for version-based matching, covers the majority of the codebase, provides license visibility, generates SBOMs.
Limitations: Detects only known vulnerabilities (zero-days are invisible); dependent on database accuracy and currency; can produce noisy results without reachability analysis; manifest-only scans miss vendored/copied code and binaries; cannot find flaws in your own custom code (that is SAST's job); license detection can be ambiguous for dual-licensed or unlabeled components.

Exam Tips: Answering Questions on Software Composition Analysis and Open Source
1. Know the tool taxonomy cold. If a question describes finding a CVE in a third-party library, the answer is SCA. If it describes finding SQL injection in developer-written code without running it, the answer is SAST. If it probes a running application, DAST. If it instruments the running app from inside, IAST. If it protects at runtime, RASP. Questions love to mix these.
2. "Known vulnerabilities" is the trigger phrase. SCA finds known, published vulnerabilities in components. It does not discover novel flaws. If a question asks which technique would NOT find a zero-day in a library, SCA is a candidate.
3. Transitive dependencies are the exam's favorite twist. If a scenario says the team "reviewed all the libraries they added" but still got compromised, the missing piece is transitive dependency analysis. Also remember that the majority of vulnerable components are transitive.
4. SBOM questions: know SPDX and CycloneDX as the two major formats, know that SBOMs enable rapid impact assessment during incidents (the Log4Shell lesson), and know that VEX communicates exploitability status. If asked what enables an organization to quickly determine whether it is affected by a newly disclosed vulnerability, the answer is an up-to-date SBOM plus continuous monitoring.
5. Licensing questions: GPL/AGPL = strong copyleft, risky for proprietary distribution; LGPL = weak copyleft, usually acceptable for dynamic linking; MIT/BSD/Apache = permissive. AGPL specifically triggers obligations for network/SaaS use. Legal counsel involvement is the correct answer when the question is about license conflicts, not the developer deciding alone.
6. Shift left, but also shift right. CSSLP favors answers that integrate security earliest in the lifecycle (IDE, pull request, CI gate) AND maintain continuous monitoring after deployment. An answer that scans only once before release is usually wrong because new CVEs appear after release.
7. Prefer policy and process answers over purely technical ones when the question is about governance. If asked how to manage open source risk organization-wide, look for "establish an open source policy with an approved repository and review board" rather than "run a scanner." If asked how to detect vulnerable components, choose the scanner.
8. Prioritization logic: CVSS alone is not the best prioritization method. The best answer combines severity (CVSS), exploitability (EPSS, KEV), reachability, and business context. A question asking how to reduce alert fatigue points to reachability analysis and risk-based prioritization.
9. Remediation hierarchy: the preferred fix is to upgrade to a patched version. If no patch exists, consider replacing the component, applying compensating controls, or formally accepting the risk with documentation and an expiry date. "Ignore because it's internal" is never the right answer. "Rewrite the library yourself" is almost never the right answer.
10. Supply chain attack vocabulary: recognize typosquatting, dependency confusion, maintainer account takeover, and malicious commits. Controls include private registries/proxies, scoped packages, version pinning with lockfiles, hash/signature verification, and provenance attestation (SLSA, Sigstore).
11. Build reproducibility and pinning: if a scenario describes builds that "suddenly" started failing or behaving differently without code changes, the answer involves pinning versions and using lockfiles so dependencies do not float.
12. Map to OWASP Top 10. "Vulnerable and Outdated Components" (A06:2021) is the direct mapping. Know it moved up from A09 in 2017, reflecting increasing importance.
13. Dev vs. production dependencies: a vulnerability in a test-only or build-only dependency carries lower risk than one shipped to production. Questions about accurate risk assessment may hinge on this distinction.
14. Read for the role. CSSLP questions frequently ask what the security professional or development lead should do first. First steps are usually: inventory (generate the SBOM), assess impact, then remediate. Don't jump to patching before you know what you have.
15. Eliminate absolutes. Options like "prohibit all open source" or "trust components from well-known projects without scanning" are distractors. The CSSLP philosophy is risk management, not avoidance or blind trust.
16. Binary vs. source scanning: if the scenario involves a vendor-delivered compiled product or a container image, the correct SCA approach is binary/image analysis, since manifest files may be absent.
17. Contract and procurement angle: when acquiring software, the secure practice is to require an SBOM, vulnerability disclosure commitments, and patch SLAs in the contract – connecting Domain 5 to Domain 7 (Supply Chain).

Sample Practice Questions
Q1. A development team's SAST and DAST scans are clean, yet the application was compromised through a flaw in a logging library. Which control was most likely missing?
A. Code review B. Software Composition Analysis C. Penetration testing D. Threat modeling
Answer: B. SAST and DAST do not reliably identify known vulnerabilities in third-party components; SCA does.

Q2. A new critical CVE is announced. Which artifact allows the security team to determine within minutes which products are affected?
A. Threat model B. Software Bill of Materials C. Penetration test report D. Architecture diagram
Answer: B. The SBOM is the component inventory that enables rapid impact assessment.

Q3. A company sells a proprietary, closed-source desktop application. The SCA tool flags a newly added component. Which license finding should MOST concern the team?
A. MIT B. Apache 2.0 C. BSD-3-Clause D. GPL-3.0
Answer: D. GPL is strong copyleft; statically incorporating it may obligate the company to release its own source code.

Q4. Developers complain that the SCA tool reports hundreds of high-severity findings, most in code paths the application never calls. What capability BEST addresses this?
A. Increasing the CVSS threshold B. Reachability analysis C. Disabling transitive scanning D. Running the scan less often
Answer: B. Reachability analysis determines whether vulnerable functions are actually invoked, reducing noise without hiding real risk.

Q5. An attacker publishes a package to the public npm registry with the same name as an organization's internal private package but a higher version number, and the build pulls it in. What is this attack called?
A. Typosquatting B. Dependency confusion C. Dependency pinning D. Reverse tabnabbing
Answer: B. Dependency confusion exploits resolver preference for higher version numbers across public and private registries; mitigations include scoped packages and registry configuration.

One-Paragraph Summary to Memorize
Software Composition Analysis identifies open source and third-party components (direct and transitive), matches them against vulnerability and license databases, prioritizes findings using CVSS, exploitability, and reachability, enforces policy in the pipeline, and produces an SBOM (SPDX or CycloneDX) that enables continuous monitoring and rapid incident response. It finds known issues in code you did not write, complementing SAST (your code, static) and DAST (running app). Effective open source governance combines tooling with policy: an approved component repository, license rules (permissive vs. copyleft), review board, remediation SLAs, and supply chain protections against typosquatting and dependency confusion. On the exam, choose risk-managed, lifecycle-integrated, policy-backed answers over absolutes or one-time scans.