Secrets sprawl was already a serious problem when humans wrote all the code. An API key gets pasted into a config file for a quick test, the commit lands, the key sits in git history forever, and three years later somebody clones the repository for an unrelated reason and the credential is still live. GitGuardian built a business on detecting that, and the learning centre it publishes around the problem is unusually practical for vendor content. The situation has changed materially in the last two years, which is why this material matters more now.
Code generation assistants and autonomous coding agents produce a great deal of code quickly, and they produce it in a context where a developer reviews the output less carefully than they would review their own typing. Credentials in example code, credentials in generated test fixtures, credentials pasted into a prompt and then echoed back into a file. The rate at which secrets enter repositories has gone up for structural reasons and the review step that used to catch some of them has thinned. The remediation content is the best part and I would recommend it to anyone regardless of whether they ever buy the product.
There are specific, step-by-step guides for what to do when a particular credential type leaks: AWS access keys, database credentials, Google API keys, OpenAI keys, generic API tokens. Each covers the actual sequence, which is revoke first, assess exposure second, rotate third, and work out how it happened fourth. That ordering matters and people get it wrong under pressure. The instinct when a key leaks is to investigate, and the correct action is to revoke immediately and investigate afterward, because the window where the credential is live and public is the only part of the incident you can still control.
Material that drills that ordering into people before they need it has real value. The secrets glossary is a smaller thing that earns its place. Terminology in this area is muddled, with secret, credential, token, key and identity used interchangeably by people who mean different things, and having a shared reference to point at resolves arguments quickly. The non-human identity content is where I want to be more careful.
The observation underneath it is correct and important: service accounts, machine identities, CI runners and now autonomous agents vastly outnumber human users in most environments, and they are governed far less rigorously. The secret zero problem, meaning the credential that protects all the other credentials, is a real and under-discussed issue. All of that is worth learning. It is also true that NHI as a named category is something GitGuardian and its peers are actively working to establish, because a named category is easier to buy a product for.
Learn the concepts, treat the acronym with mild scepticism. The State of Secrets Sprawl report deserves a mention because it is one of the few vendor research reports built on data rather than on a survey of three hundred self-selected security leaders. Scanning public repositories at scale produces actual numbers about actual leaks, and those numbers have been consistently alarming in a way that has changed how some organisations think about the problem. The structural limitation is that this is a library rather than a course.
There is no path, no assessment, no credential. If you want something to put on a CV, this is not it. If you want to know what to do in the first ten minutes after a key leaks, it is better than almost anything you will pay for. Three point nine.
Free, ungated, practical, written for the person with the problem rather than the person with the budget, and more relevant now than when it was written because AI-assisted development has made the underlying problem worse.