The Three Faces of DevSecOps

DevSecOps is a hot buzzword these days, and I love it – as well as hate it.

I love it because it embodies a goal the app sec industry, myself included, has been trying to accomplish for years – getting developers to own security. This simple buzzword gives our mission a name and helps its momentum, driving it towards becoming the norm.

I hate it because, like all buzzwords, it doesn’t properly reflect the high complexity behind this journey. Security is a broad topic, spanning infrastructure, application code, network stacks, third party vendors, and, of course, people. Changing how we applysecurity involves a lot of detail, but buzzwords don’t have room for such nuance. Inevitably, different people use it for different meanings – or at least emphasize different parts.

This isn’t surprising, and many buzzwords have a similar effect. More specifically, if you get three experts in a room you’ll get 4 different interpretations of the term DevOps, and 5 of the term Cloud. While we’ll never get to a single definition, writing down the different points of view still helps, as they give us a way to classify what someone means when they use the term.

Looking at its different uses, I see three primary meanings attributed to the term DevSecOps. These views represent different milestones in the DevSecOps journey and align to common interpretation of the term DevOps itself. Let’s go through each and dig one layer deeper into this wonderful and horrible term.

DevSecOps as “Security for DevOps Technologies”

Perhaps the most literal translation of DevSecOps is to describe security solutions for the wave of technologies DevOps brought along. Technologies like cloud, containers and serverless, to name a few, are key players in the DevOps movement. Each of these offers new functionality and introduces new technology stacks, which in turn have specific security needs.

The first step in supporting these technologies is taking an existing security product, which is used primarily on older stacks, and adding the technical components necessary to use it in a DevOps environment. These are mostly minor adaptations of existing tools - as opposed to substantial change in the way the tool operates - simply meant to support the new surroundings.

Let’s take container security as an example. Symantec, McAfee, TrendMicro and others offer endpoint security solutions which include anti-malware, monitoring for malicious network activity and more. These mature products have long worked for servers and virtual machines, and conceptually apply to containers just as much. However, the division of controls between the container and the machine hosting it, along with various other technical differences, prevented these products from supporting containers out of the box and requiring them to adapt. A good example of that is TrendMicro’s Deep Security product, which added container support in version 10 with a new split of responsibilities between the the host machine and the container. This change was enough for them to claim participation in the DevSecOps movement, although the product is still primarily used in traditional security context.

One step further down the path of securing DevOps technologies are security solutions that address the newsecurity needs these technologies introduce. Examples here include CloudCheckr and Evident.io inspecting cloud configurations to find storage buckets inadvertently left publicly accessible (and other issues, as can be seen in the figure below), or Snyk looking for vulnerabilities in open source libraries. Handling newer technologies requires novel thinking, and is often harder for incumbents who are already predisposed and structured to older ways of thinking. It is therefore typically the domain of startups, with big companies stepping in via acquisitions as opposed to building a solution from scratch.

Figure: CloudCheckr’s cloud security assessment results

Containers exemplify this scenario well. The fact the isolation between the host and the container isn’t perfect created a new risk - having malicious code running in a container break out of the container sandbox and impact the host machine. Since the same physical host often runs containers at different levels of sensitivity or even belonging to different owners, sandbox escaping is a real and immediate threat. This and additional new risks introduced by containers opened the door to startups focusing specifically on container security, such as Sysdig, Aqua and Twistlock, who harden the container and flag attempts to break out of it. These startups typically identify themselves as DevSecOps companies through and through.

In both cases, the term DevSecOps refers to securing DevOps technologies. That said, some of these solutions naturally bleed into the way we applyDevOps too, which gets us to the next meaning…

DevSecOps as “Security for DevOps Methodologies”

Beyond its technologies, DevOps drove adoption of powerful new methodologies, such as continuous delivery (CD) and microservices (followed by serverless). These techniques lead to faster development and more granular components, both of which quickly break existing security methodologies.

Once again, these new approaches require an evolution for existing players. Let’s look at CI/CD as an example.

The adoption of continuous delivery means “stopping for an audit” in the midst of the release process is no longer acceptable, requiring strong automated security tests in the pipeline instead. This demand for automation drew attention to static application security testing(SAST) tools, but these took too long – often hours – to complete a single code scan, which isn’t viable in a frequent build environment. To adapt, most SAST tools introduced a concept of incremental scans, only testing the code that changed. These scans complete faster and can therefore fit inside the pipeline. Once again, these tweaks are often featured as a demonstration of DevSecOps prowess.

While such adaptations are important, they’re often not enough. Some new methodologies don’t just change the technical setup, but also break core concepts existing tools rely on, requiring a rethinking of the entire product – again a realm where startups excel. Microservices security monitoring offers a good demonstration of this.

Moving from a monolith application to microservices changes the definition of an app. Instead of monitoring one entity with a set of inputs and outputs, data now flows between multiple – at times dozens or even hundreds – of different services. Successfully identifying attacks in real time in such an environment requires an entirely different security monitoring solution, which scales to monitoring a large number of services and the data flows between them. Startups like Aporeto tackle this problem by tracking service to service communication and flagging unauthorized connection attempts, while startups like SignalSciences focus aligning per-service security insights with their respective ops dashboards.

Figure: Aporeto maps microservice and flags untrusted connections (Aporeto demo webinar)

