Build Infrastructure Is a Trust Anchor: Threat Modelling Exposed CI/CD and Artifact Repositories

A build server holds the credentials that sign, package and publish your software. An artifact repository holds the packages your production systems install. Neither is a peripheral system, and both are frequently reachable from networks they were never meant to face.

Treating them as ordinary internal services is the modelling error. They are trust anchors: compromising one lets an attacker produce software that your own pipelines will accept.

The reachable population

Measurements taken on 20 September 2026 show how much of this class is internet-observable. app="GitLab" returned 1,315,022 matches, app="Artifactory" returned 1,524, app="SonarQube" returned 11,586, app="Nexus Repository" returned 33,772, app="Gitea" returned 115,463 and app="Jenkins" returned 3.

The Jenkins figure is instructive rather than alarming. A count of 3 means the fingerprint matched three assets, not that three Jenkins servers exist on the internet. Fingerprint coverage for a given product varies enormously, and a small number is evidence about the fingerprint, not about the population.

The GitLab figure is the opposite case: a large count for a product whose fingerprint is well established. Neither number tells you whether a given instance is misconfigured. Both tell you the class is widely deployed on reachable addresses.

What an attacker gains

Work through the trust relationships rather than the vulnerabilities.

Source control. Read access to repositories reveals internal architecture, hard-coded endpoints and sometimes secrets committed by accident. Write access allows a change that the pipeline will build and ship.

CI runners. A build job executes code. If an attacker can influence what a job executes, they execute code with the runner's credentials, which typically include registry and deployment access.

Artifact repositories. These are the distribution point. An attacker who can publish to a repository your systems trust does not need to compromise the build at all.

Signing material. Where signing keys are held in the build system, compromise of the build system is compromise of the signing identity.

Each of these is a different path to the same outcome: code you did not author, delivered through a channel you trust.

Modelling questions worth answering

Who can reach the interface?

A GitLab instance or Jenkins controller reachable from the public internet has a different exposure profile from one behind a VPN. Establish which it is before discussing anything else.

What can a build job reach?

A runner that can reach production, the cloud control plane and the artifact repository is a single point of failure. Runners should reach what the build needs and nothing more.

Who can publish to the repository?

Write access to an artifact repository is a privileged capability. Enumerate who holds it, including service accounts and tokens that were issued once and never revoked.

Where do the secrets live?

Secrets in environment variables, in job configuration and in repository files have different blast radii. Know which you are relying on.

What is the provenance of an artifact?

If you cannot state which pipeline produced a package and from which commit, you cannot detect a substituted artifact. Provenance is not a compliance artefact; it is the detection mechanism.

Practical hardening

Remove public reachability from build systems. There are very few legitimate reasons for a CI controller to answer on the public internet.

Scope runner credentials to the job. A runner that deploys to production should not also be able to read every repository.

Separate the build identity from the publish identity. The account that compiles code should not be the account that signs and publishes it.

Require review on pipeline definition changes. A change to the pipeline file is a change to what executes. It deserves the same review as application code.

Rotate and inventory tokens. Long-lived tokens issued for a migration in a previous year are still valid.

Log artifact publication. Publication events are the ones you need during an investigation, and they are frequently not retained.

Why this keeps being missed

Build infrastructure is owned by engineering, not by security, and it is measured by how often it works. It is also invisible to the asset inventory that the security function maintains, because it was never a server anyone classified.

The result is a system with privileged access to everything, outside the process designed to protect privileged systems. Fixing that is an ownership question before it is a technical one.

References

• ZoomEye measurement queries executed 20 September 2026 via the ZoomEye AI cyberspace search service, sub_type=all: app="GitLab" (1,315,022), app="Artifactory" (1,524), app="SonarQube" (11,586), app="Nexus Repository" (33,772), app="Gitea" (115,463), app="Jenkins" (3). Counts describe internet-observable matching assets at query time and do not confirm vulnerability, misconfiguration or exploitation.