Secrets & Supply Chain

An API key goes into a config file by mistake, gets committed, and is spotted within the hour. Someone removes it in the next commit, and the branch looks clean. It is not: the key is still sitting in the repository's history, readable by anyone who can clone it, and if the repository was ever public it should be assumed to have been harvested by an automated scanner within minutes. The only real fix at that point is rotation. This track is about the two build-time problems that make a perfectly written application insecure anyway.

The first is keeping credentials out of the repository in the first place, which means catching them before the commit lands rather than auditing afterwards. You will look at what a secret actually looks like to a scanner — high-entropy strings, recognisable key prefixes, private-key headers — why scanning history is a different and much slower job than scanning a diff, and why the response to a real detection is always rotate-then-clean rather than clean-and-hope. Where the secrets should live instead follows naturally: injected at runtime from a manager or the environment, never baked into an image or a config file that travels with the code.

The second is everything you did not write. A modern application is mostly dependencies, each one running with your process's full privileges, any one of which can be compromised upstream or simply left unpatched for years. The defences are unglamorous and effective: pin versions so that a build is reproducible and an unexpected change is visible, maintain an inventory so that "are we affected by this advisory?" is a lookup rather than an investigation, and patch on a schedule rather than on the news cycle. Together with the secrets half, this is the part of application security that lives in your pipeline rather than your code.