Some of your secrets belong to systems GitGuardian cannot reach: your internal services, your own platforms, your private APIs. GitGuardian cannot tell you whether those secrets are still active. It reports them as cannot check or failed to check.

You can check them yourself. You can now send the result back to GitGuardian, with one API call.

What does this mean for you?

• You run the validity check on your side, on the systems only you can reach.
• You send the result to GitGuardian: valid or invalid.
• GitGuardian uses it as the validity of the secret, everywhere it uses validity: filters, severity and everything downstream.

Incidents display Custom validity with the date it was set, so your team can see the status came from you and not from GitGuardian. Setting it and removing it are both recorded in the incident activity log and in your audit log.

The status applies to the secret, so every incident for that secret shows it.

Get Started Today!

Use a personal access token with the secrets:write scope.

Learn how to set your own validity status

Enhancements​

• Public API: Added the ability to set the "Only use detectors with validators" option when creating or updating custom sources through the public API, enabling fully automated and consistent source configuration.
• Sources: Improved the clarity of tooltips on disabled source actions, so it is now clear why monitoring, criticality, or team assignment may be unavailable for a given source.

Fixes​

• Public API: Fixed an issue where an API endpoint was missing from the OpenAPI specification and published documentation.
• Incidents: Fixed an issue where incident IDs were not displayed in the ID column despite being returned correctly.
• Dashboard: Fixed an off-by-one issue in the date filter.
• Sources: Resolved a performance issue that caused bulk scan requests to fail when enqueuing a very large number of sources at once.

Credential stealers do not hunt around a developer machine, they go straight for the handful of files where developers keep their secrets.

Endpoint Protection already gives you a full inventory of the credentials sitting in those files, and it now adds intrusion detection to that same deployment: ggshield plants a decoy AWS credential exactly where the stealers look first. The decoy opens nothing, so nobody has a reason to touch it. The moment someone does, you get an alert that names the compromised endpoint.

What does this mean for you?

• A tripwire on the surface attackers hit first: stealers arrive through malicious packages, trojanized tools, and rogue browser extensions. Whichever way they get in, reading that credential file is their first move, and that move is now what exposes them.
• Alerts with no ambiguity: the decoy has no legitimate use, so any use of it is unauthorized by definition. There is no baseline to learn, no tuning, and no signature list to maintain.
• A last line of defense: if malware has already slipped past your EDR and other endpoint controls, using the decoy still gives it away.
• A named machine to investigate: each event carries the IP address, user agent, and timestamp, and resolves to a specific endpoint and its owner.
• Coverage you can measure: a new Honeytoken protection card in the Endpoints dashboard reports the share of your fleet that is protected and lists the endpoints that are not, so you can drive coverage to completion.
• No new agent to deploy: planting reuses the ggshield binary you already install for scanning and writes a file rather than running a resident process.

Why is this important?

Credentials on developer machines have been a blind spot for a long time. Repository scanning, CI checks, and collaboration tool monitoring only ever see secrets that leave the laptop, while the credentials that stay local are exactly the ones harvesting malware is built to collect. Endpoint Protection brought those credentials into your inventory. It now watches for the theft itself, at the moment it happens, on a surface where most organizations have no detection at all.

For developers, this is invisible. Planting only ever touches its own credential profile and leaves every other profile on the machine untouched.

Start securing your endpoint fleet now!

Honeytoken protection is available now for workspaces with Endpoint Protection on a Business or Enterprise plan. If you already run endpoint scanning, adding it means nothing more than one MDM job to update and one more scope on your service account token.

• Protect endpoints with Honeytokens for how planting works, how to verify it, and how to remove it
• Deploy ggshield at scale with a service account token for the token scopes and MDM job setup
• Monitor coverage for tracking coverage across your fleet
• ggshield honeytoken plant for the full command reference

Enhancements​

• Public API: Added the ability to create Personal Access Tokens (PATs) and Service Account Tokens (SATs) programmatically via the API, enabling automated token rotation workflows. Tokens created via the API must have a finite TTL.
• ggshield: Launched an Azure DevOps extension that lets admins add a ggshield secret scan job to every pipeline in their organization with a single pipeline decorator. See Azure Pipelines for details.

Fixes​

• Audit Logs: Scans triggered via a Personal Access Token now emit an audit log event.
• Issue Tracking Integration: Fixed the "Edit issue" dialog closing unexpectedly.
• Notifications: Fixed an issue where the team name was not populated for notifiers when the workspace contained more than 100 teams.
• Access Management: Fixed an issue where deactivated members were incorrectly displayed in the grant access dialog.
• GitHub Checkruns integration: Fixed an issue where a disabled detector could still block pull requests.
• JFrog Artifactory Integration: Fixed an issue where the JFrog Container Registry reachability check did not route through ggbridge.
• GitLab Integration: Fixed an issue where GitLab sources appeared as monitored in the integration settings but were not reflected in the perimeter view.

GitHub check runs now have a dedicated page in the GitGuardian dashboard. Until now, check run results lived only in the GitHub UI, making it hard to answer questions like "did this pull request get scanned?" or "why did this check fail?" without digging through GitHub. The new GitHub check runs page, available in the Perimeter section, brings every check run into one place.

What does this mean for you?

• Full visibility into every scan: Browse all your check runs with their status (Successful, Failed, Skipped, and more), repository, commit SHA, associated pull request, and timing.
• Find what you need fast: Filter by repository, status, or date, and search across your check runs, even on workspaces with hundreds of thousands of runs.
• Key metrics at a glance: A KPI strip at the top of the page summarizes your check run activity so you can spot failures and trends immediately.
• Recover without leaving the dashboard: Re-run a check directly from the list, or skip it when appropriate, without switching back to GitHub.
• Jump to linked incidents: When a check run detects secrets, navigate straight to the related incidents to start remediation.

