Security Training for Teams: Who It's For, and What Actually Changes

Almost every organisation that writes software buys security training, and almost none of it works. The usual shape is an hour-long slide deck, delivered once a year, ending in a multiple-choice quiz that everybody passes. A week later the same team ships the same authorisation bug, and next year's penetration test reports it again.

The failure is not attention span or budget. It is that the training taught vocabulary rather than behaviour. Someone who can define IDOR in a quiz still will not notice this endpoint trusts a user-supplied ID in a pull request, because recognising a definition and recognising a pattern are different skills — and only one of them is built by reading.

That is the whole premise behind hands-on training: every lesson ends with the learner attacking a real vulnerable application and getting in. Below is who that model is genuinely for, what each group should focus on, and what you should expect to change afterwards.

Who it's for

“Security training” gets sold to everyone, which is why it fits nobody. In practice four groups get most of the value, and each is solving a different problem.

1. Engineering teams

The problem: your pen-test report comes back with the same handful of bug classes every cycle. Injection, broken access control, weak authentication. The findings get patched individually, the underlying habit never changes, and the same classes reappear next year in new code.

The focus: the OWASP Top 10 — but exploited, not enumerated. A developer should spend an hour bypassing a login with a single quote and reading a table the login page was never meant to touch. The point is not that they will ever attack production; it is that afterwards they cannot look at string concatenation into a query without flinching.

What changes: the catch moves earlier. Vulnerabilities start getting stopped in code review by teammates rather than in a report six months later by a consultant — which is roughly two orders of magnitude cheaper to fix.

2. Security and AppSec teams

The problem: scanner output arrives faster than anyone can validate it. Junior analysts escalate everything because they cannot tell a genuine finding from noise, and senior people spend their week triaging instead of doing the work only they can do.

The focus: breadth plus methodology. Not just the common bug classes but the full assessment loop — reconnaissance, mapping the attack surface, exploitation, and writing the finding up so somebody else can reproduce it.

What changes:analysts who can answer “is this actually exploitable?” by trying it. Triage stops being a forwarding exercise, and the escalation queue shortens because most of it gets resolved where it lands.

3. Universities and colleges

The problem: lab infrastructure eats the course. Virtual machines break, VPNs fail on campus wifi, student laptops vary wildly, and a meaningful chunk of the term goes on setup rather than security. The lecturer becomes a systems administrator.

The focus: a sequenced curriculum where the lab is already inside the lesson. Students open a link and exploit something in the first session, which is also the single best predictor of whether they stay engaged for the rest of the module.

What changes: contact hours go back to teaching, and per-student progress is visible without collecting screenshots as proof of work.

4. Bootcamps and training providers

The problem: cohorts are seasonal but licences usually are not. You pay for a platform per cohort, and the access you bought for last term sits unused this term.

The focus: a security track that graduates and the employers hiring them will both respect — exploitation students can demonstrate in an interview, not certificates of attendance.

What changes: you can reuse seats, so your bill only counts the students actually taking the course right now — not everyone who ever signed up. When one class finishes, you free their seats and the next class uses them.

Why hands-on is the part that matters

There is a specific reason exploitation sticks where explanation does not, and it is worth being precise about it rather than hand-waving at “engagement”.

• —It produces a memory with a result attached. Reading that SQL injection concatenates untrusted input gives you a sentence. Typing ' OR 1=1 -- into a login form and landing on the admin dashboard gives you an outcome — and outcomes are what get recalled under time pressure in a code review.
• —It teaches the attacker's question. Defenders ask “does this work?”. Attackers ask “what happens if I send something the developer never considered?”. That question is the entire discipline, and it is learned by asking it, not by being told about it.
• —It makes severity concrete. Everyone nods at “broken access control is critical”. It means something different once you have changed a number in a URL and read a stranger's bank statement.
• —It exposes the gap between passing tests and being secure. The vulnerable app in a lab usually works perfectly for its intended users. That is the lesson: your test suite is green and the bug is still there.

What to look for in a platform

Assuming you are convinced on hands-on, the practical differences between options come down to friction and evidence.

• —Time to first exploit. If someone has to install a VM, join a VPN and troubleshoot a network adapter, a meaningful share of your team never reaches lesson one. Measure the platform by how long it takes an average participant to land their first exploit, not by how many labs it advertises.
• —Whether IT has to approve anything. Training that requires new software on managed laptops or outbound traffic to a lab network turns a purchase into a security review. Browser-based training skips that entirely.
• —Per-person progress. You will eventually need to show someone — an auditor, a board, a course committee — who completed what. Collecting that by hand afterwards is miserable; a platform that records it as a side effect is not.
• —Whether seats can be reassigned. Teams and cohorts change. If a seat is permanently bound to the first person who used it, you are paying for churn.
• —Whether learners keep their accounts. People move on. Training tied to a company login vanishes with the job; training tied to the learner's own account keeps its value, which makes it a genuine benefit rather than a compliance line item.

How rollout actually works

The administrative half is worth stating plainly, because it is where most programmes stall — not on content, but on the weeks between buying and anyone starting.

• —Buy a pool of seats sized to the people learning at the same time, not everyone who might participate eventually.
• —Share one invite link. In a company that is a Slack message; in a university it goes in the syllabus.
• —People sign up themselves and claim a seat. Nobody creates accounts, distributes passwords, or approves a queue.
• —Track progress per person and per module from a dashboard, rather than asking for status updates.
• —When someone leaves or a cohort finishes, free the seat and reassign it. Their account and history stay with them.

The summary

Who it's for: engineering teams who keep shipping the same bug classes; security and AppSec teams drowning in unvalidated findings; universities that want to teach security instead of maintaining lab infrastructure; and bootcamps that need a security track employers will respect.

What the focus should be: exploitation over vocabulary. The OWASP Top 10 for developers, the full assessment loop for security teams, a sequenced curriculum for classrooms, and demonstrable skills for cohort programmes.

How everyone benefits: bugs get caught in review rather than in a report, triage stops being a forwarding exercise, teaching time goes back to teaching, and you end up with per-person evidence of what was learned. The infrastructure cost is zero because it runs in a browser tab, and seats follow the number of students actually learning at any one time, not the biggest number you ever had.

The one-line version: buy training where every person exploits something themselves. Everything else — the dashboards, the seat management, the certificates — is logistics around that single requirement.