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.

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.

Your container images are scanned. Your Git repos are covered. But what about the packages flowing through your software supply chain?

We're thrilled to announce JFrog Artifactory Package Registries integration — bringing GitGuardian's secrets detection engine to the artifacts that power your builds. Maven JARs, npm tarballs, PyPI wheels, NuGet packages, and more: if a secret is hiding in there, we'll find it.

What does this mean for you?

• 12 package ecosystems covered: Scan Maven, npm, PyPI, NuGet, Go, Gradle, Swift, Cargo, RubyGems, Composer, Pub, and Generic repositories — all from a single integration.
• Historical + incremental scanning: Detect secrets already lurking in existing packages, and catch new ones as they're published.
• Granular perimeter control: Choose exactly which repositories to monitor, or cover your entire JFrog instance — your call.
• Share remediation efforts: Assign package repositories ownership like you do for VCSs, to route findings to relevant teams.
• Seamless setup: Connect your JFrog Artifactory instance in minutes with an Access Token — no agents, no sidecars, no complexity.

Why is this important?

Secrets don't stay in source code. They travel — embedded in build artifacts, bundled into packages, and shipped across your software supply chain. A leaked API key in a Maven artifact or a database credential in an npm package can compromise production systems just as effectively as one committed to Git.

With this integration, GitGuardian closes a critical blind spot. You now have unified secrets detection across your repositories, container images, and package registries — a complete view of your exposure surface.

Get Started Today!

1. Navigate to Settings > Integrations > Sources
2. Click Install next to JFrog Package Registries in the Package registries section
3. Connect your JFrog instance with an Access Token and start scanning

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

Enhancements​

• Audit Logs: Scope information is now displayed in audit log entries when Personal Access Tokens (PATs) and Service Account Tokens (SATs) are created, providing enhanced visibility into token permissions for security compliance and monitoring.
• Security Settings: Added the ability to restrict Personal Access Token (PAT) scopes for members, allowing workspace managers to limit members to creating PATs with specific scopes (e.g., "Scan only") for enhanced security control. Learn more.
• Authentication Settings: Added customizable session duration setting, allowing workspace administrators to configure how long dashboard sessions remain active before users are automatically logged out. Learn more.
• Slack & Webhook Alerting: Added feedback content (remarks) to Slack and Webhook alerts for both internal and public monitoring incidents, providing complete feedback information in notification payloads. Learn more.
• Slack Alerting: Enhanced incident notification messages with improved formatting, additional context (secret type, status, assignee, severity, risk score), and clearer attribution for automated GitGuardian actions.
• Jira Ticketing: Added filename and line number as template options in Jira templates, displayed as "N/A" when not applicable to the incident source.
• Dashboard: Added "System" theme mode option that automatically matches the operating system's light or dark mode preference, set as default for new users.

Fixes​

• Alerting: Fixed an issue where Jira Cloud installations were unexpectedly soft-deleted without user action, causing notification failures.
• API: Fixed schema validation error for API response path 'id' that was causing client-side errors.
• Incidents: Fixed timeout issues when applying bulk updates to incident custom tags, improving performance for large-scale operations.
• Public Incidents: Fixed 400 Bad Request error when creating public incidents from secrets found in Explore.
• Security: Fixed an authorization issue where Workspace Members with Team Leader permissions could delete notification settings for the "All Incidents" team, ensuring only Workspace Managers can manage these settings.

We're introducing Ownership in NHI Governance: you can now assign and track who is responsible for each Non-Human Identity across your inventory. Ownership helps close the accountability gap for machine identities, speed up remediation when secrets are exposed, and align with compliance expectations.

What does this mean for you?

• Suggested owners: GitGuardian automatically suggests owners using data from your integrated sources and from secret incidents.
• Manual control: Add, edit, or remove owners at any time from an NHI's detail view.
• Inventory at a glance: An Owner column in the NHI inventory shows who is responsible for each identity.
• Workspace members and external users: Owners can be workspace members or external users identified by email.

Why is it important?

NHIs outnumber human identities by orders of magnitude, yet accountability for machine identities is usually unclear. Without ownership, remediation slows down, orphaned accounts go unaddressed, and incident response suffers when secrets are exposed or misconfigured. Ownership gives you:

