Build Pipeline Security Starts By Treating The Artifact Repository As Tier 0

There is a machine in almost every business network that holds a checkout of the source code, credentials to the cloud account, push rights to the container registry, and a scheduled job that touches production on a Tuesday night. Nobody calls it a domain controller. Most asset inventories file it under development, somewhere between the wiki and the test database. It is the build server, and along with the artifact repository it publishes to, it is the most consequential pair of systems that a small or mid-sized company has almost certainly never threat modeled.

The last two weeks made that case better than any blog post could. A JFrog Artifactory flaw let an attacker mint administrative tokens against the repository that stores every binary an organization ships. A FreeIPA vulnerability handed anonymous clients administrative rights inside the identity domain that a lot of Linux build fleets authenticate against. An N-able N-central pre-auth remote code execution bug landed in the same window, on the management console that pushes software to endpoints. Different vendors, different bug classes, one shared property. Each of them sits on the trust path between the code a business writes and the software its customers actually run.

Build pipeline security is not a developer concern that security teams politely defer to. It is infrastructure security applied to the one tier that can sign, store, and distribute anything it wants, to anywhere it wants, and have every downstream system accept the result without argument.

The build and artifact plane is a trust root, and nobody drew it on the diagram

Walk through what happens when a business ships a change. A developer merges to main. A runner picks up the job, pulls dependencies from a public registry and a private one, compiles or bundles the result, tags it with a version, and pushes the artifact to a repository. Something downstream, a deployment job, an orchestrator, an update service, or a customer's own auto-updater, pulls that artifact and executes it. At no point in that chain does anything meaningfully re-verify the intent behind the bytes. The pipeline is trusted because it is the pipeline.

That is what makes this plane a trust root in the same sense a certificate authority is a trust root. NIST's Secure Software Development Framework, SP 800-218, spends much of its Protect the Software and Produce Well-Secured Software practice groups on exactly this idea, that the integrity of the build and release process is a security control and not a delivery detail. CISA and NSA said the same thing more bluntly in their joint guidance on defending continuous integration and continuous delivery environments, which frames the CI/CD stack as high-value attacker infrastructure rather than a productivity tool.

Here is the part that gets missed in a small business context. Nobody needs a formal software supply chain program to be exposed to this. A company with fourteen employees, one self-hosted runner, and a Docker registry living on a virtual machine in the corner of the hypervisor has all of the trust properties and none of the controls. The registry is a trust root whether or not anyone put it on a slide.

Asset inventory is where this starts to fail, which is the same story I keep landing on in these posts. NIST SP 800-53 control CM-8 asks for an inventory of system components detailed enough to support the security program. In practice the build server gets inventoried as a workstation-class asset, which means workstation-class patch priority, workstation-class log retention, and workstation-class network placement. The artifact repository frequently is not inventoried at all, because an engineer stood it up in an afternoon and it never went through procurement. When a critical advisory drops on a Thursday afternoon, the honest answer to "do we run that" takes four days instead of four minutes.

Why a token minting flaw makes MFA on the console irrelevant

The Artifactory issue is worth sitting with because of its shape rather than its severity score. A flaw that lets an unauthenticated party mint an administrative token is not a weak password problem or a phishing problem. It is an authentication bypass, and an authentication bypass means the login logic never runs.

Every control an organization layered on top of that login screen assumes the logic executes. Multi-factor authentication is a step inside the authentication flow. Conditional access policies evaluate during that flow. Impossible-travel detection needs a sign-in event to inspect. Account lockout counts failed attempts against a code path the attacker never touched. When the token comes out the side of the building, front-door hardening is decoration. This is the same structural lesson as the FortiOS authentication bypass in CVE-2022-40684, the Cisco IOS XE web UI implant campaign under CVE-2023-20198, and the PAN-OS management interface bypass in CVE-2024-0012. In MITRE ATT&CK terms the technique is T1190, exploitation of a public-facing application, landing directly at T1078, valid accounts, without ever passing through credential theft.

The FreeIPA advisory is the identity-side twin of the same problem. If anonymous clients can obtain administrative rights in the identity domain, then every host trusting that domain for authentication has lost its access control decisions wholesale. On a Linux build fleet using FreeIPA for SSH access and sudo rules, that means the runner, the artifact host, and whatever else got joined to the realm because joining the realm was the convenient way to manage keys.

The defensive conclusion is unglamorous, and it is the same one every time. Since identification and authentication controls do nothing against code that executes before authentication, the remaining lever is reachability. SC-7, boundary protection, is the control that actually changes the outcome here. The Artifactory web interface and the CI console have no business resolving from the internet, and when a vendor architecture requires an internet-facing component, that component belongs behind a VPN or a zero trust proxy that authenticates first. CISA's Binding Operational Directive 23-02 pushed federal agencies to pull management interfaces off the public internet for exactly this reason, and the logic ports cleanly to a fifty-person company in Plano running a self-hosted registry.

