Without These 3 Things, You Don’t Have DevSecOps

DevSecOps adds security to the DevOps software development and releasing paradigm. Everyone thinks this is a great idea, except actual Dev and Ops practitioners, for whom security can be a thankless, stressful time sink. Without the right approach and tools, an organization can run a DevSecOps process that actually contributes little to security. Security simply tags along after development and operations, ignored at every turn. The result is rapidly released, insecure code.

Industry vendors will tell you they have a DevSecOps solution. You, in turn, may believe you have DevSecOps up and running. However, there can be a big difference between acquiring a DevSecOps solution and fielding a viable, effective DevSecOps program.

What DevSecOps Isn’t

1. Every task is manual, and done mostly by consultants.
2. You send out myriad PDFs or spreadsheets and waste time in meetings.
3. Your solution or program escalates a lot of security alerts, but never delivers a fix.

DevSecOps, a Brief Overview

DevOps, the merging of previously separate software development (Dev) and IT operations (Ops) workflows, has been a boon to businesses. When developers work directly with Ops, which releases and manages the code in production, the entire development-to-release cycle speeds up. This is great news, except when it comes to security.

Rushing new code into continuous integration/continuous deployment (CI/CD) platforms invites risk exposure. DevOps can easily, but inadvertently, put vulnerable code straight into production on a daily basis. To mitigate this risk, the DevSecOps approach inserts a security function into the workflow.

This is good, in theory. However, if this is all you have, you do not have a DevSecOps program; you have missed the bigger picture. Without automation, tool integration and results validation, simply injecting security processes into the DevOps workflow might actually make everything worse. Your code will be less secure. The security team will not move quickly enough for the DevOps team, which aims to rapidly release code, and will not always address the security issues raised.

DevSecOps Requires True Automation

DevSecOps has to include true automation in the security process. The practice of security pros copying code for security testing and then returning with a spreadsheet of remediation requests simply does not work. Good intentions aside, the Dev team does not want to deal with a long list of security problems, many of which are perceived to be low-risk or could generate false positives. Security is perceived as slowing everything down. There can even be organizational issues that keep the two groups in opposition to one another.

Instead, code vulnerability assessments should be automated within the DevOps workflow. As code gets checked into Github and then compiled via the build pipeline CI tools, it needs to undergo automatic static, dynamic and interactive analysis. It should undergo a full stack assessment, too. The automated assessment must examine code for vulnerabilities at the mobile or web client layer, the API data transport application network layer and the back end cloud building block app services layer. Automated security testing can analyze microservices, serverless architectures, storage and databases. With this approach, the “sec” part of DevSecOps comprises a “build, set and forget” function. There will be security people involved, of course, but the majority of work is automated.

This automated vulnerability assessment must then generate alerts and establish a priority hierarchy for their handling. Again, automation plays a pivotal role here, and needs to automatically, and in a meaningful way, triage the long list of findings based on issue severity, privacy concerns and app store blockers. If the assessment produces an overly long list of risks to fix, the DevOps teams commonly tune them out as noise that delays release schedules. However, if the automated process identifies the five or ten “must address” problems, developers are more likely to respond to a realistic, practical set of tasks that create an effective process and resolve issues at the roots.

DevSecOps Must Integrate With Development and Security Tools

Security processes are most effective if they integrate with the toolsets used by the DevOps team. These include development tools, cloud platforms and monitoring tools such as security incident and event management (SIEM) systems, as well as ticketing and remediation solutions. That way, security connects directly into the DevOps pipeline; it is neither a digression nor a bottleneck.

For example, if issues get distributed via ticketing systems, they go directly into developer workflows. Developers might be accustomed to working on issues described in JIRA tickets, for example. If the alerts are suitably prioritized, the developers will likely not perceive the ticket as an imposition on their other work. As security issues appear in JIRA tickets, developers can work on them at a familiar, practical cadence. This improves security and DevOps team collaboration by providing details about issues, occurrences, recommendations and remediation. The results can help remediation of security vulnerabilities be more effective.

DevSecOps Provides Validation of Results

A viable DevSecOps program will also provide stakeholders with data about how the program is performing. Reporting and data visualization that documents the results of its vulnerability assessments, and the subsequent remediations, are critical to a successful program. While no application is always perfect on any given release, knowing the risks and having a measurable, clear course of action is critical to a solid DevSecOps program. Successful programs will feature reporting on metrics such as critical issues fixed before production, “business blockers” fixed before rejection, legal costs and regulatory fines avoided and security time and costs saved. Without such reporting and validation of results, there can be no actual DevSecOps. It will be DevOps with some ambiguous security activity surrounding it.

Application security tools are essential to realizing these three tenets of true DevSecOps and an effective appsec program. The preferred tool should be, as these parameters suggest, highly automated and easy to integrate. It also has to have in-depth reporting capabilities. Armed with the right tools, a DevSecOps group can embrace an approach to the work that is fully automated and intuitively part of the DevSecOps workflow.