I gave up on software security ever being fully owned by software development teams many moons ago. It has always made sense to me that it should be owned by development at a philosophical level, but after two decades and counting, there were no real signs that it would ever happen, and I just gave up hope.

Hindsight here is a layup for a cheesy quote about the definition of insanity is to repeat things over and over expecting a different result, but security teams have repeated the same things over and over again and got the same results: more insecure code and more frustrated developers.

The Problem with Old-School Secure Coding Approaches

As long as I can remember, people wrote policies and standards about what developers can and can't do, and tried to hold them accountable when they didn't follow the rules. Development is so varied that it was always a fool's errand because you could never ever hope to write down everything needed. These policies were always generic , aged worse than Mickey Rourke, usually morphing into “guides” to explain away why written policies didn’t work, and then inevitably ended up being spun as “awareness” material when “guides” weren’t effective. Chapeau, your developers spent hours reading generic material and are now aware that there are lots of potential security issues when building software. It’s like a chapter from a book by Captain Obvious.

Another approach was to send them to “secure coding school” so they can “learn” how to write secure code, only too often to sit them in a classroom with no windows and fluorescent lights, and teach them a few hacking parlor tricks with HTTP, or how to hit the shiny red “scan now” button. Empirical studies have shown that most developers don’t retain the security training information beyond a few months.

It’s just like how I can’t remember any real crypto, even though I studied it as part of a Master's Degree in the Maths department of a top British University. It wasn’t my thing, it didn't interest me, but I had to do it, so I did the minimum, got out of there, moved on, and forgot about it. Despite companies spending millions each year and consultants collecting those millions, it's largely been a waste of time and hasn’t moved the needle. The exception is Jim Manico , who not only teaches but inspires, but he's a rare beast.

Yet another approach was to stop developers' work before it even started by asking them to build and maintain subjective threat models.

Developers loved that: not.

Almost all of them will tell you it’s like going back 40 years and spending months writing and maintaining functional specs, trying to guess everything that might possibly happen. We all know how developers feel about old-school waterfall software development.

RTFSCM (Read The Fucking Secure Coding Manual) was ironically like an RTFM comic itself. Going to coding school was an insult, considering most developers take the piss out of the “coding bootcamps” that sprung up in the noughties, promising lucrative jobs as full-stack engineers after 12 weeks of PHP training. Think twice and cut once flies in the face of “move fast and break things.”

And all of this had an undertone of security people mumbling, sometimes shouting, and occasionally screaming something along the lines of, “Security is the developer's responsibility!” Then, all too often, behind the closed doors of their security frat houses, threatening to beat them with a stick if they didn't do it. It was like threatening to whack kids over the knuckles with a ruler in a classroom to get better academic results.

When you look back in time, there was a common theme that the way security teams asked developers to do security was nothing like the way they built or wanted to build software , culturally, procedurally, or philosophically. Security people were simply from Mars and developers were from Venus.

So if things have changed, and I think they have, a good question is, “What changed that means we now see security teams taking responsibility themselves?” First up, and hopefully obvious, is that it's not more of the above. It's not more endless rules, more reading, more study, and the threat of more beatings. That was what caused the tipping point.

I think the shift happened for a trifecta of reasons.

How DevOps Empowered Developers to Own Code Security

The first is that developers had simply had enough, and when DevOps came along and the autonomy they got handed meant it was easy to take back control. They got to choose what tools they wanted to use, how they wanted their process to work; the power dynamic for security was inverted. No more forms to fill out, classes to attend, paper models to keep up-to-date; just put a tool that solves the problems in a way that worked for them, and suddenly developers were taking responsibility for the security of their own code, like they do for the other things that affected their day-to-day lives, and getting security off their back.

The second is that the smart security teams saw this and even encouraged it. You won’t find mini-dictators anywhere in good security teams anymore, and the relationship has changed from a policing role to a trusted advisor role. Through collaboration, everyone got what they wanted. Security egos were put aside, and it was progress over perfection. Good enough is indeed good enough.

Finally, when development tools vendors saw this happening, they started to buy or build security features into their platforms to sell as value-added extra features. Here we are today with development platforms like GitHub able to meet developers where they are as part of their workflow. Today, companies like DataDog are as much security companies as they are observability companies.

The Right Way to Build Security Testing into Software Development

The key lesson for me is that to move the needle on software security engineering, treat it the way great product teams build products. Describe the problem you are trying to solve, manage the security risk of software, and work with the collective team to come up with a solution that will work for everyone. Align everyone about the problem domain, but don’t tell developers how they need to solve the problem. Let them figure it out for themselves, because when they do that, they will take responsibility for making sure it works.

As a footnote, it's worth noting that this shift has had a dramatic impact on security tools vendors. For instance, at Crash Override, we don't consider ourselves to be a security vendor at all. We are a DevOps vendor that solves security use cases alongside developer use cases. Just like code security is another quality attribute, almost all security problems are two sides of the same coin for security and DevOps. Tech standardizations, shadow engineering , access control, change management, build integrity, etc. I don't think the world will see many application security companies survive in the long term, and fewer and fewer will be born.

Open-Source

Chalk has a new home

Subscribe to our newsletter