3rd-Party Packages Scanning
Also known as:
- Software Composition Analysis (SCA)
What problem does it target?
SCA solutions address the risk of vulnerabilities and license compliance issues in open-source and third-party components used in software development. A key challenge is determining whether detected vulnerabilities are actually exploitable (reachability) in the context of the application.
What does this solution do?
SCA platforms:
- Identify open-source components and dependencies
- Detect known vulnerabilities (CVEs) and outdated packages
- Monitor for license compliance and policy violations
- Provide remediation guidance and automated updates
- Prioritize vulnerabilities based on reachability and exploitability, not just presence
Reachability and Prioritization
Modern SCA tools increasingly use reachability analysis to prioritize vulnerabilities:
- Static reachability determines if vulnerable code is called in your codebase. This can be performed at the package or function level. Function-level static reachability provides much more precise results and can reduce vulnerability counts by 90-99% compared to traditional SCA, but it cannot confirm if the vulnerable code is actually executed at runtime.
- Runtime reachability confirms if vulnerable code is actually executed in your environment, offering higher certainty and reducing false positives further. Function-level runtime reachability is more accurate for prioritizing vulnerabilities and enables application detection and response (ADR) capabilities.
The main goal is to focus remediation on exploitable software, not just the presence of vulnerable components. The definition and implementation of reachability can vary between vendors, as determining exploitability often requires detailed environmental context.
For a detailed comparison, see Static vs. Runtime Reachability.
Compliance and Justification
Compliance requirements have traditionally driven patching of all vulnerabilities, but there is a shift toward justifying non-patching of non-exploitable findings using tools like VEX statements for SBOMs.
Who is this for?
- Development and DevSecOps teams
- Organizations using open-source software
- Enterprises with compliance requirements
Who might not benefit from this?
- Teams using only proprietary or closed-source software
- Projects with no external dependencies
Pitfalls and remedies
| Pitfall | Remedy |
|---|---|
| Missed transitive dependencies | Use deep scanning and SBOM generation |
| Overwhelming vulnerability alerts | Prioritize based on exploitability and usage (see reachability) |
| License confusion | Maintain clear policies and automate compliance checks |
Sample products
- Snyk
- WhiteSource (Mend)
- Black Duck (Synopsys)
- GitHub Dependabot
- FOSSA