Subscribe
Velocity is one of the pillars of DevSecOps. Through the magic of automation, DevSecOps teams can achieve impressively short timespans between when developers make changes in code and when those changes are deployed. The measure of those timespans is sometimes used as a badge of honor: “We can go from developer commit to deployment in four minutes” or “We do six deployments a day.”
I like things that go fast as much as the next person, but with DevSecOps, you must keep in mind exactly why you’re trying to go so fast.
The giant leap
In retrospect, traditional approaches to software engineering were naïve. From a business standpoint, the plan has always been to build software that gives value to customers. You can think of this as building a piece of software that moves us from where we are to where we think customers want to be.
To bridge the gap, you go through the traditional steps of the waterfall model:
- Gather requirements
- Design
- Implement
- Test
- Release
Things take a little longer than you thought, because creating software always takes longer than you thought, but 30 months later, you’ve built the software. What you ended up with was not exactly what you intended, but it’s pretty close to where you think customers want to be.
Unfortunately, you were wrong. Maybe you didn’t talk to enough of your customers, or maybe the problem you’re solving brings you into a new customer base, or maybe you didn’t really understand how you could bring value to your customers, or maybe the market shifted significantly during the 30 months that you’ve been creating your software.
Iterate, iterate, iterate
One of the cornerstones of DevSecOps is taking many small steps instead of one giant leap. This makes it easy to adjust your course if it turns out you’ve been moving in the wrong direction. Based on principles inherited from agile development and continuous integration, DevSecOps emphasizes iteration using quick design-build-test-deploy cycles called sprints. Each sprint typically takes two weeks. Instead of building the entire piece of software in one giant leap, you create features iteratively. This provides the agility to change direction as your understanding of the market evolves, and as the market itself evolves.
Releasing on smaller intervals means that you can evaluate your changes and get new features in front of customers sooner than with waterfall development. Whether features work well or work poorly, you’ll know sooner and be able to adjust course on the next sprint if necessary.
Use your robot army in DevSecOps
Another cornerstone of DevSecOps is leveraging automation to build and deploy software without manual steps. This means cutting the time between when developers make changes and when those changes are deployed. This makes perfect sense: if you’re going to build and deploy more frequently, you should optimize the process as much as possible.
We often call this velocity, because it appears that in DevSecOps we are creating software faster. This plays well with the C suite—everybody's boss likes to hear that work is being done faster. To some degree, it’s an optical illusion: it’s just a series of smaller steps instead of a giant leap. DevSecOps also suggests continuous improvement, which means looking critically at the process and adjusting and optimizing it. From this standpoint, the development process should actually become faster and more nimble over time. Once you’ve been doing DevSecOps for a while, it should be significantly more efficient than that old waterfall model.
Security batteries included
Where is security in all this? It’s part of every phase of software development, as it must be. It must be part of sprint planning, design, development, and testing. It should have been every part of waterfall development as well. Historically, however, security was neglected or ignored outright. If it was included, it was often at the end of the development cycle, as a gate to be hurdled before release.
Including security as an integrated part of software development is not a new idea, but DevSecOps shifts the conversation. If building, packaging, and deploying software are highly automated tasks, how does security fit in this scenario?
The answer is doing the right testing at the right time. For the most part, that means automating security tools to the point furthest left in the cycle, as soon as necessary artifacts are available. Static testing, for example, runs on source code. Security should therefore be integrated into the pipeline at the developer’s desktop and run when code is pushed back to the source code repository. Software composition analysis should be integrated at a similar point to manage open source and third-party components. Fuzz testing should be integrated as soon as a binary is available.
Furthermore, security testing must be optimized based on context. When developers commit code changes, your automation should analyze the change and choose appropriate types and levels of security testing. In static analysis, for example, you don’t have to scan all your code all the time; incremental analysis will often be sufficient. Determining the appropriate level of testing and adjusting automatically should be a goal of your automation.
Finally, some security testing will always need to be performed asynchronously. This includes comprehensive tests, extended fuzz testing, red teaming, and other activities. Release gates should be set up as a combination of automated and asynchronous testing results.
Speed with intention
The real win of DevSecOps is not necessarily going faster, but building better software. Quick iterations mean the organization is more nimble and better able to adjust to changing market conditions and perceptions. Heavy use of automation enables the development team to get changes into the hands of testers and customers faster than the traditional waterfall process.
Security is a crucial part of this process. Integrating security into every part of software development means that more bugs are found and fixed during product development, which means lower risk in the final product. With the quick iterations and heavily automated processes of DevSecOps, tuning and optimizing security testing means that the right testing will be done at the right time.
eBook
Trying to get to DevSecOps?
Continue Reading