1. Faster remediation – Know who to contact when an NHI is compromised or needs rotation.
2. Fewer orphaned accounts – Assign responsibility so every identity has someone accountable.
3. Stronger compliance – Meet audit and regulatory expectations (e.g. PCI-DSS, SOC 2, HIPAA) that require clear accountability for sensitive resources.
4. Better triage – Filter and prioritize by owner (e.g. "identities with no owner" or "owned by my team") to focus efforts where they matter most.

Get started

Open NHI Governance → Identities to see the Owner column and filter. Open any NHI to view or edit owners in the Owners section. Learn more about Ownership

This feature is available to NHI Governance paying customers.

Enhancements​

• Incidents: CSV exports now include new columns (risk_score, custom_tags, incident_name), updated tags, and a dedicated public monitoring export format with additional actor and source information.
• ggshield: Secrets with multiple incidents (when using "By secret per source" grouping) are now correctly ignored in scans if a related incident exists and is closed, preventing CI pipelines from blocking unnecessarily.

Fixes​

• Validity Checks: Secrets marked as invalid are now re-checked periodically, so their status can update to valid when they become usable again.
• Analytics: Commit date in hover tooltips now matches the actual timeline data.
• Developer in the Loop: Duplicate feedback submissions are now prevented by disabling the submit button after click and applying a cooldown period.
• SCIM: Email notifications for user and team sync operations (onboarding, offboarding, team membership changes) are now off by default. A new setting in the identity provider section lets you opt in to these notifications when desired.

We've refreshed the GitGuardian interface and introduced Dark Mode so you can work comfortably in any environment. The updated design brings cleaner layouts, improved contrast, and polished forms and navigation, making everyday tasks feel smoother and easier to consume.

What does this mean for you?

• Reduced Eye Strain: Work comfortably during late-night incident responses or in low-light environments with the new Dark theme.
• Personalized Experience: Choose the theme that works best for you—Light or Dark.
• Cleaner Interface: Enjoy improved contrast and polished navigation that makes reviewing incidents or exploring NHI identities faster.

How to Enable Dark Mode

To try it out, head to Account → Interface → Theme and pick your preference. Theme selection is per-user and stored in your profile, so your choice follows you across sessions.

Enhancements​

• Incidents API: Added external ticket information (Jira/ServiceNow) to incidents API responses, simplifying integration and improving tracking in alerting and issue management workflows.
• Analytics: Updated period selector options to include "Last 30/60/90 days" and "Previous month/quarter/year" for more flexible date range selection.
• SSO and GitGuardian Bridge configuration: Improved user experience when editing SSO Identity Provider and GG Bridge certificates, with clearer certificate status display and replacement workflows.

Fixes​

• Validity Checks: Implemented automatic retry mechanism for failed validity checks to reduce false alarms caused by transient errors such as temporary service unavailability.
• CSV Export: Fixed an issue where the secret value column in CSV exports contained invalid JSON format with single quotes instead of proper double-quoted JSON.

We are excited to announce expanded governance support for Microsoft Entra ID and AWS IAM. This update provides a unified source of truth for your cloud identity footprint, allowing you to manage risk and visibility across fragmented environments from a single pane of glass.

Core Identity Capabilities

• Unified Visibility: Map identities across your cloud infrastructure in a single platform, utilizing an enriched graph view to understand complex relationships between identities, policies, and secrets.
• Risk-Based Prioritization: The new risk criticality score automatically surfaces high-impact threats—such as leaked credentials, cross-environment secrets, and orphaned accounts—so you can focus remediation where it matters most.
• Secure, Secret-less Auth: Both integrations leverage OIDC (OpenID Connect) for credential-free, short-lived token-based access, eliminating the need for long-lived secrets.

Deep Cloud Integration

While providing a unified view, NHI Governance captures the unique architecture of each provider to ensure complete coverage:

• For Microsoft Entra ID: Gain transparency into Users, Service Principals, and Managed Identities, as well as both Security and Distribution Groups.
• For AWS IAM: Audit your posture by tracking Users, Roles, and Groups with full metadata.

Getting Started

