Skip to main content

Glossary

General

Engine

A microservice that performs a specific type of security test, whether it be static analysis, dynamic analysis, secret detection, etc.

False Positives

  • A false positive is when a security issue was wrongly identified. We aim for zero false positives in GuardRails results.

Findings

  • All issues that are identified by GuardRails engines are called findings. Only enabled rules qualify as a Vulnerability candidate.

Secrets

  • A secret is any of the following: API keys, cryptographic keys (e.g private keys), or passwords.

Vulnerabilities

Each Vulnerability will go through our expert system to determine if it's a false positive or not. More information on how to report false positives can be found here.

Runtime

Application Testing Engine

This is the runtime web application testing engine, the micro-service responsible for dynamically testing your web application. The appScanner resource object in the Job file contains the directives for the application testing engine.

Build User

The person that creates the Job for GuardRails Runtime.

Emissary/Emissaries

Containerised tools that do the runtime engines testing. In the case of the application testing engine, the emissary is Zaproxy.

Job

A test specification defined by the Build User and saved via the GuardRails dashbaord. Job file examples can be found here. Additional details on the Job File pages.

SUT

System Under Test (your application / API).

Test Run

This is the back-end activity initiated via the GuardRails dashboard, that tests the customer’s SUT.

Test Session

Defined in the Job file by the Build User. Resource objects... for example those of type appScanner, tlsScanner, serverScanner and others added in the future are Test Sessions. In the case of an appScanner Test Session, you can think of the Test Session as a specification for a single user with a set of credentials (in the case of an authenticated Job) that may want to test zero to many routes. For example you could have a Test Session for a low privileged user and one for an administrative user, both testing the same or different areas of your SUT. Test Sessions are also discussed in the Job file documentation.