Security teams are overwhelmed and overburdened by the very tools meant to help them. The “shift left” movement in code security, intended to shift security responsibilities to developers, has largely failed. Instead of easing burdens, it has inundated developers with noisy alerts, straining the relationship between development and security teams, and ultimately putting the burden back on security. This has led to an endlessly growing issue backlog for security teams—a “doom loop.”
How have successful teams addressed this issue? By implementing secure guardrails that notify (but don’t block) developers in their native workflow, and promote the use of secure defaults. These guide developers back to their organization’s “paved road” at just the right moment. The result: fewer vulnerabilities, regained control of the issue backlog, and restored trust between developers and security.
"Modern AppSec programs, like Figma’s, rely on a paved road with secure guardrails for fast and safe development."
–Devdatta Akhawe, Head of Security, Figma
“Notion’s developers are guided towards secure-by-default coding practices by secure guardrails during development.”
–Mayank Dhiman, Head of Security Engineering, Notion
A different approach to AppSec
Secure guardrails, unlike traditional shift-left “gates,” don’t halt traffic (i.e., block merges). Instead, they nudge developers back to a secure-by-default path or organizational standards before they veer off course. For example, if a developer uses an insecure YAML library, they might see a suggestion in their IDE or pull request: “Use this other library for YAML parsing because it’s not vulnerable to deserialization attacks.” This approach has significant implications for AppSec teams, covering interfaces, content, and philosophy.
The return on investment in secure guardrails is deeply connected to the accuracy and reliability of the underlying scanning tool.
Shift left = interface
"Firehose of security issues now pointed at developers"
Secure guardrails = interface + content + philosophy
"Gently drip security knowledge & fixes to developers"
Interface - Early integration: Guardrails should be integrated directly into the developer's workflow, appearing as they write code in their editor. They should feel seamless and native, similar to a linter, providing immediate feedback without requiring the developer to visit a separate security tool.
Content - Autofix with secure defaults: Guardrails should offer automatic remediations, such as “click here to fix.” These fixes should be customized to and align with the organization's development standards, such as how to authenticate users, securely construct SQL queries, or perform encryption.
Philosophy - Empowered developers: Developers should have the ability to view, understand, and modify guardrails. They must retain the option to override guardrails when necessary, with security teams able to audit these decisions later. This balances power between security, who chooses the tooling and standards, and developers, who write the actual code.
At Semgrep, we see our most effective and metrics-driven customers consistently have a well-implemented guardrails program as a common factor. But it's a spectrum–and you don't have to get to A+ to get value.
Here's a scorecard you can use to grade the maturity of your AppSec program:
A+ | A | B | F | |
|---|---|---|---|---|
Speed | On keystroke in editor | Fastest tool in CI pipeline | Not the slowest tool in the CI pipeline | Slowest tool in the CI pipeline |
False positives (as perceived by developers) | 0% | < 2% | < 10% |
|
Where results are seen | In editor | PR/MR comments on the line of code | Somewhere in CI/CD | Some internal tool URL that only the security team reviews |
Actionable remediation | Every result has a 1-click fix (patch, upgrade command, or suggested code snippet) shown in editor | Fix is available | Advice is available | No remediation advice |
Customizable to add contextual understanding of business-specific security issues | Customizable by any developer | Customizable by skilled developers | Customizable, if you have a PhD | Pure black box with no customization |
How Semgrep is different
What's the best way to build these guardrails and encourage the use of secure defaults? We believe it's Semgrep, which bridges the gap between developer tooling (originally open-sourced as a developer tool at Facebook) and security solutions.
Interface:
Semgrep runs scans pre-build: in the editor, at commit-time, and during code reviews. It provides immediate feedback even with incomplete code.
This is quite different from older generation tools which run during or after the build phase as a compiler plugin or on bytecode/binaries. When Semgrep shows results, for Supply Chain, Code, or Secrets, it always points to the line of code you wrote. We even discourage developers from logging into the Semgrep platform. Of course the Semgrep platform provides a dashboard for security teams, but there's no need for developers to ever log in.
Content:
Developers are best served by guardrails that provide guidance in the context of the security policies and best practices of their organization, or even team.
With Semgrep Assistant's new Memories feature, you can just write an English description of how you'd like the remediation advice to be adjusted – Semgrep will learn from and incorporate your instructions into the guidance shown to developers during code review. See the technical blog post on secure guardrails for specific examples of secure guardrails and secure defaults, and what remediation looks like.
Philosophy:
With Semgrep, both developers and security engineers can view, understand, and modify guardrails.
Rules can be forked from the registry or written from scratch. Crucially, no security knowledge or computer science PhD is required. All engineers have agency to change and update the guardrails, rather than dealing with the scanner as a black box. Developers are always in control to dismiss guardrail nudges when appropriate for their use case.
What's new in Semgrep today?
We believe guardrails are the future of writing secure code, and we want to make that vision possible without multi-hundred person security and platform engineering teams. Today, we're excited to announce new features in Semgrep specifically for secure guardrails!
First, Semgrep reporting dashboard tracks guardrails vs backlog separately, which helps teams understand the impact of their work to roll out guardrails.
New guardrails reports measure developer engagement by tracking the number of issues fixed vs. unresolved pre-production and the percentage of total findings surfaced early in development.
Second, we've shipped a new feature for Semgrep Assistant, our AI-powered security engineer: Assistant Memories. It allows teams to tailor remediation guidance to their organization's standards and defaults on a per-project, per-rule basis. In place of a general (but still feasible) AI-generated fix, teams can enter their own custom instructions, and Assistant will provide all remediation guidance for that project and Semgrep rule following the instructions saved in the Memory. Watch the short screencast here:
