The key in the commit,
found before someone else finds it.
Datadog Secret Scanning reads every commit on every branch of the repositories you connect, and the full Git history on the first pass, for API keys, tokens and credentials. It checks whether some of them still work. We connect the repositories, triage the first list by validity, and rotate the live ones with their owners before anything is muted. Then we operate it every month, so the next leak is a same-day call, not a questionnaire answer.
Quick facts
Related
- Code Security, the group this belongs to
- Access Control, the keys that belong to Datadog itself
- Sensitive Data Scanner, the same detectors, applied to logs and traces
A list sorted by whether the key still works, which is the only sort that matters
Every repository with a history has credentials in it. The question is never whether, it is which of them are still live. A scanner that returns four hundred matches with no validity status produces a project. One that returns four hundred matches with three marked valid produces three phone calls, today.
The whole history, then every commit. The first hosted scan reads every branch back to the beginning. After that, each commit is scanned as it lands, reading the full file rather than the diff, so a key moved between files is still found.
Validity checked where the provider allows it. Findings are marked valid or invalid, and for a subset of detectors Datadog checks with the provider whether the key is live. The triage starts from the valid ones.
Detectors shared with Sensitive Data Scanner. The same credential rules that redact a key in a log line find it in a commit. A generic detector for internal tokens that match no provider pattern is available in Preview.
The next one stopped at the pull request. Inline comments flag the secret on the line. PR Gates fail the check on GitHub and Azure DevOps, and on GitLab in Preview. A finding can open a Jira ticket or declare an incident from the findings view.
Four hundred history findings, three of them live, and a mute applied to all four hundred
How it bills. Secret Scanning is part of Code Security and is billed per committer, per month, on its own or in the Code Security bundles that include it. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. Datadog publishes the bundles, meters and rates. The scope decision runs the other way from the other scanners. A repository that is archived and untouched adds nobody to the count, because nobody commits to it, and it still has its history. If that history ever held production configuration, it belongs in scope.
The configuration traps. The history scan returns hundreds of findings for keys committed years ago, and the list is muted wholesale because it is old, with the three live keys inside it. A key is found, the file is edited to remove it, and the finding is closed, while the key itself is unchanged and still in the history of every clone. A key is rotated and the finding is never muted, so the next review spends an hour re-confirming it. Test fixtures with placeholder keys are never excluded, so every test run that adds a fixture adds a finding. Scanning is set up only in CI, so the history is never read and the repository is declared clean on the strength of its last commit.
Field noteThe most common gap we see is the edit without the rotation. The developer removed the line, the pull request merged, and the key is still valid in every clone, every fork and every CI cache that pulled the branch. The finding was closed. The exposure was not.
Field noteThe pattern we keep finding is a live key whose owner nobody can name. It was created for an integration that was switched off. The vendor account still exists, the key still works, and rotating it means first finding out what would break.
Field noteThe repository about to be shared with a contractor or made public is where the history scan matters most, and where it is run last. The code looks clean at the head. The commit from the first week of the project does not.
Field noteInternal tokens that match no provider's format are the ones the detector misses and the ones that matter most inside the estate. A password in a connection string, a shared secret between two services. They need the generic detector, which Datadog has in Preview, or a custom regex rule, and a custom rule needs somebody to decide what the pattern is.
History first. Valid keys the same week. Then the gate that stops the next one.
Secret Scanning is the first scanner enabled in the Code Security Accelerator, four weeks, fixed scope, because its first result can be an incident and the other scanners' first results are backlogs. It needs no tracer and no Agent.
- List every repository that has ever held configuration. Active, archived, forked, about to be shared. The owner of each, and the owner of the credentials it is likely to contain. Nothing excluded for being old.
- Connect the source host and run the history scan. Hosted scanning, so the full Git history across all branches is read. CI scanning alone would miss it.
- Triage by validity. Valid findings first, then findings with no status, then invalid ones. Each valid key gets an owner, a rotation date within the week, and a record of what depends on it.
- Rotate, then mute. The credential's owner rotates or revokes it, with us on the call where it is in the runtime we operate. Only then is the history finding muted, with the rotation recorded as the reason.
- Exclude the fixtures and set the gates. Known fixture paths and placeholder patterns excluded inline, each one recorded. Pull request comments on. PR Gates made blocking for secrets, because there is no severity at which a live key should merge.
- Hand over, in writing. Repository list, findings by status on the day we finished, rotations completed and by whom, mutes and their reasons, exclusions and their paths, and the gate configuration.
Access is admin on the Datadog organisation and the Datadog app on the source host with read access to the repositories. We do not hold your credentials, and we do not rotate them for you unless they belong to a runtime we already operate. The owner rotates. We confirm, record and close.
A finding closed by editing the file is a finding that is still open
A new repository is created without scanning. A fixture directory is added and becomes forty findings. A key is rotated and the mute on its history finding is never applied, or applied and the rotation never happened. Managed Observability is the monthly service that keeps the list true and the live count at zero.
Every month, the new findings are read by status. Valid first. Each one is a call to the owner that week, with the commit, the detector and the rotation steps attached. Findings with no status are treated as valid until the owner says otherwise.
Coverage follows the repositories. New repositories are enabled when they appear, and their history is scanned on enablement. A repository about to be opened to a third party is re-scanned before the access is granted.
Mutes are re-confirmed against rotations. A muted history finding whose rotation was never recorded is reopened. The list of exclusions is read against new fixture paths, so the placeholder list stays accurate and the real-key-in-a-fixture is not hidden by it.
A valid key is an incident, not a finding. It is raised the same day. The finding is closed only when the rotation is confirmed by the owner, and the record of when it was found, when it was rotated and by whom is kept for the questionnaire.
We operate the stack. You own the product.
We are not a security company, and we do not hold your secrets. We are a managed runtime operator. We run the scanning inside your Datadog and read what it finds by whether the key still works. We rotate what sits in the runtime we operate, and route the rest to the credential's owner with the commit and the steps attached. We operate and evidence the runtime controls that support your compliance obligations. The credentials, the vendor accounts and the rotation stay yours.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Secret Scanning, answered plainly
Does Datadog Secret Scanning check whether a leaked key still works?
For some detectors, yes. Datadog attempts to validate detected secrets and marks each finding valid or invalid, and for a subset of providers it checks against the provider whether the key is live. That status is the first thing we sort by. A valid key in a commit is an incident that day. An invalid one is a clean-up task. A finding with no validation status is treated as valid until someone with access to the provider says otherwise, because the cost of being wrong is not symmetrical.
How is Datadog Secret Scanning billed?
Secret Scanning is part of Code Security, billed per committer, per month, on its own or in the Code Security bundles that include it. Datadog counts a committer as an active Git author, identified by email address, who commits at least three times in the month. An archived repository nobody commits to adds nobody to that count. Datadog publishes the current meters and rates. We do not publish prices. We do decide, with you, which repositories are enabled, and every repository that has ever held production configuration is on the list regardless of how active it is.
Does Datadog Secret Scanning scan old commits?
When a repository is first scanned with hosted scanning, the full Git history across all branches is scanned. After that, every commit on every branch is scanned as it lands, and each scan reads the full contents of every in-scope file at that commit rather than only the changed lines. A scan run from a CI job covers only the commit being built. History findings are marked as such, and a key found only in history cannot be fixed by editing the file. It has to be rotated or revoked, and then the finding is muted.
Will Datadog Secret Scanning flag our test fixtures?
It will, until they are excluded. A test suite with a placeholder AWS key or a sample JWT matches the same detector as a real one. Datadog supports inline exclusions in the code and muting rules in the findings view. We set the exclusions for known fixture paths during the first triage, record each one, and keep the list so a new fixture directory does not quietly become a hundred findings. A fixture that contains a real key from a real account is not a false positive and is handled as a leak.
What does Critical Cloud do with Secret Scanning every month?
Managed Observability reviews new findings by validation status every month. Any valid key is raised to the owner the same day, with the commit and the rotation steps. We confirm that newly created repositories are enabled and that the gates agreed are still in force. We review exclusions against new fixture paths and re-confirm that muted history findings were actually rotated. Then we report what was found, rotated and routed. A finding is closed only when the rotation is confirmed, not when the file is edited.
- Datadog products: every product, and how we implement and run each one
- Code Security: the group, and how findings reach the developer
- Sensitive Data Scanner: the same credential detectors, applied to the logs and traces
- Code Security Accelerator: repositories, scanners, rules and gates, in four weeks
Every key in the history known. Every live one rotated this week.
Tell us which repositories have ever held production configuration and which one is about to be shared. We will show you what the history scan would find, how many are live, and what it takes to keep that number at zero.