Assess developer security skills before training with three light tools: a short set of scenario questions, one small code exercise and a review of your own past findings. Use the results to choose topics for each group, not to rank individuals. A baseline also gives you something to compare against later.
Why bother with a baseline
Without one, training topics get chosen by guesswork or by whatever the last course covered. You may spend an hour on a topic everyone knows and skip the one that keeps causing bugs.
NIST SP 800-50 Rev. 1, published in September 2024, describes a lifecycle approach to a cybersecurity and privacy learning program and covers metrics and evaluation methods for improving the program over time. A baseline is the first data point for that kind of evaluation.
Tool 1: scenario questions
Ask ten or fewer questions framed as situations, not definitions.
- A teammate asks for the production database password in chat. What do you do?
- An endpoint takes a file name from the request. What could go wrong?
- A new package would save a day of work. What do you check?
Scenario questions show reasoning. Multiple choice trivia shows who remembers a term.
Keep the assessment anonymous or group level where you can. People answer honestly when it is not a test of worth.
Tool 2: a small code exercise
Give a short snippet, twenty lines or fewer, with one or two realistic flaws. Ask developers to mark what concerns them. Time limit: fifteen minutes. You are looking for patterns, such as most people missing an authorization gap while all catch an injection.
Tool 3: mine your own history
This is the cheapest and most telling source. Review the last year of security findings and incidents. Which categories repeat? Which teams? That tells you where training should aim far better than a generic quiz.
Putting results to use
| Finding | Response |
|---|---|
| Most miss authorization gaps | Add an exercise on ownership checks |
| Few check new dependencies | Add a package review checklist |
| Strong across the board on injection | Cut that session short |
| One team has repeat issues | Offer that team a tailored session |
Common mistakes
- Sharing individual scores widely. It encourages gaming and resentment.
- Running a long exam. Fatigue distorts results.
- Skipping the retest. Repeat a lighter version after training to see whether anything shifted.
Where Safeguard fits
Your own findings make a strong baseline, and Safeguard can supply them through dependency scanning, reachability analysis, SAST and vulnerability management views. It does not offer training courses. Start with the free scan at gold.safeguard.sh/scan. For how to judge results afterwards, see how to measure whether secure coding training worked.
Quick check
Should a baseline assessment be graded?
Grade it for the group's gaps, not for individuals. Individual grades discourage honest answers.
How often should you repeat it?
Once a year is a reasonable rhythm, with a lighter check after a major training round.
Sources
- NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program: csrc.nist.gov/pubs/sp/800/50/r1/final
Last reviewed: 19 October 2026.