Why is this important?

Check runs are your first line of defense against secrets entering your repositories. When they fail or get stuck, pull requests are blocked and developers lose time. This page gives security teams and admins a single place to audit scan coverage, troubleshoot failed runs, and unblock developers quickly.

Get started today!

Open the Perimeter section of your GitGuardian dashboard and select the GitHub check runs tab. Learn more in our documentation.

Enhancements​

• Public perimeter: Fine-grained GitHub personal access tokens can now be used to monitor private member of a GitHub organization, in addition to classic tokens.
• Integration source pages: The Display as Tree view was removed from integration source pages, and only the Display as List view was kept. The tree view could cause frozen or lagging pages on workspaces with large perimeters, while the list view covers the same use case with better performance.
• Sources health management for Bitbucket Cloud, Bitbucket Data Center, GitLab, and Azure DevOps: Extending the source health coverage from previous releases, GitGuardian now pauses real-time ingestion and historical scans on unreachable Bitbucket, GitLab, and Azure DevOps sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to the other VCS in upcoming releases. See the integration guides for Bitbucket Cloud, Bitbucket Data Center, GitLab, and Azure DevOps.

Fixes​

• Email & MFA: Fixed an issue where multi-factor authentication emails were not delivered to users who had been globally unsubscribed in the email delivery system.
• Source monitoring: Fixed a performance issue where every push event triggered a full repository clone instead of reusing locally cached data.
• Slack integration: Fixed an issue where the Slack integration monitored channels that were not manually added, even when auto-monitor was disabled.
• Incident notes: Fixed an issue where user mentions in the incident feedback popover displayed a raw identifier instead of the member's display name.

You can now mention members and teams directly in incident notes and feedback. Type @, pick a member or team from the searchable list, and they are notified, so the right people see the incident without leaving the note.

What does this mean for you?

• Loop in the right people instantly: Mention a member with @name or a whole team with @team-name. The mentioned member, or every member of a mentioned team, receives an email linking straight to the incident.
• Faster collaboration on incidents: Keep the conversation where the work happens, with no switching to Slack or email to ask a teammate to take a look.
• Works across the platform: Mentions are supported on both Internal Monitoring and Public Monitoring incidents.

Why is this important?

Remediation is a team effort. When an incident needs a specific owner or a team's attention, mentions cut the back-and-forth and shorten response time, while respecting existing permissions.

Get started today!

Open any incident, add a note or feedback, and type @. Manage your mention emails from your notification settings under Workspace.

Enhancements​

• Sources health management for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive: Extending the source health coverage from previous releases, GitGuardian now pauses real-time ingestion and historical scans on unreachable sources of these types, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the integration guides for ServiceNow, JFrog Container Registry, JFrog Package Registry, and Microsoft OneDrive.
• Perimeter:
  • sources now show a status (Monitored, Unmonitored, Unreachable, Archived, or Deleted) that you can filter on from the perimeter page and the incident list, and save as a view (e.g. to set aside incidents from archived or deleted sources). Note: a valid secret in an archived or deleted source is not necessarily less risky. See Manage your monitored perimeter.
  • You can now choose which columns are displayed in the perimeter table, so you can surface the source attributes that matter most to you and tailor the view to your workflow.
  • On top of setting criticality and launching scans, you can now bulk Monitor, Unmonitor, and Assign team on selected sources directly from the perimeter page. Selecting more than 30 sources shows a confirmation popup before the action runs. Note that Assign team only adds monitored sources to a team, and unmonitoring a source removes it from all of its teams, so those teams' members lose access to that source's incidents. Only managers can monitor, unmonitor, or assign teams. See Bulk actions on perimeter sources.
  • Historical scans now have their own tab on the perimeter page, so you can track past and in-progress scans and their status in one place. See Historical scanning.
• GitHub check runs, scan very large pull requests (Business plan): Previously, pull requests above the size limit (200 commits, 60,000 files, or 300,000 lines changed) were skipped to protect your GitHub API rate limit. On the Business plan, GitGuardian now scans these oversized pull requests by cloning the repository branch instead of calling the GitHub API commit by commit. This reuses the clone-based approach already used for historical scans, avoiding rate-limit consumption while still scanning the full pull request. On other plans, oversized pull requests are still skipped. Learn more.
• Custom Sources (BYOS), scan with validated detectors only: Custom Source installs can now enable a "use only detectors with validators" option. When it is on, a source-linked scan keeps only secrets whose detector supports validity checks and drops the rest before the validity check runs, cutting noise from matches that can never be verified. The option is opt-in per install. Learn more.
• JFrog Container Registries: Backfilled author information for existing JFrog container registry occurrences.

Fixes​

• Audit Logs: Changes to monitoring settings (such as toggling automatic monitoring on or off) are now logged in the audit trail.
• Custom Webhooks: Fixed an issue where Discord webhook notifications were not triggering on incident alerts.
• Jira Cloud Integration: Fixed an issue where Jira Cloud sources were not performing recurrent scans as expected.
• Bitbucket DC Integration: Fixed an issue where some Bitbucket Data Center sources stopped being monitored after infrastructure maintenance.
• GitLab Integration: Fixed an issue where updating the integration token failed with an "invalid token" error.

Until now, a generic password or high-entropy secret hardcoded in a Jira ticket, a Confluence page, or a Slack message went undetected. GitGuardian now runs Generic Password and Generic High Entropy Secret detection on your non-code sources (Confluence, Jira, Slack, Microsoft Teams, and others). This is one of the most requested improvements from teams who already monitor their code with GitGuardian and want the same coverage everywhere.

What does this mean for you?

