Dependency hygiene audit

What this audit answers

The dependency hygiene audit asks whether dependency risk or disorder is accumulating in the repository. It combines package and lockfile structure, reproducible acquisition paths, lifecycle-script controls, current vulnerability evidence, exception handling, and scanner confidence. It does not reduce the result merely because no update bot or recurring scanner is configured.

What Guard inspects

Guard detects dependency sources across supported ecosystems, including manifests, lockfiles, workspace definitions, images, registries, install scripts, CI/build acquisition paths, and exception records. It prepares relevant read-only native tools or open-source scanners instead of installing every possible scanner. Findings from multiple tools are normalized and deduplicated by the underlying package and advisory.

The report preserves disagreement, unknown severity, missing fixed versions, direct or transitive paths when available, and tool limitations. Only medium- or high-confidence deduplicated findings affect severity totals.

The nine criteria

The scorecard covers dependency source inventory, reproducible install, known-vulnerability posture, separation of runtime/dev/test dependencies, safe install and acquisition paths, lifecycle-script controls, dependency-footprint control, managed exceptions, and evidence quality and deduplication. Each applicable criterion receives 0–5 for a maximum of 45.

A docs-only repository with no dependency sources can be a valid no-action outcome. A deployable application whose primary dependency sources cannot be found is instead a material inventory gap.

How the score works

Criterion points are normalized to 0–100. Confirmed findings are split so current risks remain distinct from control gaps. Risk findings subtract 20 for critical, 8 for high, 3 for medium, and 1 for low impact, capped at 35. Control findings subtract 3 for high and 1 for medium, capped at 8; low control findings do not reduce the score.

Caps then apply: any critical finding caps the result at 39; two or more high runtime, deployable, or privileged-acquisition findings cap it at 69; a non-reproducible primary CI/build/release install path caps it at 69; inability to identify dependency sources for the main deployable surface caps it at 59; materially incomplete scanner coverage can cap an otherwise usable result at 79.

Missing update automation, scanner schedules, ownership notes, or CI dependency checks are context, not automatic penalties.

Limitations and boundaries

Private registries, unsupported ecosystems, missing credentials, shallow history, and scanner disagreement can limit coverage. Guard records those facts instead of claiming that an unscanned package is safe. General pipeline composition belongs to CI/CD; application security findings outside dependencies belong to security; package freshness without concrete risk is not inflated into a vulnerability.

The audit is read-only and never changes manifests or lockfiles.

Improvements and reruns

Prioritize confirmed risk, then reproducibility and acquisition controls: update a vulnerable dependency to a verified fixed version, freeze the primary install path, constrain a privileged lifecycle script, remove an unnecessary dependency, or document a managed exception with an owner and review condition. Scanner output is starting evidence; the proposed change still needs compatibility checks and human review.

Rerun after the lockfile or acquisition path is merged. Confirm the advisory resolution, reproducible installation evidence, and whether scanner coverage changed.