A small team can safely postpone formal frameworks, signing and provenance for its own builds, scoring dashboards, custom tooling and low severity noise in unreachable code. Do the basics first: inventory, alerts, locked installs and a protected main branch. Revisit the postponed items when a customer, auditor or incident demands them.
Why ignoring things is a skill
Security advice is written for large teams, so a small team that follows all of it burns out. Choosing what to skip is part of the plan, as long as it is a decision with a date, not a silent gap. Write each ignored item in a short list with a review date.
The ignore list
| Item | Why it can wait | Revisit when |
|---|---|---|
| Low severity findings in code that is never called | Little exposure and high noise | A fix is trivial or the code path changes |
| Signing and provenance for your own releases | Matters most to consumers of your packages | You publish a library or a customer asks |
| Full SLSA build levels | Higher levels need hardened build platforms | You sell to buyers who ask for them |
| Custom scanners and scripts | You will maintain them forever | Off the shelf options fail a real need |
| Scoring every dependency by hand | Too slow at scale | You add a new package to a sensitive path |
| Formal framework mapping | Useful for audits, not for week one | An audit or tender appears |
Notes on the trickier rows
SLSA describes build levels. Its own text says Build L1, where provenance exists, can prevent mistakes but is trivial to bypass or forge. That is a reminder that the first levels are about visibility, not tamper proof. If you do not publish software others consume, the effort is better spent elsewhere.
Provenance for packages is similar. npm documents that provenance links a package to its source code and build instructions, which helps consumers verify where it was built. If you only consume packages, the check you can run is verifying signatures with the audit signatures command described in the npm documentation. That is a one line addition to a CI job.
Frameworks are the opposite case. NIST's Secure Software Development Framework is a set of high level practices, and a small team can borrow one practice at a time. You do not need a full mapping to benefit from the ideas.
What you must not ignore
Some things stay on the list from day one.
- Known exploited vulnerabilities in anything you ship.
- Account security on your registry and code host.
- Unreviewed changes to your main branch.
- A lockfile that is not committed.
If a postponed item appears in a customer questionnaire, move it up. That is a real trigger. A hunch is not.
Keeping the list honest
Review the ignore list monthly. Delete items you have started, add items you have newly decided to skip, and note why. A list with dates is a plan. A list without dates is a hope.
Safeguard reachability analysis is one way to cut the first item on this list down to size, since it shows which vulnerable functions your code calls. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is ignoring a finding the same as accepting the risk?
Not quite. Accepting risk should be a recorded decision with an owner and a review date. Ignoring without a record is just a gap.
When should we start signing our own releases?
When you publish packages or software that others install, or when a customer asks for it. Consumers benefit most from provenance.
Sources
- SLSA, Security levels
- npm Docs, Generating provenance statements
- npm Docs, npm-audit
- NIST SP 800-218, SSDF Version 1.1
Last reviewed: 19 October 2026.