• To begin syncing your identities, visit the integration documentation for setup instructions and required permissions: 👉 Microsoft Entra ID Setup | AWS IAM Setup
• Available to NHI Governance paying customers.

Enhancements​

• GitHub Check Runs: Updated neutral check run message to clarify no new secrets are detected in merge queues, as scanning already occurred during PR review.
• Perimeter: Custom perimeter support for Microsoft Teams, Confluence Cloud, Confluence Data Center, Jira Cloud, and Jira Data Center — selectively monitor specific channels, spaces, or projects for each integration.

Fixes​

• Secrets Validity Checking: Fixed an issue preventing validation of Google Cloud Keys secrets that resulted in "failed to check" errors.
• List of detectors in the settings: Fixed an issue where the validity check filter was not working properly.
• GitLab Integration: Fixed broken link in health check unhealthy error message that led to a 404 error.
• Health Check Email Notifications: Fixed an issue where GitLab integration health check emails incorrectly displayed "Bitbucket" as the source.
• Container Registries: Enhanced JFrog compatibility by implementing checksum search fallback when Docker image layers are not found via standard endpoints.
• Analytics Overview: Fixed misleading MTTR values by displaying "N/A" instead of "0" when no data is available.

Introducing ML-Powered Similar Incident Grouping - a smart solution to combat incident fatigue by automatically grouping related incidents for efficient bulk remediation.

Key Benefits:

• Reduce incident overload by identifying patterns in similar security incidents
• Streamline bulk actions on groups of related incidents
• Focus on unique issues while efficiently handling repetitive cases

Common grouping scenarios:

• Rotating tokens in automated deployments
• QA test credentials appearing across multiple files
• Database connection strings to the same environment
• Repeated false positives from templating code or tutorials
• High-entropy strings in logs that are likely system-generated
• Known noisy patterns from specific services or file types

Our ML algorithms analyze incident context beyond just detector types to identify meaningful relationships between incidents. View similar incidents in the sidebar of any incident detail page, then use bulk actions to resolve them efficiently.

This feature is available for both Internal Monitoring and Public Monitoring on the Business & Enterprise plans.

Enhancements​

• Integrations: Improved token refresh reliability for Slack and Atlassian Cloud integrations with automatic retry on transient failures.

Fixes​

• Playbooks: Fixed an issue where the "Auto-ignore incidents when secrets are tagged as false positive" playbook was incorrectly reactivated when a Business account's plan was edited in the back office.
• Historical Scans: Resolved a scan queueing issue that prevented all eligible sources from being properly enqueued during bulk scan operations.

We're expanding NHI Governance to cover your critical infrastructure, data, and identity platforms—closing blind spots in your non-human identity landscape.

Highlights

• Infrastructure & Data Platform Coverage: Enumerate service accounts and API keys across Datadog, Snowflake, Okta, and Auth0.
• Unified Identity Risk Assessment: Understand which identities have access to your most sensitive systems and data.

Get started

• Available to NHI Governance paying customers.
• Navigate to Settings > Integrations > Sources > NHI Governance and connect your Datadog, Snowflake, Okta, and Auth0 instances.

We're launching a streamlined Overview Analytics page that gives executives an instant pulse on security posture. At the top, unified KPIs for Protect, Detect, Remediate, and Govern surface repository coverage, incident volume, remediation speed, and identity safeguards—all at a glance.

What does this mean for you?

• Unified KPI Strip: Quick status check across all security dimensions—repository coverage, critical incidents, remediation time, and governance metrics.
• Monitored Perimeter Trends: Visualize how your monitored repository count evolves week over week.
• Top Risky Data Sources: Identify which repositories generate the most critical and high-severity incidents.
• Critical Incident Trajectories: Track how incident volume changes over time to spot emerging risks.
• Most Common Secret Types: Understand which secret categories appear most frequently in your perimeter.
• Closure Progress: Monitor remediation performance including auto-closures and manual resolutions.
• Governance Signals: View vaulted secrets and breached policies for NHI governance insights.

Why is this important?

This view is purpose-built for leadership reviews and status reporting. Use it to:

