Shannon Lietz, VP, Vulnerability Labs at Adobe and Founder of DevSecOps Foundation, shared a talk on the history of DevSecOps at a DevOps Institute SKILup Day. This blog post summarizes the contents of the talk, informing readers how the DevSecOps movement came to be as well as ten key ways to advance DevSecOps in your work.
There are three major movements that have really brought DevSecOps to the forefront:
- Waterfall has become Agile, which also transcended into DevOps.
- Monoliths have become microservices.
- The data center is now giving way to the cloud.
The history of DevSecOps starts in 1976. At this point, folks were trying to define quality for software. That begins with a paper that was written in 1976 to describe the attributes of quality.
Many of these papers described factors associated with what was considered to be next-generation quality. So that turns into the 1978 paper that was also written on quality, so the software quality factors, if you will. They summarized eleven quality factors. But you didn’t see a lot of security anywhere. In the 1970s, there weren’t a lot of hackers, and you didn’t see a lot of software abuse cases. Occasionally, you saw things like access controls come to life. Whether something is secured to the integrity of that software was a very non-critical consideration. Whereas today, security has to be built into the software, which means that it’s part of the product development lifecycle. That’s a crucial thing to remember.
Why is this important? Lietz created the map below to help understand what commoditization was doing to the genesis of new concepts such as DevSecOps. She evaluated what the cloud is doing to bring forward this new set of capabilities as the cloud commoditizes. We see more adoption of the cloud because people are moving away from computers. This also means that they’re migrating to more and more continuous integration, continuous deployments, and software is becoming a way of the future. That means that Agile is also important because customers are demanding more of their problems be solved by software and computers. This essentially creates demand at the top level of this chart that’s forcing more of the problems of software development to be commoditized by having them become part of the software stack.
Finally, this brings us to security. Firewalls were essentially one of the main beginnings of true security. In hindsight, DevSecOps and security were an afterthought when creating a new platform that’s software-defined. The cloud software platforms of today are security-rich, meaning we’re seeing more security as code being possible.
We turn to Dr. Edwards Deming for inspiration. Dr. Edwards Deming did most of his work around the supply chain at Toyota. Some of his principles are spot on when it comes to building software: understanding the costly mistakes in designing, understanding the parts that you’re bringing in, and what defines a security recall. His books have been instrumental in his treatises on software or supply chains. They have given way to inspiring the innovators in software supply chains to look at what it means to build software with great quality and ultimately to have the practice of a great feedback loop. One of the biggest things Lietz believes to be missing has been that much-needed feedback loop for security to go right back to design so developers can consider it.
Another thing to consider is that this is similar to a CI/CD pipeline. With this pipeline, developers build value and availability, while security builds trust and confidence – the best of all worlds. Making software safe doesn’t mean that developers need to become security practitioners, but they need security to be embedded into their DevOps pipeline. DevSecOps practitioners focus on integrating security capabilities into the software development lifecycle and figuring out how to make things come together. This practice is crucial to your DevSecOps practice. Whether you’re building one or just getting started, it’s important to determine how to build trust by understanding what’s happening in your environment, so you get that feedback loop.
Test your DevSecOps knowledge. Get Certified in DevSecOps today!
They say it’s important to understand all sides of an equation. It is crucial to recognize that DevOps is in place because of speed, getting to customer problems and solving them with the customer, practicing customer-driven development, and understanding what it means to design for delight. Practicing these aspects also lends itself to understanding what the security practitioner is trying to achieve: perfection. If you’ve ever tried to combine speed and perfection, you know that’s not always possible. Lietz believes that 60-to-80 percent of the use and abuse cases can be solved when you put them together in the most meaningful way. You don’t have to solve every type of abuse and most use cases. While they don’t solve for the edge case, when you bring everything together, you solve for the right edge cases – meaning the abuse cases – and if you solve for the right use cases, you end up with great software. It is possible to bring enough perfection into the speed that you’re building at. That 60-to-80 percent marker creates confidence in all sides of this equation.
It’s also important to think about the ten different ways to advance in DevSecOps. Considering that everything is software-driven, we’re not seeing the ability for developers to build a data center and create the secure capabilities that people plop their software into. Instead, we’re having to build security into software. That’s a critical element.
Everyone has a different way of advancing in DevSecOps, so here are the ten ways to advance in DevSecOps:
- See the new world.
- Recognize your place in the value chain.
- Know Agile and DevOps.
- Live out bi-directional empathy.
- Do security for the developer’s benefit.
- Operationalize DevSecOps.
- Make security normal.
- Track adversary interest.
- Create security observability.
- Build the future.
The new nirvana is security observability; it’s essential and critical to what we’re trying to achieve because change brings more changes.
We’ve seen now that the growth cycle of DevSecOps is underway, as long as we allow that to happen. It means that one of the questions at the forefront is: how do you measure the security advancements of frameworks like DevSecOps,and having fewer better suppliers and how security is baking itself into the process of rapid software development? How do you measure security? It’s essential to understand that the next part of the journey in advancement is to figure out how to measure something, and security is still in its infancy when it comes to measurement. This is a crucial area of research, which Lietz indicated is why she dedicates much of her time to security measurement.
Test your DevSecOps knowledge. Get Certified in DevSecOps today!
Learn more about the DevSecOps Practitioner Certification.