GitGuardian Secrets Detection
More detectors = more secrets caught
This quarter, our dedicated security research team has unveiled 14 new detectors, bolstering our total count to 410 individual detectors (regrouped into 340 unique types of secrets supported)! The latest detectors include:
- Webflow API token
- Google Bard API key
- Sourcegraph Token
- Cohere API key
- Airtable API key v2
- Scalr API Access Token
- Tailscale webhook key
- Tailscale SCIM key
- Tailscale pre-auth key
- Tailscale oauth key
- Tailscale API key
- Readme API key
- Base64 AWS SES keys
- Base64 AWS IAM keys
Every detector has its comprehensive ID card in the public documentation, outlining the secret type, its intended usage and scope, and detailed steps for remediation.
If you haven’t activated these detectors yet, go to your workspace’s secrets detection settings page and turn them on to keep your secrets safe.
Are your secrets also in Slack messages?
When we think of hardcoded secrets, we usually think of source code, build pipelines, and container images. The issue “lives” inside and outside the typical code and runtime environments. Developers can also expose secrets in productivity and messaging tools like Slack channels or Jira tickets, introducing a unique visibility challenge for security teams.
Recognizing this, we extended our monitored sources beyond Version Control Systems (e.g., GitHub) to include Slack workspaces. We actively monitored over 5,000 Slack channels during the private beta phase to unearth hardcoded secrets!
What’s more, GitGuardian regroups occurrences of hardcoded secrets found in Slack with other occurrences of the same secrets found in source code!
Keen on exploring GitGuardian’s Slack scanning capabilities or eager to be an early adopter for the next monitored source, Jira Cloud? Reach out to your dedicated account manager or reach out to customersuccess@gitguardian.com today to jump aboard.
Focus on the 1% of your secrets
More detectors and monitored sources can only mean one thing… more findings and certainly more time and effort your security teams will have to invest in determining what’s a high priority and what can be snoozed until later.
At GitGuardian, we ensure that improving our detection engine goes hand in hand with making it easier for your teams to sort and fix these incidents.
Source (or business) criticality
We recently introduced Source Criticality. You can now set the importance level for each source (i.e., code repository) based on how critical a particular service is for your business.
Source criticality can be easily set via inline or bulk editing in the Perimeter view. Once configured, you can filter incidents based on the criticality of related sources, streamlining your incident triage and remediation process.
Automated severity scoring and custom rules
Contrary to other secret detection providers relying on a one-dimensional severity evaluation based on the secret type, GitGuardian automatically evaluates the context, type, validity, and public exposure, among other incident metadata, before assigning an accurate severity score. Skip hours of manual investigation and start remediating your most critical incidents instead!
Our engine has scored the severity of over 4.9 million exposed secret incidents spanning 400 thousand workspaces, covering both free and business accounts.
Moreover, GitGuardian offers flexibility, allowing users to override and edit the 15 out-of-the-box severity scoring rules or even craft their own. Vermeer, one of our customers, achieved 100% incident coverage by tweaking existing rules and designing a few new rules, ensuring every incident in their workspace received a severity level without requiring manual review! Learn more about Vermeer’s story using GitGuardian and how they improved their secrets security posture.
Guest Expert
But it’s not just Vermeer. More than 91% of GitGuardian Business and Enterprise-tier accounts have enabled automated severity scoring, making it one of our most adopted features this year!
Validity checks
We were the first to release automated validity checks for secrets more than two years ago with a strong intuition that it would help our users (i) prioritize incidents based on whether the secrets are still exploitable or reachable and (ii) for security teams to verify the claims of developers that a hardcoded secret has been appropriately handled (i.e., revoked and rotated).
Today, of our 327 specific secret detectors (tied to a provider or a specific technology), 216 already have built-in validity checks!
Public leak checks
GitGuardian now checks if your (already) hardcoded secrets have not also leaked publicly in projects hosted under GitHub organizations or users outside your monitored perimeter! GitGuardian searches for your secrets against 20 million leaks records on GitHub.com and attaches a `Publicly leaked` tag when it finds a match. In addition, it provides a comprehensive view of where a secret has been publicly leaked by listing up to 10 places and their URLs (files, issues, or gists).
This tag is also already integrated into our automated severity scoring engine. Secrets found to be of any status other than invalid and exposed outside your perimeter exactly once are flagged with a `CRITICAL` severity level. We recommend you take a look at those before anything else.
Bringing dev & sec under one roof
Team-level filters and alerting
Teams now have advanced filtering options and alerting integrations at their team level, offering enhanced control and precision in incident management.
With these updates, managers can still filter the incidents attached to all teams, but members can now only filter the ones attached to the teams they belong to.
Additionally, it’s now possible to configure notifications and alerts at the team level. For instance, in case of a secret exposure in specific service repositories, alerts can be efficiently directed to the involved developers via the appropriate communication channels. GitGuardian users can combine multiple alerting integrations (e.g., PagerDuty, Slack, Splunk, etc.) in the same workspace in this way.
These advancements aim to streamline incident resolution, ensuring targeted notifications and helping developers focus only on what matters to them.
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 steps 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):
Quality of life improvements–the small changes that make GitGuardian Secrets Detection better
New filters UI
Our commitment to a delightful user experience also extends to user interface enhancements! We revamped our UI components for a better experience when filtering records in tables (e.g., incidents, detectors, members, etc.). Less clutter, more space! See for yourself.
Before: all filters were displayed
After: filters are now in their modal
Perimeter view and historical scans
Metadata within historical scan status tooltips now include scan duration, total commits, branches scanned, and reasons for scan failures. These enrichments facilitate better analysis and understanding of scanning outcomes.
GitGuardian Honeytoken
This year marked the beta and general availability announcement of GitGuardian Honeytoken, our spin on deception technology for securing your software supply chain components. By deploying decoy AWS IAM secrets or ‘honeytokens’ within your systems, including source control and build pipelines, GitGuardian Honeytoken can help detect intruders inside your systems before it’s too late.
IP tagging and allowlists
IP tagging
Additionally, we’ve rolled out significant enhancements in IP tagging for Honeytoken events. With our latest update, users can now create customizable IP tagging rules for Honeytoken events, providing the ability to assign tags based on IP addresses.
This empowers you to distinguish between probable false alarms and legitimate alerts, enabling swift action on events originating from new or unfamiliar addresses. Our improved event displays now even showcase country flags alongside IP addresses!
IP allowlists
Furthermore, we’ve introduced IP allow-listing for Honeytoken, enabling users to add specific IP ranges to an allow-list. This functionality ensures that events triggered from these specified IPs (usually trusted internal addresses or ranges) do not activate your honeytokens, thus refining your security strategy by muting alerts. Dive deeper into the details of these IP rules in our public documentation.
What 2024 holds for the GitGuardian Platform
Our Q4 2023 product release showcases our unwavering commitment to enhancing GitGuardian’s capabilities, helping you harden your software supply chain’s security posture and protect the secrets within.
Stay informed about our latest features, updates, and more by watching our public release notes and roadmap!
If you have any questions or feedback for our team, please write to your account manager or customersuccess@gitguardian.com.