The CI service account is the most overprivileged identity you own

Ask a security team to name the most privileged non-human identity in the environment and you usually hear the backup service account or the vulnerability scanner credential. Both are reasonable answers. Neither is usually the right one.

The CI service account tends to hold, in one credential set, the ability to read every private repository, push to the artifact registry, assume a cloud role with deployment permissions, decrypt whatever sits in the secrets manager, and connect to at least one production database because a migration job needed it in 2023 and nobody revoked it afterward. Those permissions were granted incrementally, each one justified at the time, each one small. The aggregate is a credential that can do more damage than most domain administrator accounts.

Attackers understand this economy better than most defenders do. The Codecov Bash Uploader compromise in 2021 was not interesting because a shell script got modified. It was interesting because the modified script simply printed the environment variables of every CI job it ran inside, and CI environments are where organizations concentrate their most valuable secrets in plaintext at runtime. That is T1552, unsecured credentials, executed at industrial scale without exploiting anything beyond trust already granted. The CircleCI incident in January 2023 produced the same downstream advice, which was to rotate every secret stored in the platform, because there was no way to reason about which ones had been read.

The control objective is AC-6, least privilege, applied to machine identity with the seriousness normally reserved for human accounts. That means the build identity and the deploy identity stop being the same identity. A pipeline that compiles code and produces an artifact needs registry push rights and nothing in production. A deployment process that promotes an artifact to production needs the ability to pull and deploy, and no access to source. Splitting those two converts a total compromise into a partial one, which is the entire game. It also gives you something to alert on, because a build job that suddenly authenticates with the deploy identity becomes an anomaly instead of a Tuesday.

Short-lived credentials do the rest of the work. OpenID Connect federation between a CI platform and a cloud provider, where the job exchanges a signed workload identity token for a temporary role session, removes the standing cloud key from the environment entirely. If there is one modernization worth funding this quarter, it is that one, because it deletes the exact class of secret that Codecov-style collection exists to harvest.

SolarWinds, Codecov, and 3CX were the same attack wearing different clothes

The lineage matters because it shows this pattern is mature rather than emerging. SUNBURST, disclosed in December 2020, worked because the adversary compromised the SolarWinds build process and injected code during compilation, which meant the resulting Orion update carried a legitimate vendor signature and passed every integrity check a customer could reasonably perform. Nothing about customer patching discipline mattered. Applying the update was the attack.

The 3CX compromise in 2023 added a recursive twist, since initial access into 3CX traced back to a trojanized installer for an unrelated financial trading application that an employee had downloaded. One poisoned build produced a second poisoned build. The xz-utils backdoor tracked as CVE-2024-3094 refined the technique again by hiding the payload in test fixtures and injecting it through the release tarball's build scripts, so the public source repository and the shipped artifact told two different stories.

MITRE tracks this family as T1195.002, compromise of the software supply chain. What the incidents share is that the target was the process rather than the product. An attacker who owns the build gets code execution on every downstream consumer with the vendor's own reputation attached to the payload. For an MSP or a software company in the DFW area shipping an agent or an installer to a few hundred customers, the math scales the same way it did for SolarWinds, just with smaller numbers on both sides of the equation.

Signing and provenance make a stolen artifact considerably less useful

If the artifact repository is a trust root, the practical question becomes how a downstream consumer distinguishes a legitimate artifact from one an attacker uploaded using a stolen admin token. Storage location is not an answer, because the attacker is putting the file in exactly the right location under exactly the right name. The answer is cryptographic provenance.

Artifact signing at build time, verified at deployment time, breaks the chain that a repository compromise depends on. The SLSA framework, now maintained under the Open Source Security Foundation, describes this as a set of increasing levels that start with generating provenance recording what was built, from which source, by which builder, and progress toward provenance the build process itself cannot falsify. Sigstore makes the key management side survivable for small teams by issuing short-lived certificates tied to workload identity rather than long-lived signing keys somebody has to protect for five years.

The verification side is where most implementations stop short, and stopping short wastes the effort. Signing artifacts and then deploying whatever happens to be in the registry regardless of signature is a compliance artifact, not a control. Admission policy in the orchestrator, or a verification step in the deploy job that fails closed on an unsigned or mis-signed artifact, is what turns provenance into enforcement. NIST SP 800-218 practice PS.2 is the reference to cite when somebody asks why the sprint has a story about signature verification in it.

