After week one, spend weeks two to four on triage, a pull request check, build pipeline hardening and a monthly review. The aim is that new risk gets caught at the pull request, existing risk gets ordered sensibly, and someone looks at the numbers every month.
Week two: triage what you found
Your first alert list will look worse than it is. Sort it in this order.
- Anything on the CISA Known Exploited Vulnerabilities catalog. CISA states that it strongly recommends all organizations review and monitor that catalog and prioritize remediation of listed vulnerabilities.
- Anything the package manager marks as having a fix available, in a component your code actually calls.
- Everything else, in a backlog with a review date.
EPSS is a useful second signal. FIRST describes it as a model that estimates the probability a published CVE will be exploited in the wild in the next 30 days, published daily as a number from 0 to 1. A high score does not prove you are exposed. It tells you where attackers are looking. For a deeper comparison, see CVSS, EPSS and KEV explained.
Week three: gate new risk at the pull request
Existing alerts are a backlog, but new ones are a decision you can stop. Add a dependency review step to pull requests. GitHub's documentation says dependency review shows which dependencies were added, removed or updated, with release dates and vulnerability data, including indirect dependencies from lockfiles. Start in warn mode. Once the team trusts it, block on known exploited vulnerabilities only.
Week four: harden the build
Three small settings matter most.
- Set the default token permission for workflows to read only, then raise it per job. GitHub's guidance calls this good practice.
- Pin third party actions to a full length commit SHA. The documentation explains that this mitigates the risk of a bad actor adding a backdoor to the action's repository.
- Turn on two factor authentication for your registry and code host accounts. npm documents 2FA as a second check before sensitive actions such as publishing.
The step by step for pinning is in how to pin GitHub Actions to SHAs correctly.
Close the month with a review
Hold a 30 minute review at the end of week four. Bring four numbers: how many dependencies, how many alerts open, how many on the exploited list, how long the oldest takes. Write them down, because next month they become your trend. See a monthly one hour review agenda.
What to leave for later
Signed builds, provenance for your own packages and formal frameworks can wait until the basics hold. Do them when a customer or auditor asks, not before.
Safeguard supports policies and gates on pull requests, plus reachability analysis that shows whether a vulnerable function is called. A free scan is available at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do we need a paid tool for the pull request check?
Not to start. Built in dependency review on a code host covers added and changed packages. A dedicated tool adds value when you need reachability or one view across many repositories.
Should the gate block merges immediately?
Start by warning only. Block once the team trusts the signal, and begin with the narrowest rule, such as known exploited vulnerabilities.
Sources
- CISA, Known Exploited Vulnerabilities
- FIRST, Exploit Prediction Scoring System
- GitHub Docs, Dependency review
- GitHub Docs, Secure use reference for Actions
- npm Docs, About two-factor authentication
Last reviewed: 19 October 2026.
