Turn over every stone for secrets

For the last five years, GitGuardian has been the trusted partner of hundreds of organizations looking to tame secrets sprawl. Our commitment doesn’t stop at providing solutions – we’re deeply invested in advancing the industry’s understanding of the challenge. For example, in our latest issues of The State of Secrets Sprawl report, we explored the various corners of development environments where hardcoded secrets end up–from public GitHub repos to Docker images and Infrastructure-as-Code.

Yet, the term “hardcoded” somewhat understates the problem. Secrets aren’t confined to code alone; they can be found in every tool developers see or touch. GitGuardian users can now benefit from first-class support for continuously monitoring developer productivity tools, and we’re exploring many new data sources besides Version Control Systems (VCS).

Contact our team to learn more about what we have in store!

Catch real secrets

Our detection engine is growing steadily, now featuring a host of new detectors that have taken our arsenal past the 385 detectors mark (grouped into 322 unique types of secrets supported).

"Why are you building more detectors? I already have what I need."
This is a common misconception application and cloud security teams may have. Within large organizations, security is often missing a complete inventory of the programming languages, ecosystems (package managers), CI/CD tools, third-party APIs, and cloud services the engineering teams use to build and run their applications. In addition, engineering teams may be doing ‘shadow code,’ introducing new tools and technologies in the stack without security vetting.

We’re also continuing our efforts to include secrets validity checks where possible to improve the precision of your findings and filter out the false positives before they even reach your incident dashboard. Out of our 310 specific secrets detectors (tied to a provider or a specific technology), 202 already have built-in validity checks!

Secrets detectors with built-in validity checks

Here’s a sample of highly requested detectors we’ve shipped to production in 2023:

Prioritize ruthlessly and focus on the incidents that matter

Secrets scanners, and automated security testing tools, in general, are plaguing the industry with the number of alerts they raise, leaving security engineers and developers scratching their heads, not knowing where or how to start. At GitGuardian, we vowed to offer our users an experience that truly values their time and aims at reducing the cognitive load associated with incident management.

Automate Incident Severity Scoring

If your secrets detection tool is still forcing you to triage your incidents manually, drop it. GitGuardian now automatically evaluates the context, type, validity, and public exposure of secrets to assign accurate severity scores (ranging from low to critical). Skip hours of manual investigation and start remediating your most critical incidents right away!

You can also override our built-in severity scoring rules or create your own.

Example of a severity rule
Example of a custom severity rule

Context-based prioritization and remediation

Our incident tags are meant to provide you with as much context as possible when investigating a hardcoded secret:

  • Exposed publicly: the visibility of the GitHub repository revealing the secret is set to public.
  • From historical scan: one of the occurrences of the incident was detected during an entire history Git scan, as opposed to being caught in real-time.
  • Regression: the incident was once resolved, but GitGuardian detected a new occurrence.
  • Sensitive file: one of the occurrences of the incident is located in a sensitive file.
  • Tagged as false positive in check runs: one of the occurrences of the incident has been tagged as a false positive in a GitHub PR by a developer.
  • Test file: one of the incident occurrences is located in a test file.

In July, we added a new tag for incidents where at least one occurrence of the secret was found in the default branch of a repository. Without a surprise, this tag’s value is “Default branch.” Look out for this tag because, in many cases, secrets found on a default branch are more sensitive than others, especially if this branch is used to trigger deployments to production environments.

Default branch tag

Also, when creating severity rules, you can include conditions to include the tags of your choice. For example, you can decide to systematically set the severity of incidents with a “Default branch” tag to “critical.”

Automate incident closing

Bid farewell to closing incidents manually 👋 GitGuardian now continuously crawls your open incidents to check if the secrets’ validity has changed. If it finds a newly revoked secret (status = invalid), it will resolve the incident by itself!

Auto-close incidents when valid secrets are revoked

Learn more about our automated playbooks in this post:

Automate your way out of code security incidents with GitGuardian’s playbooks
Learn more about GitGuardian’s no-code workflows and how they can help you enjoy some respite from the manual and grunt work no security engineer ever enjoys.

Fix (faster) with your developers

Bring every developer on board

In the past, inviting new users to a workspace was limited to workspace managers and owners. However, to accelerate developer onboarding, you can now authorize team managers in your workspace to invite users to sign up for an account and join their teams.

Invite users to sign up for a GitGuardian account

Relevant documentation link(s):

Shorten the incident feedback loop

Engaging your developers during the remediation process can be difficult. Previously, we gave security teams the option to generate a sharing link (to an external page) and send it to the involved developer to submit their feedback. Now, developers with a GitGuardian account can access their incidents and directly submit their comments and observations in-app. We’re doing everything we can to shorten the feedback loop!

Submit your feedback in-app

Relevant documentation link(s):

Pass on remediation guidelines to your developers

No two organizations are alike when it comes to remediating hardcoded secrets! Each set of security, cloud infrastructure, and engineering teams has internal rules for revoking and rotating keys, re-deploying services… and so on.

This is why we now enable you to create remediation steps in GitGuardian, which every developer should follow to stay in line with your organization’s processes for incident response. Custom remediation guidelines can have up to 20 different steps. Each step can have a title, body, and a link to an external resource such as your internal wikis or ticketing portals!

Custom remediation guidelines

Relevant documentation link(s):

Deploy GitGuardian wherever you need it to be

Our partnership with Replicated, a Kubernetes application delivery and management platform, has helped us deliver the GitGuardian Platform to all kinds of customer-controlled infrastructure.

Since late 2020, organizations with strict data privacy requirements, which usually prefer self-hosting their version control systems (e.g., GitHub Enterprise Server or GitLab Self-Managed), were given the same option with GitGuardian thanks to Replicated and KOTS (Kubernetes Off-The-Shelf).

Earlier this quarter, we made it possible to install GitGuardian on existing Kubernetes clusters using Helm, a popular Kubernetes package manager. You can learn more about this option in our public documentation:

Get the support you deserve

GitGuardian is committed to helping every organization regain control over its secrets and improve its software supply chain security posture. In this spirit, we have grown our Solutions Engineers and Customer Success Managers team to nine members!

We now also have a team of five full-time Site Reliability Engineers (SRE) watching over the infrastructure powering our SaaS platform while lending a helping hand to all our customers on the self-hosted plan, ensuring their instances are up and running around the clock!

These Guardians will support you through every step of the journey:

  1. Proof of Concept exercises: understand the scope of secrets sprawl and build a case for secrets detection and remediation in your AppSec program.
  2. Assisted deployment: If you choose the self-hosted option, Solutions Engineers and SREs will help you configure and deploy GitGuardian on your own infrastructure.
  3. Phased rollout and scaling: Solutions Engineers will work hand-in-hand with you to design an enablement plan and detailed remediation workflows – all tailored to your organization's security and engineering culture.
  4. Continuous support: Technical account managers will provide a variety of training sessions, on-demand webinars, and just general advice to help support your teams as you scale your secrets security program.

Lastly, keep an eye on our release notes and public roadmap!

GitGuardian’s product release notes are always available on our public documentation. Keep an eye on our feature releases, bug fixes, and more!

Release notes | GitGuardian documentation
August 7, 2023

Also, don’t forget to check out our public roadmap and vote for your favorite features (or request new ones)!