DevOps has proven to be an effective model for software development, but does it go far enough? It often leaves security as an outside factor, letting it remain an add-on rather than an integral part of the development cycle.
DevSecOps puts security practices into code from the beginning, and it includes testing along with bug checking for every release cycle. It means catching more problems before the release, instead of seeing them turn into emergencies when data thieves discover them. Some extra work up front is a small price to pay for avoiding panic when there's a breach.
Security at every step
A guiding principle of DevSecOps is that it's never too soon to consider what threats a body of code will face and how they can be averted. Threat modeling and risk assessment should start with the design process, and the earliest versions of the code should take them into account.
DevSecOps makes security a major part of continuous integration. It's a natural extension of bug checking, adding emphasis on identifying and fixing vulnerabilities. Automated tests verify not only that the code runs as expected, but that it avoids risky practices and filters all inputs.
The testing looks for well-known vulnerability types, such as the OWASP Top 10. It goes beyond looking for outright defects in code, identifying patterns that are generally risky. For example, it would flag a function that passes unsanitized user input directly to an SQL engine.
Both static and runtime code analysis play a role. Static code analysis follows the control flow in the source code and identifies cases that inadvertently bypass safety checks. Runtime tests simulate dangerous cases, such as accessing a buffer outside its bounds, and report a problem if the code doesn't handle them properly.
Special tools are available for DevSecOps checking. The update and release process will automatically run a set of tests using them. Just as the process would abort a release if it found coding bugs, it will require correction of any security issues the tools report before allowing a release.
Developers understand the need for security, but they can find it annoying. Especially in the early stages, they want to create code that does something interesting as early as possible. Checking for risks when the code is just a glorified "Hello World" will make it take longer to get there, and there's no actual risk when everything is running locally with a throwaway database. It's like resistance to test-driven development, only more so.
Against this, security specialists know that it's easier in the long run if protections don't have to be retrofitted. Programmers may know this too, but their more immediate reaction is wanting to see their code do something, They may even see AppSec as antagonistic, since it's always making them burden their code with checks that complicate it and slow it down.
This shouldn't be an insurmountable problem, though. Making software secure is one more coding challenge for developers to address, and it's no less exciting than incorporating a better sorting algorithm. It's considerably less frustrating than rewriting a large body of code to add security checks or fixing a bug under emergency conditions.
The hardest part is to achieve a shift in thinking. DevSecOps isn't just about tools. It's about getting everyone to work together in an iterative development cycle. If people still think of the cycle as writing code and handing it off to AppSec, they're missing the point. Developers should be aware of security issues as they're writing the code and develop instincts for avoiding vulnerabilities.
Securing older software
Incorporating DevSecOps into a completely new project is relatively easy. Applying it to existing software is more of an effort, but it provides major benefits. A 2017 report disclosed that 94% of all Web applications contain a high-security vulnerability, and 85% have an exploitable vulnerability. Any software developer that hasn't been paying exceptional attention probably has serious security issues in code which it currently delivers. Old methods of avoiding risks are inadequate.
Maintenance of older applications probably uses methods which were popular before DevOps. It very likely has occasional, substantial releases. It goes through a QA cycle, but without exhaustive, automated tests to make sure that everything which used to work still does. Security testing is less than systematic.
Moving from a traditional cycle to either DevOps or DevSecOps requires a significant effort as well as careful handling of the people involved. If a company is going to take the trouble at all, it should go straight to DevSecOps to get the maximum benefit from the transition.
Making the transition
The first steps are going to be hard. A risk analysis is necessary to decide what to look most closely at. The team has to select automation tools for the overall cycle and testing tools to identify bugs and security issues. If the tests are any good, the first run will report a huge number of problems, many of which will prove to be false positives. People with different outlooks will have to work together. No matter how well it's managed, there's going to be a lot of frustration.
The transition to DevSecOps needs to allow time for people to learn how to use the tools and work with each other. Managers should be prepared to mediate a lot of disagreements. It may help to remind developers of all the times they had to stay late to deal with urgent problems. With the new development cycle, they'll catch problems before the release rather than afterward. It's hard to realize it when tests seem to be making ridiculous demands, but in the long run the new process will make their jobs easier and their work schedules more predictable.
It's best to start the transition with one project, preferably a small one with fairly clean code. The people working on it need to have enough time to make mistakes, discard tools that don't work, and understand the new way of doing things. Management should impress on them that even though the project as such may not be at top priority, what they're doing is very important to the future of the company's development process. They're expected to succeed.
Once one project moves successfully to DevSecOps, the rest can make the transition more easily.