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

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.

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.

We're expanding NHI Governance with powerful new integrations to enhance your identity inventory and security posture.

Highlights

• Expanded Identity Discovery: Discover and enumerate non-human identities tied to Airbyte, Anthropic, N8n, OpenAI, CyberArk Secrets Manager Self Hosted, and Slack.
• Complete Identity Context: Map identities with enriched data including permissions and accessed resources.
• Identity-First View: New inventory interface centered around identities as the core entry point, providing better visibility and control.
• Enhanced Visibility: Gain comprehensive insights into your NHI landscape across those critical platforms.

Get started

• Available to NHI Governance paying customers.
• Navigate to Settings > Integrations > Sources > NHI Governance and connect your Airbyte, Anthropic, N8n, OpenAI, CyberArk Secrets Manager Self Hosted, or Slack workspace.

Additional integrations will be released in the coming weeks: stay tuned for more updates!

Enhancements​

• Secret Detection: Added support for secrets analyzers via GitGuardian Bridge.
• Incidents Dashboard: Added a new "Valid" saved view for all accounts.
• Incidents API: Added support for filtering incidents by triggered date in the public API endpoint.
• Public Monitoring: Improved highlighting of company domains and names in patches, now showing all matches rather than just the first occurrence.
• GitLab Integration: Added validation to block system hook integration for non-admin users and implemented health checks to verify admin token status.
• Docker Hub Integration: Updated to support organization namespaces, allowing scanning of images under organization accounts.
• Perimeter: Custom Monitored Perimeter for Container Registries, SharePoint, OneDrive, ServiceNow, and Slack — includes a redesigned interface for viewing, searching, and configuring sources, groups, and repositories with improved performance for large integrations.
• GitLab integration: Empty namespaces are now hidden by default to reduce clutter, with an option to display them when needed.

Fixes​

• Incident Management: Fixed filters not being applied to bulk actions when using "select all".
• Jira Ticketing Integration:
  • Fixed ticket creation failures for custom sources.
  • Resolved issue where Jira notifiers could become blocked in an unhealthy state.
• Perimeter:
  • Removed individual scan button from perimeter page to improve clarity around scan behavior.
  • Never create new scans on a source with scan already in progress.
  • Fixed issue where incremental scans were incorrectly displayed as user-triggered historical scans.
• GitLab Integration:
  • Fixed an issue where GitLab namespaces and projects were incorrectly displayed as "banned" when the instance was actually temporarily detected as unhealthy.
  • Fixed search functionality not working in the entity tree displayed as List view.
• Container Registry Integrations:
  • Source URL now redirects to the Google Artifact Registry repository as expected.
  • Fixed containerrRegistry cache mechanism to ensure content is rescanned when source differs, even with identical digests.
  • Handle blacked out JFrog repositories gracefully.

SCIM now supports team provisioning for Okta and Microsoft Entra ID. IdP groups are created as GitGuardian teams and kept in sync, completing end-to-end automation for users and teams.

Highlights

• Automated team creation: IdP groups become teams in GitGuardian.
• Near real-time sync: Group changes propagate to teams quickly.
• Full lifecycle automation: Works alongside user provisioning.
• Less manual work: Fewer errors and no hand-made team management.

Get started

• Available with Okta and Microsoft Entra ID.
• Service account token needs teams:write and members:write.
• Enable in Settings > Authentication and follow your IdP setup.
• See the product documentation for details.

Enhancements​

• Dev-in-the-Loop: Added incident ID display and dashboard navigation link for authenticated users on public incident sharing pages, improving investigation workflow.

Fixes​

• Container Registry Integrations: Fixed an issue where the sync task incorrectly unmonitored all repositories when automatic monitoring was disabled.
• Jira Data Center Integration:
  • Fixed an error that occurred when the installation version was not properly set during webhook synchronization.
  • Fixed an issue where historical scans failed with an unknown error for large projects.
• Incident Details: Fixed incorrect "First detected" date display by replacing it with "Detected date" and adding an "Opened for" field to show incident duration.
• Slack Notifications: Fixed incorrect user association and event triggering in Slack notifications.
• Health Check: Improved error differentiation to distinguish between GitGuardian Bridge connectivity issues and source system downtime.

Playbooks are now available for public secret incidents, bringing unified automation workflows across your entire security perimeter. This enhancement extends GitGuardian's proven automation capabilities to the Public Monitoring product.

What's new?

You can now automate remediation workflows for public secret incidents. All playbooks (except auto-share public link) now support Public Monitoring, reducing manual work when managing public incidents. The "auto-ignore false positive incidents" is activated by default on the public secret incidents, while the others have to be activated based on your desired workflows.

Why is this important?

Public monitoring can generate high volumes of incidents that require manual review and closure. With playbooks now available for public incidents, you can automatically resolve cases where secrets have been revoked, ignore invalid secrets, filter out false positives, and grant access to involved developers—significantly reducing the manual workload for your security team when managing public incidents.

Get Started Today!

Learn more about configuring playbooks in our documentation, or visit the Playbooks setting page directly.

Enhancements​

• Incident list: Added direct link to source location from the incident list view.
• API: The change_type field for secret occurrences is now exposed via API.

Fixes​

• Microsoft Teams integration: Fixed an issue which prevented to update the Client secret of a Microsoft Teams notifier integration.
• Incident feedback: Fixed a bug where the "Gives access to sensitive data" answer would always be registered as false when posting a feedback on internal incident.

We're excited to announce a major enhancement to GitGuardian's visualization capabilities: the improved identity graph with enhanced publicly leaked detection. This transforms how you investigate and understand secret incidents across your entire security perimeter.

What does this mean for you?

Comprehensive Context at a Glance: Our enhanced graph interface now consolidates scattered visualizations into one unified, context-rich view. You'll see critical details like severity levels, source information, and occurrence data directly within the graph, eliminating the need to switch between multiple pages during incident investigation.

Advanced Public Leak Intelligence: Building on our HasMySecretLeaked capabilities, the platform now provides enhanced visibility into three distinct types of public exposure—secrets in monitored public sources, incidents in your public perimeter, and external GitHub locations—all clearly categorized and contextualized within your incident workflows.

Why is this important?

Modern security teams need to understand the full scope of secret exposure across both private and public domains. With secrets often appearing in multiple locations—from internal repositories to external GitHub commits—having a unified view that correlates these incidents is crucial for effective remediation and risk assessment.

Enhanced Public Monitoring Integration

The new "Publicly Leaked" tag unifies previously scattered exposure indicators, providing clear visibility when secrets appear across your monitored sources, public incidents, or external locations discovered through our HasMySecretLeaked database. This integration ensures you have complete visibility into your organization's secret exposure landscape.

Get Started Today!

The enhanced graph views are now available across Internal Monitoring, Public Monitoring, and NHI Governance modules. Navigate to any incident to experience the new unified visualization that brings together comprehensive context, public leak detection, and streamlined investigation workflows in one powerful interface.

Enhancements​

• Incidents: Enhanced display capabilities to show large occurrence patches that previously showed "Diff too long to render".
• Explore (Public Monitoring): Added history tracking for Explore searches and scans.

Fixes​

• GitLab Integration: Fixed a 403 error that could occur during personal access token updates.
• SharePoint Integration: Resolved an issue where health-check operations would fail with error code 9999.