Product Security Plans: What They Are and Why They Matter

A product is only as secure as its weakest link. That is why many talented security engineers and researchers recommend embedding security as early in the software development life cycle (SDLC) as possible, even from the very first line of code. Or better yet, even before the very first line of code, during the threat modeling and architecture phase. Smart people have been saying this for a very long time.

So, why does product security still remain difficult?

It is because there is a tendency in the security engineering world to focus on maximum viable security versus minimum viable security — or rather, how to embed the maximum level of security without impacting engineering.

Knowing how to embed the right dose of security while ensuring that developer velocity and productivity are consistent is the hard part. We often talk about product security plans as code and minimum viable security without diving into what they actually mean.

In this article, I’ll share a little more on product security plans, why they matter and why having them as code is key to preventing security from bogging down engineering.

Product Security Plans

Product security plans are a key part of our vision for DevSecOps and security engineering. Product security plans are itemized security checklists that capture:

• Specific domain knowledge
• A security intent and objective for product security (e.g., to achieve product security requirements for SOC2)
• Product security’s implementation in the SDLC
• Verification of the implementation
• Continuous product security monitoring

The most important part is encapsulating this in an as-code plan that any engineering team can apply without having to be security engineering experts.

What does this mean practically? If you take popular and well-known security frameworks, such as OWASP’s DevSecOps Maturity Model (DSOMM), you must apply certain “controls” to cover different requirements. Let’s dive a little deeper.

What Does a Practical Plan Look Like? A DSOMM Example

The DSOMM framework outlines DevSecOps best practices that should be applied in modern engineering organizations. It helps engineering organizations establish a good and expertly crafted roadmap for applying security to real stacks. All of that is great, but it’s hard to understand how to apply this theoretical framework in actual engineering practice.

If you break down this maturity model, you see “implementation,” or application hardening, and “testing and verification.” This is how most security checklists work –– from the OWASP Top X lists, through other common frameworks, industry standards like AWS’s Maturity Model and even SOC2.

The hard part is understanding how to translate the requirement in the form of the “implementation” with a generic name like “application hardening” to the real work that engineering teams must do to tick this box. This is where product security plans come into play.

If you break down an example from DSOMM to encapsulate an actual plan, it would look like this:

1. Specific domain knowledge: Application hardening helps prevent company data or code from being stolen or hijacked from your product’s application code.
2. Intent and objective: Prevent any vulnerabilities or hard-coded secrets from reaching production code.
3. Implementation: Mapping the requirement to the tools that will get this done: - Scan code for vulnerabilities. - Scan code for hard-coded secrets.
4. Verify the implementation: Inject a vulnerability or secret and make sure it is caught.
5. Continuous monitoring: Monitor unresolved app and cloud vulnerabilities that violate your given objective, as well as DevSecOps metrics like mean time to recovery (MTTR) and exposure window.

This plan makes it possible for you to apply security across your entire product’s stack, without reinventing the wheel, through a predefined and well-defined automated security plan.

Mapping Domain Expertise to Security Plans

There are many security domains of expertise that must be captured in security plans to provide the level of coverage today’s products require. They need to be applied on every part of the application’s stack, including:

• Code
• CI/CD
• Infrastructure
• Third-party dependencies/supply chain
• Runtime application security

These can often map to a wide variety of security controls, depending on your programming language, clouds and dependencies, among other considerations. What’s more, many engineering organizations lack the domain expertise needed to translate the security requirements for each part of the stack to the control’s specific configuration.

In other domains such as DevOps, the world of configuration templates, modules and operators is very common, so you don’t need to manually configure your systems and align them to industry best practices for every new environment, virtual machine (VM), container or cluster that uses the same stack.

The same should hold true for security tooling. While there is excellent open source security tooling out there, one of the greatest barriers to adoption is the initial configuration and integration into your toolchain — at least until you see the value and can trust that your systems are covered from a threat perspective.

The other factor is the ongoing maintenance of the tools in your toolchain, particularly ensuring they are constantly up to date with evolving threats and provide relevant security coverage. What if you could automate all of this through code?

Security Plans as Code

Many tools in modern stacks are configured as code, including Infrastructure as Code (IaC), container manifest files and even environment variable files. Today’s developers leverage code as their preferred method for defining different parts of their stack.

Security should be no different.

Security plans as code make it possible to configure your security scanning tools, whatever part of the stack they are aimed at securing. You can even connect them to your pipelines or CI/CD processes so they are continuously running and covering you from a security perspective. We like to call this continuous security.

Mirroring the many communities surrounding popular developer and DevOps tools, a well-maintained library of relevant security-as-code (SaC) templates should be accessible to everyone. When we initially tried to secure our AWS environments, we had to dig through tons of documentation, blog posts and sample Terraform config files to expose the most relevant security configurations for our AWS organization.

Instead, this should be possible and accessible with the click of a button — and security plans as code can deliver on this promise. By capturing security best practices and requirements into automated plans as code, you can trigger the security controls and scans you need just in time and within your typical development workflow, and prevent vulnerabilities and exploits from reaching production.

From IaC to SaC (Security as Code)

There is almost no technology or tech stack that does not prioritize security. There are many excellent security frameworks for defining security best practices by environment, technology, programming language and much more. The last mile is applying this as code in an automated way that is native to developer workflows.

Just as Infrastructure as Code has democratized infrastructure provisioning and maintenance, security as code will bring the same values to secure development practices.

Creating security plans as code for the many different security frameworks, compliance standards and custom requirements in your environment will offload manual implementation of security from already resource-strapped security engineering teams and democratize security for the entire engineering organization.