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:

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!

Hardcoded Salesforce OAuth 2 keys found in Slack message (example)
Hardcoded Salesforce OAuth 2 keys found in Slack message (example)

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 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.

Setting source criticality with bulk editing
Setting source criticality with bulk editing

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.

Automated severity scoring and built-in rules
Automated severity scoring and built-in rules

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.

Secure by Default: Integrating GitGuardian in Vermeer’s Software Development Lifecycle
Discover how Vermeer Corporation transformed its software development lifecycle to prioritize security. Learn about their journey from open-source tools to adopting GitGuardian for seamless, integrated secret scanning, enhancing DevSecOps with a ‘Secure by Default’ approach.

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!

Secrets detectors with built-in validity checks
Secrets detectors with 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 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).

Publicly leaked Google API key (example)
Publicly leaked Google API key (example)
Places where the Google API key has publicly leaked
Places where the Google API key has publicly leaked

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.

Team-level alerting integrations settings
Team-level alerting integration settings

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

Using filters to prioritize hardcoded secrets incidents.

After: filters are now in their modal

New filter component (modal)
New filter component (modal)
Only selected filter values are displayed now
Only selected filter values are displayed now

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.

Tooltip on historical scan results (example)
Tooltip on historical scan results (example)

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. 

Create and manage IP tags for GitGuardian Honeytoken
Create and manage IP tags for GitGuardian Honeytoken

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.

Image #1Create and manage IP allowlists for GitGuardian Honeytoken
Create and manage IP allowlists for GitGuardian Honeytoken

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