Five Principles For ‘Shifting Smart’

CTO and cofounder of Contrast Security—helping companies become truly great at securing their apps and APIs.

In my last article, I described how many in the application security community have been obsessed with “shifting left”—that is, moving application security testing earlier in the software development life cycle (SDLC).

Shifting left was a useful concept a decade or two ago when security testing was not routinely done until late in the process. But recently, some organizations have been fixated on shifting further and further left beyond where it can be effective for many common security vulnerabilities.

Organizations need to take a step back and think about what makes the most sense in their specific context. In my opinion, rather than shifting left for the sake of shifting left, organizations should shift smart—optimizing security testing throughout the SDLC based on each application’s specific needs.

As promised, in this piece, I am offering five principles for shifting smart with application security.

1. Harden your software stack.

You wouldn’t think of deploying a host without hardening it against attacks. But most organizations don’t harden the software stack that they run on those platforms. Hardening your software stack with runtime protection will prevent vulnerabilities from being exploited—even if developers make mistakes.

This is a strong mitigating protection for most vulnerabilities, including published common vulnerabilities and exposures (CVEs) in third-party libraries, problems in custom code and zero-day vulnerabilities that were unknown before. Hardening your stack can be done before any code even gets written and will allow you great flexibility in how you perform security testing and respond to new vulnerabilities.

2. Test what matters when it matters!

Rather than blindly casting a net for everything in every application, you should prioritize security testing based on your threat model. OWASP, NIST and PCI software security standards all now require threat modeling. You only need to test your defenses for the threats that you actually face. Standards are great, but be sure to tailor them to your business.

The types and timing of needed security testing can differ from application to application. For example, you can eliminate SQL injection testing if your application doesn’t have an SQL database. And you can test your authentication and access control mechanisms when they’re fully deployed and configured. Fortunately, most of the development pipeline is automated these days, and the time from integrated development environment (IDE) to production is measured in minutes. So shifting some tests “right” to take advantage of the context available in a fully assembled and running application doesn’t mean you have to give up the benefits of near real-time feedback to developers.

3. Test with the best.

Builders cannot build a house with just a screwdriver, and they don’t put screws in with a saw. Your goal should be to use the best testing technique for each of your defense strategies. You do not need to test every defense with every single technique. For example, injection vulnerabilities are difficult to test with just source code. Interactive tools that trace real data through running code are far faster and more accurate. Authentication and access control are often custom-built and must be analyzed manually with code review or penetration testing.

Rather than trying to use every kind of tool on every kind of vulnerability, organizations need to select security testing approaches that deliver the optimal balance of fast, complete, accurate, easy and cost-efficient. Seek out tools that provide strong evidence of coverage and accuracy for a class of vulnerabilities. Running weaker tools for that same type of issue is unlikely to make your overall results stronger and introduces opportunity costs for your teams.

4. “Notify left.”

Even in cases when security testing shifts later in the process, notification should go left. You should focus on how quickly the security feedback gets to those who need it and route it through the tools they’re already using. If information about a vulnerability gets back to the developer that introduced it quickly, that section of code is fresher in their memory—making the fix faster and easier.

While application security dashboards can be useful for managers, you don’t want developers having to log in and check a separate system. If you have fast and accurate vulnerability data, developers should see that information immediately so they can fix it as part of their normal work. If you put vulnerabilities into a defect database, the odds are that they will never be fixed. Once vulnerabilities become part of the backlog, you’ll have to rely on expensive risk prioritization processes, selecting issues for sprints, service-level agreements, work tracking, retesting and so forth—all of which can be slow and expensive. Based on my experience, high-functioning organizations can remediate vulnerabilities within days. Research has found that it typically takes months for organizations to fix flaws that were discovered by static.

5. Optimize for learning.

Ultimately, the most cost-effective application security program goes beyond finding and fixing vulnerabilities quickly. It helps prevent vulnerabilities from existing in the first place. You certainly should invest in regular security training for developers, as the application security landscape is evolving at least as quickly as the world of DevOps. But after spending over a decade training developers in secure coding, I know they learn a lot more by working on their own code than they do by sitting in a generic training session.

That is another reason that getting rapid feedback back to developers is critical—it can help them learn from the mistake and not repeat it. Repeat that process a dozen times for different kinds of vulnerabilities, and you have a developer who introduces far fewer of them.

Executives and security professionals tend to ride slogans hard until they have far outlived their usefulness. It is time that we recognize that “shift left” can trivialize the complexity of application security and may lead organizations to make bad decisions. To provide secure software for businesses, consumers and governments, it is important to shift in many directions—often simultaneously.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?