What the heck are Security Guardrails and why are they important?

So, let’s start off by just letting anyone reading this know…there are going to be ten other blogs in this series around security guardrails (look at the end of the blog for all of the links as we release them). We will address the top ten we think are most important. We are open to having a healthy discussion if you disagree on the ranking, if we left any out, or just want to have a beverage and chat. Cheers all and thanks for reading this!

Security Guardrails noun

se·​cu·​ri·​ty guard·​rail | \ si-ˈkyu̇r-ə-tē ˈgärd-ˌrāl \

Definition of security guardrails
: orchestrates security tools by integrating them seamlessly into your existing application development workflow – associating policy to keep the noise low and only report high-impact and relevant security issues.

Cloud Security Guardrails, Application Security Guardrails, DevSecOps Guardrails, Kubernetes Guardrails, Security Guardrails AWS, Security Guardrails Azure, Guardrails Agile, Guardrails Github

Examples of security guardrails in a Sentence
// Security guardrails empower centralized security.
// Security guardrails empower compliance and risk functions.
// Security guardrails enable the appropriate level of security and compliance controls within the software development lifecycle.

Well…that was fun, got to play Merriam-Webster for a moment. Let’s dive into what we really mean from our perspective and how we see history NOT repeating itself with our customers.

Modern Application Security

Note to developers: Y’all are shipping code so freaking fast. Major kudos to y’all but DANG on the security side we have no chance of catching up.

security guardrails

We don’t have to tell you how code is developed and deployed leaving no chance to understand or control security implications of the software being developed. Even Google says so (and let’s just assume y’all are “elite”) in their State of DevOps 2021 report:

State of DevOps 2021

973x more frequent code deployments and 6,570x faster lead time (from commit to deploy)?! Seriously??? Some assumptions can be made that microservices allow for the recovery from incidents stats to also be high. But, what about the fact that changes are still having a failure rate of ⅔?

Developer-First Applications & Security

In modern development environments, development teams manage the entire software development and deployment process end-to-end which is awesome, but also places so much on their shoulders. So, I think it is fair to say that it is unreasonable to expect developers to also be security experts. It creates a pretty unique phenomenon where developers own the CI/CD pipelines but security policies are defined by the security and compliance teams. But, like most of us feel on a daily basis, security teams are never large enough – I mean we hear about it all the time the number of open security roles – almost 600k. Typically, we see a 1:100 ratio of security to developers (yeppers, you read that right). Additionally, security teams (rightfully so) have no control over CI/CD and also don’t understand the development environment as well as the developers.

Super fun, right?!

Complexity Needs Solid Context

An additional layer of complexity (not like the layers we like in lasagna or tiramisu) comes from the fact that security is never a one-size-fits-all type situation and blanket security statements (policies) cannot be applied to every code base in the same manner. Yippee…more fun! Certain parts of code are usually higher risk than others, for example code that manages authentication, authorization, encryption, or services deployed as internet facing or in compliance controlled environments are special snowflakes (no not the cool fluffy ones that snowboarders like or the Bay Area unicorn).

Uncomplicated Security Guardrails

Well, we raised some fun stuff (yes, we think they are fun problems to solve for), but this all points to the need for context specific security policies and thresholds that can be defined by security teams and can be applied within developer workflows – Tromzo! Too much?! Did we catch you off guard on where we were going? While we will not be too vendor centric in this blog series, I will caveat it with, this is what we do and we do it really freaking well so if you want to try it out just let us know.

Upcoming blogs in the Security Guardrails Series:

#10: Tags
#9: Ownership
#8: Approved Dependencies
#7: Approved Container Images
#6: Vulnerabilities
#5: Scanning Tools
#4: OSS Licenses
#3: Auto Update Dependencies
#2: Code Reviewers
#1: Branch Protection

Rate this article

Recent articles

Solving the Challenges of Engaging with Developers

On a recent episode of the Future of Application Security podcast, Chad Girouard, AVP Application Security at LPL Financial, talked about some of the challenges to overcome...

Read more
What’s Caused the Need for Software Supply Chain Security

On a recent episode of the Future of Application Security podcast, Dave Ferguson, Director of Technical Product Management, Software Supply Chain Security at ReversingLabs, explained why the...

Read more

Ready to Scale Your Application Security Program?

Sign up for a personalized one-on-one walkthrough.

Request a demo

[email protected]

Request a demo