• Instant visibility: findings from your non-code sources that were previously hidden now appear in your dashboard, already flagged as false positives where it applies.
• Real-time coverage: any new content scanned from Confluence, Jira, Slack, Microsoft Teams, and other non-code sources immediately benefits from generic detection and false positive filtering.

Why is this important?

Generic detection now gives your non-code sources the same coverage you already rely on for your code. To keep that coverage high-signal, the False Positive Remover runs on every finding. It already filters your VCS findings, and we have extended it to non-code sources with an LLM-based model. In our benchmark, it identified 25 to 40% of generic findings as false positives and tagged them before they reached the dashboard.

The result: broader coverage, high signal.

Get Started Today!

Generic detection on non-code sources is enabled by default for Business accounts with AI features enabled. No action is required. To review or change your AI configuration, see AI settings.

Learn more about the False Positive Remover

Enhancements​

• Jira Notifier: Added remediation guidance content and detector-specific links as assignable metadata fields in the Jira integration ticket description template.

Fixes​

• Notifications: Fixed an issue where Discord webhook integrations failed to trigger on incident alerts.
• Incidents Dashboard: Fixed a display and filtering issue with the False Positive tag that caused it to behave incorrectly in the UI.
• Perimeter Management: Fixed an issue where toggling the Team Perimeter view between tree and list modes incorrectly marked the selection as modified.
• NHI Inventory: Fixed a data inconsistency where the "files requiring code fix" count could differ between the UI and API responses.

The ServiceNow issue-tracking integration now covers Public Monitoring and Honeytoken events alongside Internal Monitoring, and brings the Smart Notifier filters to ServiceNow. You choose which incidents flow into ServiceNow and which events appear on their tickets, keeping your ticketing scoped to what matters.

What's new?

Event Group Selection: Choose whether ServiceNow creates tickets for Internal monitoring, Public monitoring, or Honeytoken events.

Public Monitoring Support: Route public monitoring incidents to ServiceNow, so secrets exposed on public sources are tracked in the same workflow as your internal incidents.

Honeytoken Support: Create ServiceNow tickets for honeytoken events, bringing decoy alerts into your remediation workflow.

Granular Event Subscription: Previously, you could not choose which events reached ServiceNow. The new Notify when section now lets you select them. The New incident detected event (always included) creates the ticket; the other events you select are posted as comments on that same ticket, keeping the full incident history in one place. For Internal and Public Monitoring, use filters and presets - by severity, risk score, validity, secret type, or tag - to refine the selection, or start from scratch.

Why is this important?

Security teams need ticketing scoped to their remediation work. Event group selection and granular subscription route only the incidents you care about into ServiceNow, cutting noise. Public Monitoring and Honeytoken support bring perimeter and decoy alerts into the same workflow as internal incidents.

Get Started Today!

Available for all workspaces. Existing ServiceNow integrations keep their current settings, and new configurations can enable the expanded event coverage.

Learn more about the ServiceNow integration | Configure honeytoken alerts

Enhancements​

• Sources health management — Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online: GitGuardian now pauses real-time ingestion and historical scans on unreachable Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the integration guides for Confluence Cloud, Slack, Gerrit, and Microsoft SharePoint Online.
• Incident Notifications: Incident notifications in Slack and Microsoft Teams now include the risk score and severity information.
• AWS Marketplace: Added support for a second AWS Marketplace seller account (GitGuardian Inc., US entity), enabling US customers to transact through the US listing while existing customers continue through the original French listing.
• Public API: Added a new API endpoint to retrieve the activity log of a secret incident, enabling automation and monitoring workflows. Learn more.

Fixes​

• Security: fixed an issue where a Service Account Token (SAT) could revoke itself through the public API (e.g. via ggshield auth logout), which could disable every deployment sharing that token. A SAT can now only be revoked from the dashboard or by another token holding the api_tokens:write scope; Personal Access Token self-revocation is unchanged. Learn more.
• Incident assignment: Assigning a secret incident now automatically grants the assignee the access they need. Previously, an assignee without access could receive the notification email but be unable to open the incident.
• Incident details: Fixed an issue where the incident detail view could display the wrong secret line when privacy mode was enabled, due to position misalignment caused by content obfuscation.
• Custom tags: Fixed an issue where members were unable to remove the last custom tag from an incident.
• Custom webhooks: Creating a webhook with an unreachable URL now shows a clear error message instead of failing with a generic server error.
• Playbooks: Fixed unexpected behavior with the auto-grant developer access playbook where access was not correctly applied in certain configurations.
• Activity logs: The auto-grant access playbook now records an entry in the related issue's activity log, consistent with other playbooks.
• JFrog Container Registry: Fixed an issue where only the first ~200 repositories were discovered, leaving the rest unmonitored and sometimes flagged as deleted. All repositories are now discovered.
• GitLab: Fixed a health check that could incorrectly mark a reachable GitLab instance as unavailable when its endpoint returned a 4xx response.

Every incident used to trigger an alert, a ticket, or an email regardless of how critical it was, leaving teams to drown in noise. Smart Notifiers lets you define per-channel rules so a notification is only sent for the incidents that matter - filtering by severity, ML risk score, validity, secret type, or GitGuardian tag, across both internal and public monitoring. No more third-party middleware to filter before routing.

Available now for custom webhook, Slack, and Microsoft Teams. Email alerting can also filter public monitoring incidents by severity.

Get started: configure rules from your notifier settings. See Alerting and notifications and the custom webhook, Slack, Microsoft Teams, and email alerting guides.

Coming next: ServiceNow & Jira, Splunk & PagerDuty, Discord, Email filtering beyond severity and internal monitoring support.

Enhancements​

