DevSecOps: Some tech jargon you really should understand

Photo by NESA by Makers on Unsplash

Every industry has jargon. So, of course, every industry has abbreviations for its jargon.

Hence, DevSecOps. So much quicker to say, or even think, than DevelopmentSecurityOperations. That’s good for those in the breakneck-paced software development world.

But also that much more obtuse. For the average outsider, the eyes probably start to glaze over by the second syllable.

Which is not so good. And it’s why the average consumer should care about unpacking that abbreviation. Because software, while its creation and functions may be esoteric to all but those on the inside, is behind nearly every element of modern life — your vehicle, your utilities, grocery store, entertainment, health care, education, banking, credit cards, social media and everything else.

It was almost a decade ago that Marc Andreessen, co-founder of Netscape and now a venture capitalist, famously said “software is eating the world.” What seems more accurate now is that software supports and controls the world.

So it is worth knowing more about software than that it is millions of lines of indecipherable code that make things work most of the time. It’s important to have some understanding of its benefits and risks.

You don’t need to be an expert. Most people don’t know how to do a brake job, but they know that the brakes in their cars are important, and that if they aren’t functioning properly, their lives and those of others could be in danger.

Therefore, they would want to know if a car brand had a reputation for faulty brakes so they could buy something else.

Care about software

You ought to care that much about software, and not only because it is now used to control most modern vehicle braking systems. For better and worse, software has invaded pretty much everything we use — that’s one of the reasons you hear the term Internet of Things (IoT). And the reality is that the magical, addictive conveniences and improvements those things provide can be undermined by vulnerabilities in the software that powers them.

The emergence and evolution of DevSecOps is an effort to address that — to bring customers the features and conveniences at the speed they want while protecting their privacy and security.

DevSecOps combines software development (the design, writing and quality assurance of code), security (testing that code for design flaws, vulnerabilities and other defects) and operations (product management and support of apps, networks, systems etc.).

Most people, if they have even heard the term, don’t think much about it. But they’re seeing the results of DevSecOps when they wake up most mornings to find that their phone has a red dot at the top of the “App Store” icon telling them they have anywhere from a couple to a dozen updates to install. Updates never used to come that regularly.

If you look at the little line or two about what’s in each update, most of them say, “bug fixes and other improvements.” In other words, better security and quality.

That is your daily, ongoing illustration of what DevSecOps can do — deliver frequent, regular improvements to the software behind everything you use.

Why did Dev Sec and Ops come to be glued together? It is more a marriage of necessity than anything else. As you probably imagine, those three teams used to be largely separate. Developers would design and write software. When they were done, they would “throw it over the wall” to the security team, which would run tests to find problems — design flaws, coding bugs or conflicts with open source software licensing requirements. They would kick it back to the developers to fix them.

Some things got fixed, some didn’t, which meant that by the time a product made its way into the hands of the operations team and then consumers, its security was not at all a sure thing.

This was not the friendliest environment. Particularly the development and security teams viewed one another with suspicion, if not outright hostility. If they had been opposing parties in Congress, the security team would have been labeled the “Party of No” for trying to block the release of apps with defects.

Developers who were under pressure to build cool features into apps and get them done on time viewed them as an obstacle. The last thing developers wanted was to be forced to fix something they had been working on a week or so earlier. They were trying to meet deadlines. Security was slowing them down.

Not productive either

All of which meant it wasn’t a productive environment either. As the various teams and their leaders eventually realized, looking for bugs in code at the end of what is called the software development life cycle (SDLC) was a bit like looking for flaws in a foundation after the building was up.

“Rework is a killer for team productivity,” wrote Simon King, vice president, strategic program management at Synopsys, in a recent post on Forbes. “Rework wastes time fixing and re-testing a solution and also stresses the development team.”

It’s also much more expensive. According to multiple estimates, the cost of fixing a quality or security defect during coding costs about $80. It rises to $240 if it has to be done during the build, to $960 during the quality assurance and security phase to a staggering $7,600 during production.

Enter DevSecOps, saver of time and money, reliever of stress and conflict.

The idea is that even though each team has a different role to play, they are ultimately on the same larger team with the same goal: Release secure, high-quality software faster than the competition. And fast enough to be responsive to customer feedback.

This is not a new concept. It’s all over the business and athletic world. Every football team has different units — offense, defense, special teams — whose players are rarely on the field at the same time, but they have a common goal: Win the game.

But DevSecOps is not as simple as throwing the teams in the same room and telling them to work together. It requires both better technology and a cultural shift. Organizations with effective DevSecOps generally include:

  • Automated tools. This is where technology helps. Developers are much more likely to accept — even embrace — security if it doesn’t slow them down. And the security industry has responded to that understandable desire with automated testing tools that, in many cases, function a bit like a spellcheck. They check code as it’s being written, so mistakes, bugs, defects and conflicts can be fixed immediately, throughout the SDLC.

The industry term is “shift left” — don’t wait until the end to do security testing. Do it from the start to the finish.

As King noted in his Forbes post, “The way to reduce rework is automation. Automated testing can be repeated many times without missing a test before the developer submits a change. Automated code analysis checks for programming errors before a change is released.”

  • Cross training and security champions. For years, the development, security and operations teams were plagued (some still are) by what is one of the most iconic lines from the iconic movie Cool Hand Luke: “What we have here is a failure to communicate.”

Indeed, it became a cliché that security didn’t understand developers and developers didn’t understand security. No wonder — they may have talked but they didn’t really communicate.

So it shouldn’t be a shock that better communication eases the tension and helps those teams to work together more effectively.

At security conferences throughout the world, experts relentlessly preach the value of teaching developers the basics of secure coding. Not to make them experts but to understand better how applications can be attacked.

On the other side, experts exhort security teams to stop thinking their job is to eliminate every risk — they can’t — but to set priorities to manage the most significant risks. And to make themselves enablers of the need for speed instead of being a drag on development.

That has led to implementing the “security champion” concept — recruiting volunteer members of the development team to become “internal” security experts.

It’s based on the well-established reality that an insider is more likely to communicate effectively than an outsider.

Security teams need the help anyway — they are generally vastly outnumbered. Most estimates are that in a DevSecOps environment there are 100 developers, 10 in operations and just one in security.

So, what better way to give security both a numerical boost and bridge the understanding gap between Dev and Sec? Who better to understand other developers than a developer?

Not mainstream yet

All of this should offer some reassurance to the hundreds of millions of users of billions of apps and IoT devices that software development is increasingly focused not just on speed and features, but quality and security as well.

What is less reassuring is that not everybody is using DevSecOps, and some of those that are aren’t doing it all that well. Indeed, effective DevSecOps is not yet mainstream. The 2020 Verizon Data Breach Investigations Report (DBIR) found that web application vulnerabilities had doubled in the last year alone.

If you’re a consumer, keep that in mind. Don’t mindlessly download an app or buy a device without looking into its security reputation. It doesn’t take all that long to find out what other users say about it and whether it’s been hacked. Spend a few minutes in the short term to save yourself major grief in the long term. You know, kind of like building security into a product from the beginning, instead of trying to patch it on at the end.

If you don’t, you could end up with the digital version of a car with no brakes.