When Security Meets Development: The DevSecOps Conundrum

DevSecOps can be a confusing concept. Is it a tool? A process? A culture? When do you need DevSecOps? How do you get to that point? What differentiates it from DevOps? Researching the topic often leaves one with more questions than answers.

DevOps started to gain momentum around 2008 when IT operations and software development became more focused on getting code out the door faster and implemented without major roadblocks. Traditional software development life cycles (SDLC) followed a more structured waterfall approach, which led to slower delivery of applications, fixes, and changes.

Then the Agile development methodology started to transform the software development landscape, with smaller and more frequent releases. This faster delivery led to a continuous development process across the entire landscape through collaboration and automation, which has led to the DevOps process. However, many organizations left security to the end of the development process, leading to numerous challenges and issues.

The concept of introducing security into the development life cycle is often termed a “shift left” in the process. Developers are not security specialists and can be reluctant to take on security, as it can impact their ability to push out new code. With increasing pressure to release products in shorter market windows, how does a developer prioritize vulnerabilities? Further complicating the matter is the amount of data that lacks context, making it harder to determine what is required, where, and by whom.

Development and security are not the only teams to be involved in the process. Countless vulnerabilities are found in operating systems, databases, Web servers, and other parts of the infrastructure — most of which are not the responsibility of development, but of operations.

The 5 Stages of DevSecOps Maturity

Source: Ivanti

The concept of shifting left — including security earlier and as part of the development process — is called DevSecOps. It’s about collaboration, awareness, and automation between all teams involved in the development process.

Here’s a brief summary of the maturity journey and each step along the way:

1. Beginner. At the beginner, or basic maturity, stage, there is a desire to undertake DevSecOps; however, organizations are still working in siloed teams with limited collaboration and almost no automation. Releases tend to be large, like a waterfall implementation, and scans are undertaken just prior to release. In this phase of maturity, you are faced with limited vulnerability information and a very reactive approach to resolve issues as they are found.

2. Intermediate. At the intermediate stage, organizations are moving into an adoption phase and have started introducing automation across the process, leading to continuous scans that pick up issues earlier and often. Silos start to break down, and adoption of collaboration becomes common. Software developers are starting to learn about application security and begin applying best practices into their unit testing as part of the acceptance criteria.

3. High. At the high maturity stage, organizations have embraced the DevSecOps process. Within the high maturity state, organizations have a high degree of automation across testing and deployment. Collaboration is now standard, and threat modeling is now incorporated into the process to identify vulnerabilities early and include them in the development life cycle.

4. Expert. In the expert stage, organizations are now undertaking build-based scans with full integration and automation to provide constant feedback to the collaboration teams. Siloes have entirely disappeared, and organizations now have in place cross-functional team alignment. Chaos testing is applied to identify application resiliency, code, and signature validation within the applications.

5. Advanced. Very few organizations have moved into the advanced stage, where an organization centralizes their data into a single source of truth with integration across all tools to collect, normalize, and reconcile events, assets, security, and quality. This single source of truth enables an organization to provide processwide reporting and KPIs to help identify issues in the process and drive improvement, leading to a concept of QualityOps — the holy grail!

The DevSecOps journey is complex but well worth undertaking because it will improve communication, speed up the development life cycle, and ensure quality products. Where does your company stand in its DevSecOps security journey?