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 vulnerability. Vice-versa, every vulnerability can be marked as 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 internally developed security tools. 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, such as for example identified Struts endpoints. In order 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 in 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, 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.