• Sources health management — Confluence Data Center and Microsoft Teams: GitGuardian now pauses real-time ingestion and historical scans on unreachable Confluence Data Center and Microsoft Teams sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the Confluence Data Center integration guide and the Microsoft Teams integration guide.
• Overview analytics: now include Non-Human Identity (NHI) and Public Monitoring data.
• GitHub check runs: a new setting lets you skip merge commits in pull request check runs. When enabled, check runs only flag secrets introduced by commits authored on the PR branch, reducing false positives caused by secrets pulled in from the target branch via merge commits. See Detect secrets in real time in GitHub.
• GitHub check runs - large pull requests: check runs now skip the scan on pull requests above a configured size limit to protect your organization's shared GitHub API rate limit. Previously these pull requests would time out or fail. See Detect secrets in real time in GitHub.
• Ticketing integration: you can now dissociate a Jira or ServiceNow ticket from an incident directly from the incident detail page, without deleting the external ticket itself.
• ServiceNow ticketing integration: added support for the Feedback Received event in event-based notifications. See the ServiceNow integration guide.
• Incidents:
  • Added ability to filter incidents by closure reason.
  • Increased the character limit for secret value search on the incidents page, so longer secrets such as large JWTs are matched correctly.
• Historical scans: improved scanning performance on large repositories, reducing timeouts and scan failures.
• GitLab integration: Read-only tokens are now fully supported for GitLab group hook installations, with setup instructions for manual webhook creation displayed when needed.

Fixes​

• Security: fixed a cross-site scripting (XSS) vulnerability on the mTLS redirect page where the retry button URL could be manipulated via a query parameter.
• Developer share links: fixed an issue where custom remediation guidelines were not displayed on the incident share page.
• Public monitoring: clicking the incidents column on the Secret Graspers settings page now correctly navigates to the Incidents tab with the matching filter applied.
• Slack notifications: fixed a "this team does not exist" error that could occur when adding Slack alert notifications on free plan.
• Jira & Confluence: fixed an unknown scanning error caused by provider rate limits.
• GitHub: fixed a Forbidden error on unauthenticated requests to the GitHub API root endpoint.

Developers are writing more code than ever with Claude Code, Cursor, and other AI assistants - and a lot of that code touches secrets. The new open-source GitGuardian/agent-skills repository ships skills that teach those agents how to use ggshield: when to scan, how to read findings, and how to walk the developer through remediation.

What's in it?

• Claude Code plugin: a one-command install (/plugin install ggshield) that makes the skill available to Claude Code - the agent invokes it when the developer asks to scan, validate a token, or remediate a leaked credential.
• Cursor rules & commands: the same skill packaged for Cursor, exposing the ggshield workflow so the agent can call it on demand.
• Defense in depth (optional): layer the ggshield agent hook on top (ggshield install -t claude-code) - unlike the skill, the hook runs automatically and scans every prompt, tool call, and tool output from inside the agent.

Why is this important?

We are meeting developers where they already are - no new tool to adopt, no workflow change. When the developer brings up secret scanning, key validation, or a leaked credential, the agent now knows to reach for ggshield, how to interpret the findings, and how to guide remediation in context. Pair it with the ggshield hook for fully automated, agent-side scanning. Either way, fewer secrets slip through AI-assisted development - with zero friction added to the developer's day.

Get Started Today!

The repository is public, MIT-licensed, and ready to demo:

• Browse the skills on GitHub
• Install the Claude Code plugin with /plugin install ggshield
• Or drop the Cursor rules into your .cursor/ directory

Contributions and feedback are welcome - open an issue or a pull request on the repo.

Enhancements​

• Sources health management — Jira Data Center: GitGuardian now pauses real-time ingestion and historical scans on unreachable Jira Data Center sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the Jira Data Center integration guide.
• Jira Cloud - recurrent scanning instead of webhooks: Jira Cloud monitoring now relies on scheduled recurrent scans instead of inbound webhooks. See the Jira Cloud integration guide.
• VCS - scan orphaned commits and Git notes in historical scans: Historical scans on Version Control Systems now fetch every reference the remote exposes - pull/merge request refs, Git notes, GitLab keep-around refs, Gerrit change refs, and any other custom namespace - on top of standard branches and tags. Secrets in closed PRs, force-pushed history, and Git notes are no longer blind spots. See Manage your monitored perimeter.

Fixes​

• Perimeter: Fixed an issue where unmonitored sources were incorrectly displayed as deleted in the user interface.

Cut incident triage time by getting straight to the right list. The search bar now answers the questions you actually ask during triage - "what did Alice leak in the last 3 months?", "which unassigned critical incidents need owners?" - without forcing you through a chain of filter menus.

What's new?

• Search by secret value: paste a secret directly into the bar to see if it's already raised an incident. The value is hashed in your browser before being sent, so the plaintext never leaves your device.
• Search by commit author: type a developer's name or email fragment (e.g. @contractor.com) to surface every incident with at least one occurrence introduced by that person.
• Search by file path: type any portion of a path (e.g. .env, docker-compose.yml, config/secrets) to filter incidents whose occurrences match.
• Search by source name: type any portion of a repository, channel, drive, or project name to scope the page to that source.
• Natural language search (AI Filters): when AI Filters are enabled on your workspace, type a full sentence and GitGuardian translates it into the right combination of filters - for example, Open critical unassigned incidents related to cloud providers.

All search modes compose. You can mix structured filters, raw text, and a natural-language prompt in the same query, and save the result as a view to share with your team.

Why is this important?

Incident triage is fastest when you don't have to leave the page or know the exact filter name. By making the search bar the single entry point for every way you might describe what you're looking for, GitGuardian removes a layer of clicking from your day-to-day triage workflow - whether you're chasing a specific token, auditing a developer, or scoping leaks to a critical file.

Get Started Today!

The new search modes are available immediately on every workspace, on every plan. Natural language search requires AI Filters to be activated - see AI settings for the workspace settings and self-hosted prerequisites.

Learn more about the search bar

Enhancements​

