Security policies are a critical component of your security solution and selecting the right security policy is critical to secure development. This article looks at the different types and provides insight into what to look for in a security policy to balance security and development efficiency at scale.

Security policies encapsulate a company’s requirements for a piece of code to advance in the software product lifecycle (SPLC). They effectively say: “clear these requirements and you can move to the next phase,” which may be QA, test server, production, whatever. In today’s highly distributed development world, with people working from home and often in different countries, your security policy must be codified and automated inside the development process or it simply will not scale.

The challenge is that many companies use a collection of different tools for various security functions, e.g. vulnerabilities, Software Composition Analysis (SCA), open source licenses, Infrastructure as Code (IaC), secrets, etc. This mix-and-match approach results in a collection of separate security policy tools and different security policies that may conflict when they have overlapping functionality. This results in an operational nightmare. What you really want is a unified security policy strategy.

There are three categories of security policies:

1. Separate Policies
2. Bundles of Policies
3. Unified Policies

Separate Policies

When using different tools to scan for different risks, such as one tool scanning your IaC, another scanning vulnerabilities, etc., you encounter several challenges. Your security team will have to both learn and use multiple tools with different user interfaces. This requires additional time and money upfront and on an ongoing basis. They will also have to deal with conflicts between products. Since products often have overlapping functionality, such as two or more tools addressing vulnerabilities, and since the risk scoring across different products can vary wildly, you might have one tool passing a CVE because it scores it as low, while another rejects the code because it scores that same CVE as high. You can address these conflicts with white/blacklisting, but that merely creates white/blacklist conflicts and maintenance issues. The final issue with separate policies is that you don’t have a single source of truth for compliance or governance. To get a complete picture you need to pull data from all the tools and consolidate it in another tool, adding work and expense.

From a developer’s perspective, separate tools with separate policies means a multi-step remediation process. The developer runs one scanning tool at a time and then resolves those issues before running the next scanning tool, and so on. This is because overlapping tools will generate a ton of duplicate issues that confuse and slow the remediation process, so developers run them serially, which is a slow process.

Bundles of Policies

There are a couple of tools that will scan all the risk types: IaC, vulnerability, licenses, etc. These tools provide a single user interface for building bundles of policies. By providing a one-stop shop for building policies for each of the potential risks, it reduces learning time and implementation time. This approach also eliminates conflicts between scan results, policies, and white/blacklists. By using a comprehensive security scanning tool, the security team gets a single source of truth for compliance and governance. And finally, developers love comprehensive security scanning because they get a single punch list for remediation from a single tool. This is the current state of the art for security scanning. However, this approach merely bundles up separate policies that are each dedicated to a single type of risk, it doesn’t correlate multiple risks into a unified policy.

Unified Policies

Users are starting to appreciate the value of security asset management tools, where they can correlate all the various risks. These tools provide context that enables you to determine the true risk profile of your containers. Naturally the next question is: “How do we get that same level of correlation and context into our security policies?” I haven’t seen any security vendors generate context-rich security policies that correlate various risks yet, but I’m sure that is the next wave of innovation we should anticipate. This sort of highly correlated unified policy would be exceptionally valuable because it provides a more realistic perspective of the aggregate risk.

Conclusions

Using a collection of specialty scanning and policy tools results in conflicts between tools, serialized (slower) processes, and leaves you without a single source of truth for compliance and governance. Comprehensive security solutions can scan for all the potential risks and then evaluate them with a single bundle of policy rules. This approach addresses all the deficiencies of separate policies, but under the covers they are merely a bundle of individual policies for each risk type. We believe that the next generation of policy will be patterned after security asset management tools, where users can add context and correlations to evaluate the true risk profile of each container based on a holistic view of its various risks: security, legal, content and deployment risks. We hope to work with you as we make container security easier and more effective.