A Practical Approach to Security Guardrails

I was recently invited by Semgrep to talk about Security Guardrails informed by my extensive experience of building and scaling security guardrails at organizations like Plaid, AWS and Intel. This post is a synthesized version of the discussion from that talk.

As organizations strive for rapid innovation while maintaining security, guardrails have become essential tools to balance the two.

So what are guardrails and how do we think about these things? In the context of security, guardrails are protective boundaries or standards designed to reduce risks—like safety barriers that keep you on the right path and prevent accidents.

Guardrails are essentially security controls or constraints that provide boundaries and enforce standards.

Let's break this down with a practical example. Imagine you're building a service for document uploads. Within this, you'd have multiple guardrails. For instance, you'd implement secure handling and storage of documents to protect against malicious uploads. This might include parsing documents, checking file sizes and types, verifying file extensions, and scanning for viruses. We can take it a step further by using Compute environments that limit the impact of potential incidents- using services like Lambda or ECS, which employ micro VM architecture, can help reduce the blast radius of zero-day vulnerabilities in a multi-tenant environment. Networking is another crucial component where guardrails play a vital role. You can restrict outbound access for the compute engine and limit access to storage using least-privilege access principles with IAM policies to mitigate risk of data exfiltration.

An iterative methodology to building Guardrails

As you can see, building guardrails is a multifaceted process. Based on my experience, here are some practical strategies that have proven effective:

Consider implementing security controls across various areas: The infrastructure, applications, and the underlying components and libraries your applications depend on
Establish guardrails for foundational service:. For instance, when using Terraform with AWS S3, enforce secure defaults such as blocking public access in baseline modules. This minimizes human error and frees developers to focus on coding rather than navigating complex vendor documentation.
Steer developers towards making secure choices: This is where static code analysis comes in handy. Before diving in, build context about your codebase by identify the languages and frameworks you're using and enable policies or rules to catch insecure patterns in your specific tech stack
Prioritize and review the most frequent security issues: It can help gain insights into your security landscape and uncover opportunities to standardize secure coding practices.
Identify quick wins: By reviewing security incidents, bug bounty reports, and penetration test findings, you can build a library of common code vulnerabilities and incorporate security guardrails that can be scaled through pull request feedback.

Building guardrails is an iterative process. We start small, learn from what we see, and gradually expand our guardrails as the security maturity grows. The goal is to create an environment where secure coding is the path of least resistance.

The Journey to Secure Guardrails

An Org starting from 0 is essentially starting from scratch. In this case, thinking of secure guardrails as a journey with different phases is the way to go:

As highlighted by this diagram from Semgrep, we can break it down into three distinct phases:

Foundational Phase: In this phase where an organization is just getting started, the primary goal is to prevent security incidents and bugs. So it makes sense to cast a wide net to catch potential issues and establish a basic safety net. It is here that we start building outreach with developers to get into the preparation for the next phase.
Contextual Phase: In this phase, we can start to identify patterns specific to the organization, beginning to customize detections and extend coverage for bug bounty and penetration testing findings. Adjacently, we can proactively look for bugs and enforce compliance controls.
Strategic Phase: This phase is the peak maturity phase where an organization starts to shift from reactive to proactive mode. We partner closely with engineering teams to drive efficiency and scale. Alongside this, we can now implement "paved roads" which are pre-approved, secure development paths by using data points to build secure-by-default solutions. It is here that we tackle entire classes of vulnerabilities.

This journey doesn't happen overnight and takes multiple quarters. Each phase builds on the last, gradually transforming security for your organization.

Beyond Secure Guardrails

Implementing secure guardrails is an important milestone, but it’s just one part of the broader security journey. What comes next? Let's look at the next steps from both tactical and strategic perspectives:

Tactical Focus

Promote and encourage adoption

Engage your engineering team
Host workshops, create thorough documentation, or gamify the process for better participation

Ongoing maintenance

Continuously monitor custom rules and policies
Ensure they remain effective and up-to-date

Strategic Focus

Leverage collected data to inform proactive security measures
Invest in eliminating entire bug classes
Build secure modules with embedded security defaults
Foster a culture of continuous improvement
Transition from a reactive to a proactive security approach

As you implement these strategic improvements, you'll likely identify new areas that need guardrails, creating a virtuous cycle of security enhancement.

Gaining Management Buy-In

How do you convince Engineering and AppSec Managers to invest in secure guardrails? A data-driven approach, combined with a clear vision of both short- and long-term benefits, is most effective. Here’s my approach:

Begin by translating security baselines and guidelines into code.
Recognize that this alone may not be sufficient and broaden the analysis to include: Penetration test results, Bug bounty findings and Security incidents
Use this data to:

Develop a plan for creating customized guardrails (rules and policies)
Identify future investment opportunities, such as building libraries to address specific vulnerability classes

Present a strategic plan that:

Highlights the value of implementing guardrails
Outlines how to expand and evolve these guardrails over time
Provides a gap analysis for future improvements

Common Antipatterns in Guardrail Implementation

When implementing guardrails, watch out for these common pitfalls:

Failing to design for developer experience: This is when you build tools without developers and their development workflows in mind. It leads to an poor adoption and whatever little adoption you have leads to friction.
Ignoring Organizational Context: Guardrails need to be context-aware. Building generic guardrails (e.g., for OWASP Top 10) without tailoring them to your specific environment is like shooting darts in the dark
Deprioritizing Guardrails Evolution: As we previously discussed, building guardrails is an ongoing process. Treating guardrails as a one-time implementation leads to stagnant security measures that fall out of sync with evolving codebases and development practices, particularly evident in outdated pull request rules.

Implementing security guardrails is a journey that requires careful planning, collaboration, and continuous improvement. By taking a practical, data-driven approach and avoiding common pitfalls, you can create a robust security framework that not only protects your organization but also empowers your developers to write secure code by default.