Findings
The GuardRails platform takes an opinionated approach by default, which means that we focus on providing security that doesn't get in your way.
To that end, GuardRails differentiates between Findings and Vulnerabilities.
This page describes what constitutes a Finding.
There are two main aspects to understand Findings.
All security issues that engines provide and that are either not enabled (aka curated) or didn't pass the expert system (aka false positive) will be shown under findings. Every finding can still be manually marked as a vulnerability. Vice-versa, every vulnerability can be marked as a false positive (amongst other actions).
Rule Curation
GuardRails orchestrates close to 30 different security engines. A security engine can be either an open-source tool (e.g brakeman), a commercial tool (e.g mythx) or an internally developed security tool. Any single security engine consists of many different rules, which identify different security issues.
In some cases, engines can have hundreds of rules, with different levels of usefulness. For example, the FindSecBugs rule pack for Java contains about 160 rules. Some rules identify critical issues, such as SQL injections, code execution, etc. However, other rules are more of informational nature and will report all identified Struts endpoints. To keep the noise low every single rule is vetted for usefulness.
By default, all rules that are not considered high-impact will not qualify as Vulnerability candidates.
The default configuration of GuardRails can be overwritten and the rule curation for every engine can be modified on the settings page.
False Positives
GuardRails has an expert system that reviews every vulnerability candidate for the likelihood of it being a false positive.
This expert system considers the file path, line content, and engine rule amongst other aspects to detect whether it's a true finding or not.
More information about dealing with false positives in GuardRails can be found here.