Before delivery, audit the dependency tree for known vulnerabilities, abandoned or unexpected packages, license problems and unpinned installs, then save the results as dated evidence for the client. Fix what you can, document what you accept, and make sure the numbers in your report match the build you ship.
Why do it at the end, not only during the project
Dependencies drift during a project. A package added in week two for a prototype may still be there at launch. Advisories published after you installed it will not show up unless you check again. A final audit is the last point where the agency can fix things for free in the client's eyes.
The checklist
- Freeze the build. Confirm lockfiles are committed and that CI installs from them, as described in our post on why agencies should commit lockfiles.
- Run an advisory check on the locked versions. For npm, the audit command sends a description of your dependencies to the registry and reports known vulnerabilities with impact and remediation.
- Separate production from development. A flaw in a test-only tool is not the same as one in code that serves customers. The npm audit command can limit fixes to production dependencies.
- Look for abandoned packages. Check the last release date and whether the repository is archived.
- Check for packages you do not recognize. Unfamiliar names in the tree are worth a look, especially direct ones.
- Review licenses. List them, and flag any the client's policy may not allow. This is an inventory task. Ask the client's counsel about meaning.
- Verify signatures where available. npm can verify registry signatures and provenance attestations for downloaded packages.
- Remove what you do not use. Every unused package is attack surface and maintenance.
- Save the evidence: date, tool, version, and result.
Triage, not panic
A raw audit report can list dozens of findings. Sort them.
| Finding | Typical action |
|---|---|
| Fix available, low risk of breaking | Update and test |
| Fix available, major version jump | Schedule, test, explain to client |
| No fix, package reachable in your code | Mitigate or replace |
| No fix, package not used in a vulnerable way | Record the reasoning and a review date |
| Abandoned package | Plan a replacement |
Reachability, meaning whether your code actually calls the vulnerable function, can move a finding up or down this table. Say how you decided.
What goes in the report
Keep it to a page: scope, date, tools, counts by severity, what was fixed, what remains and why, and who owns the remainder. Attach the raw output. A client who reads an honest list of open items trusts the rest of the delivery more than one who is told everything is clean.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look at how severity, fix availability and status are tracked together. That is the shape your delivery report should have.
Quick check
Do I have to fix every finding before delivery?
No. You need a decision on each one, written down, with an owner. Some will be accepted with a review date.
Is a clean audit proof the code is secure?
No. It shows no known advisories at that moment for the packages the tool recognized. It does not cover your own code or later disclosures.
Safeguard
Safeguard's dependency scanning with reachability analysis can help sort findings by whether the vulnerable code is used. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
