Challenge #1: Obtaining complete visibility over the SDLC

Challenge: With supply chain security reaching its coming-of-age moment, Application Security teams have a more comprehensive mandate to secure not only the software delivered but also the software delivery pipeline and, conceivably, the infrastructure it will spawn. This enlarged scope requires them to fully understand and see what's going on in their entire SDLC, including tooling, configurations, and activity – even before diving into risk analysis and vulnerability detection.

Answer 1: GitGuardian now integrates with all major developer platforms: GitHub, GitHub Enterprise, GitLab, Bitbucket data center/server, and most recently, Azure DevOps suite.

AppSec teams can now connect their GitGuardian workspace to Azure Repos at the instance, organization, or collection levels and add all existing and new repositories to their monitored perimeter. AppSec teams can also integrate the GitGuardian CLI, ggshield, in their Azure Pipelines to run continuous security testing on their code.

Add Azure Repos to your monitored perimeter
Add Azure Repos to your monitored perimeter

Answer 2: The bigger the organization, the larger the codebase. Organizations with a long history of developing software may own applications and repositories with millions of lines of code. While Git is surprisingly good at storing a project's history in a highly-compressed format, engineering teams sometimes keep large individual files and directories or have too many references (branches, tags), inflating the overall repository size.

Previously, adding a repository larger than 1GB to the GitGuardian perimeter would fail. We have raised this threshold to 12GB and are looking to increase it to 60GB soon. For reference, the Linux kernel repository, spanning over 25 years of development, is 1.5GB!

Challenge #2: Ensuring no secrets (or cloud misconfigurations) fall through the cracks

Challenge: With greater visibility over the SDLC comes a new challenge, unearthing hardcoded secrets and preventing new ones from finding their way through.

Answer: We entered 2022 with more than 300 built-in detectors in GitGuardian. And while it may seem like it's enough, it has not diminished our drive to deliver more. Over the last quarter, our engineering teams crafted a handful of detectors, bringing the total of new ones in 2022 to 30!

Neo4j Credentials

Data storage


Thycotic Secret Server Credentials

Development tool


Octopus Deploy API Key

Development tool

Octopus Deploy

GitHub Access Token (fine-grained PAT)

Version control platform


SonarQube Token

Development tool


See the complete list of 2022's new detectors.

Answer 2: Besides secrets detection and remediation, we have expanded our offering to include Infrastructure-as-Code security scanning to help organizations protect their infrastructure at the source. The GitGuardian CLI, ggshield, can now be included in popular IDEs or CI/CD pipelines to detect 70+ security misconfigurations in Terraform projects managing AWS, Azure, and Google Cloud Platform resources – before they are spawned.

ggshield IaC security scanning output in terminal
ggshield IaC security scanning output in terminal

Challenge #3: Remediation is indispensable, but it's also time-consuming

Challenge: The deal with secrets scanning solutions can sometimes be summed up as "we detect, you remediate," leaving security practitioners to deal with secret sprawl hell on their own.

Answer: We chose a different path at GitGuardian. We hold ourselves to helping security engineers automate every step of the remediation process whenever possible. And in this spirit, we shipped three crucial updates to our platform: automated severity scoring and incident closing.

Automated Severity Scoring

Whenever a hardcoded secret is detected, GitGuardian now analyzes the type of secret exposed (e.g., cloud provider, dev tool, data storage, etc.), its context, validity, and exposure before deciding on the severity score it should receive; low, mid, high, or critical. This helps security engineers save time prioritizing and investigating individual incidents.

Automated Severity Scoring
Automated Severity Scoring

Automated Incident Closing

Sometimes, whoever is responsible for remediation will forget to close the related incident in the GitGuardian workspace once they have finished revoking and rotating the exposed secrets. To avoid this, our GitGuardian bot continuously crawls all 'open' incidents and resolves them when it finds the secrets have become invalid – just like waving a magic wand!

Automated Jira Issue creation

When security and engineering teams opt for a best-of-breed strategy for selecting security testing tooling, tracking vulnerability remediation across all the tools becomes daunting and complex. Organizations already centralizing Jira's remediation efforts can integrate it with GitGuardian to automatically push hardcoded secret incidents there.

Challenge: Remediating hardcoded secrets is often tricky and involves multiple stakeholders, including security, engineering, and infra teams. Also, every organization has its process for investigating, revoking, and rotating keys, redeploying applications, and so on.

Answer 2: GitGuardian users can now define and display the steps every developer or security engineer should take to remediate incidents directly in the GitGuardian workspace based on their organization's internal processes. Any custom remediation workflow created can have up to 20 different steps. Each step can have a title, body, and link to a resource such as internal documentation or wikis!

Before you go

The latest releases in 2022 are only a fraction of what you can get from the GitGuardian platform! To fully experience automated secret detection and remediation, create your account and get started for free at!