• Microsoft Teams notifications: Backfilled the Issue Regression event for existing Microsoft Teams notifier configurations - channels now alert when a previously resolved incident reopens, in addition to new incidents and new occurrences. Learn more
• JFrog Artifactory scanning: Incident details now capture additional metadata for secrets found in JFrog Artifactory, making it easier to identify the leak author and assign incidents to the right owner.
• Sources health management — Jira Cloud: GitGuardian now pauses real-time ingestion and historical scans on unreachable Jira Cloud sources, auto-resumes them once health is restored, and surfaces an actionable recovery step. Rolling out to more integrations in upcoming releases. See the Jira Cloud integration guide.
• Risk score in alerting and ticketing: Incident risk score update events are now available in Custom Webhook, Slack, Microsoft Teams, ServiceNow, Jira Cloud, and Jira Data Center.

Fixes​

• Secret revocation: Fixed a case where revoking a Sendgrid API key from GitGuardian could surface a misleading error because the validity check was not re-run after the revocation request.
• Team perimeter: Restored the ability to bulk select all results when adding JFrog Artifactory sources to a team perimeter, previously broken on workspaces with large Artifactory repositories.
• GitHub health check: The GitHub and GitHub Enterprise health check now probes the documented /meta endpoint instead of the API root. This fixes false Unhealthy statuses reported after upgrading to GitHub Enterprise Server 3.19.4.
• Analytics: Fixed an issue where GitHub PR Check runs analytics dashboards were not displayed for GitHub Enterprise integrations.
• Perimeter performance: The source list now renders independently of the overview sidebar queries, fixing failed page renders on workspaces with very large source inventories (200k+ sources).

We're excited to announce a major enhancement to our Microsoft Teams integration that brings comprehensive notification coverage for all incident lifecycle events, honeytoken alerts, and public monitoring incidents. This unified notification framework provides complete visibility into your security posture directly in Microsoft Teams.

What's new?

Complete Incident Lifecycle Coverage: Previously, Microsoft Teams notifications only covered new incident detections and regression. Now you can receive notifications for every critical event including resolution, assignment, status changes, comments, access control, and sharing - giving you complete visibility into incident management workflows.

Public Monitoring Support: Public monitoring incidents can be sent directly to Microsoft Teams channels, enabling teams to receive perimeter security alerts alongside internal monitoring alerts.

Honeytoken Alerting: Microsoft Teams notifications now support honeytoken events, providing immediate alerts for honeytoken activity, previously only available via custom webhooks and email.

Flexible Configuration: Enhanced Microsoft Teams configuration allows teams to subscribe to specific event types per channel, providing granular control over notification preferences.

Why is this important?

Security teams need real-time visibility into all security events to respond quickly and effectively. This enhancement addresses key customer feedback about missing notification updates for incident resolution and status changes, while extending Microsoft Teams integration to public monitoring and honeytoken.

Get Started Today!

This enhancement is automatically available for all workspaces. Existing Microsoft Teams integrations will maintain their current notification settings, while new configurations can be set up with expanded event coverage.

Learn more about Microsoft Teams integration configuration | Configure honeytoken alerts

Enhancements​

• Public API: New Health Checks endpoints let you programmatically monitor the health of your integration instances (GitHub, GitLab, Slack, Jira, and more). List the latest health check across all instances, filter by integration type, status, or date, and retrieve the full health check history for a specific instance to power your own dashboards and alerting.
• Public API: You can now retrieve and filter archived sources.
  • Sources endpoint: now offer the provider_metadata.archived field (currently available for GitHub sources) and a provider_metadata_archived=true filter.
  • Incidents endpoint: now offer an only_on_provider_archived_sources=true filter to focus on incidents from archived sources and run bulk actions on the returned list.

We're excited to announce that file attachment scanning is now supported for Jira Cloud, Jira Data Center, Confluence Cloud, and Confluence Data Center.

You can now detect secrets in both textual content and uploaded files, giving you full coverage across your Atlassian sources.

Why this matters

Security-relevant content is frequently shared as screenshots, exported logs, reports, and documents attached to tickets or wiki pages. By scanning both attachments and page or issue content, GitGuardian helps you reduce missed exposures and improve remediation coverage across your Atlassian environment.

• Complete source coverage: Detect leaks in issue/page content and file attachments.
• Fewer blind spots: Catch secrets hidden in uploaded logs, reports, screenshots, and documents.
• Consistent experience: Atlassian attachment coverage now aligns with existing support in Microsoft Teams, Slack and other Corporate Data Sources.

Already using Jira or Confluence sources? Here's what you need to know:

• New scopes required: Attachment scanning rely on additional API scopes for Jira and Confluence Cloud (read:attachment:jira on Jira Cloud and readonly:content.attachment:confluence on Confluence Cloud). Reinstall each affected integration from Settings → Integrations → Sources so new OAuth applications include the new permissions.
• Run Full Historical Scan: To avoid any blindspot, we strongly recommend you re-execute the entire historical scans from your Confluence and Jira sources. This will ensure GitGuardian scans all attachments from the past.

Get started today

Check the updated documentation:

• Integrate Jira Cloud
• Integrate Jira Data Center
• Integrate Confluence Cloud
• Integrate Confluence Data Center

--

Enhancements​

• Public API: Removed the deprecated Honeytoken Labels API endpoints. Customers using custom tags should now use the Custom Tags API instead.
• Jira Notification: Jira templates now flag unsupported required fields at configuration time, preventing configurations from being saved with fields that would fail at send time.
• GitHub Check runs: Improved reliability of GitHub PR checks during partial outages for workspaces using GitGuardian Bridge.

