Don't let the DevOps shift left mindset diminish security

Pushing right

The drive to address security issues earlier in the development process doesn't always go over easily.

DevOps shift left is often misunderstood to mean, "It's all on the developers now," said Sergiy Golub, director of engineering at Assembla, a version control software provider. Organizations that follow this methodology often overburden their developers and do their organization a disservice. Shift left means that an organization must think about and address security issues earlier in the process, but it still remains a team effort.

Good developers want to produce good software, but not every developer is a security expert. If an organization puts the onus solely on developers to deliver secure software, that's a recipe for disaster, Golub said. Organizations need to understand that DevOps shift left doesn't happen overnight. While there is a clear long-term benefit, teams must provide the training, tools and time to help their developers reach that point.

One warning sign to watch for is if it takes developers more time to evaluate a problem than to solve it.

Paralysis by analysis is a real concern. "If your team is having trouble figuring out where to even get started towards solving an issue, then it could be a sign that they are not equipped to handle the issue," Sass said. WhiteSource's 2018 State of Open Source Vulnerability Management report found that, of the 20 hours per month that developers dedicate to issues of open source vulnerabilities, on average only 3.8 hours went toward actual remediation work.

Package security for developers

"Instead of shifting left, many organizations are sh---ing left by dumping security tools and processes designed for security specialists onto developers," said Jeff Williams, CTO and co-founder of Contrast Security.

Organizations need to repackage work in a way that's similar to how development teams deliver their product. An organization needs to enable development teams with the right technologies and processes to make them successful. "I think the only work that can't be shifted left is work that genuinely requires specialized expertise in a particular field," Williams said.

Consider small local hints

When most people shift left, the focus often results in more work for developers. However, another strategy requires you to find ways to allow more feedback earlier in the development process. "Small, local hints about improving security should be as far to the left as possible, right in the IDE, as you type," said Oege de Moor, CEO and co-founder of Semmle, a software engineering analytics and code exploration provider. For example, this hint could be not to use a deprecated API with known security concerns.

The deeper commentary, where the suggestion requires some thought, would be most helpful during the code review process. If you shift those deep analyses further left to the IDE, it would slow down the developers in the creative act of coding and take the focus away from their current role. If an analysis is too slow to run during the normal code review window -- typically, up to 30 minutes -- you want to run them as part of the CI/CD pipeline to ensure there are no serious security flaws that enter production.

In the development world, when we need to improve our release times, we often cut out the corners completely.

It's not practical to expect developers to continuously read up on the latest security threats. That's the job of security researchers. Therefore, security researchers need a way to put the latest insights, in automated form, in front of every developer.

For security and engineering teams to truly work together, the security team can't throw too many warnings over the fence for engineers to fix. Engineers will be busy with new features and can ignore a barrage of warnings to focus on their primary task. The security team needs to finely tune code analysis to maintain relevance and keep the trust of their engineering colleagues. De Moor has seen this approach reduce false positives by 90%.

One strategy that works well is to show developers when a dodgy piece of code is a variant of a mistake that caused an earlier security incident. This process can be motivating and help generate a better result for all involved.

Learn to run the tangents

In racing, there is a strategy called running the tangents. This is where athletes run the shortest distance on a course and potentially cut corners to do it. "In the development world, when we need to improve our release times, we often cut out the corners completely," Golub said. A better way to fix this problem would be to run the tangents and also become more efficient using tools.

Ideal tools should be easily integrated into a developer's normal workflow and provide actionable results that improve productivity. This move will incentivize developers to actually use the tools available to them and provide a tangible benefit to application security. When organizations successfully implement a DevOps shift left strategy in this way, developers can spend more time writing new code and less time attempting to reproduce production issues, Golub said.