Your CI masks secret values in job logs, yet a credential still escaped the build. Which build outputs carried it out?

## What masking is, precisely A CI platform's log masking takes the values it holds in its secret store and replaces occurrences of them in a job's log stream as that stream is written. That is the whole scope: **one output, one job, literal values it was given**. It is a last-line safety net designed to catch a careless `echo`. It is not an access-control decision, it does not follow the value anywhere, and it does not know that the string it just redacted was also written to a file two seconds earlier. ## The channels masking never sees **Uploaded artifacts.** The largest source of real leaks. A job that fails partway through an integration run often uploads a diagnostic bundle so somebody can debug it later, and the easiest way to build that bundle is to archive the workspace. That sweeps in the rendered configuration file the deploy step generated from a template, the `.env` the test harness materialised, the kubeconfig, the temporary key file a client library expected on disk. The bundle is then downloadable by everyone with read access to the project — often the whole organisation — for the artifact retention window, which is typically measured in weeks. **Caches.** Build caches are saved and restored by key, so a secret that landed in a cached directory (a package-manager config with an embedded token, a credential helper's store) does not just persist — it *propagates*, restored into later builds of other branches by jobs that were never supposed to hold it. **Image layers.** Anything written to the filesystem during an image build travels with the published image, regardless of whether it also appeared in a log. **Test reports and crash output.** Verbose failure output prints request headers, connection strings and full environment dumps into structured report files, which are usually uploaded and rendered in a UI rather than passed through the log redactor. Core dumps and heap dumps are worse: they contain process memory, and no redactor is looking at them. **Generated manifests and lockfile-adjacent files.** Any file the build renders from a template that interpolates a secret is a leak once that file leaves the runner. ## And masking is leaky even inside the log Since matching is literal, the redactor fires only when the exact registered value appears. Anything that changes the bytes defeats it: base64 or hex encoding, a reversed string, JSON pretty-printing that inserts escapes or line breaks, printing the value one character at a time, a URL-encoded form inside a query string, or a value split across two log lines. None of that requires malice — a debug step someone added at 2am does it by accident, and a deliberately poisoned build step does it on purpose. This is why masking is described as a safety net rather than a boundary: a control that any transformation defeats cannot be the thing you rely on. ## Who is the attacker here Often nobody external. The realistic reader is an authenticated low-privilege insider — a contractor, a new hire, an intern, or an account compromised through ordinary phishing — who has read access to the project and can browse artifacts. They do not need to attack anything; they download a bundle. That also destroys your ability to reason about the incident afterwards, because artifact download logging is usually thin or absent, so you cannot prove nobody took it. ## Controls that actually help - **Keep the secret out of the filesystem.** Consume it from the environment in the single step that needs it, and prefer credentials the runtime fetches for itself over ones the build writes down. - **Name what you upload.** Upload the specific report files you need, never a glob of the workspace. A diagnostic bundle should be an allowlist, not a sweep. - **Scrub before you publish.** If a bundle must include rendered config, run a redaction pass over it as an explicit build step, and fail the job if a known-shaped credential is found rather than uploading anyway. - **Shorten retention and narrow audience** on artifacts from jobs that touch production credentials — a real reduction, though not a fix, because it only shrinks the window. - **Prefer short-lived, narrowly scoped credentials**, so that a leaked value expires and reaches little. - **Assume exposure when you find one.** Because you usually cannot prove who downloaded the artifact or restored the cache, the correct default on discovery is rotation, not investigation-then-maybe-rotation. ## The one-line version for an interview Masking protects the log; it does not protect the build. Ask of every secret: which files did this value touch, and which of those files leave the runner?