Just as widespread cloud application adoption has led to the emergence of cloud-centric management tools (Okta, New Relic, Mulesoft, etc.), as the DevOps movement reaches ubiquity, the need for DevSecOps becomes more acute. However, with so many vendors wanting to cash in on the buzz, “DevSecOps” is quickly becoming cliche. What does DevSecOps really mean? And, perhaps more importantly, what should it mean?
If we accept that DevSecOps derives from DevOps, then DevSecOps should both embody the core principles of DevOps and address any secondary issues that result from DevOps.
The key tenets of DevOps include:
- Continuous improvement
- Adopting a microservice-based architecture
As such, it would be incongruous for DevSecOps to be heavily dependent on manual processes, only support monolithic code bases or not drive virtuous feedback loops between dev and prod.
As a result of DevOps, many organizations now:
- Release dramatically faster
- Optimize their production environment efficiency to keep cloud infrastructure costs low
So, achieving DevSecOps must include precise and comprehensive application security without slowing down releases. Furthermore, the solution itself must be performant because, while DevOps has obscured infrastructure from engineering, the AWS EC2 bill remains very real to the CFO.
DevSecOps Requirement #1: Protect All Aspects of Your Source Code
Modern applications comprise more than just the code your organization writes. Incorporating open-source components and other third-party libraries does not result strictly from DevOps, but the adoption of microservices has made it easier. To achieve DevSecOps, you must understand the potential code weaknesses in the components that you leverage just as well as you understand the components your team writes. This means:
- Finding vulnerabilities, such as injection or XSS weaknesses, in source code regardless of whether your team wrote it or you are leveraging OSS or other third-party components
- Identifying how critical data flows between microservices
- Understanding how each microservice expects to receive critical data and what the service does with that data
- Discovering known CVEs for OSS components and, most importantly, whether or not your service leverages the vulnerable code
As many recent security breaches have taught us — SF Muni (unexpected deserialized data processed by an open source component), Uber (improper exposure of AWS credentials on GitHub), Equifax (exploit of an OSS CVE) — modern application security requires taking full ownership of all aspects of your code, whether you wrote it or not.
DevSecOps Requirement #2: Comprehensive Protection in Production
Comprehensive protection in production is an obvious security requirement. However, many organizations have settled for less because of the difficulty in achieving comprehensiveness.
At a minimum, comprehensive protection in production must deliver runtime protection for the following security areas:
- Data leaks: Sensitive data written to an external destination, such as unencrypted cloud storage (S3, for example), a logging provider (such as Splunk), or a code repository (GitHub, for example).
- Documented CVEs: Weaknesses in code that you’re leveraging (OSS or other third-party libraries) for which there are documented CVEs.
- OWASP vulnerabilities: Weaknesses in the custom code that your team writes for which, inherently, there are no CVEs
- All of the above, for every release of each microservice.
The common point of failure for most security programs attempting to deliver comprehensive security in production is over-reliance on manual intervention. Manual intervention is limited to what the security team knows. But, for complex applications that change with every release, providing the depth and breadth required for comprehensive security is virtually impossible for security teams. Hence, any runtime protection dependent on manual intervention is only as comprehensive as the knowledge of the security team that maintains it. In theory, static source code analysis can help with depth of knowledge. Yet, these tools are prone to false positives that reduce precision and speed and sacrifices breadth across releases.
DevSecOps Requirement #3: Precision
Precision equals time. If security teams had unlimited time in dev, they could likely identify all potential code weaknesses and finely tune runtime security policies to eliminate false positives. Alternatively, if security teams had unlimited time to react to threats in production, wading through false positives wouldn’t be an issue. Yet, one of the key benefits of DevOps is dramatically shorter release cycles, which means security teams have less and less time to secure applications before new changes are introduced. Whether in the dev or runtime environments, traditional security methods that overwhelm with false positives have never scaled and are only falling farther behind as the release process gains efficiency.
DevSecOps Requirement #4: Automation
Automation is a hallmark of DevOps. If DevOps translates to infrastructure as code, then DevSecOps means security as code. The only way to provide security that is both comprehensive and precise is through automation. While security is stuck making incremental speed improvements, DevOps is driving exponentially faster release cycles. For security to catch up, we must rethink the problem. DevOps isn’t the result of simply speeding up the old way of doing things. It’s not about faster sysadmin physically racking and stacking servers like a NASCAR pit crew (though this might be fun to watch). DevOps is about automation. Yet, security has attempted to adapt to DevOps automation by increasing the efficiency of manual processes. Security must evolve to see manual process as bottlenecks to be eliminated via automation, just like DevOps. Reliance on manual intervention points will simply lead to falling further and further behind automation in the rest of the SDLC.
DevSecOps Requirement #5: Continuous
The goal of CI/CD is to create consistent feedback loops between development and production. If we are rethinking application security from the ground up, shouldn’t DevSecOps also generate security feedback loops? Imagine how much better runtime protection could be if it truly understood source code to the depth of intended functions and with comprehensive vulnerability coverage. Similarly, how much more efficient could development be if engineers knew exactly which vulnerabilities had real world exploit attempts and even knew the exact lines of associated source code? Thus, dev hardens production and production hardens dev.
DevSecOps Requirement #6: Low Production Overhead
Since DevOps is all about efficiency, security that adds significant overhead is a nonstarter. First and foremost, security shouldn’t degrade the user experience. In many respects, but from a different angle, this is why security has been left behind. Organizations are not willing to slow down innovation to identify and remediate vulnerabilities. New features and benefits take precedence. Thus, security that leads to slower customer experience is unlikely to be widely adopted. Furthermore, on-demand infrastructure costs, paid for by the compute unit, would skyrocket.
The natural way to attempt to address a new problem is by modifying or extending the existing tools. Unfortunately this is predominantly how application security is approaching DevOps. For example, Runtime Application Self-Protection (RASP) is the natural adaptation of the Web Application Firewall (WAF) to modern CI/CD. However, DevOps is a massive change and the old approaches simply cannot keep up. For AppSec to remain relevant, without constraining innovation, we must completely rethink the problem from the ground up. That is exactly what we’re doing at ShiftLeft. For more information or to request a demo, check out our website at https://www.shiftleft.io/.
This is a Security Bloggers Network syndicated blog post authored by Andrew Fife. Read the original post at: ShiftLeft Blog - Medium