In a TechRepublic whiteboard video, host Bill Detwiler speaks to Dr. David Brumley, Carnegie Mellon University professor and CEO of ForAllSecure, about the ways organizations can benefit by using DevSecOps.
What is DevSecOps?
Simply put, DevSecOps is a method for folding security in throughout the software development lifecycle. Instead of having a check box at the end, near release, which can be expensive, instead the software is tested repeatedly throughout the development lifecycle. This reflects the fact that software is no longer waterfall by design, that is you state your goal and keep working until you produce the result.
Rather, software is more agile. As it is developed, requirements may change as the software evolves. It’s that evolution that needs to include security.
In the white board session, Dr. Brumley references DevSecOps starting in 1976 with a paper at an IEEE conference. At the time, waterfall was the current software method. Agile was not yet widely used.
Dr. Brumley says with traditional software waterfall development, you start with the requirements phase. What is the business objective? From there you go to design. Here you need to think about individual components, how to break them up, and how to employ teams effectively.
Next is the implementation phase where you build the software which is then followed by the verification phase where you’ll need to double check their work. Dr. Brumley says originally that meant you verify that the software meets the requirements, but with DevSecOps, it also means that it is secure. Lastly is maintenance. This is a waterfall, and there’s at least problems with that.
Three Problems with Waterfall
First problem is that the above process is linear, and that’s not the way the world works. There’s no feedback loop. There’s little ability to iterate the software once it’s started the development process
Second, how do you operate the software? How you build the software will affect how it operates. There needs to be feedback between the developer and the operator. This is how you get DevOps.
Third, how are you going to maintain the software? It can’t just exist, there needs to be a feedback loop to the beginning, to the planning phase, which includes security. This is how you get to DevSecOps. Dr. Brumley insists DevSecOps isn’t a fad; this has evolved from nearly 40 years of research into software development.
Not only is the software development journey a loop, but appropriate security testing needs to be done along the way. Dr. Brumley says there are appropriate tools for each of the different phases of development. In particular, the build step has gotten a lot of attention in DevSecOps.
For example, what kinds of things do you want to secure? Where is your data? What is your attack surface?
Dr. Brumley said, “Back when I was first writing software, you had development and they had come up with maybe a package that you'd go in and install on a completely different system and that this system had one setup and this one had a different setup. Well that's just asking for security problems, right? Tools like Docker become really popular because during development we can test both--a development platform as well as how it's going to be operated and make sure those are consistent and that we've put in all best practices.”
Dr. Brumley said when it comes to testing, organizations look at the Gartner quadrants. There are two sets of tools. Those that look at known vulnerabilities and those that look at unknown vulnerabilities.
Knowns and Unknowns
A known vulnerability is when you include open source components and there’s a vulnerability found for that. This is where software component analysis becomes important. It keeps track of dependencies and updates.
With unknowns, it’s with code you just wrote. Traditionally, developers turn to static analysis tools which look for insecure coding patterns. The problem is, these often produce false positives which require someone to go back and make sure that a vulnerability exists. You can’t take the tool’s word for it. This might slow the process down.
Additionally, there’s dynamic analysis, which looks at how the code performs when it runs. This includes fuzz testing. With dynamic testing, you can prove when it finds a vulnerability. It is reproducible.
Dr. Brumley said if you are asked which is better -- static or dynamic -- he said it is a question of am I going to staff someone to look at reports, or do I want a process that’s more automatic?
Dr. Brumley cited Google as an example. He said they use software composition analysis and fuzz testing. This has been part of their evolution as they embraced DevSecOps.
Dr. Brumley said the good news is that tools are able to work with the lazy eight or infinity cycle of modern software development. He said Docker and Kubernetes help with the configuration and update process. He said on the operations side there’s runtime applications security testing or RASP. These look at the application layer, defending the software against attacks. There’s also web application firewalls. These tools help monitor for security.
The full video is available from TechRepublic.