Air gap deployment? This release introduces a new image.registry parameter in Helm values to support the Log Collector system. This parameter specifies the location of the GitGuardian images for the Log Collector components (Loki, MinIO, Fluent Bit) and is separate from the main imageRegistry parameter. Follow the upgrade instructions to update your helm values file.
Detect hardcoded secrets in your AWS ECR Container Registry
We are excited to introduce Secret detection for Amazon Elastic Container Registry (ECR).
Secrets often end up in container images due to common mistakes during development and image creation, mainly:
Hardcoding Secrets in Code: Developers may directly embed sensitive credentials, such as API keys or passwords, into application code, which gets packaged into container images.
Misconfigured Dockerfiles: Commands like ENV or RUN in Dockerfiles can inadvertently expose sensitive data during the build process.
By identifying and addressing hardcoded credentials in your AWS ECR repositories early in the development pipeline, this feature significantly minimizes the risk of security breaches, helping you prevent the unintended exposure of sensitive information before it even reaches production.
We're excited to announce support for Valkey, a Redis-compatible database that is a fork of Redis 7.2. This provides users with an additional option for Redis while maintaining full compatibility with GitGuardian Self-Hosted.
New Checkers
These checkers are implemented to verify the detected secrets, adding another layer of security and ensuring their validity and correct application:
Custom webhooks: Enhanced webhook configuration with more granular event selection. See the updated documentation.
VCS Integrations: Provided the capability to disable Automatic Repository Monitoring upon VCS Integration. Toggles controlling this capability was also moved on top of the discovered sources for more visibility
Bitbucket Cloud Integration: Updated authentication to support API tokens as Atlassian discontinues app passwords, ensuring continued integration functionality.
GitGuardian 2025.6 now requires Kubernetes 1.28 as the minimum supported version. However, Kubernetes 1.28 is no longer receiving active or maintenance support from the Kubernetes project (see end-of-life schedule).
We strongly recommend upgrading to Kubernetes 1.32 for optimal security and stability. See our system requirements for more details.
Securely Access Secret Values via API with GitGuardian's New “Secrets” Endpoint
GitGuardian is excited to announce a new API endpoint /v1/secrets/{secret_id}, allowing users to securely access secret values directly through our API.
This feature introduces several key benefits:
Enhanced Security Automation - Integrate secret remediation into existing security workflows and tools with secure API access to secret values.
Reduced Manual Intervention - Eliminate the need to manually copy secrets from the UI, saving time and reducing human error.
Comprehensive Security Controls - Multiple security layers (PAT permissions, workspace settings) ensure secrets are accessed only by authorized users.
Complete Secret Context - Receive both the secret value and detector information in a single API call for efficient remediation.
We’re pleased to introduce hardcoded secret detection for Microsoft Teams!
What’s new?
Our platform now scans Microsoft Teams messages for hardcoded secrets—such as API keys, credentials, and tokens—across both new activity and historical content. This means you can instantly identify and remediate exposed secrets, whether they were just shared or left unnoticed in your Teams environment.
Why is this important?
Once a secret is leaked, it remains a security risk until addressed—regardless of when it was exposed. By providing both real-time and historical scanning, we offer:
Comprehensive coverage: Instantly detect newly introduced secrets and uncover old leaks hiding in past conversations or shared files.
Proactive risk management: Take swift action to rotate, revoke, or investigate secrets, minimizing the window of exposure.
Complete peace of mind: Ensure your Teams environment is continuously monitored and secured against secret sprawl.
Secure your collaboration. Protect your business.
Simply connect your Microsoft Teams instance and let our enhanced detection engine do the rest. Our solution will automatically scan both ongoing and historical Teams content, surfacing any hardcoded secrets for prompt remediation.
Check out our documentation to start protecting your MS Teams communications!
Historical Scanning now available for Jira and Confluence Cloud sources.
We’re excited to announce a significant enhancement to our secret detection capabilities for Jira and Confluence Cloud: historical scanning is now available!
What's new?
Previously, our integration would surface hardcoded secrets in real-time, alerting you to newly introduced risks as soon as they appeared. With this update, we’re extending our detection to include secrets that were leaked in the past—not just those introduced going forward.
Why does this matter?
Once a secret is leaked, it should always be considered compromised, regardless of when the leak occurred. By surfacing historical secrets, you can now:
Identify and remediate old, forgotten leaks that may still pose a security risk.
Reach a comprehensive security posture by ensuring that no secrets—past or present—slip through the cracks.
Take proactive action to rotate or revoke secrets that may have been exposed long ago.
Check out our documentation to enable the feature now:
Detect hardcoded secrets in your Container Registries
We are excited to introduce Secret detection for Container Registries, including:
Azure Container Registry
Google Artifact Registry
JFrog Container Registry
DockerHub
Secrets often end up in container images due to common mistakes during development and image creation, mainly:
Hardcoding Secrets in Code: Developers may directly embed sensitive credentials, such as API keys or passwords, into application code, which gets packaged into container images.
Misconfigured Dockerfiles: Commands like ENV or RUN in Dockerfiles can inadvertently expose sensitive data during the build process.
By identifying and addressing hardcoded credentials early in the development pipeline, this feature significantly minimizes the risk of security breaches, helping you prevent the unintended exposure of sensitive information before it even reaches production.
Check out our Blog Post to learn more and our documentation to enable the feature now:
New Checkers
These checkers are implemented to verify the detected secrets, adding another layer of security and ensuring their validity and correct application:
Laravel Encryption Key with Host
GitLab Feature Flags Client Token with Project ID
Kubernetes JWT with Host
Brave Search API Key
Firecrawl API Key
Dify API Key
GitLab Runner Authentication Token
Detector Improvements
Ubidots Token – Now includes new secret prefixes and improved checker responses for tokens from disabled accounts.
AMQP Credentials – Detector Upgrade: Enhanced multimatch selection to reduce false positive combinations, vital for secure message queuing in distributed systems.
Confluent Keys – Detector Upgrade: Improved multimatch selection for better accuracy and fewer false positives, essential for managing access to Kafka clusters.
Generic High Entropy Secret – Detector Upgrade: Excludes secrets ending with '.certificate' from being reported, reducing noise by ignoring non-sensitive certificates.
Artifactory Token – Analyzer Upgrade: Improved stability by preventing crashes when analyzing secrets with multiple scopes, key for managing and securing software artifacts.
Microsoft Azure Storage Connection String – Checker Upgrade: Enhanced to accept additional fields, crucial for accessing and managing Azure storage resources securely.
Microsoft Azure Storage Account Key – Detector Upgrade: Increased precision, reducing false positives, critical for safeguarding data in cloud storage.
Engine Enhancements
Established a priority rule favoring the confluent_api_keys detector over amqp_assignment and amqp_assignment_attached_port detectors.
Expanded detection pattern list for encrypted strings to increase precision.
Enhanced AssignmentRegexMatcher for N prefixed strings in SQL, supporting Microsoft SQL Server.
Teams: Optimized the /teams API endpoint to reduce loading times for workspaces with large team structures.
Self-Hosted:
Improved ML Secret Engine Docker image permissions to support running with custom user and group IDs for better Kubernetes security contexts.
Improved Docker image permissions to support running with custom user and group IDs for better Kubernetes security contexts.
Improved handling of failed index creation migrations to allow safe re-execution of database updates.
Added capability to specify constraint of only one worker per node in Kubernetes deployments to optimize resource allocation. Learn more about scaling.
Emails: Resolved an issue where email alerts were being sent to inactive workspace members.
Custom Tags: Resolved pagination issues in the custom_tags endpoint that were causing incorrect next page URLs.
GitLab: Improve permission checking for GitLab group integrations to properly handle inherited permissions from parent groups.
Severity rules: Corrected an issue preventing Self-Hosted customers from adding or editing custom severity rule sets.
Secret analyzer: Improved behavior to ensure secret analyzer is properly disabled when validity checking is turned off.
Self-Hosted Deployment on GCP and Azure: Fixed an issue with ACL limitations on GCP and Azure cloud platforms where Redis deployments disable the ACL command, causing pre-deployment checks for the FLUSHDB command to fail. The system now gracefully handles scenarios where ACL commands are unavailable.
Release Date
Amazon Elastic Container Registry (ECR).
GitGuardian is excited to announce a new API endpoint 
Azure Container Registry
Google Artifact Registry
JFrog Container Registry
DockerHub
