GitHub Token Exposure in Docker Image Layers: OWASP A02 Vulnerability Confirmed

A critical security flaw has been confirmed in the Docker build process for services under the `tazamaorg` namespace. The GitHub Personal Access Token (`GH_TOKEN`), used for authentication with GitHub Packages, was being leaked into the metadata of published Docker images. This exposure occurs because the token is passed as a standard `build-arg`, which Docker permanently records in the image's layer history. Anyone with pull access to the image—such as `tazamaorg/<service>:<tag>`—can retrieve the secret token using a simple `docker history --no-trunc` command, constituting a direct credential exposure vulnerability classified under OWASP A02: Cryptographic Failures.

The vulnerability is present in two GitHub Actions workflows: `dockerhub-image-build.yml` and `dockerhub-image-build-rc.yml`. Both workflows currently pass the sensitive `GH_TOKEN` via the `build-args` parameter, which is the root cause of the persistent leak into the final artifact. This design flaw transforms a private authentication secret into a publicly accessible piece of image metadata, fundamentally undermining the security of the GitHub Packages (`npm.pkg.github.com`) integration.

The prescribed solution mandates a shift from using `build-args` to leveraging BuildKit's native secret management. By using the `secrets` parameter in the `docker/build-push-action`, the `GH_TOKEN` can be mounted as an in-memory filesystem (`tmpfs`) exclusively within specific `RUN` commands during the build. This method ensures the token is never written to any image layer, eliminating the historical trace and closing the credential exposure vector. The fix requires updating both workflow files to implement this secure pattern immediately.