What is dependency management?

Most of your codebase is code you never wrote. The average application pulls 70–90% of its components from open source, which means most of your attack surface, and most of your legal exposure, lives in packages your team never reviewed.. Frameworks, libraries, and utilities pulled from public registries make up the bulk of a modern codebase, and each one carries its own version history, license terms, and vulnerability record. That inheritance is what makes software development fast. It is also what makes your codebase hard to secure. Dependency management is how you keep that inherited code under control: tracking what's in your build, whether it's safe, and whether it's licensed the way your business needs it to be.

This page explains what dependency management covers, how teams track versions, licenses, and vulnerabilities, the risks specific to today's stacks, and how software bills of materials and software composition analysis support better decisions. It closes with how to operationalize dependency hygiene inside your CI/CD pipeline.

What does dependency management cover?

Dependency management is the practice of identifying, tracking, updating, and securing the external software components an application depends on throughout its lifecycle. It spans the direct packages a team explicitly adds and the transitive packages those add in turn, covering version control, license compliance, and vulnerability remediation.

In a typical project, a handful of declared packages resolve into hundreds or thousands of installed components once transitive dependencies are counted. A package manifest and lockfile record which versions resolve at build time, giving you a reproducible starting point. Managing that graph means answering three ongoing questions: what is in it, is any of it vulnerable or non-compliant, and when do you update.

Think of it as governance over borrowed code. You are accountable for the security and licensing of every component that reaches production, whether your team authored it or inherited it from an open-source package.

Why does dependency management matter?

Most of your application's code, and therefore most of its risk, comes from dependencies. When a widely used package ships a vulnerability, every downstream project that pulls it in inherits the exposure until it patches. That is why software supply chain security has become a primary concern for engineering and security leaders alike, not just an open-source hygiene exercise.

The timing gap is what makes this urgent. Zerodayclock.com, which tracks mean time-to-exploit across more than 3,500 confirmed-exploited CVEs, shows that window collapsing from 2.3 years in 2018 to roughly a day and a half so far in 2026. Remediation hasn't kept pace: Verizon's 2026 Data Breach Investigations Report puts the median time to fully fix a critical vulnerability at 43 days. Attackers now move in hours. Most organizations still measure their response in weeks. A vulnerable dependency sitting in production during that gap isn't a theoretical risk. It's an open door with the exploit already published.. Regulation has caught up to the stakes. The EU Cyber Resilience Act introduces mandatory vulnerability and incident reporting starting September 11, 2026, more than a year ahead of its full conformity requirements in December 2027. Beyond the CRA, a widening set of compliance regimes, from PCI-DSS's software inventory expectations to general audit requirements under SOX, DORA, and HIPAA, increasingly assume you can produce an accurate record of what your software contains. You can't attest to code provenance you've never inventoried, which is why a software bill of materials sits at the center of both compliance and security programs.

How do teams track versions, licenses, and vulnerabilities?

Dependency management resolves into three tracking disciplines, each answering a different question about the same component graph. They overlap in tooling but not in purpose.

Version tracking

Version tracking keeps a record of which release of each package your build resolves to, and flags when newer releases exist. Lockfiles pin exact versions so builds stay reproducible, and update tooling surfaces upgrades that carry security fixes or breaking changes. The discipline here is deciding when to update: pulling a patch that closes a CVE is urgent, while a major version bump that breaks your API contract is not.

License tracking

License tracking identifies the license attached to every component and checks it against your organization's policy. A permissive license like MIT carries different obligations than a copyleft license like GPL, and a single non-compliant transitive dependency can create legal exposure for a shipped product. Automated detection matters because no team can manually read the open-source license of every package in a graph that runs to the thousands.

Vulnerability tracking

Vulnerability tracking matches your resolved components against known-vulnerability databases and flags affected versions. A common vulnerability and exposure record identifies a specific flaw in a specific package version, and severity scoring helps you decide what to fix first. The hard part is prioritization: not every disclosed CVE is reachable or exploitable in your context, so raw counts without exploitability signal produce noise, not action.

What are the common dependency risks in modern stacks?

The risks of using third-party code aren't new. What's changed is the speed and scale at which they now enter a codebase, driven by AI coding agents that add dependencies without evaluating them.

• AI-introduced dependencies at machine speed. AI coding agents pull in open-source packages to satisfy a prompt without checking license exposure, known CVEs, or maintenance status. The agent optimizes for a working solution, not a governed one, so risky dependencies enter the graph faster than any manual review can keep pace with.
• Malicious packages and worm-style propagation. Attackers publish open-source packages designed to look legitimate, or compromise a maintainer's account directly. The Shai-Hulud campaign, first identified in September 2025, showed how far this can scale: a self-propagating npm worm harvested credentials from compromised packages, used them to authenticate as the maintainer, and automatically published malicious versions of every other package that maintainer owned. It spread across hundreds of packages, and later waves, into 2026, extended the technique to additional registries, all without further action from the attacker after the initial compromise.
• Slopsquatting. AI coding assistants routinely hallucinate plausible-sounding package names that don't exist. Attackers monitor those hallucinations and register the invented names with malicious code inside, so a developer who trusts an AI suggestion, or copies AI-generated code without checking, installs the attacker's package instead of a real one. Unlike typosquatting, which bets on a human mistake, slopsquatting bets on the AI being confidently wrong.
• Transitive vulnerability propagation. A vulnerability in a deep transitive dependency propagates upward to every project that pulls in the top-level package. You often carry the exposure without ever having chosen the vulnerable component, and it stays invisible until something inventories the full graph.
• License conflicts. A copyleft license buried in a transitive dependency can impose distribution obligations on your entire product. This risk is legal, not technical, and it tends to surface at the worst possible moment: during acquisition due diligence or a compliance audit, if you haven't tracked it continuously.