We're excited to announce that the GitGuardian Slack app is now officially listed and approved on the Slack Marketplace, available in both US and EU regions ! This means you can install GitGuardian directly from Slack's app directory, and the peace of mind that comes with Slack's marketplace review process. Beyond marketplace approval, this release bundles several improvements to the Slack integration that make it more powerful, more privacy-aware, and easier to operate at scale.

What's new?

• Channel selection at setup time: You now choose which public channels to monitor during installation, instead of the app automatically joining every public channel. This gives you full control over your scanning perimeter from day one.
• File attachment scanning: Secrets hiding in file attachments dropped in channels and messages are now detected alongside text-based messages.
• Interactive messages (Beta): When GitGuardian detects a secret, it posts a threaded response directly in the original conversation with details about the finding and quick actions — including the ability to ignore low-risk incidents without leaving Slack.
• Enhanced privacy controls: Private channel names are now redacted for users who don't have access to those channels in Slack, fully respecting Slack's privacy model. A privacy information banner is also displayed during setup to clarify what GitGuardian can and cannot access.

Why does this matter?

Slack is where developers share code snippets, debug outputs, and configuration examples in real-time. These casual exchanges frequently contain accidentally pasted API keys, database credentials, and tokens that persist in chat history. With the new GitGuardian Slack app, you extend your proactive defense and efficiently streamline the efforts with the responsibles of the leaks!

Get started

1. Open the listing for your region: GitGuardian (US) or GitGuardian EU.
2. In GitGuardian, go to Settings → Integrations → Sources and install Slack from the Messaging section, then complete the OAuth flow for your workspace.

If you previously covered your Slack Perimeter with GitGuardian, you will need to reinstall your Slack App using the same procedure.

Check out the full Slack integration guide for perimeters, private channels, and interactive messages configuration.

Enhancements​

• Accessibility: Added support for Ctrl+Enter to submit forms, improving keyboard navigation efficiency.
• Jira Integration: Dynamic variables (e.g., {secretType}, {sourceName}, {sourceType}) can now be used across all Jira fields — including Labels, Summary, Priority, and custom fields — not just the description. Variables are interpolated at incident creation time, making it easier to build filtered Jira dashboards and reports. Learn more.

Fixes​

• Dashboard: Fixed an issue where filtering Personal Access Tokens could cause the UI to become unresponsive.
• Bitbucket Cloud Integration: Updated API calls to use the new workspace-scoped endpoints, following Bitbucket Cloud's deprecation of cross-workspace APIs.

We're excited to announce native support for Gerrit as a VCS source. Gerrit is widely used for enterprise code review workflows, often hosting sensitive internal repositories. You can now connect your Gerrit instance to GitGuardian to detect secrets exposed across your repositories and commit histories, with the same experience as our other VCS integrations.

What does this mean for you?

• Historical scanning out of the box: GitGuardian performs a full scan of your repositories' commit history as soon as you connect your Gerrit instance, uncovering secrets that may have been exposed weeks, months, or years ago.
• Real-time detection with the webhook plugin: Install the Gerrit webhook plugin to catch new exposures the moment commits are pushed.
• Granular perimeter control: Choose exactly which repositories to monitor, and apply team-based access control just like with other VCS sources.
• Read replica support: Point GitGuardian to a read replica for cloning operations to reduce load on your primary Gerrit server.

Why is this important?

Gerrit repositories often host some of an organization's most sensitive internal code, yet many security programs lack visibility into them. Credentials and API tokens committed to Gerrit can remain in git history indefinitely, exposing internal systems and infrastructure to anyone with repository access. Native Gerrit support closes this gap and extends GitGuardian's secrets detection coverage to another critical part of your development ecosystem.

Get started

1. Generate an HTTP username and HTTP password in your Gerrit account settings (we recommend using a dedicated bot user).
2. Navigate to Settings > Integrations > Sources and click Configure for Gerrit.
3. Submit your Gerrit instance URL and HTTP credentials to start monitoring.

Check out the full integration guide to learn more.

Fixes​

• Personal Access Tokens: Fixed a bug where the source scopes selected during PAT creation were not correctly applied, resulting in tokens being created with unintended permissions.
• Bitbucket Cloud Integration: Updated the Bitbucket Cloud integration to use the new workspace-scoped APIs, following Atlassian's deprecation and removal of cross-workspace REST API endpoints.

NHI Governance can now tell you which of your Non-Human Identities hold admin rights, which are overprivileged compared to what they need, and automatically raises the risk level of any policy breach that lands on an admin NHI. You get a prioritized inventory where the identities an attacker would abuse first are already at the top, across AWS IAM, Microsoft Entra, and Okta.

What does this mean for you?

• Admin identities at a glance: NHIs with admin-level permissions (e.g. AWS AdministratorAccess, Entra Global Administrator, Okta Super Admin) are marked with an Identity level: Admin badge in the inventory and detail view.
• New policy, Overprivileged Identity: A dedicated policy flags identities granted broader permissions than they use, so you can drive NHIs back toward least privilege.
• Smarter risk criticality: Any policy breach on an admin NHI is automatically bumped one severity level higher, capped at critical. A leaked internal secret on an admin identity now shows as critical, not high.
• Cross-source coverage: Admin and overprivilege checks run on AWS IAM, Microsoft Entra (directory roles, Azure RBAC, Microsoft Graph permissions), and Okta (built-in and custom admin roles).

Why is it important?

Not all NHIs carry the same risk. An admin or overprivileged identity that leaks gives an attacker full control of the account, tenant, or directory, while a scoped identity limits the blast radius to one system. Until now, spotting those identities meant combing through IAM policies, directory roles, and custom permissions by hand, and a leaked internal secret looked the same whether it belonged to a read-only service or a Global Administrator.

With this release you can:

