A 90-minute secure coding workshop works best as about 15 minutes of framing, 55 minutes of hands-on labs split into two blocks, 10 minutes of discussion, and a 10-minute close where each person commits to one change in their own code. Less talking and more keyboard time is the main rule.
Before the session
Pick one theme. "Injection and output handling" is a better title than "Application security." Send attendees a two-line setup note a few days ahead: install the lab, confirm it starts, bring a laptop. Most lost time in workshops is setup, so ask people to test the lab before they arrive.
Choose labs in the language most of the room writes. A lab in an unfamiliar language teaches syntax, not security.
Minute by minute
0 to 10: Why this matters here. Show one real bug class from your own codebase or a sanitized past incident, not a slide of statistics. People pay attention when the code looks like theirs.
10 to 15: The mental model. One sentence on the bug class, one diagram. For injection, the model is simple: data must not be able to change the meaning of a command.
15 to 45: Lab block one. Attendees exploit a deliberately vulnerable page, in pairs. Exploiting first matters because it makes the fix feel necessary. Walk the room and give hints, not answers.
45 to 50: Break. Short, and real. Pairs swap seats if they like.
50 to 75: Lab block two. Now they fix it. Ask for a failing test first, then the fix, then the test passing. This builds the habit of proving a fix instead of asserting it.
75 to 85: Debrief. Ask which hint helped, which fix surprised them, and where in your own repositories the same pattern might live.
85 to 90: Commit. Each person writes one sentence: "On Monday I will check X in service Y." Collect them in a shared document.
What to cut when time runs short
Cut the framing, never the labs. If the room is slow, drop the second bug class rather than rushing the fix block. A fix that nobody finished teaches little.
Ground rules worth stating aloud
Only attack the lab, never a real system. Do not share exploit write-ups outside the group. Questions are welcome at any point. Say these in the first two minutes.
After the session
Send the commitments list back within a day, with the lab links, so people can redo it alone. Keep the lab available for a few weeks. Our related guide on what to teach first in secure coding training can help you choose the theme.
If you want participants to see how real dependency findings look, the free scan from Safeguard can be pointed at a sample project as an optional extra exercise.
Quick check
How long should a secure coding workshop be?
Ninety minutes is enough for one bug class with real hands-on time. Longer sessions need more breaks and tend to lose the back half of the room.
Should people work alone or in pairs?
Pairs are usually better for a first session. One person types, the other reads and questions, and weaker participants are not stuck silently.
Last reviewed: 19 October 2026.
