# Abandoned or Unmaintained Package Installation

- **Severity:** Medium
- **Signature ID:** `c2f3a4b5-c6d7-4e89-0123-f4a5b6c7d8e9`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain), ASI08 (Supply Chain Attacks on Agent Ecosystems)

## Summary

This rule flags when a software project pulls in a package that has been abandoned by its maintainers. Abandoned packages stop receiving security patches, so any vulnerability found in them stays open forever.

## How the attack works

A developer or automated build process runs a package installer and adds a dependency from a known list of abandoned or unmaintained packages. The package gets pulled into the codebase along with whatever known or future vulnerabilities it has. Because no one maintains it, those flaws are never fixed, giving an attacker a stable, unpatched entry point into anything that depends on it. The rule checks installs against a curated list of abandoned packages (SkillSpector SC5) rather than detecting exploitation itself.

## Why it matters

Software built on an abandoned dependency inherits permanent, unpatchable vulnerabilities, increasing the chance of compromise through a known weak point that will never be fixed upstream.

## What you can do

- Review any flagged install and check if an actively maintained replacement or fork exists.
- If the package must stay for compatibility reasons, document why and track it for future removal.
- Pin dependency versions and audit them periodically against maintenance status, not just known CVEs.
- Add abandoned-package checks to CI/CD so new introductions are caught before merge, not after deployment.

## Known benign look-alikes

- Legacy codebases explicitly maintaining compatibility with these packages

---
Source: https://www.netzilo.com/threats/abandoned-dependency