1. Focus remediation where it matters: Start with admin and overprivileged NHIs, and with the incidents their breaches generate, instead of treating every NHI equally.
2. Enforce least privilege: Surface NHIs that accumulated broad permissions over time and bring them back in line.
3. Shrink the blast radius: Cut the number of high-impact identities that a single compromised secret could abuse.
4. Meet audit expectations: Evidence that admin and overprivileged machine identities are reviewed, named, and tracked.

Get started

1. Open NHI Governance → Identities and sort by Risk criticality to see which NHIs rank highest.
2. Use the Identity level filter to isolate admin NHIs, and the Breached policies filter to find Overprivileged Identity breaches.
3. Learn more about admin identities, the Overprivileged Identity policy, and risk criticality.

This feature is available to NHI Governance paying customers.

Enhancements​

• Privacy Mode: Workspace owners can now enforce privacy mode at the workspace level, restricting the ability to view plaintext secrets to managers only or owners only for tighter control over sensitive data visibility. Learn more.
• Audit Logs: The list of captured audit log event types is now available through the public API, making it easier to configure SIEM ingestion and alerting rules. Learn more.
• AI: Workspace admins can now manage third-party LLM usage directly from the dashboard. Choose between GitGuardian's managed LLM providers (default), routing calls through your own AWS Bedrock account with Bring Your Own Cloud, or turning external LLMs off entirely. Internal ML models for false positive detection, prioritization scoring, and similar issues continue to run regardless, and existing configurations are unchanged. Learn more.

Fixes​

• Incidents: Fixed an issue where secret grasper matches found in long diffs were not visible in the dashboard occurrence view. The full file content is now displayed when the match falls outside the truncated patch.
• GitLab health check: Updated the GitLab instance health check for compatibility with GitLab.com and upcoming GitLab 19 self-hosted versions.

Team perimeter already scoped internal incident access for version control repositories. It now applies to all non-VCS integrations—container registries, messaging and collaboration (Slack, Microsoft Teams), documentation and file storage (Confluence, SharePoint Online, OneDrive), ticketing (Jira, ServiceNow), package registries—and to Bring Your Own Sources. Members only see incidents for sources that workspace managers add to their team's perimeter.

What does this mean for you?

• Consistent access control: The same team rules apply whether a secret is found in a repository, a container image, a chat, a document, or a custom source.
• Clearer delegation: Managers can assign sources to teams from the same team perimeter configuration flow.

Get started

Workspace Managers can add sources to a team's perimeter from Settings > User management > Teams, then open the team and use Add sources under the perimeter section. See Configure team perimeter and the Sources integration overview for supported integrations.

Fixes​

• Public Monitoring: Fixed an issue where some secret grasper matches were not displayed and highlighted in the incident page when they occurred in the full file content rather than in the commit diff.

AI coding assistants like Cursor, Claude Code, and GitHub Copilot can now read files, run shell commands, and call external tools during a session. That makes them powerful, but it also means secrets can be exposed before code ever reaches a repository or CI pipeline. ggshield now scans AI interactions in real time and blocks secrets before they are sent to a model or executed.

What does this mean for you?

• Prompt scanning: Secrets in your prompts are caught before they reach the AI model.
• Tool call protection: File reads, shell commands, and MCP calls are scanned before the AI assistant executes them.
• Post-action alerts: If a tool output contains secrets, you get a desktop notification so you can act immediately.
• Simple setup: A single ggshield install command configures hooks for your tool of choice.

Why is this important?

Prompts, local file access, shell output, and MCP tool calls sit outside the controls that protect repositories and CI pipelines. A developer might paste an API key while debugging, or an AI agent might read a .env file and pass credentials to a model provider. These interactions are invisible to most security programs today. Secret scanning at the hook level closes that gap, giving security teams visibility and control over what flows through AI-assisted development workflows.

Get started

1. Make sure you have ggshield 1.49.0 or later installed
2. Run ggshield install -t <tool> -m global where <tool> is cursor, claude-code, or copilot
3. Start coding: ggshield will automatically scan prompts and tool calls in the background

Check out the full setup guide to learn more.

Enhancements​

• Risk Score: Shipped an updated model that improves separation between low-risk noise and higher-priority findings; some incident scores may shift. Learn more.
• Saved views: The Critical saved view is now the default when you open the Internal Monitoring incidents page. Learn more.
• Public API:
  • Added privacy mode support, allowing users to control secret content visibility when retrieving secrets via API endpoints. Learn more.
  • Added new endpoints to trigger and cancel historical scans programmatically, enabling integration of scan management into automated workflows. Learn more.
  • Added severity_rule_id and detector category to the incident response - for both internal and public secret incidents.
  • Added a new GET /v1/severity-rules endpoint to list severity rules.
• Authentication: The SSO domain is now remembered after logout, allowing users to reconnect with a single click instead of re-entering their domain each time.
• Public exposure: "Found outside perimeter" leak details are now visible to all customers, regardless of Public Monitoring subscription. This allows users to better assess and qualify the signal as we continue to improve the reliability of this detection. Access to this information may evolve as the feature matures.

Fixes​

• Secrets Detection: Fixed an issue where ggshield could return an incorrect incident URL when two secrets shared the same hash across different repositories with the "Group by secret per source" enabled.
• Analytics: Fixed an issue where the "All time" date range filter did not consistently cover all incidents, potentially causing some older incidents to be excluded from analytics views.
• Jira Data Center Integration: Fixed an issue where Jira Data Center source connections could intermittently lose authentication.
• Honeytoken: Fixed a deployment job failure caused by an encoding error when interacting with the GitLab API during honeytoken deployment.
• Public API: Fixed an error when querying occurrences for public incidents originating from Explore Search.

GitGuardian now enforces multi-factor authentication (MFA) via email verification for all users who sign in with email and password. After entering your credentials, you'll receive a verification code at your email address to confirm your identity.

