Skip to main content

What is GuardRails

GuardRails orchestrates open-source, and commercial security tools by integrating them seamlessly into your existing development workflow. GuardRails curates each security rule of the security tools to keep the noise low and only report high-impact and relevant security issues.

Installing and configuring security tools, even for one repository, typically takes a lot of time and effort. GuardRails makes that process frictionless, quick and rewarding for developers.

GuardRails can be installed across all your repositories in minutes. Once enabled, GuardRails scans every new code change, identifies whether security vulnerabilities are being introduced and provides step-by-step instructions on how to fix them.

To see the list of security tools that are integrated into GuardRails, go to the Tools page.

GuardRails is effectively a full fletched DevSecOps pipeline, no assembly required, including batteries. It is built on the experience of industry veterans that have overseen and deployed dozens of DevSecOps programs around the globe.

With GuardRails, you can move fast and be safe.

Differentiation

GuardRails is providing a unique differentiation to other solutions in 4 key areas:

  • Version Control System Integration
  • Security Tool Orchestration
  • Security Rules Curation
  • False Positive Detection

Version Control System Integration

GuardRails is a platform with a unique architecture. We focus on providing a completely frictionless integration with all modern Version Control System. At the moment GitHub, GitLab and Bitbucket is supported, for both cloud and on-premise versions. This allows GuardRails to establish an end-to-end security verification pipeline that covers all repositories (present and future), without requiring any configuration or additional setup.

Security Tool Orchestration

Build on-top of the tight Version Control System integration, GuardRails receives notifications of any new code change that is created. GuardRails then seamlessly identifies the programming languages and frameworks in a repository, selects the matching security engines, and runs it against the code. GuardRails is smart and detects similar results from different security tools and automatically de-duplicates them, so you don't have to. GuardRails also understands what latest code changes introduce vulnerabilities and, out of the box, only alerts on these new vulnerabilities.

Security Rules Curation

The traditional mindset of security tool vendors is that more vulnerabilities equals better, which resulted in a tremendous amount of security issues being flagged. This burden is then handed to the engineers or the security team, which causes a lot of noise and work. At GuardRails we understand these problems, and based on our extensive first-hand experience, every single rule of every single tools is curated to decide whether it qualifies as a GuardRails issue, or not. This means much less noise for you and your teams, so that you can focus on shipping new and exciting features.

False Positive Detection

Even with a carefully curated rule-set, tools are limited in their ability to identify false positives in the reported issues. GuardRails has build an expert system that detects false positives and is starting to use machine learning to continuously increase the accuracy of detecting real vulnerabilities that need to be addressed. This further ensures that engineers and security teams have more time to work on challenging and important activities, that can't be done by tools.

Business Outcomes

GuardRails is typically purchased to achieve the following business outcomes:

  • Reduced time to market: Continuous security scanning of software changes reduces cycle times and as such speeds up the shipping of software products and features.
  • Reduced engineering cost: Real-time feedback loop allows software engineers to fix critical security issues, when they are introduced, early in the Secure SDLC, without requiring external security support.
  • Reduced business risk: Enforcing consistent security scanning across the entire product portfolio results in more secure software.
  • Increased visibility: Extensive security scan data allow deep insights of risk across the entire product portfolio, which is accessible via Dashboards and APIs.
  • Improved skills: Security scan data combined with development data allows identification of training opportunities within departments, teams and engineers.

Report

A usual report based on what we found will look like this: Example Report

Note: By default we only fail builds on newly introduced vulnerabilities. However, GuardRails can be configured in many different ways, based on you and your teams preference.

Security Testing Techniques

GuardRails orchestrates and unifies over 20 engines that perform one of 3 different security testing techniques.

  • Source Code Analysis
  • Vulnerable Dependency Analysis
  • Secret Detection
  • Cloud Security Analysis

Source Code Analysis

Our static application security testing (SAST) code analysis engines can detect a range of security issues:

  • GR0001: Insecure Use of SQL Queries
  • GR0002: Insecure Use of Dangerous Function
  • GR0003: Insecure Use of Regular Expressions
  • GR0005: Insecure Authentication
  • GR0006: Insecure Access Control
  • GR0007: Insecure Configuration
  • GR0008: Insecure File Management
  • GR0009: Insecure Use of Crypto
  • GR0010: Insecure Use of Language/Framework API
  • GR0011: Insecure Processing of Data
  • GR0012: Insecure Network Communication
  • GR0014: Privacy Concerns
  • GR0015: Information Disclosure

Dependency Analysis

Dependency Analysis, also known as software composition analysis (SCA), rely on public available vulnerability data to provide feedback on the status of your current dependency tree. By default, reports are only created for high severity issues that have a real impact on your application.

This category is identified by this rule:

  • GR0013: Using Vulnerable Libraries

Secret Detection

Our secret detection engines, leverage sensitive information scanners (SIS) that can identify several types of hard-coded secrets in your code:

  • Private Keys
  • High Entropy Strings
  • Basic Authentication Strings
  • API Keys (Stripe, AWS, GCP, etc.)

This category is identified by this rule:

  • GR0004: Hard-Coded Secrets

OWASP Mapping

GuardRails can be mapped to OWASP, as shown in the table below.

OWASP CategoryGuardRails Category
A1:2017-InjectionGR0001: Insecure Use of SQL Queries
A2:2017-Broken AuthenticationGR0005: Insecure Authentication
A3:2017-Sensitive Data ExposureGR0012: Insecure Network Communication
A4:2017-XML External Entities (XXE)GR0011: Insecure Processing of Data
A5:2017-Broken Access ControlGR0006: Insecure Access Control
A6:2017-Security MisconfigurationGR0007: Insecure Configuration
A7:2017-Cross-Site Scripting (XSS)GR0011: Insecure Processing of Data
A8:2017-Insecure DeserializationGR0011: Insecure Processing of Data
A9:2017-Using Components with Known VulnerabilitiesGR0013: Using Vulnerable Libraries
A10:2017-Insufficient Logging & MonitoringN/A

In addition to OWASP, Guardrails identifies the following issues:

  • GR0002: Insecure Use of Dangerous Function
  • GR0003: Insecure Use of Regular Expressions
  • GR0004: Hard-Coded Secrets
  • GR0008: Insecure File Management
  • GR0009: Insecure Use of Crypto
  • GR0010: Insecure Use of Language/Framework API
  • GR0014: Privacy Concerns
  • GR0015: Information Disclosure

Language Support

GuardRails is currently supporting a variety of languages including Apex, Dotnet, Python, Ruby, PHP, JavaScript, TypeScript, Rust, Kubernetes, Go, Solidity, Java, Elixir, Terraform, and C/C++. If you are looking for a language that we do not support at the moment, please drop us a line at [email protected].