Skip to content
Notifications
Clear all

Just built a training module for devs based on our common CodeQL alert types.

4 Posts
4 Users
0 Reactions
2 Views
(@k8s_cost_ninja)
Estimable Member
Joined: 5 months ago
Posts: 70
Topic starter   [#9217]

Our team was getting flooded with the same CodeQL alerts. We tracked the top 5 for the last quarter and built targeted training.

The module is a 15-minute walkthrough for each alert type. It shows:
* The vulnerable code pattern (real internal example, anonymized).
* The exact fix.
* Why it matters (links to CVEs).

Example for "Uncontrolled data used in path expression":
```yaml
# Bad
path: "./uploads/" + userInput

# Fixed
path: Paths.get("./uploads/", sanitize(userInput))
```

Result: New PRs with these patterns dropped ~40% in two sprints. The key was using our own data, not generic examples.


null


   
Quote
(@chloeh)
Trusted Member
Joined: 1 week ago
Posts: 45
 

Love this approach! Using your own data turns a generic security lecture into something that actually sticks. That ~40% drop is proof.

Ever think about gamifying it? We did something similar and added a tiny leaderboard for teams with the cleanest PRs after the training. It made a big difference in ongoing adoption, not just the initial drop.



   
ReplyQuote
(@julianp)
Estimable Member
Joined: 1 week ago
Posts: 55
 

Using your own data is the only part that isn't vendor-certified snake oil. The rest sounds like a band-aid on a process problem.

That ~40% drop? It's impressive, but I'd want to see the next quarter. You trained people on five specific alerts, so of course those five drop. What about alert number six? Or the new variant of number two your scanner hasn't been updated to catch yet?

This works for a quarterly hotlist, but it's reactive training. The real win would be if your devs started understanding *why* these patterns are dangerous, not just memorizing the fix for last quarter's top hits. Otherwise, you're just playing whack-a-mole with a custom-built mallet.


If it's free, you're the product. If it's expensive, you're still the product.


   
ReplyQuote
(@liamr3)
Eminent Member
Joined: 1 week ago
Posts: 15
 

That leaderboard idea is clever! Gamification works on us too, we just did something similar with our email template QA process. Made a "rockstar reviewer" badge for the team that caught the most personalization errors before send.

But I'm curious - how did you structure the scoring? We found we had to weigh severity heavily, otherwise you'd get teams just fixing low-hanging fruit to climb the board. A critical path traversal fix should be worth more than a minor linting thing, you know?


ABT – always be testing


   
ReplyQuote