Managing Unmaintained Dependencies

Overview

Outdated or unmaintained open source dependencies pose serious security and operational risks — particularly when those packages reach end-of-life (EOL) status. These risks include a lack of security patches, reduced community support, and a greater likelihood of unpatched vulnerabilities.

However, identifying EOL dependencies isn’t always straightforward. Maintainers don’t always clearly declare EOL status, and many open source projects fade into inactivity without a formal announcement.

Heeler provides automated guardrails and intelligent detection to help you reduce exposure to unmaintained or EOL dependencies — without relying solely on explicit EOL declarations.

Why This Matters

Unmaintained dependencies can:

• Become high-value targets for attackers (e.g., typo-squatting or hijacking)

• Harbor unpatched vulnerabilities with no available fix

• Introduce breaking changes during emergency upgrades

• Create friction for developers trying to resolve incidents quickly

In production-grade environments, it's critical to prevent the introduction of unmaintained packages and identify any currently used packages that are no longer actively developed.

What Counts as “EOL”?

There’s no universal marker for EOL in open source ecosystems. That’s why Heeler focuses on pragmatic, behavior-based signals of whether a package is actively maintained:

• Is the repository archived or abandoned?

• Are commits and issue activity still occurring?

• Is the latest version recent and stable?

• Are vulnerabilities unresolved, with no fix in sight?

Recommended Guardrails for Unmaintained Dependencies

Heeler has a number of guardrail rules that pertain to unmaintained dependencies. We'll cover these below.

Compromised Dependencies

This rule leverages the OSSF Malicious Packages feed to identify known open source packages that have been compromised.

Recommended Usage: Set a global rule to block the introduction of compromised or malicious packages.

Unmaintained Dependency

This rule scores each OSS package based on recent commit and issue activity from core maintainers:

Recommended Usage: There are two rules which help handle unmaintained dependencies

1. Set a rule threshold of 0 to block the introduction of abandoned or clearly EOL packages.

1. Use a combination of the no fix version available + maintained dependency < 10 rules to identify packages with some activity but the version in the commit has vulnerabilities with no fix available. This will identify packages that are poorly maintained and have vulnerabilities with no known fix version available.

Older Version of Existing Dependency

This rule flags attempts to reintroduce older versions of dependencies that are already in use in a more recent form elsewhere in your codebase.

Recommended Usage: Prevent developers from accidentally committing outdated or previously patched versions of a package.

Unapproved Dependency

This rule allows teams to prevent known EOL or unwanted packages by name.

Recommended Usage: Block deprecated or high-risk packages at the organizational level (e.g., "log4j:log4j").