Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

In this section, we cover what to do when ggshield finds something you don’t actually need to remediate, like a false positive, an intentionally fake credential in a demo repo, or a known non-sensitive test value. ggshield secret ignore lets you mark specific findings as ignored by adding them to the secrets.ignored_matches section of your local configuration. If your repo doesn’t already have a local config file, ggshield will create a.gitguardian.yaml file for you.

Let's look at Git hooks, which is where ggshield really starts paying off in day-to-day developer workflow. Git hooks are built-in automation in Git. When certain events happen, like committing or pushing, Git checks for specific files inside the.git/hooks folder. If a hook file exists, Git runs it automatically. For example, if there’s a file named pre-commit, Git will execute it every time you commit.

Next up is ggshield secret scan ci, the mode built for continuous integration, not your local machine. In this section, we’ll show how CI scanning works and why it’s different. Instead of scanning your whole repo, it scans the set of commits that triggered your pipeline, whether that build came from a direct push or a pull request. That means you catch secrets at the exact moment they’re introduced, before they get merged or released.

Now we’re getting to the heart of ggshield: secret scanning. In this section, we jump into ggshield secret and its two subcommands, ignore and scan. Ignore makes a lot more sense once you’ve seen scan in action, so we start by learning what ggshield can scan and why it’s so flexible across the development lifecycle. We’ll open the help menu so you can see every scan target available: ggshield secret scan -h.