# Software Composition Analysis (SCA) Software Composition Analysis (SCA) is the automated process of identifying all open-source and third-party components in a codebase, mapping their known vulnerabilities, license obligations, and security risks. It's the primary defensive tool against supply chain attacks like [[Typosquatting]], [[Slopsquatting]], [[Dependency Confusion]], and [[Starjacking]]. ## What SCA does - **Inventory**: builds a complete dependency tree (direct + transitive) and generates SBOMs - **Vulnerability matching**: cross-references dependencies against CVE databases (NVD, OSV, GitHub Advisory Database) - **Malware detection**: flags packages known to be malicious or exhibiting suspicious patterns - **License compliance**: identifies license types and flags incompatibilities - **Reachability analysis**: determines whether a vulnerable function is actually called in your code (reduces false positives) - **Continuous monitoring**: alerts when new vulnerabilities are disclosed for packages you already use ## How it fits in the pipeline ``` Code commit → SCA scan (CI) → Block if policy violated → Deploy ↓ Continuous monitoring (post-deploy) ``` SCA runs at multiple points: - **IDE/local**: catch issues before commit (e.g., Snyk IDE plugins) - **CI/CD**: gate PRs on vulnerability and license policy - **Registry proxy**: scan packages before they enter your private registry - **Production monitoring**: alert on newly disclosed vulnerabilities in deployed dependencies ## Key tools | Tool | Focus | |------|-------| | Snyk | Vulnerability scanning, license compliance, container images | | Mend (formerly WhiteSource) | Vulnerability remediation, license policy, SBOM | | Dependabot (GitHub) | Automated dependency updates and vulnerability alerts | | Socket.dev | Supply chain attack detection (behavior analysis, not just CVEs) | | Grype + Syft (Anchore) | Open-source vulnerability scanner + SBOM generator | | OWASP Dependency-Check | Open-source CVE scanner | | npm audit / pip audit | Built-in registry vulnerability checks | ## Limitations - CVE-based scanning only catches known vulnerabilities, not zero-days - Most SCA tools don't detect [[Slopsquatting]] (hallucinated packages that aren't in any CVE database yet) - Reachability analysis is imperfect; transitive dependencies are hard to trace fully - License detection can miss dual-licensed or re-licensed code - High false positive rates without reachability analysis or policy tuning ## References - ## Related - [[Static Application Security Testing (SAST)]] - [[Software Supply Chain Security]] - [[Package Registry Security]] - [[Namesquatting]] - [[Typosquatting]] - [[Slopsquatting]] - [[Dependency Confusion]] - [[Starjacking]] - [[Attack surface]] - [[Least Privilege Principle]] - [[CI CD pipelines]] - [[DevSecOps]] - [[Vercel DeepSec]]