Dependency Governance: Choosing, Updating and Retiring Open Source Components

Scanning dependencies for known vulnerabilities tells you about problems that already have a CVE number. Governance is the upstream question: which components you take on in the first place, how you keep them current, and how you get rid of the ones that become liabilities. It is the part that prevents findings rather than reporting them.

Evaluating a dependency before adopting it

Adding a library is a long-term commitment to someone else's code and someone else's maintenance. A short check before the first import costs minutes and saves years.

Maintenance signals. When was the last release, and how quickly do security issues get fixed? A project with an eighteen-month gap since its last commit is not maintained, whatever its popularity.

Bus factor. How many people can merge changes? A great deal of critical infrastructure is maintained by one unpaid person, which is a supply chain risk and a burnout risk simultaneously.

Dependency weight. A package pulling in forty transitive dependencies to do something small is forty more things to track. Prefer smaller dependency trees, and check whether the standard library already does the job.

Security posture. Does the project have a documented vulnerability disclosure process and a history of handling reports well?

Licence compatibility with how you distribute your software — which is a legal question that arrives late and expensively if ignored.

Abandoned and hijacked projects

Abandonment is a slow-moving risk. A dependency stops receiving fixes, a vulnerability is eventually found, and there is nobody to fix it. Your options narrow to forking and maintaining it yourself, replacing it, or accepting the risk — all expensive, and all cheaper if you noticed the abandonment two years earlier.

Hijacking is the fast-moving version. A maintainer's account is compromised, or an exhausted maintainer hands the project to a volunteer who turns out to have been waiting for exactly that. Either way a malicious version is published through the legitimate channel and installed automatically by everyone with a loose version range — the attack pattern described under supply chain security.

Pinning exact versions with integrity hashes is the direct defence: a new release does not enter your build until someone chooses it. The cost is that updates become deliberate work rather than something that happens by itself, which is the trade-off the next section covers.

An update policy that people follow

Two failure modes, both common. Updating nothing means an accumulating gap that eventually requires a painful multi-major-version migration, usually under pressure because a vulnerability was announced. Updating everything automatically means a malicious or broken release reaches production before anyone looks.

The workable middle is tiered. Security patches move fast, with automated pull requests and prompt review. Minor and patch updates run on a regular cadence — frequent small updates are far cheaper than rare large ones. Major versions are planned work with their own testing.

What makes any of this survivable is a test suite you trust. Teams that cannot update dependencies confidently usually cannot because they cannot tell whether an update broke something, and that is a testing problem wearing a dependency costume.

Licence obligations

Not security, and it lands on the same team because it uses the same inventory.

Permissive licences require attribution and little else. Copyleft licences require that derivative works be released under the same terms, which matters when you distribute software. Network copyleft extends that to software offered as a service, which surprises organizations that assumed not shipping binaries meant no obligation.

The practical control is an allowlist of acceptable licences checked automatically in the build, so an incompatible dependency is caught in the pull request rather than during due diligence for a funding round.

Where it connects to the rest

Governance and scanning are the same inventory used twice. An SBOM generated at build time lists what you actually ship, continuous composition analysis checks that list against new advisories, and governance decides what goes on the list and how long it stays.

Prioritisation still applies to whatever comes back — exploitability and reachability rather than raw severity, using data such as EPSS — because a governance programme that generates an unworkable queue gets abandoned like any other.

Exam angles

Know dependency selection criteria: maintenance activity, maintainer count, transitive dependency weight, disclosure process and licence. Recognize abandoned projects and maintainer account compromise as supply chain risks, with version pinning and integrity hashes as the control. Know that a tiered update policy — fast for security, cadenced for minor, planned for major — depends on trustworthy automated testing, and that licence type determines distribution obligations.