Beyond login, verification is also required before performing sensitive actions in your workspace settings — such as configuring SSO, creating API tokens, managing integrations, or inviting members.

Who is affected?

• Users who log in with email and password will be prompted for email verification at login and before sensitive actions.
• Users who log in via SAML SSO or GitHub are not affected — MFA is handled by your identity provider.

For more details, see the MFA email verification documentation.

Enhancements​

• Bring Your Own Sources: The POST /v1/scan/create-incidents API now supports an optional location.url field, allowing you to link scanned documents back to their origin (e.g., a wiki page, ticket, or config file). When provided, this URL appears in incident details for easy navigation to the origin of the leak.
• Authentication: Personal Access Tokens (PAT) and Service Account Tokens (SAT) now use an improved v2 format with gg_pat_ and gg_sat_ prefixes for better detection and security.

Fixes​

• Audit Logs:
  • Fixed an issue where the incorrect actor was displayed for certain audit log entries in the frontend.
  • Audit logs are now properly generated when creating Custom Sources via API using Personal Access Tokens.
• Incidents: Fixed an issue in the bulk filter panel where the select-all checkbox showed "0 incidents" and failed to deselect incidents after selection.
• API: Fixed a bug in the /v1/public-incidents/secrets/{id}/occurrences endpoint when retrieving occurrences for incidents discovered through Explore.
• NHI Governance: Resolved timeout issues when collecting Microsoft Entra ID data for workspaces with large datasets.

We are introducing a unified approach to public exposure information for secrets detected in Internal Monitoring. This update consolidates how we display public exposure, making it easier to understand and act on publicly visible secrets.

What's changing?

• Single tag: The "Publicly exposed" and "Publicly leaked" tags are now consolidated into a single "Publicly leaked" tag that appears whenever a secret has any type of public exposure.
• New "Public exposure" property: A new property provides detailed information about the nature of the exposure, categorized into three types:
  • Source is publicly visible: The incident has at least one occurrence in a monitored source that is publicly visible.
  • Has linked public incident: The secret also appears in public incidents from your public perimeter (requires Public Monitoring).
  • Found outside perimeter: The secret was found in public locations unrelated to your company, such as repositories you don't own (requires Public Monitoring for full details).

A new default saved view "Public exposure" and a dedicated column are available to help you filter and view exposure details.

👉 Learn more about public exposure

Setting up SSO and user provisioning shouldn't feel like a side project. That's why GitGuardian is now available as an Okta-verified app on the Okta Integration Network — giving your identity team a streamlined, standardized way to connect GitGuardian with your Okta directory.

What does this mean for you?

• One-click SAML SSO: Add GitGuardian from the Okta app catalog and configure SSO in minutes — no custom SAML app required.
• SCIM provisioning built in: Automatically create, update, and deactivate GitGuardian users when changes happen in Okta. No more manual onboarding or orphaned accounts.
• Group Push: Sync your Okta groups and their memberships directly into GitGuardian teams, keeping access aligned with your directory structure.
• SP and IdP-initiated SSO: Users can sign in from the GitGuardian dashboard or straight from their Okta portal — both flows are supported out of the box.
• Just-in-Time provisioning: New users get a GitGuardian account automatically on first login, even without SCIM.

Why is this important?

Managing user access across security tools is a pain point for every identity team. Manual provisioning leads to delays, stale accounts, and inconsistent permissions. With the Okta Integration Network app, GitGuardian plugs directly into your existing identity lifecycle — so access stays in sync, offboarding is instant, and your team can enforce consistent security policies without extra overhead.

Get Started Today!

1. In Okta, go to Applications > Browse App Catalog and search for "GitGuardian"
2. Click Add Integration and enter your GitGuardian Workspace ID
3. Configure SSO in your GitGuardian dashboard under Settings > Authentication
4. Optionally, enable SCIM provisioning under Settings > Identity Provider

Check out the full Okta SSO setup guide and the SCIM configuration guide to learn more.

Another registry, zero blind spots. We're expanding GitGuardian's container security coverage with a new integration for Red Hat Quay — the enterprise-grade, OCI-compliant registry trusted by organizations running OpenShift and hybrid cloud infrastructure.

Whether you're on quay.io or running a self-hosted Quay instance, GitGuardian now has you covered by scanning your container images for hardcoded credentials, API keys, and internal tokens buried in image layers.

What does this mean for you?

• SaaS and self-hosted, covered: Works with quay.io and on-premise Red Hat Quay deployments — same integration, same protection.
• Full image layer analysis: Every layer, every Dockerfile, every environment variable — scanned for secrets that shouldn't be there.
• Historical + incremental scanning: Catch secrets already hiding in existing images, and detect new ones as they're pushed.
• Granular perimeter control: Monitor specific repositories or your entire Quay instance — fine-tune coverage to match your needs.
• OAuth2 authentication: Secure, token-based integration with read-only access. No credentials stored, no write permissions required.

Why is this important?

Container images are the final artifact before production. A secret embedded in an image layer — a database password in an ENV directive, an API key baked into a config file — travels straight to your runtime environment. Unlike source code, image layers are often overlooked in security reviews, making them a prime vector for credential exposure.

With Red Hat Quay joining Docker Hub, Amazon ECR, Azure Container Registry, Google Artifact Registry, and JFrog Container Registry, GitGuardian now covers six major container registries — giving you unified secrets detection wherever your images live.

Get Started Today!

1. Navigate to Settings > Integrations > Sources
2. Click Install next to Red Hat Quay in the Container registries section
3. Create an OAuth Application in your Quay instance and connect it to GitGuardian

This feature is currently available in beta. Check out the full setup guide to learn more.

--

Enhancements​

• Public API: Added endpoint to retrieve GitGuardian's egress IP addresses in CIDR notation for allowlisting in firewalls, network security groups, or other access control systems. Learn more.