Loading content
Dependency Security covers practices, processes, and tools to protect project dependencies and the software supply chain from compromised packages, malicious code, and unpatched vulnerabilities. It includes governance, automated scanning, signatures and supply-chain standards to ensure integrity, trustworthiness and timely incident response.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Dependency security means protecting software dependencies and supply chains from tampered packages, malicious code, and known vulnerabilities. Its goal is to make component origin, integrity, and freshness visible and enforceable.
The concept sits in the lineage of software supply chain security and DevSecOps: as teams relied on more external packages, compromised dependencies, tampered builds, and missing origin evidence became a practical risk. SLSA emerged as a cross-industry framework within OpenSSF to make artifact integrity, provenance, and supply-chain controls measurable across the chain.
Think of dependency security as a control chain around every third-party component. First, teams inventory which packages and transitive dependencies are in the project. Then scans, signatures, and provenance checks test whether content and origin are trustworthy. Policies and build gates decide what may reach release or production, while monitoring and fast updates close known gaps.
A complete list shows direct and transitive components together with versions and sources.
Origin evidence links source, build, and produced artifact in a traceable way.
Hashes, signatures, and verified artifacts help detect tampering.
Automated checks find known vulnerabilities in direct and transitive dependencies.
Rules decide which packages, versions, and attestations are accepted for build or release.
Dependency security matters most when projects rely on many external packages, operate in regulated settings, or need verifiable trust in suppliers and artifacts. It reduces risk, but it does not eliminate the need for maintenance: inventories, scans, and exception handling require ongoing care, or teams end up with alert fatigue, extra work, and blind spots in transitive dependencies or private repositories.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.