1. Identify where risk concentrates: Quickly pinpoint which data sources need immediate attention.
2. Measure response speed: Track how fast teams respond to security incidents.
3. Plan coverage expansion: Understand where monitoring should grow next.
4. Demonstrate progress: Show month-over-month / quarter-over-quarter improvements in security posture.

Get started

Navigate to Analytics > Overview to access the new dashboard. Use the KPI strip for a quick status check, then drill into each section to pinpoint hotspots and validate remediation performance.

Learn more about Analytics overview

Fixes​

• Risk Score: Removed an empty bullet point that appeared in the risk score explanation when no specific factors were highlighted.
• GitHub Check runs: Fixed an issue where check runs continued to run and block pull requests despite being disabled by property.

We're excited to introduce risk score — an ML-powered feature available to Business workspaces that helps you focus on the incidents that matter most.

What's new

Each incident now includes a risk score ranging from 0 to 100, where 100 indicates the highest risk and 0 the lowest. The score automatically assesses threat level by analyzing multiple signals including secret type, validity, detection context, and exposure patterns.

Key capabilities:

• Granular prioritization: 0-100 scale for fine-tuned incident triage
• Flexible filtering and sorting: Filter by risk score range and sort by priority in your incidents table
• Updated "Critical" saved view: Now shows incidents with risk score above 80 for immediate focus on highest-priority threats
• Availability: Risk score is available for both Internal Monitoring and Public Monitoring on the Business & Enterprise plans.

Why it matters

The risk score cuts through the noise and helps you focus on critical incidents first. No more asking "where do I start?" or "which incidents are truly important?"—the ML model does the prioritization work for you.

📖 Learn more: How Machine Learning Transforms Security Alert Chaos into Actionable Intelligence

Enhancements​

• Detectors: Some detectors are now flagged as non-business and disabled by default for business accounts to reduce noise (related incidents are therefore hidden). Use the new "Recommended for business" filter in detector settings to identify and re-enable them if needed.

We're transforming how you interact with generic incidents. Secret Enricher replaces vague detector names with precise, ML-enriched secret identities, making every incident immediately actionable.

What's changed?

Instead of seeing generic detector names like "Generic Database Assignment" or "Generic High Entropy Secret," you now see the actual enriched secret type directly in the incident list:

• ❌ Before: "Generic Database Assignment"

• ✅ Now: "Redis Identifiers", "PostgreSQL Connection String", "MongoDB Credentials"

• ❌ Before: "Generic High Entropy Secret"

• ✅ Now: "Stripe API Key", "AWS Access Key", "Twilio Auth Token"

Why does this matter?

This shift from detector-centric to enrichment-driven incidents fundamentally changes how you understand and prioritize your security posture:

1. Instant Context: Know exactly what type of secret leaked at a glance—no need to open each incident
2. Faster Triage: Immediately identify critical infrastructure secrets (databases, cloud providers, payment systems)
3. Confident Prioritization: Clear secret categories help you focus on high-impact incidents first
4. Accelerated Remediation: Understanding what leaked speeds up the remediation workflow

How it works

Powered by our Secret Enricher v2 machine learning model, the platform analyzes the full context around generic secrets to identify:

• Provider: The specific service (Redis, Stripe, AWS, etc.)
• Category: The type of service (Database, Payment System, Cloud Provider, etc.)
• Family: Broader grouping for filtering and analysis

When our ML model successfully enriches a generic incident, the enriched name automatically becomes the primary display name throughout the platform—in incident lists, dashboards, filters, and reports.

Availability: Business and Enterprise plans.

What's next?

This enhancement brings us closer to our ultimate goal: zero generic secrets in your workspace. By making ML-driven categorization tangible and actionable, we're ensuring every secret detection provides maximum clarity and definition.

The enriched names work seamlessly with all existing Secret Enricher features:

• Category and provider filters
• Customizable columns

Learn more about Secret Enricher

Enhancements​

• Incident API: Enhanced incident retrieval endpoints to include enriched secret names in API responses for programmatic access.
• Export Reports: CSV and JSON exports now include both the original detector name and enriched secret name for comprehensive reporting.

Fixes​

• Docker Hub Integration: Fixed an error where users encountered "Input should be 'image' or 'manifest'" when configuring the Docker Hub source connector.