Most security labs end at the flag. That is how the industry keeps producing script kiddies.
"Script kiddie" is a twenty-five-year-old insult for someone who runs exploits they do not understand. It is usually said with contempt. It is more useful to read it as a product description — because it is exactly what most security training is designed to produce, and the design is visible in how

"Script kiddie" is a twenty-five-year-old insult for someone who runs exploits they do not understand. It is usually said with contempt. It is more useful to read it as a product description — because it is exactly what most security training is designed to produce, and the design is visible in how the exercises are scored. Open any popular hands-on platform and look at what earns the green tick. PortSwigger's Web Security Academy — arguably the best free resource of its kind — marks a lab as solved the moment the attack goal is reached: the admin panel opens, the other user's data appears, the alert fires (PortSwigger). Hack The Box machines and TryHackMe rooms are complete when the flag is submitted. Capture-the-flag competitions are complete when the flag is captured; it is in the name. The accompanying reading often has a section on prevention. The graded act is the exploit. Nobody asks for the diff. That is not an accident and it is not malice. CTF grew out of offensive training for penetration testers, and for that audience "make the payload work" is the job. The problem is who ended up using the material: developers, students, career changers — people whose actual job will be to stop the payload, not to launch it. Three separate bodies of data describe the same gap. The people who write the software were never taught. The Linux Foundation and OpenSSF surveyed about 400 development professionals in 2024. Nearly one in three said they were unfamiliar with secure software development practices. Sixty-nine percent said on-the-job experience was their main way of learning it, and the report estimates it takes about five years of that to reach a minimum level of familiarity. The two most cited obstacles were lack of time (58%) and lack of awareness and training (50%) (OpenSSF, 2024). Training that grades the fix works — and almost nobody gets it. Secure Code Warrior analysed nine years of data from 600 enterprise customers and found that organisations with more than 7,000 developers trained in secure-by-design practices introduced 47–53% fewer vulnerabilities; smaller organisations in the case studies ranged from 20% to 80%. The same analysis estimated that roughly 4% of developers worldwide apply CISA's secure-by-design practices (CyberScoop, 2024). Researchers working with Siemens reached a similar conclusion from the other direction: citing a survey of more than 4,000 developers in which fewer than half could spot a security hole, Gasiba and colleagues proposed a different kind of challenge for industry — one built around entering code that an automated coach checks, rather than around breaking in (Gasiba et al., 2021). The idea is older still: the "Build It, Break It, Fix It" contest of 2016 added a third phase in which teams had to repair what other teams broke in their code (Ruef et al., 2016). The bottleneck is the fix, not the finding. Veracode's 2026 State of Software Security reports that 82% of organisations now carry security debt — up 11% in a year — that 60% carry debt classed as critical, and that nearly half of all applications (49%) have flaws that have sat unfixed for more than a year (Veracode, 2026). HackerOne's platform data for the year to March 2026 shows submissions up 76% while the number of vulnerabilities actually resolved each month fell by about 46%; the backlog of validated-but-unfixed findings grew more than twenty-fold (HackerOne, May 2026). Put the three together. The industry is drowning in findings, starving for fixes, has evidence that fix-oriented training cuts vulnerabilities roughly in half — and trains people almost exclusively to find. The exploit pipeline rewards the payload. Its graduates can make ' OR '1'='1 log them in and cannot say which line to change, because no exercise ever asked. The developer pipeline never showed them the payload at all; they learn security, if they learn it, from the incident five years in. The two groups then meet in the same place: a bug bounty queue. One side writes reports without a root cause. The other side cannot act on them. The report says "the payload does something". The maintainer needs "here is the decision that is missing and here is the change that makes it". Neither party was trained to produce that sentence, and the gap between them is where triage time, bounty budgets and maintainer goodwill go to die. AI did not create this. It automated the first pipeline. A model can generate a plausible payload and a plausible paragraph about impact at almost no cost; what it cannot reliably generate is the verified root cause, which is the only part that was ever scarce. That is why curl ended its bounty over what its maintainer called "crap and non-well researched reports" (The Register, Jan 2026), and why the platforms are now selling validation as a product. A lab that ends at the flag teaches where the payload goes. A lab that ends at a passing test teaches where the decision lives — and those are different pieces of knowledge. The format is simple and the research above describes it in several forms. First the learner exploits the bug, so the failure is concrete. Then they receive the vulnerable handler — the actual function, not a description of it. They change it. The server re-runs the original exploit and a small regression suite against their version. Green means the exploit no longer works and the legitimate behaviour still does. What people learn from that second half is specific: that authorization is a decision about a person, an object and an action, taken next to the object; that a parameterised query is a boundary, not a string trick; that an allow-list belongs at the sink, not in the form. They also learn the thing every reviewer eventually learns — that the fix is often one line, and finding the right line is the whole skill. Breachloom was built around that split. Its 81 challenges end at the flag like everyone else's. Its 18 CodeOps missions do not: each hands over the vulnerable code and grades the repair, with the server replaying the attack. Four of them map onto the bugs above: IDOR — add the ownership decision the invoice endpoint never made: https://breachloom.com/codeops/owner-bind/ SQL injection — turn a concatenated query into a parameterised one: https://breachloom.com/codeops/query-lock/ XSS — fix the sink, not the input: https://breachloom.com/codeops/dom-guard/ JWT — verify the signature and the claims that matter: https://breachloom.com/codeops/jwt-verify/ Everything runs in the browser against fictional applications; nothing to install. The training industry is very good at producing people who can make an exploit work. The data says the world needs people who can make it stop working, that such people are rare, and that teaching them is measurably possible. Until the green tick moves from the payload to the patch, "script kiddie" will keep being an accurate description of the graduate. Sources: OpenSSF / Linux Foundation — Secure Software Development Education 2024 Survey · CyberScoop — Secure-by-design ROI, Secure Code Warrior data (Oct 2024) · Gasiba, Lechner, Pinto-Albuquerque, Zouitni — Design of Secure Coding Challenges for Cybersecurity Education in the Industry (2021) · Ruef et al. — Build It, Break It, Fix It (CCS 2016) · Veracode — 2026 State of Software Security · HackerOne — Finding Fast, Fixing Slow (May 2026) · The Register — curl shutters bug bounty program (Jan 2026) · PortSwigger Web Security Academy
Key Takeaways
- •"Script kiddie" is a twenty-five-year-old insult for someone who runs exploits they do not understand
- •This story was reported by Dev.to, covering developments in the dev space.
- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.
📖 Continue reading the full article:
Read Full Article on Dev.to →


