Teach a new engineer vulnerability triage by pairing, not by documents. Walk through three real alerts together, give them the written policy, let them triage a week of low-risk alerts with review, and add them to the rotation after a second review. About a week is enough to start.
What a new engineer needs to know
Not the whole field. Four ideas cover most decisions.
- Severity is not risk. FIRST's CVSS guidance says Base scores measure severity and should not be used alone to assess risk.
- Exploitation matters. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities seen exploited in the wild, and CISA strongly recommends all organizations prioritize them. FIRST's EPSS estimates exploitation probability over 30 days and says it is not a complete risk score.
- Reachability matters. A vulnerable package that never runs the vulnerable code is a different case from one that does.
- Everything dismissed needs a reason and a date.
Day by day
| Day | Activity | Output |
|---|---|---|
| 1 | Read the policy and ownership map | Can name the owner of three services |
| 2 | Pair on three alerts: one known exploited, one reachable, one dev-only | Written decision for each |
| 3 | Triage a batch of low-risk alerts alone | Reviewed by a senior engineer |
| 4 | Fix one real dependency upgrade end to end | Merged change |
| 5 | Review the week | Decide whether to join the rotation |
The three alerts to pick for day two
Choose cases that teach different lessons.
- A known exploited item in production. Teaches urgency and the fix path.
- A reachable high severity issue. Teaches how to confirm reachability and write the evidence.
- A dev-only alert. Teaches when waiting is fine. GitHub's auto-triage documentation describes a preset that auto-dismisses certain low impact issues in development-scoped npm dependencies, and notes they are unlikely to be exploitable outside a developer environment. It also notes such alerts can be reopened if the dependency scope changes.
Let the new engineer talk through each one aloud before looking at the answer.
What good output looks like
A decision note should say what the alert is, whether it is reachable, what you decided, who owns it, and when it will be checked again. Short and specific. Compare these two:
- Weak: "Low risk, ignoring."
- Strong: "Dev dependency used only in test runs, not shipped. Dismissed. Review at next upgrade day."
Common beginner mistakes
- Sorting by severity only.
- Dismissing without a date.
- Fixing in the wrong place, for example pinning a transitive dependency locally when the direct dependency should be upgraded.
- Skipping the ownership check and fixing a repository they do not own.
For more on reading an alert quickly, see how to read a dependency alert in five minutes.
Try it yourself
Click through it at your own pace, or open it full screen. Use it as a practice case for day two.
Safeguard's reachability analysis can show the evidence side by side, and the free scan at gold.safeguard.sh/scan gives real findings to practice on.
Quick check
Should a new engineer be on the rotation in week one?
Usually not alone. Pair for the first rotation and review their decisions.
What if they disagree with the policy?
Welcome it. Write the point down and review it at the next policy check.
Sources
- FIRST, CVSS v4.0 User Guide
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- FIRST, EPSS frequently asked questions
- GitHub Docs, Dependabot auto-triage rules
Last reviewed: 19 October 2026.
