DryRun Security CEO & Co-founder James Wickett sat down to talk with Eric Sheridan, Chief Innovation Officer of Tromzo, while at Developers and Security are Friends Day about what’s causing friction between developers and security, and how to mitigate it.
Causes of Friction: Incentives and Imbalance
There is misalignment between developers and security. Often, security people are incentivized for different outcomes than developers. Developers are generally incentivized for delivering features and trying to ship the feature to the customer as fast as possible, while security is incentivized to limit risk and maintain stability, safety, and compliance.
But, this causes friction.
The friction gets worse when you consider the imbalance in the ratio of staffing. The security to developer ratio of 1 to 100 (although we’ve seen one security person to 400 developers), makes it so that these groups are often at odds and security is unable to match pace with the raw number of changes to the code and system every day.
James likened this disparity to the early days of DevOps. Back in 2009 when DevOps started making waves, it was really common for the operations to developers ratio to be 1 to 10. Compared to that, the security to dev ratio is an order of magnitude worse.
Bridging the Gap
With the move to DevSecOps, many organizations are trying to bridge the two groups of security and developers and get them to work together in a way that is for the good of the organization.
Right now, there are challenges facing both sides. As a result of development teams adopting a DevOps practice, the CI system has now become another area for vulnerability and exploitation for security to worry about.
As security has moved their tools (aka shift left) into the CI/CD pipeline,they have increasingly become a blocking function and significantly increased build time for developers. Instead of increasing productivity by testing early, developers are now being loaded with security testing that is causing them to slow feature development down.
When this happens, developers do what anyone would do in this situation: circumvent the controls. There are two ways they do this.
The first is the most common we see: work-arounds. These can be from flagging security alerts as false, or having a peer do a quick code review to bypass more scrutiny. It might be silencing a shifted left tool, or using a tag or branch that has testing disabled. According to James, if you're seeing work-arounds—and it may be hard to see on the surface—that's where you should focus some effort inside your organization to ask why.
The second is also common, but usually only if work-arounds fail: batching. Batching is the practice of putting as many changes as possible through the delivery pipeline at one time so that you only have to deal with the slowness and penalty once instead of on every single change.
This is a real problem that should strike fear into the heart of any agile or devops organization. We've learned through Agile and DevOps that small code changes more frequently is the path that really helps an organization win. It helps you reduce your cycle time and helps everybody along the value stream. All that comes to a halt if you start batching.
This leaves us wondering, was the shift left of security and all the automation really a good idea? We now have access to a lot of automation, but if you’re seeing new bottlenecks in your pipeline, return to first principles and ask why you're doing something in an organization. The way to get dev and sec teams moving together is to remember how security operates inside the value chain and incentivize them in the same way as we’re incentivizing the developers.
Contextual Security Analysis
Assessing risk for anything is really difficult. Ken Johnson, Co-Founder of DryRun Security, and James have been seeking to make it easier.
- How do we understand the actual security of a code change or of this pull request?
- What does that mean to the organization?
- What does that mean to the project that it's on?
- How does it affect all of its dependent services and things inside of the organization?
Before starting DryRun Security, Ken ran internal security at GitHub and the practices he put in place there led to another question: how can security look at any change and gather all the context needed to do analysis?
There are five key areas:
- Surface - how the surface of the application changes
- Language - the language and framework that the application is written in
- Intent - evaluates the person making the change, both in their patterns and their purpose
- Detection - the tooling in place to detect vulnerabilities and security issues
- Environment - the purpose of the application and service in the organization
This is the SLIDE model.
Contextual Security Analysis uses SLIDE to perform an analysis of every change at the speed of your development team. Using this approach, changes are easier to reason about, faster to approve, and evaluated holistically.
{{blog-button}}
Your Choice for Security
A striking quote in James’ talk came from Steve Belovin, and it comes from Belovin’s book, Thinking Security, as he is surveying the state of the security industry. Belovin says, “Clearly something is wrong…We’re protecting the wrong things, and we're hurting productivity in the process.”
We think that security has to choose. Is it going to be part of the value stream of the organization or is it going to work against the organization and inhibit the value stream? If you’re seeing work-arounds or batching from developers, that's a sign that productivity is hurting and security’s efforts are negatively impacting the value stream.
The security industry needs to move beyond a control-oriented approach and find ways to increase productivity through adding security context for developers.
Wait, there’s more!
Watch the full interview for even more on context plus discussion of AppSec’s future. And you’ll definitely want to get to the end for Eric’s BBQ analogy challenge!
Want to learn more about Contextual Security Analysis? Download the guide.
