A speaker on OWASP's channel says three build habits put 500,000 tokens in public images

A speaker on the OWASP Foundation's channel said that about 500,000 GitHub tokens ended up in public Docker Hub images. The episode is called "Race Against The Workflows." The speaker blamed three common build habits chained together. The figure comes from a machine transcript, and we could not check it. The excerpts also give no count of tokens that could write to a repository.

What was said

The speaker walked through the chain. First, checkout, an action made by GitHub, pulls the code onto the build machine. It works like a git clone over the web, using a temporary GitHub token. Git caches that token in a .git/config file inside the local copy. The speaker called this a small catch.

Second, the Docker build step sets its context to the current folder, because that is where the code was cloned. The context is the set of files handed to Docker, so the cached token goes along. Third, a COPY instruction with a dot puts the whole context into a layer of the image. The speaker called this an anti-pattern and said: "It's bad, but no one cares about it because why?"

The image is then pushed to Docker Hub as a public image. The speaker called this a very common use case. To show how common COPY is, the speaker said 3.7 million Dockerfiles on GitHub contain a COPY instruction of some kind. That figure does not count only the risky COPY-with-a-dot form.

Why it matters

Our reading: reviewers check lines one at a time, and each of these lines can pass. The problem shows up only in the finished image. A pipeline repeats that result on every run, with no person watching.

Also our reading, and not the speaker's advice, here are questions for a security team. Do any images we publish contain git configuration files? Inspect built layers, not just Dockerfiles. Does the build need the saved credential at all? Can the build context be narrowed? The speaker made one more point: "You are leaking maybe not your secrets but you are leaking your private code and that's already pretty bad."

The other side

The speaker raised two limits on the damage. The tokens are read-only by default, which adds little when the repository itself has leaked. They also die when the workflow ends, so a token leaked a month ago is useless today.

The speaker argued these limits matter less than they seem. Workflows get permissions based on what they need, and an attacker can simply look for tokens that can write. Examples were pushing a malicious commit or overwriting a package image.

The speaker gave no count of write-capable tokens in the excerpts, or of tokens still live when found. That argument therefore rests on what is possible, not on a measured number.