Human review at every step made sense when developers wrote and added every line. It does not scale to the volume AI generates, which is why dependency risk has shifted from a periodic audit problem to a continuous verification problem.

What is SCA and SBOMs and how do they help in dependency management?

Software bills of materials and software composition analysis answer different questions. An SBOM tells you what's in your software. SCA tells you what's wrong with it. Does it have any vulnerabilities? You need both, and they're frequently confused for each other.

What an SBOM provides

A software bill of materials is a complete, machine-readable inventory of every component in your application, including direct and transitive dependencies, their versions, and their licenses. Standard formats like CycloneDX and SPDX make that inventory portable across tools and consumable by auditors. An SBOM is no longer just an engineering artifact: it's the record that demonstrates code provenance, and regulators are starting to require it.

What SCA provides

Software composition analysis is the automated process that scans your dependency graph, matches components against vulnerability and license databases, and flags risks for remediation. Where an SBOM is a snapshot of composition, SCA is a continuous assessment that runs every time your dependencies change.

SBOM vs SCA: the key distinction

An SBOM is the output; SCA is the process that produces and evaluates it. SCA generates the inventory and SBOM records, then goes further, correlating each component against known vulnerabilities, exploitability scores, and license policy. Treat an SBOM as a compliance checkbox without the SCA engine behind it, and you get a list you can't act on. The inventory only has value when something continuously assesses what it contains.

How do you operationalize dependency hygiene in CI/CD?

Dependency hygiene works when it's automated and enforced, not when it depends on a developer remembering to check. Point-in-time audits catch issues too late, after a vulnerable package is already deep in your codebase and the context that would make remediation cheap is gone. The goal is to move the check as early as the dependency enters, and enforce it consistently across every team and pipeline.

That means embedding dependency analysis directly into the CI/CD pipeline so every build is evaluated against the same policy. A quality gate that blocks a merge when a new dependency introduces a critical vulnerability or a prohibited license converts governance from a report into an enforced control. An SCA pre-commit hook pushes that same check into the developer's inner loop, catching a risky package before it's ever committed.

The organizations that get this right treat dependency governance as a Golden Path, not a gate developers route around. Centralized policy, applied uniformly and surfaced in the tools developers already use, gives platform engineering a single standard across every repository, and gives security a consistent, auditable record of what was scanned, when, and what was found.

How can SonarQube help you secure dependency management in CI/CD?

SonarQube Advanced Security extends code verification to your open-source dependencies through software composition analysis, so third-party components meet the same standard as first-party code. It analyzes your dependency graph as part of the build, giving platform and security teams one workflow instead of a separate scanning silo.

Its dependency-management capabilities cover every discipline above:

• CVE detection identifies known vulnerabilities in direct and transitive dependencies and prioritizes them by severity (CVSS) and exploitability (EPSS, KEV), so your team fixes what's actually reachable first.
• Malicious package detection flags compromised or attacker-registered libraries in your CI/CD pipeline, whether introduced through a hijacked maintainer account, typosquatting, or a slopsquatted package name, and can trigger a quality gate that stops confirmed malware before it merges.
• License management automates license detection and validation, enforces custom policy, and runs compatibility checks for corporate use.
• Software bill of materials export produces a complete inventory of your dependencies in CycloneDX and SPDX formats, integrated into your DevOps workflow.
• Advanced SAST extends dependency-aware taint analysis into third-party libraries for Java, C#, JavaScript, and TypeScript, tracing data flows across code boundaries to uncover vulnerabilities that only surface in the interaction between your code and a library.

Because these checks run inside quality gates, dependency risk becomes an enforced control instead of an after-the-fact report, and the same activity produces the timestamped record compliance teams need. To get started, connect SonarQube to your repository and configure a quality gate that every build has to pass before merge.

Next steps

• Software composition analysis explained — companion learn page on the process that scans and evaluates your dependency graph.
• What is a software bill of materials? — deeper coverage of SBOM formats and their role in compliance.
• Software supply chain security — how dependency risk fits into the broader supply chain threat model.
• SonarQube Advanced Security — product documentation for SCA, license management, and SBOM export.
• Set up an SCA pre-commit hook with the SonarQube CLI — implementation guide for catching risky dependencies in the inner loop.
• Stop malicious packages in your CI/CD pipeline — walkthrough of detecting and blocking compromised libraries at build time.