Improving the software development lifecycle has benefits both internally and externally, particularly when security is well-integrated into the process. DevOps, which breaks down the siloes between developers and operations, can shorten and improve the lifecycle. We’ve already discussed what it means to have a culture of DevOps, so now we’ll drill a bit deeper into what DevOps looks like in practice, particularly when thinking about security.
Day 0 DevSecOps, for example, looks different than Day 2 DevSecOps. The former refers to the stage in which DevSecOps is a greenfield endeavor, while the latter takes place a little further down the line, namely, when software has already been deployed. Let’s take a closer look at each of these stages.
Day 0
Day 0 DevSecOps, as the name implies, refers to the very first day of applying DevSecOps to the software development cycle. While your team may have started to build the software, it hasn’t been deployed yet. At this stage, the priority is selecting the proper platforms and tools to use for development and to identify vulnerabilities. Indeed, being prescriptive about the tooling developers need to write software is center stage, as opposed to focusing on the software that the team is producing.
To that end, Day 0 DevSecOps can be broken down into three key buckets: automation, best practices, and static scanning. To start, any process with a long list of pain points—basically anything that no one wants to do—should be a priority for automation. Doing this work upfront takes patience but will pay off in the long run.
Next, Day 0 DevSecOps includes implementing best practices for software development. For example, developers shouldn’t use platforms that haven’t been vetted. Pre-vetted development options with tools and guidance should be built for developers to keep them on track regarding security throughout the development process.
Finally, Day 0 DevSecOps includes static scanning. This takes place once the software is built but before it’s deployed and is a component of the overall push for shifting security left. Static scanning includes running various scenarios to see what vulnerabilities might arise. Common vulnerabilities, as outlined by CWE and/or OWASP, must be addressed before the software is deployed.
Day 2
Day 2 DevSecOps, meanwhile, is an analysis of software that is already in production via continuous, dynamic scanning. Integrating security into DevOps (and shifting security left in the development lifecycle) requires an understanding that a green check today might not be a green check tomorrow. Dynamic scanning is done more consistently and with a greater degree of reliability and resilience than static scanning, offering a valuable lens into the software’s security posture ahead of deployment and every day thereafter.
Another component of Day 2 DevSecOps is container scanning, which can be done through platforms like Prisma Cloud, Anchore, and Twistlock. In simplest terms, these platforms scan OCI compliant Docker images, then send a message or provide a dashboard showing whether any vulnerabilities exist.
Having a dedicated site reliability engineer (SRE) during Day 2 can offer additional gating and enforcement, which offloads those concerns from developers. SREs sit closer to servers than developers and focus on the stability of the software while enabling optimum velocity for change. For example, SREs might work to automate operational tasks such as system management and application monitoring.
Ready, set, deploy
All in all, DevSecOps is a great way to improve the software development lifecycle while bringing security concerns closer to the source. There are other ways to break down DevSecOps approaches, too. DevOps team topologies, for one, were created to help classify and compare team models and DevSecOps practices. But the Day 0 and Day 2 stages offer a great starting point for understanding what DevSecOps means with regards to security over time.
The bottom line is that maintaining a good security posture looks different during different stages of the software development lifecycle. Working with a team that’s new to DevSecOps will vary dramatically from working with a team that already has an established software development team. It’s important to be cognizant of these differences as your team gets started with DevSecOps, to ensure a smooth software development cycle.