Policies are a critical part of your application security program; you need them to frame your program, set goals, measure success, and report on progress. But they can also stall your program if they work against, and not with, developer processes and priorities. With the shift to DevOps, and developers working in a faster and more incremental way, it might be a good time to ensure your policy isn’t holding them back. Is your application security policy DevOps-ready? Pejman Pourmousa, Veracode VP of Program Management at Veracode, recently recorded a quick “chalkboard” video where he outlines our top 5 tips on application security policies. Listen to Pejman as he walks you through:
Tip No. 1: Work with current development processes, not against. With the rapid change in the ways software is developed and released, most of the security policies that were deployed a few years back are no longer acceptable by the development community. Many application security policies were built when we did not have fast, automated security tools that could be plugged into the SDLC. Now more than ever, with teams moving to DevOps and CI/CD, it is important to revisit and build new policies that work with, and not against, the developer goal of “getting good code out quickly.”
Tip No. 2: Don’t set the bar too high. If your development team is new to security, enacting a stringent policy right out of the gate will create pushback and frustration.
Tip No. 3: Not all apps are created equal … Treating all apps equally will leave your developers spinning their wheels to address vulnerabilities that would never lead to exposure of sensitive information. A one-page temporary marketing site doesn’t require the same attention as an application that contains valuable IP. Tweak policies based on the criticality of applications.
Tip No. 4 … nor are all vulnerabilities. Similarly, adjust your policies to ensure your team isn’t wasting time on flaws that are not actually vulnerabilities. Consider whether a flaw is truly an exploitable vulnerability or whether it has compensating controls.
Tip No. 5: Don’t neglect open source components. In today’s development environment, if your policy is only addressing your internally developed code, it’s missing a significant portion of your threat surface. Ensure your policy covers your code, plus any components your developers are adding to your environment. One option is to build developers a library of safe components.
Watch Pejman’s short video to get all the details on these five tips, and set yourself up for AppSec success.