DevSecOps Challenges From a Security Perspective

The transition from DevOps to DevSecOps requires security professionals to have a whole new understanding of development processes, priorities, tools, and painpoints. It’s no longer feasible for security professionals to get by with a superficial understanding of how developers work. But this understanding can be a significant undertaking for most security pros who haven’t had to be immersed in the development side of the house previously.

In its new report, Building an Enterprise DevSecOps Program, analyst firm Securosis notes of security teams and DevSecOps, “Their challenge is to understand what development is trying to accomplish, integrate with them in some fashion, and figure out how to leverage automated security testing to be at least as agile as development.”

In this same paper, Securosis highlights the questions security professionals ask them most often surrounding DevSecOps, which include “can we realistically modify developer behavior?” “What tools do we start with to ‘shift left’” and “how do we integrate security testing into the development pipeline?” These are all valid and important questions, but Securosis points out that there are also questions security teams should be asking, but aren’t, including:

• How do we fit — operationally and culturally — into DevSecOps?
• How do we get visibility into Development and their practices?
• How do we know changes are effective? What metrics should we collect and monitor?
• How do we support Development?
• Do we need to know how to code?

The questions the security team is currently asking are about security tasks in DevSecOps; the questions they aren’t asking are about how to understand and work with the development organization. And those are the questions they should start asking. Where to start? The key development areas security teams need to understand when trying to get a handle on application security include the following:

Process: At the very least understand why development processes have changed over the years, what they are trying to achieve, and make sure security testing embraces the same ideals.

Developer tools: You need to understand the tools developers use to manage the code they are building in order to understand where code can be inspected for security issues.

Code: Security tests are shifting left and looking at code, not fully developed applications. The traditional thinking about security audits needs to shift as well.

Open source: You would be hard-pressed to find an app that isn’t made up primarily of open source code. Understand why, and then work with the development team to help them continue to use open source code, but in a secure way.

How security tools affect developer processes: Make sure the security tools you select integrate with the tools and processes developers already use and don’t slow them down with false positives.

Cultural dynamics: You need to fully understand the development team’s goals and priorities – which are most often centered around speed. That understanding is key to getting developer buy-in and acceptance.

SDLC: It’s best practice to include some kind of security analysis in each phase of the software lifecycle. For instance, threat modeling during design, and software composition analysis during development. In this way, you establish a process-independent AppSec program that will work with varying development processes.

For more details on these development areas and practical advice on building an effective DevSecOps program, check out the full Securosis report.