Provenance pays off during incident response too, which is the underrated half. When an advisory lands and the question is which of our releases could have been affected, an organization with build provenance answers from a query. An organization without it answers from memory and optimism.

Detecting compromise on a system whose entire job is publishing binaries

Here is the detection problem stated honestly. The build server compiles unfamiliar code, spawns processes with strange names, reaches out to the internet to pull dependencies, writes executables to disk, and pushes them to a network service. Every behavior an endpoint detection product would flag on a finance workstation is the documented purpose of this machine. Behavioral detection tuned for a normal fleet produces either silence or noise on a build host, and both outcomes end the same way, with somebody adding a broad exclusion and moving on.

The way out is to stop hunting for malicious behavior on the host and start watching for deviation in the outputs. Registry push events make a good baseline candidate because they have shape. Pushes come from known identities, at known times, from known source addresses, tagging known repository names. A push to a repository nobody has published to in eight months, from the CI identity, at three in the morning, matches no signature anywhere, but it is a clean anomaly against a baseline. The same logic applies to pipeline definition changes, changes to which branches can trigger a deploy, and new tokens or deploy keys created inside the platform.

Log location decides whether any of this survives contact with an actual attacker. AU-9, protection of audit information, exists because logs stored on a compromised system are logs the attacker can edit. Build platform audit logs, artifact repository access logs, and host telemetry all need forwarding off the box in near real time to somewhere the build identity holds no write permission. Once that is true, absence-of-telemetry alerting becomes possible, which remains one of the highest-value and least-implemented detections available anywhere. If the build server stops sending logs at 2:14 in the morning and nobody has a maintenance window open, the gap itself is the finding.

Corroboration from systems the build plane does not control is what closes the case. Internal DNS resolver query logs will show a runner resolving a domain it has never resolved before. Switch-level flow data will show egress volume that does not match a dependency fetch. The identity provider's sign-in logs will show a service principal authenticating from an unfamiliar location. None of those three is conclusive on its own. Correlated inside a monitored environment, they are the difference between finding this in hours and finding it in a customer notification email.

What to actually do about build pipeline security in the next ninety days

Start with inventory, because everything downstream depends on it. Write down every system that can build, sign, store, or distribute software. That includes the CI platform, self-hosted runners, the artifact repository, the container registry, the package proxy, any code signing service, and the deployment orchestrator. For each one, record who administers it, what identity it runs as, what it can reach, and where its logs go. The exercise reliably surfaces at least one runner nobody remembered provisioning.

Then handle exposure. Scan your own external footprint the way an attacker would, using Shodan or Censys against your address space alongside a direct scan, and confirm nothing in that inventory answers from the internet. Anything that genuinely must be reachable goes behind an authenticating proxy first.

Next, split the identities and shorten the credentials. Build and deploy become separate identities with separate permissions, standing cloud keys give way to federated short-lived credentials, and every secret that has been sitting in a pipeline environment since before the split gets rotated on the assumption that it has already been read.

Finally, write down a patch clock for this tier specifically. SI-2, flaw remediation, requires an organization-defined time frame, and the default time frame in most small businesses is whenever somebody notices. Borrowing the structure of CISA's Binding Operational Directive 22-01, anything in the Known Exploited Vulnerabilities catalog touching the build or artifact plane gets a short defined window, and FIRST's EPSS scoring offers a sane way to sort everything else by likelihood of exploitation rather than by CVSS alone. Every advisory from the last two weeks would have tripped that clock immediately, which is the point of writing it down before the advisory rather than during it.

Where this work usually lands

The frustrating part of build pipeline security is that the evidence lives in different consoles that do not talk to each other, so a token minted in the artifact repository, an unusual push at an odd hour, and an egress spike from a runner arrive as three unrelated events in three places, none of them alarming alone. That correlation problem is what the Managed SOC and Threat Management module inside CyberSphere was built to handle, with 24/7 monitoring that pulls platform audit logs, identity telemetry, and network flow into one view, ties detections to remediation tickets in the same dashboard, and runs dark-web breach monitoring for the credentials that tend to surface publicly after this class of compromise. For MSPs and IT partners around McKinney, Plano, Allen, and Frisco who would rather deliver that capability under their own brand, the partner portal is white-labelable. The platform sits at https://cybersphere.thecyberone.com/, though the honest first move for most teams is not buying anything at all. It is finishing the inventory, because you cannot monitor a build server you have not written down yet.

Ready to Take the Next Step?

Innovation Network Design helps businesses across McKinney, Dallas, and the DFW metroplex — as well as organizations nationwide — with expert cybersecurity services. Contact us for a free consultation and we'll assess your needs with clear, actionable recommendations.

Have questions? Call us at 512-518-4408 or schedule a free assessment.