In the first month, developer security training should cover only what matches your own codebase and findings: handling secrets, choosing and updating dependencies, validating input, access control checks, and how to read and act on the scanner's results. Keep sessions short, hands on, and tied to real pull requests.
Start from your data
Generic courses cover everything and change little. Start with your last quarter of findings and incidents. If most findings are dependencies and secrets, spend most of the time there. The OWASP SAMM model supports this approach: assess where you are, set targets practice by practice, and improve in iterations rather than trying to reach the top in every area at once.
A four week plan
| Week | Topic | Format | Outcome |
|---|---|---|---|
| 1 | Secrets and credentials | 30 minute live demo | Everyone knows where secrets live and how to rotate |
| 2 | Dependencies and updates | Workshop on a real repository | Each team has an update routine |
| 3 | Input handling and access control | Code review of a past finding | Reviewers know what to look for |
| 4 | Reading tool output and exceptions | Office hours | Fewer questions, fewer bypasses |
What to include in each session
Secrets. Never commit credentials, use a secret store, how to rotate if one leaks, and why deleting a commit does not remove the exposure.
Dependencies. What a lockfile does, how to read an advisory, what an upgrade can break, and how to choose a library with active maintenance.
Input and access. Validate on the server, check authorisation on every request that changes data, and never trust identifiers sent by a client.
Using the tools. What each message means, how to suppress with a reason, how to ask for help, and what blocks a merge.
Make it practical
- Use code from your own repositories, with names removed
- Ask people to fix something during the session
- Keep slides to a minimum
- Record it and add a short written summary
- Hold sessions per team when possible, since examples feel closer
What to skip at first
- Long compliance videos with quizzes nobody remembers
- Advanced topics such as cryptography design, until a team needs them
- Rankings of who scored highest
Measure whether it helped
Check the same measures you used before: repeated finding types, time to fix and questions asked. If secrets findings fall after week one, the session worked. If not, change the session, not the audience.
Keep it going
After the first month, move to short, regular touches: a tip in the team channel, a five minute segment in sprint review, a post incident write up. Learning sticks when it arrives close to the work.
Quick check
How long should a developer security session be?
Thirty to sixty minutes is enough if it is hands on. Longer sessions lose people quickly.
Do developers need a certification?
Not to start. A certificate shows attendance, not changed behaviour. Check whether your own findings improve.
Safeguard's free scan at gold.safeguard.sh/scan can supply real findings from a team's own repository to use in the first session.
Sources
Last reviewed: 19 October 2026.
