Application Security Policy: Might Need to Revisit as DevOps Emerges

I’ve worked in program management at Veracode for the past six years, and during that time, I have seen a lot of different approaches to deploying AppSec policies. Typically, the security team (CISO/CIO led) deploys an AppSec policy that applies to developers and engineers. However, 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.” Here are some items to consider when right-sizing your application security policy:

Implement achievable policies at first

If security is being introduced for the first time or being enforced for the first time, start off with some achievable policy standards. Don’t make a team that has never had security built into their daily cycle try to meet PCI or all OWASP requirements; they will not pass, feel defeated and give up before they start.

Start with a simple policy: no high or very high critical flaws. Then get more stringent over time as developers adopt security into their daily routine.

Include more than just the flaw types that are disallowed

Make sure you include what types of assessments need to be included (static/dynamic/composition analysis/etc.). In addition, how long do they have to fix something that is found? Add grace periods based on the criticality of the flaw (i.e., a very high critical flaw needs to be fixed in five days; a medium critical flaw needs to be fixed in 15 days; a low critical flaw is not required to be fixed).

Also add frequency and stage requirements. How often do they need to scan, and in what stage of development? This goes hand-in-hand with what assessment types are required. Security must move to the left more and more if it is going to have a place in DevOps.

Right-size your policy

Development teams are releasing faster and faster; make sure you don’t slow them down. Ensure your policies align to the security tools/solutions your developers are using to embed security in their development cycle. For instance, do not require a pen test for each release or towards the end of a release cycle. Change this type of requirement to quarterly, outside the release process. Include automated testing like static in a daily release cycle. In addition, not all apps are created equal, so create different requirements for different apps. For instance, an application that has IP, is public facing and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed.

Governance

It’s definitely best-practice to have an application security policy, but it’s also useless without governance. And it’s on security to figure out how to track policy adherence (many tools today have a policy manager built in that can be reported on).

In addition, if policy is consistently being failed, security needs to partner with development and provide training to help educate the teams (instructor-led training, workshops, webinars, eLearning, capture the flag events).

Key takeaways

• Development environments are changing, make sure your security policies work with them not against them.
• Security policies need to be a “no judgement zone.” Use them to help educate development teams on topics they seem to be struggling with, not to scold them for failing.
• Don’t start stringent. Make policies achievable at first, and then make them more demanding over time as the teams become better at building secure code out the gate, and as you provide the training they need to pass frequently.

Get more details on application security policies in our guide Policy Matters.