When does GuardRails comment on a PR?
What qualifies as a GuardRails issue?
Our vision is to make security a commodity. As part of that the biggest problem to tackle, besides making security accessible, is to make security relevant and actionable. Security tools are designed to identify all patterns that may cause security issues, no matter how low the potential impact. This provides a big hurdle for developers that are not experts in security, because they have to understand which issues are relevant and which issues aren't.
We at GuardRails spend a tremendous amount of time on tuning the rules, improving them and making sure the amount of false positives are continuously getting closer to 0. GuardRails issues are security issues that have a high impact if exploited by attackers. This means issues that cause the targeted application to stop working (Denial of Service), allow attackers to get full access to user data, or allow attackers to take over the application.
For that reason, GuardRails may be perceived as "quiet". Our goal is to not bother people with security, unless it is absolutely necessary to take immediate action.
Does GuardRails work for front-end code?
Technically speaking GuardRails works for front-end code. However, our rule-set has been tuned to not report security issues in front-end components. Front-end related security typically don't have a serious security impact and thus don't qualify as GuardRails issues.
Where do you get the data from?
All the statistics we use in the our descriptions are based on hard data. Want to know more about this? Drop us a line at email@example.com.
Which Platforms do you support?
At the moment we are supporting Github and Github Enterprise. Support for GitLab and Bitbucket is coming soon.