Is This a Security Team Problem? Why Secure Code is Actually a Dev Deliverable 

Security teams review code, set policy, run incident response, and maintain the tools that catch what ships. All of that matters, and none of it is in question here. 

Where security’s job ends and a developer’s begins

Everything security does happens after code exists, or around it — never at the point it gets written. Security can flag a risky query. It can block a merge, escalate a finding, and run a retro.  

What it can’t do is sit at the keyboard for the moment you decide whether to parameterize a value or reach for the ORM’s .raw() method instead. That decision happens before security ever sees the code, on your team, in your editor. 

There aren’t enough security people to review everything

Security can’t be the backstop for every line of code. Across nearly two decades of BSIMM research — the industry’s longest-running study of application security programs — the ratio of dedicated security staff to developers has held remarkably steady at roughly 1 per 100, sometimes less.  

This isn’t a single data point. The same ratio appears in the original BSIMM research, in a European cohort measured separately, and in later editions published years apart.  

Different researchers, different companies, same number, over and over again. 

Hiring a few more security people doesn’t change a hundred-to-one ratio. You’re likely hiring more developers at the same time.  

The problem is that security can’t review most of the code your team ships, not because they’re bad at their job, but because there aren’t enough of them to look at everything.

Where the decision actually happens

When a vulnerability ships, it’s easy to ask who should have caught it, but that’s not a useful question. The useful question is, “Who was best positioned to prevent it?” 

By the time a security team sees a pull request, the developer who wrote it has already made every decision that determines whether it’s safe.  

Security isn’t falling short by not being there for that moment. It was never their moment to begin with — the decision happens at the developer’s keyboard, long before the code reaches review. 

The SQL injection example makes the point concretely: Parameterize the customer ID, or don’t. Reach for .raw(), or don’t. That decision gets made once, by one person, at a keyboard, long before security ever sees the code.  

That’s the case for training developers quickly and directly, instead of routing everything through a security audit: The person who can prevent a vulnerability is the person about to write it, not the person who reviews it three steps later.  

The gap is widening, not closing

The ratio problem is also getting worse in one direction that has nothing to do with headcount.  

As AI tools generate more of the average enterprise codebase, the volume of code a security team is responsible for keeps growing, while the number of security staff doesn’t grow nearly as fast.  

The distance between “security owns this” and “security can actually see this” widens every sprint. 

See it, don’t take our word for it

NINJIO Secure Code builds training for developers around the exact decision points they make at the keyboard — not a security audit checklist.