The term “DevSecOps” has been on the rise in recent years, popularizing the idea that security needs to be included in the overall software development lifecycle. But with all this talk about DevSecOps comes a big question: does tacking on security tools and methodologies throughout the SDLC really work, or will it just complicate matters?
Even as we innovate by adding in CI/CD pipelines and what appear to be DevSecOps “best practices”, many businesses still face the issue of overtooling their SDLCs and adding in overly complex philosophies, in an attempt to bring dev and sec together. As Ray Ozzie, former Microsoft employee, famously said in a 2005 memo: “Complexity kills. Complexity sucks the life out of users, developers and IT. Complexity makes products difficult to plan, build, test and use. Complexity introduces security challenges. Complexity causes administrator frustration.”
Although he was discussing complexity from a development tools perspective, the same idea can be applied to security too. While a number of point solutions have emerged to address the multi-faceted nature of application security, too many tools and people have resulted in a DevSecOps “hairball”, leaving organizations inundated with data but no actionable information to drive actions. And as an extension of the Agile and DevOps transformations, the adoption of CI/CD pipelines further siloed security as processes fail to keep pace. It means that while DevSecOps is an important concept in theory, it needs to be executed in a way that makes sense with the principles of DevOps.
Security Integration with the CI/CD Pipeline: Still just an Ideal
When it comes to DevSecOps, many businesses are still just tossing around the idea of true security integration into a CI/CD pipeline, without actually adopting it in practice. The real problem at hand: CI/CD focuses on the ability to continuously develop and deploy software that meets the most current needs of the business, but security often can’t keep up. And without security integrated as part of this process, organizations are not able to account for the number of permutations of security requirements that rapidly evolve with changing business needs.
If the integration of security into a CI/CD pipeline did happen as it should, it would look like:
- Organizations responding in real-time for changes both internal (changing databases, software versions, etc.) and external (compliance requirements, threat landscape, etc.)
- Reduced time required to complete security requirements for a release, getting working software to users as quickly as possible
- Stakeholders and users enabled to to access new features and provide feedback immediately, creating an iterative cycle of information for future decision making
But, these principles aren’t really happening in the real world yet. While 66.8% of security teams believe that integrating security in the DevOps cycle is a top 3 priority, only 33% say their organization’s security solutions are mostly or completely integrated. This includes either seamless sharing of data between products/tools, or integrated with custom or off the shelf APIs. According to Forrester: “Because security solutions remain unintegrated, the challenges of ensuring security in the cloud and securing workloads/containers are exacerbated.”
Continuous Security, a New Approach to AppSec
Because continuous integration, delivery, and deployment are such important concepts to DevOps, it stands to reason that security should follow suit. That’s how the idea of continuous security came to be. In essence, this term refers to the automation and orchestration of cradle-to-grave application security programs, ensuring a repeatable and reliable execution of security processes at every step of the software development life cycle (SDLC).
A few of the goals of continuous security include:
- Removing security bottlenecks
- Reducing product delivery risk
- Enabling real-time collaboration between Dev, Sec, and Ops
- Centralizing and automating security governance
- Eliminating manual processes
CI/CD/CS means that the CI/CD pipeline seamlessly includes continuous security. It’s the philosophy of continuously shipping software that meets the most current security standards for the business, and accounts for internal and external change throughout the SDLC. An effective CI/CD/CS does not require full maturity of a CI/CD, but rather can be deployed in any SDLC with a commitment to three key principles:
Automation & Orchestration: It’s important to stop relying on manual processes that slow the SDLC or become an afterthought. Automation and orchestration of the application security program as part of the SDLC is essential to make sure pipelines run efficiently.
Collaboration…but Segmentation: It may seem paradoxical, but delivering the segment of information to the appropriate stakeholder at the right time, without overwhelming all the other roles in the overall SDLC, ensures better collaboration so stakeholders know where, when, and with whom to direct their attention.
Embrace imperfection…but control for it. There is no such thing as perfect code, and therefore no such thing as perfect application security. When you have the ability to accept risk within the risk tolerance of the business, you know the right times to stop, and the times to carry on because you have other controls. Don’t let perfection be the enemy of shipped.
Because different organizations have different risks to be accounted for, security must be aligned to business strategies and priorities. Continuous security focuses on delivering solutions that make sense with each organization’s priorities. With end-to-end integration into the SDLC, continuous security supports CI/CD to improve productivity and time-to-market, while reducing the risks that might impact a particular business or even product-line. Software is inherently impermanent, and organizations need to be able to continuously balance security, technical and business priorities. Most importantly, businesses need to maintain their focus on what matters: delivering value to customers and shareholders.
This post was originally published on the Wabbi blog.