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?
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|
|Outdated version identification||
|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)|
|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|