Dependency Security
Dependency security manages the risk introduced by third-party libraries and packages in a software project. It covers vulnerability scanning, license compliance, update strategies, lock files, and supply-chain verification to prevent compromised or outdated dependencies from reaching production.
itSoftware supply chain security | OpenSkills.info
Intro
Dependency Security
Most applications are assembled as much as they are written. A package manager brings in libraries, frameworks, plugins, and their dependencies. That saves time, but each component becomes code you must understand, update, and trust.
Dependency security is the practice of controlling that inherited risk throughout a product's life. It starts before you add a package. It continues through installation, review, release, monitoring, and replacement.
The central mistake is to reduce this work to a vulnerability scan. A scanner can match known advisories to an observed package and version. It cannot decide whether you should trust a maintainer, whether the package is actually deployed, or whether an upgrade breaks your application. It also cannot find a vulnerability that nobody has disclosed.
The mental model
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/
Supports
- Software supply chain failures include vulnerable or malicious third-party code, tools, and dependencies
- Direct and nested dependency versions require tracking
- Unsupported, outdated, and unmaintained components create risk
- Regular vulnerability monitoring, trusted sources, change tracking, testing, and risk-based updates
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- Secure development practices integrated across the software development life cycle
- Acquisition and maintenance of well-secured third-party components
- Component evaluation in the context of expected use
- Ongoing vulnerability identification, assessment, remediation, and root-cause response
- https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review
Supports
- Pull-request review of dependency changes in manifests and lockfiles
- Direct updates can also change transitive dependencies
- Detection and prevention of newly introduced known-vulnerable versions
- https://google.github.io/osv.dev/api/
Supports
- Vulnerability queries by package ecosystem, name, version, or commit
- Single, batch, and identifier-based query operations
- https://www.first.org/cvss/v4.0/implementation-guide
Supports
- CVSS Base as system-independent severity rather than complete organizational risk
- Threat metrics for exploit maturity
- Environmental metrics for local impact, asset criticality, and validated mitigations
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Supports
- Catalog entries based on evidence of exploitation in the wild
- KEV as an input to vulnerability-management prioritization
- https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
Supports
- SBOM as machine-processable component information
- Hierarchical components, subcomponents, and dependency relationships
- Component identity and inventory for transparency and tracking
- https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json/
Supports
- package-lock.json records the exact generated dependency tree
- Subsequent installs can reproduce the tree despite intermediate dependency updates
- The lockfile is intended for source control
- https://pip.pypa.io/en/stable/topics/secure-installs/
Supports
- Hash-checking mode with local hashes protects against remote tampering and network issues
- Hash-checking requires all dependencies to be specified, hashed, and pinned
- Package integrity checks are distinct from vulnerability analysis