Identifying risk in supply chains containing third-party and open source components involves identifying known vulnerabilities, component age and "freshness", license terms, project health, chain of custody, and a host of other factors. Component analysis is applicable to software being developed, purchased, or as a result of being embedded in a device (or the device itself). If a vulnerability is possible for a given component (software or hardware) it can and should be analyzed.
One of the most common questions that arise from people familiar with either Dependency-Check or Dependency-Track is the distinction between the two. What's the relationship between them and how they are different?
| Dependency-Track | Dependency-Check | |
|---|---|---|
| Software type | Platform |
Library with multiple implementations:
|
| Approach | Software Bill-of-Materials (SBOM) which can be automatically generated at build-time or obtained from vendors | Scans files on filesystem and extracts evidence with varying degrees of confidence |
| Vulnerability intelligence |
|
|
| Outdated version identification |
|
None |
| Ecosystems supported | Ecosystem agnostic (all ecosystems supported) | 10+ with varying degrees of maturity |
| Reporting | Dynamic intelligence and metrics delivered via REST API or web interface | Per-project statically generated HTML, XML, JSON, and CSV reports |
| License support | Resolves over 500 SPDX license IDs as well as supporting unresolved license names | Unresolved license names as evidence |
| Jenkins plugin | Yes (bidirectional) | Yes (unidirectional) |
| Sonarqube plugin | No | Yes |
| Vulnerability aggregation |
|
|
| Notification support |
|
None |
| Auditing | Per-project and global auditing workflow supporting analysis decisions, comments, and suppressions that are captured and tracked in a per-finding audit log | Suppression file with support for CPE, filename, and regex pattern matching |
| Private vulnerability repository | Yes | No |
| Perspectives |
|
|