A microservice that performs a specific type of security test, whether it be static analysis, dynamic analysis, secret detection, etc.
- A false positive is when a security issue was wrongly identified. We aim for zero false positives in GuardRails results.
- All issues that are identified by GuardRails engines are called findings. Only enabled rules qualify as a Vulnerability candidate.
- A secret is any of the following: API keys, cryptographic keys (e.g private keys), or passwords.
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.
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.
The person that creates the Job for GuardRails Runtime.
Containerised tools that do the runtime engines testing. In the case of the application testing engine, the emissary is Zaproxy.
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.
System Under Test (your application / API).
This is the back-end activity initiated via the GuardRails dashboard, that tests the customer’s SUT.
Defined in the Job file by the Build User. Resource objects... for example those of type
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.