In 2022, over 10 million secrets were leaked into GitHub. For organizations, detecting and fixing secrets committed into source control has never been more important. This post will look at considerations when implementing secrets detection in your organization, including why:
Preventing secrets leaks is important
Secrets detected by tooling are bypassed by developers
GuardRails can improve your security posture.
Why is preventing secret leaks important?
Protecting sensitive key material is vital to ensure continued reliability of your technology stack. The loss of authentication keys, tokens, and certificates can result in data breaches that affect ongoing business operations, the reputation of your organization, and ultimately prove very expensive.
Secrets leaks can be expensive
The compromise of key material in one case has resulted in a loss of $14.8 million through API keys stolen by one attacker. 60% of participants in this study stated that their enterprise had suffered an important data leakage. In addition, the costs involved in the remediation of key leak incidents can include:
Engineering time to determine how the key was leaked, the length of exposure, and services that use the material.
Understanding the impact of the compromise and rotating the previously used key by technical teams.
Managing the incident and communicating with your customers and stakeholders on how it affects your business.
Let’s take a look at some of the reasons that this still remains an issue, and how GuardRails can help.
Why are secret findings bypassed by developers?
Many static analysis tools are available for developers to integrate into their software development lifecycle (SDLC) to detect secret key material that has been committed to a repository. The false positive rate of issues surfaced by these tools can be high, especially when matching with regular expressions on generic secrets patterns and, as we show, detection without verification is lacking.
Developers mark findings as false positives
Despite the availability of static analysis tooling to detect sensitive key material that has been inadvertently checked into a repository, developers are inclined to classify issues as false positives. For example, in this case study, developers classified 50% of the warnings as false positives, which demonstrates that the detection tooling can be useful in alerting developers to key material, but results in creating additional work to verify if the finding is valid. This leads to the second component, where…
Detection without verification is not enough
The additional manual effort this brings for developers introduces fatigue and a loss of confidence in the tooling. Security products should make releasing software easier, not harder and, when more false positives are raised this destroys trust in the software, changes attitudes to findings, and the utility of the tool starts to lose value. A different and more effective approach is needed.
The GuardRails approach to protecting secrets
We provide developers with a security pipeline to detect secret key material that has been committed to a repository. Our workflow supports the detection and verification of key material so that clients can immediately know if the material is valid. This gives a clear signal to developers at the beginning of the development process that the material that has been added to a repository is valid, exposed, and provides guidance on remediation.
Third-party integration verification
To support the detection layer of secret key material, we have built integrations with commonly used third-party services to validate the liveness of keys and certificates. We attempt to authenticate with the detected material and use this to indicate to platform users whether the secret is live. This validation and authentication eliminates manual finding validation, helps to reduce developer fatigue, and builds confidence in the results.
We continue to expand the integrations we have for our secrets detection pipeline. Currently, we cover a range of commonly used services, including:
- Cloud services like AWS, Azure, GCP
- Financial services providers like Stripe and SquareUp
- Productivity tools such as Slack, Dropbox, Microsoft Teams
- Emerging technologies in AI
- Development tooling including Ruby Gems, Postman, and TravisCI.
Protecting confidentiality of results
When GuardRails verifies key material detected by our platform, we attempt to authenticate with the third-party service relevant to the secret. However, at no point do we attempt to read or change state, store your secret for our own consumption, or output the secret in any system log or event message.
Providing a clear signal
The integration of a verification layer in our secrets detection pipeline makes it trivial for developers to understand whether key material is live. Feedback is provided via the GuardRails Dashboard, and on the developer’s PR for the validity of the detected key material. This gives a single pane of glass view to exposure of AppSec issues in code and secrets detection with verification.
Example detection and verification
This is an example of a valid Ruby Gems secret that has been committed to a repository. The hard-coded secret is presented on the dashboard, and the Verification Status field shows the status to the developer that the key material is valid:
Filtering results
On the dashboard, it’s trivial to filter the secrets that are valid. This helps you to determine exactly which secrets have been leaked and should be rotated.
Conclusion
As you’ve seen, integrating GuardRails into your software development lifecycle increases your security posture, and prevents secrets from being leaked into repositories. Combined with our AppSec and Infrastructure as Code (IaC) vulnerability scanning, we help to keep your organization secure. This workflow is available for you to test now with the free plan!
Interested to learn more about how GuardRails can help your organization? Contact us here either to discuss how we can help or to schedule a demo.
Top comments (0)