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.