Now more than ever, cybersecurity is top of mind for every business unit – and Development is no exception. In the post-Equifax breach world, we understand that good Application Security isn’t just about tools, but about the processes that deliver the right information into Development pipelines at the right time. This mindset has led companies to explore SecDevOps: the integration of security into Development processes.

The key here is the word “right.” More is not more when it comes to information. In fact, it’s the exact opposite. Yes, we want BIG data, but let’s not confuse data with information.

             da·​ta | \ ˈdā-tə  :  factual information (such as measurements or statistics) used as a basis for reasoning, discussion, or calculation

             in·​for·​ma·​tion | \ ˌin-fər-ˈmā-shən : knowledge obtained from investigation, study, or instruction

In other words, data are pieces of information – like individual bits – without organization or context. When they get this structure – like lines of code – they become meaningful and actionable, and this is information that can be used for decision making. There’s a reason our industry is called information technology, not data technology.  

In Application Security, the data are the security test results and the context is a policy. Without context, there is no way to understand what the security test result means for that company, division or specific project, so that it doesn’t just become another alert that creates bottlenecks.

A Rose by Any Other Name

The concept of a policy already exists in Development, it’s called something different: Coding Standards.

So when Development thinks of policies as just secure coding standards, it not only reduces friction in their adoption, but provides natural points for Application Security to integrate into the SDLC:

• Design: Understand what policies are pertinent to a project and how they will impact project delivery.
• Code: Share the policies with the Developers and allow them to provide feedback during the pull request
• Build: Check – either manually or through automation – to understand if the code meets the standards to be committed.
• Test: Identify security defects, fix what has to be fixed before release and prioritize the rest as part of technical debt
• Deploy: Verify that the code meets the standards set to be released into production – and if not, that it has the appropriate signoffs to be deployed
• Maintain: Continue to identify new security defects and continuously re-prioritize security debt
• Operate: Get continuous feedback on policy performance and real-time understanding of the health of the pipeline from an Application Security perspective

Policies provide the context for how to manage the data at each stage and turn it into actionable information. Going back to Merriam, we’re reminded that a policy is a “method of action…to guide,” which means that it’s not a definitive rule, but a guideline.  That being said, it is critical to have visibility into understanding when the policy has not been followed so that you can make educated decisions on how to handle it.

Why do policies have such a bad rap?

Policies have lived outside of the world that they impact – Development – for too long, often trapped in Excel and PDF files that get distributed quarterly and lack connection back to the work they’re impacting. So, no wonder they often feel aspirational or esoteric. A good policy is rooted in action: how and when to execute and control – and how to manage when it doesn’t work.

• How to execute: What are the instructions? How do I implement it?
• When to execute: In what situations is this policy applicable?
• What is the control: Is this manual or automated? What is the test and how often is it run?
• Exception Handling: Who needs to approve? When will it be fixed (if ever)? 

When the focus is on creating actionable policies, they can be integrated into the existing development processes without disrupting the workflow and will even improve Development productivity, reducing project delivery risk and potential “fire drills,” all while producing better code.

A good policy will evolve. Development priorities and security risk are never static, so policies must be living, breathing entities. As the threat landscape changes, a company grows or enters a new direction, and efficacy is measured, policies are going to change.