There is a lot of talk about DevSecOps these days, and we've been working in the area for years now and have learned some things that work and some that don't. First, we'll give you our view on what DevSecOps is, and then we'll make a few recommendations on how to start doing it and get real results in an hour or two!

What is DevSecOps?

DevSecOps is a broad category, but generally it is the inclusion of security across all parts of the software development lifecycle, rather than having it as a gating function at the end or a layer that is added during deployment. Depending on the part of the stack, this can have different process and tooling ramifications. For example, if you're using open source libraries, there are tools such as Sonatype's Nexus that can help you control for potential vulnerabilities in inherited source code. With Fugue, your team is alerted to misconfigured cloud services automatically. The important theme is to embed the practices and tools for security from the inception of the Software Development Life Cycle (SDLC).

Organizationally, this means that the security team needs some development capabilities, or the DevOps team needs security skills. Delivering applications is now highly automated through CI/CD pipelines, infrastructure-as-code, and automated deployments into cloud. Security, therefore, has to automate along with DevOps to keep pace. It also means that the security practitioners need to be embedded in the DevOps team, living in the same sprints and with transparent and clear goals. We'll talk more about where to start in terms of goals a little later.

Why Do DevSecOps?

Ultimately, the goal of all IT is to serve the needs of the business. Security is often an afterthought because historically it's been a rate limiter to meeting those needs. DevSecOps is about making the security team highway builders, rather than toll booth operators. By implementing DevSecOps, security's cadence is increased, allowing the organization to go fast and innovate, while decreasing risk. Done well, DevSecOps will also improve your security posture, as it allows for automation in ways that just weren't possible before due to disconnects with the development and operations teams.

Where to Start with DevSecOps?

If you're operating on the cloud, the most important attack vector is misconfiguration of cloud services. According to Gartner, more than 80% of cloud breaches are due to misconfiguration. In the cloud, developers are creating and modifying infrastructure, so they're making decisions about configurations that can impact the security posture of cloud environments. This is a departure from the datacenter, where ops and security teams had more control over the configuration of IT resources like networks and firewalls. Security needs to get in front of this, while simultaneously not creating too much friction or too many limitations for the developers. The good news is that developers want to create secure systems. With modern tooling, security teams can provide near-instantaneous feedback to the developers that can guide them to getting things right while they are going fast.

The first place we recommend you start is with automated policy checking of existing environments. This can be done in hour or two, and will give you an assessment of your current security posture. We often do workshops with organizations who think they have a solid security posture, but actually have many areas of exposure. It's gratifying to watch them start fixing things immediately, which is what you'll want to do as well! It's very important that after this initial assessment, you use automation to stay up to date, as you’ll find cloud infrastructure frequently drifts out of policy due to manual maintenance and deployment updates.

Once your production security posture is in good shape, turn to making sure that no new problems are created. You can do this by integrating a tool like Fugue into the development process early. When a deployment occurs into a development environment, you can set up your CI/CD tool to trigger a scan which puts security posture feedback right into the tools the developers are used to using on a daily basis. Each pull request can now contain detailed information for the developer on any security issues with their code.

DevSecOps is About Highway Building

Like actual highway building, DevSecOps is an ongoing practice with no real conclusion. In this post we pointed out a couple good places to start, but as you get into it, you'll seem more opportunities for automating security functions as well as the need to go back and revisit earlier decisions on the journey. Done well, DevSecOps unifies the teams rather than having them at tension with each other. Security is no longer a source of "no", but instead provides valuable tools to the developers and operators, working in concert with them. It's a lot more fun than operating a toll booth!