Turn over every stone for secrets
For the last five years, GitGuardian has been the trusted partner of hundreds of organizations looking to tame secrets sprawl. Our commitment doesn’t stop at providing solutions – we’re deeply invested in advancing the industry’s understanding of the challenge. For example, in our latest issues of The State of Secrets Sprawl report, we explored the various corners of development environments where hardcoded secrets end up–from public GitHub repos to Docker images and Infrastructure-as-Code.
Yet, the term “hardcoded” somewhat understates the problem. Secrets aren’t confined to code alone; they can be found in every tool developers see or touch. GitGuardian users can now benefit from first-class support for continuously monitoring developer productivity tools, and we’re exploring many new data sources besides Version Control Systems (VCS).
Contact our team to learn more about what we have in store!
Catch real secrets
Our detection engine is growing steadily, now featuring a host of new detectors that have taken our arsenal past the 385 detectors mark (grouped into 322 unique types of secrets supported).
This is a common misconception application and cloud security teams may have. Within large organizations, security is often missing a complete inventory of the programming languages, ecosystems (package managers), CI/CD tools, third-party APIs, and cloud services the engineering teams use to build and run their applications. In addition, engineering teams may be doing ‘shadow code,’ introducing new tools and technologies in the stack without security vetting.
We’re also continuing our efforts to include secrets validity checks where possible to improve the precision of your findings and filter out the false positives before they even reach your incident dashboard. Out of our 310 specific secrets detectors (tied to a provider or a specific technology), 202 already have built-in validity checks!
Here’s a sample of highly requested detectors we’ve shipped to production in 2023:
- Databricks Authentication Token With Hostname
- Hashicorp Vault Token
- Azure Active Directory API Keys
- Docusign API Key
- Pinecone API Key & Pinecone API Key and Environment
- Keycloak API Keys
- Tableau Personal Access Token
- Palantir JWT
- Figma Personal Access Token
- Cloudinary API Keys
- MongoDB Atlas Keys
Prioritize ruthlessly and focus on the incidents that matter
Secrets scanners, and automated security testing tools, in general, are plaguing the industry with the number of alerts they raise, leaving security engineers and developers scratching their heads, not knowing where or how to start. At GitGuardian, we vowed to offer our users an experience that truly values their time and aims at reducing the cognitive load associated with incident management.
Automate Incident Severity Scoring
If your secrets detection tool is still forcing you to triage your incidents manually, drop it. GitGuardian now automatically evaluates the context, type, validity, and public exposure of secrets to assign accurate severity scores (ranging from low to critical). Skip hours of manual investigation and start remediating your most critical incidents right away!
You can also override our built-in severity scoring rules or create your own.
Context-based prioritization and remediation
Our incident tags are meant to provide you with as much context as possible when investigating a hardcoded secret:
- Exposed publicly: the visibility of the GitHub repository revealing the secret is set to public.
- From historical scan: one of the occurrences of the incident was detected during an entire history Git scan, as opposed to being caught in real-time.
- Regression: the incident was once resolved, but GitGuardian detected a new occurrence.
- Sensitive file: one of the occurrences of the incident is located in a sensitive file.
- Tagged as false positive in check runs: one of the occurrences of the incident has been tagged as a false positive in a GitHub PR by a developer.
- Test file: one of the incident occurrences is located in a test file.
In July, we added a new tag for incidents where at least one occurrence of the secret was found in the default branch of a repository. Without a surprise, this tag’s value is “Default branch.” Look out for this tag because, in many cases, secrets found on a default branch are more sensitive than others, especially if this branch is used to trigger deployments to production environments.
Also, when creating severity rules, you can include conditions to include the tags of your choice. For example, you can decide to systematically set the severity of incidents with a “Default branch” tag to “critical.”
Automate incident closing
Bid farewell to closing incidents manually 👋 GitGuardian now continuously crawls your open incidents to check if the secrets’ validity has changed. If it finds a newly revoked secret (status = invalid), it will resolve the incident by itself!
Learn more about our automated playbooks in this post:
Ziad Ghalleb
Fix (faster) with your developers
Bring every developer on board
In the past, inviting new users to a workspace was limited to workspace managers and owners. However, to accelerate developer onboarding, you can now authorize team managers in your workspace to invite users to sign up for an account and join their teams.
Relevant documentation link(s):
Shorten the incident feedback loop
Engaging your developers during the remediation process can be difficult. Previously, we gave security teams the option to generate a sharing link (to an external page) and send it to the involved developer to submit their feedback. Now, developers with a GitGuardian account can access their incidents and directly submit their comments and observations in-app. We’re doing everything we can to shorten the feedback loop!
Relevant documentation link(s):
Pass on remediation guidelines to your developers
No two organizations are alike when it comes to remediating hardcoded secrets! Each set of security, cloud infrastructure, and engineering teams has internal rules for revoking and rotating keys, re-deploying services… and so on.
This is why we now enable you to create remediation steps in GitGuardian, which every developer should follow to stay in line with your organization’s processes for incident response. Custom remediation guidelines can have up to 20 different steps. Each step can have a title, body, and a link to an external resource such as your internal wikis or ticketing portals!
Relevant documentation link(s):
Deploy GitGuardian wherever you need it to be
Our partnership with Replicated, a Kubernetes application delivery and management platform, has helped us deliver the GitGuardian Platform to all kinds of customer-controlled infrastructure.
Since late 2020, organizations with strict data privacy requirements, which usually prefer self-hosting their version control systems (e.g., GitHub Enterprise Server or GitLab Self-Managed), were given the same option with GitGuardian thanks to Replicated and KOTS (Kubernetes Off-The-Shelf).
Earlier this quarter, we made it possible to install GitGuardian on existing Kubernetes clusters using Helm, a popular Kubernetes package manager. You can learn more about this option in our public documentation:
- Installing GitGuardian on an existing K8s cluster with Helm
- Managing secrets and sensitive data in Helm
Get the support you deserve
GitGuardian is committed to helping every organization regain control over its secrets and improve its software supply chain security posture. In this spirit, we have grown our Solutions Engineers and Customer Success Managers team to nine members!
We now also have a team of five full-time Site Reliability Engineers (SRE) watching over the infrastructure powering our SaaS platform while lending a helping hand to all our customers on the self-hosted plan, ensuring their instances are up and running around the clock!
These Guardians will support you through every step of the journey:
- Proof of Concept exercises: understand the scope of secrets sprawl and build a case for secrets detection and remediation in your AppSec program.
- Assisted deployment: If you choose the self-hosted option, Solutions Engineers and SREs will help you configure and deploy GitGuardian on your own infrastructure.
- Phased rollout and scaling: Solutions Engineers will work hand-in-hand with you to design an enablement plan and detailed remediation workflows – all tailored to your organization's security and engineering culture.
- Continuous support: Technical account managers will provide a variety of training sessions, on-demand webinars, and just general advice to help support your teams as you scale your secrets security program.
Lastly, keep an eye on our release notes and public roadmap!
GitGuardian’s product release notes are always available on our public documentation. Keep an eye on our feature releases, bug fixes, and more!
Also, don’t forget to check out our public roadmap and vote for your favorite features (or request new ones)!
