1. Inventory what the build actually uses
Record the package manager, lockfile, Node version, direct dependencies, transitive path for each flagged package, and any install or post-install script. A package name alone is not enough: the same package can be safe or risky depending on version, source, script, and execution context.
Keep the inventory read-only first. The first useful output is a map another maintainer can inspect, not a long list of CVE identifiers without affected paths or reachability.
- The lockfile and package manager are named.
- Flagged packages map to a dependency path.
- Lifecycle scripts and registry source are recorded.
- The build and runtime environments are distinguished.
2. Pair the guardrail with evidence
supply-chain-risk-auditor is a natural fit for a focused dependency review. Semgrep or CodeQL may add rule or data-flow context when the repository and language are supported. Use each tool for the signal it can actually produce, then preserve the command, revision, scope, and output.
A finding can be stale, unreachable, or a false positive. The review should explain what changed, which path is affected, and what a maintainer must verify next—not translate a tool label into automatic approval or panic.
3. Classify before changing the tree
Separate a suspicious install script, an abandoned or typosquatted package, a known vulnerable version, unexpected maintainer or registry changes, and a package that is simply unused. These categories need different next steps and different evidence.
For each item, record the reason to escalate, the smallest safe experiment, and the rollback. If the review cannot state what would falsify the concern, it is not ready to drive a dependency change.
- The concern is tied to a version and source.
- The affected code path or script is identified.
- A safe verification step is named.
- The proposed change has a rollback and owner.
4. Keep the claim smaller than the audit
A passing scan can support one bounded statement, such as “the checked lockfile had no finding matching this rule set.” It cannot prove the package is safe, the application is free of vulnerabilities, or the registry will remain unchanged.
Publish the evidence record only after removing credentials, private paths, and sensitive logs. The value of the page is a repeatable review boundary, not a security badge for a package or repository.