Why You Can’t Scan Your Way Out of Modern AppSec
Traditional AppSec is straining for one simple reason: AI is multiplying both the volume of code and the number of people who can build it.
You can feel it: Findings pile up while development accelerates. Your team scans more code, adds another checkpoint, and opens another role. Each move helps, but the gaps keep opening.
Your team isn’t failing. The playbook was built for a different way of making software.
A single prompt can now generate an entire feature, including authentication, data handling, and error handling, in one pass. Developers increasingly direct and review code instead of writing every line themselves. People outside engineering can now build useful applications without knowing what a repository, pull request, or security gate is.
The familiar AppSec playbook — scan-gate-hire — still matters. It just can’t carry the whole security program anymore.
In the first Secure Software Coffee Club conversation, NINJIO Chief Product Officer Laura Bell Main put a practical question on the table: Where do tools and gates belong when agents are part of the development lifecycle?
Her answer is practical: Keep what works, and stop asking yesterday’s controls to cover every part of tomorrow’s development process.
What scan-gate-hire still gets right
The scan-gate-hire model became the default for good reasons. Scanners catch real problems, gates protect important boundaries, and security specialists bring context and judgment that automation cannot replace.
A healthy application security strategy still needs all three. Trouble starts when they become the whole strategy.
That approach worked when trained engineers wrote most software and moved it through a controlled process. It strains when AI increases both code volume of software and the number of people who can build it.
Why traditional AppSec doesn’t scale
Traditional AppSec concentrates security at a few checkpoints, but today’s software no longer follows a few predictable paths. More people are building in more tools and workflows, while the volume grows with them.
CloudBees 2026 State of Code Abundance Report found that AI now assists or generates 61% of the average enterprise codebase. Security teams are covering more software, produced faster, across paths they may never see.
Pushing the security team harder won’t close that gap. The problem isn’t effort; it’s reach. Security has to move closer to where the decisions actually get made, not just work faster at the checkpoints it already has.
Scanning starts after the biggest choices
Static application security testing, dynamic application testing, secret scanning, and related tools all have useful jobs.
They can spot vulnerable code patterns, exposed credentials, unsafe dependencies, and other recognizable signs of risk. That feedback can prevent a bad change from reaching production, but the software must exist before it can be scanned.
By the time a scanner reviews a pull request, someone has already made important choices. They’ve decided what data the application will collect, how people will authenticate, which systems it will trust, and who will have access.
A scanner may recognize a dangerous implementation. It is less likely to ask whether the application needed that sensitive information in the first place. Those decisions no longer arrive one small commit at a time. A single prompt can define the data model, authentication flow, and trust boundaries together.
The Veracode 2025 GenAI Code Security Report found that 45% of AI-generated code samples introduced a detectable OWASP Top 10 vulnerability. Scanning hasn’t failed. It’s being asked to evaluate a larger bundle of connected decisions after those decisions have already been made.
Scanning still matters. Be clear about where its job begins and where it ends.
Gates can’t protect work they never see
A senior team may use version control, pull requests, automated testing, security scans, and deployment approvals. A gate works well in that environment because everyone knows where the checkpoints are.
But not everyone builds software inside that path anymore.
Laura uses the term “citizen engineer” for someone without a formal software development background who uses AI to build an application, script, or automation. That person may never touch the official development pipeline. They may not know what security checks exist or when to ask for help.
Most people aren’t trying to bypass security. They’re trying to solve a problem.
They have a deadline, a repetitive task, or an idea that could make work easier. If the approved process feels confusing or inaccessible, they will find another way that works. A gate can’t protect work it never sees. That is the limit of a DevSecOps strategy built around one official pipeline.
Give people a safe, visible path to build useful things, and a clear way to get help when risk rises.
Hiring can’t change the math
A talented AppSec professional can make a huge difference. They bring experience, context, and the ability to recognize risks that do not fit a standard rule. The problem is not the value of that expertise. It’s how many decisions one person can actually make.
BSIMM data via Shostack puts the industry median at fewer than one security professional for every 100 developers. Security teams were already outnumbered before AI increased the volume of software and the number of people who can build it.
Security team scaling can’t depend on recruitment alone. Specialists should focus on the decisions where their judgement matters most. Secure defaults, clear guidance, and simple escalation paths extend their reach.
Agentic development changes the reviewer’s job
Software teams have spent years learning to keep changes manageable. Small stories and focused pull requests help reviewers understand what changed and why.
AI assistants can change that rhythm.
“We, in essence, have become the reviewers and arbiters of enthusiastic junior coders’ work.” – Laura Bell Main
The scaling challenge is helping people evaluate the intent and design behind generated code, not just the syntax at the end. That guidance has to arrive while there’s still time to change the decision.
What replaces scan-gate-hire in security
No single tool replaces scan-gate-hire. A scalable AppSec model combines secure defaults, guidance inside the development process, independent testing, practical education, and access to specialists.
Laura is not suggesting that teams remove tools that already work.
Keep them. Tune them. Make sure the results are useful, not noisy. Scanners remain valuable as independent checks that catch mistakes that a person or AI assistant missed. Improve the reporting so developers and security leaders can act, while auditors and customers can see testing happened.
“We can see them as an efficiency tool for creating the evidence that we need to give comfort to third parties that we’re doing this in a way that they understand” – Laura Bell Main
Give each tool a clear job.
Some controls help people prevent and correct vulnerabilities. Others give third parties confidence that testing happened. Both jobs are important, but expecting one tool to perform both perfectly can lead to frustration.
Bring security into the moment of building
The best time to raise a security concern is while someone is still making the decision.
“The future of secure development is not in syntax.” – Laura Bell Main
Approved AI development environments can bring security policies, design patterns, templates, and examples into the work itself. Teams can check generated work as they build instead of waiting until the end. Useful guidance might include:
- Approved authentication and access-control patterns
- Clear rules for collecting and storing sensitive information
- Standard ways to manage secrets and credentials
- Boundaries for third-party services and dependencies
- Security tests created alongside functional tests
- Clear moments when a specialist should join the conversation
The goal is to make good decisions easier, not turn every prompt into a security checklist.
Independent scanning should still test the result. Now, it serves as another layer of protection, not the first time security enters the conversation.
Welcome citizen engineers into the process
Citizen engineers are already solving real problems. Laura describes the challenge this way:
“You’re not going to be able to stop people from being creative and solving problems. People are like water, and… we’ve got to find ways to get the same functionality that we use in our SAST (Static Application Security Testing) tooling and our gates into any part of our organization that develops software.”
The work won’t disappear because security disapproves of it. It will simply become harder to see. Extend useful safeguards without expecting citizen engineers to already know which security questions to ask.
Start with curiosity: What are people building? Which tools are they using? What information are those applications handling? Where do people get stuck?
Then, offer approved tools, reusable patterns, clear boundaries, and a simple way to ask for help. Let risk set the depth of review, not whether it happens. For example, an internal tool that organizes public information does not carry the same risk as an application that processes customer records or moves money.
Build stronger reviewers, not longer checklists
As AI takes on more implementation work, people need to become better reviewers. That doesn’t mean memorizing every vulnerability. It means learning to spot the decisions that shape security:
What information does this feature collect? Who can see or change it? What happens when the system fails? Which assumptions did AI make? When should someone with deeper security experience take a look?
The Linux Foundation/OpenSSF reports that nearly one in three software professionals aren’t familiar with secure development practices. As more people oversee AI-generated work, that skills gap becomes a coverage problem, not just a training problem.
NINJIO Secure Code provides role-based AppSec education that fits into development workflows. It helps people build the judgment they need across the software development lifecycle.
Training doesn’t replace security tools or specialists. It helps more people make sound decisions before a problem reaches either one.
How to scale application security without more headcount
You can expand security coverage without making every decision depend on another hire. Start with a few practical moves.
Find where software is actually being built
Look beyond the official engineering pipeline. Include AI coding tools, employee-built applications, internal scripts, automations, and low-code platforms. Make it a discovery conversation, not an investigation. People are more likely to show you what they’re building when they believe security wants to help.
Separate protection from proof
Give every scanner and gate a clear job.
Does it help a developer correct a problem? Does it stop a high-risk change? Does it produce evidence for an auditor or customer?
A clear purpose makes each control easier to tune and easier to trust.
Make the secure path the easy path
Create approved patterns for common decisions involving authentication, access, data storage, logging, secrets, and third-party connections. Put those patterns where people and AI assistants can use them. Share the safer option before the final review, not after.
Make expert help easy to reach
Define the situations that need AppSec involvement, such as sensitive data, financial transactions, public-facing systems, high-privilege access, or an unfamiliar architecture.
Then give citizen builders a simple way to reach the right person. Clear escalation points protect expert time and show that asking for help is part of secure building.
Measure coverage, not noise
More findings do not necessarily mean the program is improving. They may simply reflect more code being scanned, more tools running, or noisier rules. Depending on the tool, those findings might flag exposed secrets, vulnerable dependencies, injection risks, weak authentication or access controls, insecure data handling, or cloud and pipeline misconfigurations.
Counting every alert equally rewards volume and can hide the same underlying problem appearing again and again.
Measure what expands the defense: how much of the development environment uses approved patterns, receives appropriate security checks, and has a clear owner. Track whether teams are removing recurring causes. That is a more honest picture of application security at scale.
Build secure development at scale around the people who build
Keep the controls that work. Move guidance closer to the decisions that shape software. Give people patterns they can trust and help they can reach. Let your specialists focus where their judgment matters most.
People are part of the defense, not the problem. Help them recognize the next important decision and give them the confidence to make it well.
That’s how AppSec grows with the people it exists to support. When everyone builds, everyone defends.
