/nov 6, 2017

Application Security Policy: Might Need to Revisit as DevOps Emerges

By Pejman Pourmousa

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.


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.

Related Posts

By Pejman Pourmousa

Pejman Pourmousa is Vice President of Services at Veracode, where he is responsible for the successful adoption of Veracode’s solutions by its customers. This includes program management, customer success, security consulting, manual penetration testing, and customer support. In the last seven years, he has built cohesive teams that help cutomers develop, deploy, and mature their AppSec programs. Pejman has spent the entirety of his career in the area of services management and delivery, specifically around compliance, risk, and security. Prior to Veracode, he was a Manager of Client Services at Integrity Interactive (acquired by SAI Global), where he led the team responsible for the delivery of compliance and risk solutions across SAI Global’s client base. Pejman holds a bachelor's degree in Business, History, and Secondary Education from Brandeis University in Waltham, Mass.