Dependency hygiene

What it means

Dependency hygiene is the upkeep of the third-party code a project installs. OWASP’s Top 10 describes its absence: unknown component versions; vulnerable, unsupported, or out-of-date software; upgrades neither risk-based nor timely.

• Inventory. CISA calls an SBOM a nested inventory, a list of ingredients that make up software components.
• Reproducible installs. A lockfile gives teammates, deployments, and CI the same dependencies; npm ci fails when lock and manifest disagree; pip’s hash-checking mode verifies downloads.
• Vulnerability posture. OSV-Scanner connects a project’s list of dependencies with the vulnerabilities that affect them.
• Lifecycle scripts. Installing runs package code: pip warns that a default install runs arbitrary code from distributions; npm’s ignore-scripts switches that off.
• Footprint and upkeep. Remove unused dependencies and prefer maintained upstreams; OpenSSF Scorecard’s Maintained check scores an archived project lowest.

Software composition analysis and update tooling serve the practice rather than define it. Enji Guard uses the phrase for an audit scoring the current dependency state on nine criteria.

Why it matters for AI-written code

Every habit above assumes a person evaluates a package before it enters the manifest. OpenSSF’s concise guide puts that first: evaluate software before selecting it as a direct dependency, and only add it if needed. A coding agent writes the import, the install line, and the version constraint in one change, so the evaluation comes afterwards, if at all.

OpenSSF’s guide for AI code assistants answers that gap: prefer popular, community-trusted libraries over obscure ones, and evaluate packages before use as a developer would manually. Those instructions steer the next addition, and Dependabot’s pull requests cover the outdated ones. Neither describes what the lockfile holds today, and that current state is what NIST’s SSDF asks producers to keep verifying throughout a component’s life cycle.

Where it appears in Enji Guard

In the repository dashboard the audit is the metric card titled Dependency hygiene. The catalog describes it as checking whether repository dependencies are accumulating risk or disorder that makes safe development harder, using scanner-backed evidence and key verification gaps.

The runbook scores nine current-state criteria, in this order:

1. dependency source inventory
2. reproducible install
3. known vulnerability posture
4. runtime/dev/test separation
5. safe install and acquisition paths
6. lifecycle script controls
7. dependency footprint control
8. managed exceptions
9. evidence quality/deduplication

Renovate, Dependabot, CI scanner gates, and periodic local scans count as context only, because the score describes the dependencies rather than the maintenance process. The paired improvement is dependency updates, whose catalog line reads: safely find one dependency update and open an issue or pull request for review.

How Enji Guard helps

Each criterion, from dependency source inventory, reproducible install, known vulnerability posture onward, gets 0 to 5 points. The runbook turns the sum into a baseline, criteria_score = round((criteria_sum / 45) * 100), subtracts for confirmed findings, and caps the final score at 39 when any critical finding exists.

The scan is read-only: manifests, lockfiles, branches, and pull requests stay untouched. Each run ends in a report with a status per criterion and a staged checklist, and reruns on the recurring schedule keep the dependency area of the green zone in view as agents add packages.

What follows depends on the finding:

• A vulnerable package whose safe target version is proven can move to the dependency updates improvement: at most one root cause per run, an issue or a review request, and no PR when the version cannot be proven.
• A control gap, such as an unfrozen install path or an unguarded lifecycle script, stays with the team as a checklist step.
• A package that should go also stays with the team; the improvement only updates what it selected.

The audit reads what the repository contains. It does not judge whether a package name is genuine, stop or intercept an install, or watch installs as they happen; those risks reach it only as an advisory, a missing control, or an inventory gap.