Export your findings from the last quarter, group them by flaw class, rank by how often and how severe, and teach the top three with a hands on exercise built from your own code. Your findings are a free syllabus because they show what your developers actually get wrong.
Why findings beat a generic syllabus
Generic training covers everything, so it covers your problems thinly. Your scan history shows the three or four categories that dominate. NIST SSDF PO.2.2 lists measuring outcome performance to decide where training should change as an example, and findings are the cheapest data for that.
The method
- Pull findings from static analysis, dependency scanning and secrets detection for the last quarter.
- Normalize them into flaw classes: injection, broken access control, hardcoded secrets, vulnerable dependency, unsafe deserialization, misconfiguration.
- Count by class and by team. Note severity.
- Remove noise: findings marked false positive, and anything in test code, unless test code is the issue.
- Rank by count times severity. Look at the top three.
- For each, pick one real, anonymized example from your repos.
- Build a 20 minute exercise: show the vulnerable code, let people fix it, show the fix.
- Re-run the counts next quarter.
A worked example
The numbers below are made up to show the arithmetic. They are not from any report.
| Flaw class | Findings | Severity weight | Score |
|---|---|---|---|
| Vulnerable dependency | 120 | 2 | 240 |
| Hardcoded secret | 30 | 4 | 120 |
| Missing access check | 12 | 5 | 60 |
| Injection | 8 | 5 | 40 |
By raw count, dependencies dominate. By risk you might still put the access check first. Use judgment, and say so when you present it. Exercises for dependency work are different from those for code flaws, so pick one of each at first.
Avoid teaching to the scanner
Scanners do not see everything. A quiet scan does not mean no flaws. Add one topic each quarter from threat modeling or review comments that tools cannot see, such as business logic errors.
Naming and privacy
Never name the developer who introduced a finding. Use team level data. People who feel watched stop reporting.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a code finding shows the flaw class, the file and the suggested fix, which is the content you can turn into an exercise.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, vulnerability scanning and reachability analysis, so findings can be grouped and ranked. A free scan gives you a first data set.
Quick check
How much history do we need?
A quarter is a good start. If volume is low, use six months.
What if we have no scanner yet?
Use code review comments and incident notes as your data, and run a free scan to get a first picture.
Sources
Last reviewed: 19 October 2026.