Beyond overcoming the challenges of these new approaches, such dedicated solutions also capitalize on the opportunities they present. For instance, while containers are logically similar to VMs, they are often stateless and deployed in highly elastic environments. As a result, it’s entirely reasonable to shut down a container which is behaving suspiciously and may be compromised, as no data will be lost, and the system will simply spin up a new one. Such a harsh response is clearly not an option for bare metal hosts and is not viable in a heavy virtual machine either. And, indeed, you’ll be hard pressed to find an endpoint security solution that promotes destroying a machine on alert, while practically all the container and microservice security startups heavily promote doing so.

Adapting to DevOps methodologies is a substantially broader interpretation of DevSecOps than focusing on technologies alone, and far more valuable in the long run. It typically requires some technology support as well (e.g. you can’t secure microservices without supporting containers) but goes on to understand and adapt security to the new processes being enacted. And yet, while it touches two parts of the golden triangle(People, Process, Technology) - it still overlooks the most important one. 

DevSecOps as “Security for DevOps’ Shared Ownership Philosophy”

DevOps isn’t – at its core - about technologies or methodologies, but about people and collaboration. It’s about accepting that keeping our software running well is everybody’s problem, and that we share the responsibility for making it happen. DevOps goes against the practice of devs “throwing code over the wall” for ops to handle and helps ops appreciate the constraints developers face on a daily basis.

This cultural and philosophical shift drives the new methodologies and technologies. It leads to developers writing more operable code, ops treating infrastructure as code, and the horde of ensuing software and techniques to make it scale. This shift is what truly makes business move faster and compete better.

The last and broadest view of DevSecOps follows the same footsteps. To truly address security at the DevOps pace, we must embed it into the regular development and operation processes. Since security teams - like ops teams before them - are vastly outnumbered by developers, the only way to achieve shared ownership is by having the bulk of the daily security activity performed by the development teams. The remaining work should be done primarily by ops, and the security team should spend most of their time empowering those teams, governing and automating this activity (“security as code” to follow “infrastructure as code”).

For existing security solutions, this is a tough change. These businesses are built to cater to security professionals, and their entire go-to-market models, as well as their world view, is focused on that industry. They sponsor security events, use the terminology of security people, and price their product per the security industry’s standards. The bigger the security vendor, the more they’ll have to lose from changing their target market, thus the less likely they are to do so.

More importantly, security products are designed primarily to help the InfoSec person do their daily job, and developer integrations are often done from that skewed perspective. The results are similar to what would happen if VMWare built an IDE, or Citrix created a CI offering. Those are powerful ops tools, but they don’t think developer, and are unlikely to design the right tool for that audience.

Interestingly, this DevSecOps philosophy fits the opposite direction better, that is having developer tooling companies embrace security. These companies have already won the hearts and minds of developers and can now take those developers a step further in their DevOps journey. Source code vendors can tackle code security, APM vendors can monitor for security flaws, and pipeline vendors can harden what goes through them.

This is no longer a theoretical opportunity. In 2017, we saw GitHub add security alerts to its repos, Google Chrome flag vulnerable JavaScript libraries in its built-in dev tools, and Sysdig launcha container security product. These companies also have a learning curve to understand how to build security solutions, but they are anchored in the right place.

Figure: Chrome Dev Tools flags vulnerable JavaScript libraries

Lastly, for startups, this is a golden opportunity. Businesses that sell to developers are far more capital efficient than their security counterpart, as the former have far lower sales costs. In addition, CSOs today are increasingly bombarded with cold calls they learn to ignore, but security solutions already embraced by dev teams will still capture their attention. We now know developers are the new kingmakers in the operations world, and security is likely to follow the same footsteps.

Right now, there are very few security companies focusing on developers. One good example is in the authentication space, where Auth0 is winning developers over with great documentation, a bottom up pricing model and strong community forums and programs. Their latest $55M Series D is one indication of the payoff. Another example I can give here is my own company, Snyk, which fixes vulnerabilities in open source dependencies. We focused on developers throughout, from deep dev tools integrations, through many thought leadership activities, to investing in automated remediation which helps developers more than auditors, and it’s paying great dividends.

Figure: Bringing automated remediation into the developer context inside GitHub

Stats show that organizations that truly adopt the DevOps philosophy get better business results, regardless of the tech and methodologies they used. I expect organizations that truly adopt this DevSecOps interpretation to get the equivalent boost in keeping themselves and their users data secure.

Understanding DevSecOps

DevSecOps is a hot buzzword, and it’s not going away. The term is quickly entering the InfoSec buzzword bingo, and the hotter it is, the more companies and vendors will use it, regardless of what it means.

The next time you come across a solution using this term, I hope this article will help you classify it properly. Is it a security solution that supports DevOps technologies, adapts to DevOps methodologies, or embraces the DevOps philosophy and helps you change your organization? Or perhaps it fits multiple buckets? With the right classification, you can help remove the noise, and focus on the DevSecOps mission.

About the Author

Guy Podjarny (@guypod) is Snyk’s co-founder and CEO, focusing on using open source and staying secure. Guy was previously CTO at Akamai following their acquisition of his startup, Blaze.io, and worked on the first web app firewall & security code analyzer. Guy is a frequent conference speaker & author of O’Reilly “Securing Open Source Libraries”, "Responsive & Fast” and “High Performance Images”.