Secrets and Supply Chain

Two scenarios close out the security round. The calm one: "Where do secrets live in your applications?" And the fire drill: "A connection string with a SQL password just got pushed to the repo. What do you do, right now?" The second is a test of incident instincts, and there's exactly one correct first move.

The secrets ladder

Answer the calm question as a ladder by environment. Local dev: user-secrets (dotnet user-secrets) — outside the repo tree, per-developer, zero excuse for real values in appsettings.Development.json. Deployed environments: Azure Key Vault (or the platform's store), accessed via managed identity — the phrase that matters, because it means the app authenticates to the vault without any bootstrap secret to leak. Configuration providers make vault values look like ordinary IConfiguration keys, so code never knows the difference. Pipeline: Azure DevOps variable groups linked to Key Vault, secrets masked in logs. Two senior add-ons: secrets rotate (design for it — cached config must refresh, or at minimum a recycle picks up new values), and the best secret is no secret — managed identity to SQL Server (Authentication=Active Directory Managed Identity) removes the password entirely.

"A key leaked into git — what now?"

Order matters and the interviewer is listening for it: 1) Revoke/rotate the credential immediately. Not after cleaning history — first. The secret is compromised the moment it was pushed; scrapers watch public repos in near-real-time, and even private repos have clones, forks, and CI caches. 2) Assess exposure: what could this credential reach, since when, any anomalous access in the audit logs? For a public-sector shop say the compliance words: this may be a reportable incident depending on what the credential guarded. 3) Then clean history (git filter-repo / BFG, force-push, coordinate clones) — while stating plainly that cleanup is hygiene, rotation is the fix; history rewriting never un-leaks anything. 4) Prevent recurrence: pre-commit scanning (gitleaks), push protection / secret scanning on the server, and pipeline scans. The failing answer is any version of "delete the commit and move on."

Dependencies: the code you didn't write

"How do you know your NuGet packages are safe?" Concrete practices, not vibes: lock and review dependency updates rather than floating on latest; scan continuously — dotnet list package --vulnerable, GitHub Dependabot or the Azure DevOps equivalent wired into CI so a new CVE in an existing dependency pages someone; prefer fewer, well-maintained packages (every dependency is a standing invitation); and keep the framework patched — servicing releases carry security fixes. Bonus vocabulary that lands well in government work: SBOM — knowing what's in your build because someone will eventually ask, in writing.

Answers that fall flat

• Cleaning git history instead of rotating the credential.
• Secrets in appsettings.json "because it's a private repo."
• No process for hearing about new CVEs in already-shipped dependencies.

Practice prompts

• Run the leaked-key drill aloud: rotate, assess, report, clean, prevent — under two minutes.
• Explain managed identity to a junior: what problem it removes and how the app authenticates.
• Sketch the pipeline: where user-secrets, Key Vault, variable groups, and dependency scanning each sit between a dev laptop and production.