To make training pay off, convert it into work within a week: collect the commitments, search your own repositories for the pattern taught, open small tickets with owners, add a test or lint rule, update the review checklist, and re-check in a month. Without those steps, most of the learning evaporates.
Step 1: Collect commitments within a day
If you asked each person for one sentence, such as "On Monday I will check X in service Y," send the list back to the group and to team leads. Seeing names and promises in one place creates a mild, useful pressure.
Step 2: Search for the pattern
Use the lab's bug class as a search query. For injection, look for query building by string joining. For cross-site scripting, search for framework escape hatches such as dangerouslySetInnerHTML or unsafeHTML, which the OWASP cheat sheet names as places where default encoding is bypassed. For access control, list endpoints that take an object id and check which ones lack a test for another user's id.
Step 3: Open small tickets
One ticket per finding, with a file, a description and an owner. Avoid a single giant "fix security" ticket. Small tickets close.
Step 4: Add a guardrail
A fix without a guardrail returns. Options include a unit test that encodes the exploit, a lint rule or static analysis check, a pipeline gate on new findings of that class, or a code review template line. Choose the cheapest one the team will actually keep.
Step 5: Update the review checklist
Add a line to the pull request template for the class you taught: "Any new query built from user input?" Reviewers learn the pattern by seeing it in every review. Our secure coding review checklist is a good starting point.
Step 6: Share one story
Ask a participant to describe in a team channel what they found in their own service. A real example from a colleague does more than a slide.
Step 7: Re-check in a month
Run the repository search again. Count the open tickets, and ask what blocked the rest. Feed the answers into the next session.
Who owns this
Name one person, usually the team lead or a security champion, for each team. If nobody owns follow-up, nothing happens. Give them a time budget, even if small.
What to do about big findings
If the search turns up something serious, treat it as a normal security issue and route it through your usual process, not as a training topic. Do not wait for the next sprint if it exposes real data.
Quick check
How soon should follow-up start?
Within one to two days, while the session is fresh. Set the re-check date before the workshop ends.
What if teams are too busy?
Ask for one ticket per team, not all of them. A small, finished change beats a long list left open.
Last reviewed: 19 October 2026.
