// Defense

Explore Non-Human Identity & Secrets Management

Your CI pipeline has a secret. So does your attacker.

Machine identities — service accounts, API keys, OAuth tokens, CI/CD credentials, workload certificates — already outnumber the humans at your organization by ten to one, sometimes fifty to one. Each one can authenticate and act with no second factor standing between it and real damage. This topic is about the full lifecycle: how those identities get issued, scoped, stored, rotated, and revoked — and what happens when any one of those stages quietly breaks.

The field has a dry running joke: most serious breaches weren't won by breaking cryptography. They were won by copy-paste. A key committed to a private repo, an environment variable exposed in a crash dump, a CI log that shouldn't have been public — that's the actual attack surface. Here you'll work through why "it's in a private repo" is not an argument, why a secret manager where one IAM role can read everything is just a more expensive environment variable, and why scope and expiry are the closest thing machine identities have to a second factor.

Sessions on this topic follow the practitioner's instinct: start with a concrete leaked credential and ask what an attacker can do with it right now — then work backwards into prevention, detection with tools like gitleaks and trufflehog, short-lived federated alternatives like OIDC workload identity and SPIFFE/SVIDs, and the rotation process you can actually execute at 2am under incident pressure. The goal isn't a certification checklist. It's building the habit of asking, about any credential, "what is it allowed to do, and for how long?"

// What a session feels like

You bring the questions. Nugget asks the next one.

You paste a Docker image's ENV block into the session and ask why baking AWS_SECRET_ACCESS_KEY into the layer is worse than injecting it at runtime. Nugget doesn't hand you the answer — it asks you to map every stage where that image exists: build cache, registry, layer history, any system that pulls it. The whiteboard fills up with a timeline of exposure surfaces you hadn't counted. By the end you can articulate the difference in terms of blast radius, not just "best practice".
You're in the browser terminal and Nugget hands you a simulated scenario: a long-lived GCP service account key has just been confirmed leaked. It asks one question — what's your kill path? You work through revoking the key, checking IAM audit logs for usage since issuance, and scoping what the key could actually reach. Nugget then asks the follow-up that changes the exercise: "What if you couldn't safely revoke it without taking down a production job?" That's where rotation-under-pressure stops being theoretical.
You tell Nugget you've moved your team's secrets into AWS Secrets Manager and want to understand what's still left to do. It asks who currently has read access to the secrets store — and whether that's one broad IAM role or several narrow ones. The conversation moves to whether anything in the store is a static long-lived key that could be replaced with a short-lived OIDC workload identity token, and Nugget pulls a current AWS docs reference mid-session to anchor the federation setup. "Put it in a secret manager" was the beginning of the problem, not the end.

// Pairs well with

Incident Response Detection Engineering Software Supply Chain Security

Start exploring Non-Human Identity & Secrets Management tonight — three topics free, no card.

Start a 30-day free trial