Skip to main content

4 posts tagged with "container-registries"

View All Tags

Mention members and teams in incident notes

calendar icon   Release Date: July 20, 2026

Mention members and teams in incident notes

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

What does this mean for you?

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

Why is this important?

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

Get started today!

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

Enhancements

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

Fixes

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

Red Hat Quay Integration: Your Enterprise Images, Under Watch

calendar icon   Release Date: March 5, 2026

Red Hat Quay thumbnail

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.

JFrog Artifactory Package Registries: Secrets Hide in Your Packages Too

calendar icon   Release Date: March 3, 2026

JFrog Package Registries thumbnail

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.

Detect hardcoded secrets in your Container Registries

calendar icon   Release Date: March 19, 2025

Container Registries Thumbnail

We are excited to introduce Secret detection for Container Registries, including:

  • microsoft-azure-container-registry Azure Container Registry
  • amazon-ecr Amazon Elastic Container Registry
  • google-artifact-registry Google Artifact Registry
  • jfrog JFrog Container Registry
  • dockerhub 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.

Container Registries Dashboard

Check out our Blog Post to learn more and our documentation to enable the feature now:


Fixes

  • Jira Cloud Issue Tracking Integration: Fixed an issue where Jira project keys were incorrectly changed during synchronization.