What actually leaks from build pipelines.

The premise

Most CI/CD platforms have improved their default secret handling materially since 2023. GitHub Actions, GitLab CI, and the major cloud-vendor pipeline products now mask secrets in logs, restrict secret access by repository, and offer audit trails on secret usage. The default is meaningfully safer than it was two years ago.

That does not mean pipelines stopped leaking. It means the leaks shifted to the places where defaults are still weak.

This report is about where the leaks actually happen in 2026, drawn from pattern observation across many engagements, with no engagement attributable.

The five surfaces we read

1. Public workflow files in private-org pages. GitHub repositories under a public organisation have their .github/workflows/ directory readable by anyone, even when the repository itself is private — if the workflow run history page has been enabled for public viewing. The same logic applies to GitLab public CI/CD pages. The workflow YAML rarely contains a secret, but it contains the shape of the deployment: cloud account hints, role names, deployment target patterns. An attacker uses that shape to build the social-engineering pretext for the operator.

2. Artefact downloads from old runs. Workflow run artefacts are kept for the platform's retention period — typically 90 days. Many runs upload more than the team realises: full build directories, debug logs, profiling output, test result JSON containing fixture credentials. The retention defaults are generous; the cleanup discipline is not.

3. Public Docker images tagged with the CI run ID. This is a recurring failure mode. A pipeline tags its build with ${BUILD_ID}, the build ID is published to a public Docker namespace, and an attacker can enumerate the tags to walk the full history of intermediate builds. Each intermediate build may have been pushed with --build-arg containing a credential that the team rotated after the build. The credential is gone from the secret store. The image is not.

4. Public S3 buckets or equivalent used for "release artefacts." A team publishes a release artefact, makes the bucket public to let customers download it, and forgets that the bucket also contains the staging artefacts, the QA artefacts, and the internal-only "test release" artefacts from a year ago. The release process never explicitly listed which versions are public. The bucket policy did.

5. Sourcemaps published with the production bundle. The single most-leaked CI artefact in 2026 is the sourcemap of a production JavaScript bundle. The team published the sourcemap for an internal debugging workflow, forgot the production build also exposes it, and the bundle's full original source — including API endpoint constants, auth flow comments, and feature-flag names — is reconstructable in any browser devtools.

What attackers actually stop at

A pattern from six months of observation: attackers reading public CI/CD signals are surprisingly disciplined in what they treat as actionable. They tend not to pursue:

• Logs with high-noise output and no recognisable credential pattern.
• Artefact ZIPs without an obvious filename hint.
• Workflow YAML that does not reference a cloud account or role name.

They tend to pursue, in order:

• Any artefact whose filename contains prod, release, staging, or a version tag.
• Any workflow that references a specific named cloud role (especially with a star scope nearby).
• Any sourcemap.
• Any artefact ZIP older than 60 days from a repository that has since been made private — the artefact survives the privacy flip.

This is useful information when prioritising what to clean. The cleanup ROI is highest at the top of this list.

The pipeline-leak triage runbook

For a team that wants to act before commissioning an audit, the order of operations matters.

1. Inventory public-facing workflow runs. For GitHub Actions: visit the organisation's public profile, list every public repository, and check the Actions tab of each. Note any workflow whose runs are publicly readable. Decide which are intentional.
2. Purge or rotate artefacts. The GitHub Actions retention default is 90 days. Walk the artefact list of every workflow you intend to keep public. Delete what is not needed; rotate the credentials referenced in what was published.
3. Disable sourcemap publication on production bundles. This is a one-line config change in every major bundler. The downside is harder production debugging; the upside is the elimination of a class of leaks.
4. Tag policy for public registries. Decide which CI-generated tags are allowed to be public. Most teams do not need any CI tag to be public; the production tag can be republished as prod, prod-N, without the build ID.
5. Bucket policy review. Every "release artefact" bucket should have a manifest of what is intended public. If the bucket grew organically, the manifest does not exist. Build it.

What this is not

This is not a comprehensive supply-chain hardening guide. It is the subset of CI/CD exposure that an external attacker can read without authentication, in 2026, in patterns Labs has seen repeat.

The internal pipeline surface — runner compromise, build-time injection, dependency confusion via internal registries — is a separate report and requires evidence Labs cannot collect from outside. For that, a different class of engagement is needed.

Where Labs comes in

A Labs Discovery Brief on a single organisation will identify which of the five surfaces above are currently exposed and produce a runbook for the first cleanup pass. A Board-Ready audit extends this to the full historical surface of the organisation's public footprint, with the AI-Alliance Challenging applied to each finding and a retest attestation on closure.

If you have a public organisation profile and you have not audited the workflow-run visibility in the last six months, the probability that something is currently public that should not be is high enough to be worth a 3-day diagnostic.