For most companies, software is a tool, a cost of doing business similar to any other piece of equipment. Some companies need a fleet of delivery trucks to do business. Others need a software driven inventory procurement system. Both cost money, a lot of money. Funny as it may sound, no executive gets up in the morning eager to buy either. If they could avoid the expense, they would. But, they can’t.

Those of us who make tools tend to sentimentalize their value. Both truck designers and software engineers can become mesmerized by their work. After all, there is an innate, almost obsessive fascination that goes with making things. Most engineers really do love what they’re doing. But, for those on the receiving end of the technology, all that matters in the end is that the tool works according to expectation.

The good news is that the history of truck manufacturing is one of reliability in terms of cost and features. Sadly, for the art and science of software development, twas but a dream. The history of software development is that of companies writing big checks for software systems and getting poor results. Delays and cost overruns were common. And, when the software finally did show up, there were usually defects that required a number of workarounds. Spending money on software development was more of a roll of the dice than a planned expense.

Something had to be done. Hence, DevOps.

DevOps: The Remedy for a World of Testing Pain

Software development prior to DevOps used the waterfall methodology. For many, waterfall is a world of pain. Each step in the waterfall approach to software development life cycle (SDLC) gets conducted in a strict sequence, by an isolated group. Coders do the programming. Testers do the testing. Release management get the code out to the end-user. Once released, Customer Service deals with the complaints.

Each group is surrounded by a very high, organizational wall. On each side of the wall is a manager who is remarkably adept at tossing over completed work to the next group in the waterfall sequence. Also, the manager is usually good at tossing back faulty work. However, the ability to accept and effectively fix rejected work varies from manager to manager. Dropping the ball on the toss back is not unusual.

History has shown us that the waterfall process created an environment in which each group in the SDLC becomes a tribe with its own language, customs and rituals. Some groups might be friendly to one another. Others might be belligerent. Sadly, belligerence tended to be more common than friendliness.

Programmers consider QA annoying. QA, whose job was to find fault in the code, perceive programmers to be people whose sense of self is defined by one’s ability to dominate the given coding language toward some entertaining end with little regard for the needs of the customer or company. Release management is made up of folks who end up spending more than a few weekends away from family and friends, trying to get a mishmash of code artifacts to work in production. Thus, they’re hostile to just about everybody. Or, so it seems.

The limited information sharing and continuous infighting that is commonplace between groups under waterfall kept driving up costs and failure rates to unbearable, and more importantly, unprofitable levels. Fortunately, Corporate America had a kumbaya moment. Someone had the idea of creating a process that promoted unity over fragmentation and episodic releases of acceptable, working code over a grand release of perfect software. Thus, Agile was born and on it’s coattails came CI/CD and DevOps.

DevOps is, as the name implies, the unification of Development and Operations. The fundamental premise of DevOps is to combine all those associated with making software into a unified, cross-functional group while also injecting automation into as much process as possible. The thinking is to let automation do the rote work and have humans focus on creating better products, better testing and better release processes.

The results have been remarkable. Due to DevOps, deployments are becoming more granular. Automation is doing more of the work of coding, testing and release. Teams are becoming more cross functional. Given recent history, it’s not unreasonable to expect DevOps to continue to allow companies to make better software and lower costs.

It’s a good dream that lasted for a while... until the debacles at Target, Experian and Cambridge Analytica came along.

What Could Possibly Go Wrong?

Christmas 2013 was not a good year for Target. At the height of the Holiday Season hackers broke into its systems and stole the credit card and user information of 40 million customers. To give you a sense of scale, this is equivalent of everybody in the states of Pennsylvania, Ohio, Illinois and Iowa having their pockets picked. To say it was a major security breach is an understatement.

Then, in September 2015, hackers busted into Experian’s infrastructure and stole information on about 15 million users who had applied for service from T-Mobile. The perpetrators got birth dates as well as passport, driver’s license, and social security numbers; all the information a would be impersonator needs to live a life luxury for a long time on a remote, yet warm and wired beach somewhere on the Aegean Sea.

You’d think that Experian would have learned, given a related attack it suffered back in 2012 that resulted in the theft of information about 200 million users. But, it didn’t. However, Experian wasn’t the only victim of cyber-robbery. In September 2014 hackers got their hands on private data about 76 million households stored in the datacenters of the premiere Wall Street financial institution: JPMorgan Chase.

Clearly, when it came to security, the DevOps magic was not working. It seemed as if any kid with a laptop could break into any system, anywhere. Something was dreadfully wrong and a lot of people were getting hurt.

Why? Mostly because up until recently security was never really part of the DevOps way of life. Granted, nobody trivialized security or tried to cut back on the resources it needed to do its work. Security has always been considered essential. The problem was that security was never really given a first-class seat the the DevOps table. To put it bluntly, security tends to be more about birth control than family planning: give Johnny and Suzy enough information and technology to make sure they don’t do anything stupid, but let the bigger picture work itself out… hopefully.

Which brings us to Cambridge Analytica.

The story of Cambridge Analytica is pretty well known at this point. A data analysis company uses existing technology to extract, analyze and repurpose data in a questionably legal way, with far reaching outcomes. Yet, Cambridge Analytica perpetrated no unauthorized intrusion into systems. If anything, Cambridge Analytica violated the Terms of Use of the supporting platform, in this case, Facebook. While, no illegal invasion took place, security was still the problem. No bad tech was used. It’s just that tech was used badly.

So what does it have to do with DevSecOps?

The Value of DevSecOps

As mentioned above, DevSecOps is about giving security personnel a rightful seat the the DevOps table. DevSecOps is about not only making standard security processes part of the SDLC, but it’s also about instilling basic security principles and sensibilities among all members of the development team, from product designers to release managers to Customer Service representatives.

Going back to the Cambridge Analytica example, the issue was more about policy violations than any breach of a security perimeter. Facebook never authorized Cambridge Analytica to share the user data it gathered with others.

Could Facebook have created a technology that would detect such a policy violation? Who knows? But the idea of implementing a security framework that automatically ensures proper policy compliance would have had a whole lot better chance of seeing the light of day had a security expert been an ongoing member of the product’s DevOps team.

What are the Principles of DevSecOps?

The principles of DevSecOps, published in the DevSecOps manifesto, by DevSecOps.org are as follows:

• Leaning in over Always Saying “No”
• Data & Security Science over Fear, Uncertainty and Doubt
• Open Contribution & Collaboration over Security-Only Requirements
• Consumable Security Services with APIs over Mandated Security Controls & Paperwork
• Business Driven Security Scores over Rubber Stamp Security
• Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities
• 24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident
• Shared Threat Intelligence over Keeping Info to Ourselves
• Compliance Operations over Clipboards & Checklists

There’s a quote by the noted quality control expert, Harold F. Dodge, that goes like this, “You can not inspect quality into a product.”

The same is true for security. For too long security has been about inspection. Inspection is useful for uncovering the security hazards of the moment and then addressing those immediate threats. But inspection does not necessarily make the overall environment more secure. Like quality, security needs to be built into a product from the beginning, not inspected in after the fact.

Building security into a product at the start, under the standard practices and sensibilities of DevOps is the essential premise of DevSecOps. DevSecOps is the welcoming acceptance of security personnel, technologies, techniques and sensibilities as an essential part of the continuous software development lifecycle as practiced within the discipline of DevOps overall. DevSecOps is about giving security a first-class seat at the DevOps table.

Is it really that different the DevOps overall? Dunno. We could argue over its nature until the cows come home. But, regardless of definition, DevSecOps is an important addition to DevOps landscape and we’re lucky it showed up when it did.