Build Pipelines Are Production Systems

The SolarWinds compromise was a wake-up call that exposed a blind spot many organizations still carry: the code that builds and ships software is just as attractive a target as the application code itself. Attackers who can manipulate a build pipeline can inject malicious behavior into every artifact that pipeline produces, reaching downstream consumers who never touch the compromised systems directly.

Yet many teams don't know the full sprawl of their build environments, nor do they treat the ones they do know about with production-level rigor. Build systems are production systems—they are extensions of your operating environment and deserve the same protection you'd apply to your most sensitive operations.

A practical first step is simply taking inventory. How many build systems do you have across the org? How many distinct tech stacks feed into your artifacts? Understanding exactly what inputs flow into the software you produce is a prerequisite to securing the process. You can't protect what you don't know exists.

Two-Factor Authentication Is the Baseline

There's a temptation in security circles to focus on sophisticated threats and exotic attack techniques. But the most effective supply chain hardening measures are still the basics—and there is no more basic measure than requiring two-factor authentication.

Account takeover of maintainers and publishers is one of the oldest and most persistent attack vectors against the open source ecosystem. Once an attacker controls a contributor's account, they can push malicious code to packages that millions of developers depend on. GitHub now requires 2FA for all code contributors on its platform, a decision made after first rolling out the requirement to npm package publishers considered high-impact.

By requiring 2FA for contributors, maintainers, and publishers, you dramatically reduce the risk of account takeover—and, by extension, the risk to every developer who builds on that code. Phishing remains a top threat precisely because account compromise is so often the entry point for larger attacks.

Organizations should enable 2FA for every account and require it across their production infrastructure. This is a quick win that requires no new tooling, only discipline and enforcement.

Provenance Makes Dependencies Verifiable

When you pull in an open source package, do you actually know where it came from and how it was built? Most developers don't—but they should hold third-party code to a similar standard as they would a random USB drive found in a parking lot.

To help close this gap, GitHub partnered with the Sigstore project to bring provenance to the npm registry. This allows package maintainers to generate signed attestations about where their software originated and how it was built. Consumers can then verify these claims and make their own trust decisions instead of relying on blind faith in a package name.

The adoption of Sigstore in the community has been significant, and the model is straightforward: if you publish npm packages, build them with provenance enabled. If you consume npm packages, use provenance to validate what you install.

A Practical Checklist for Broader Threat Modeling

Expanding your supply chain threat model should start with a concrete set of questions, each better answered by a specific action.

  • Do you understand your build systems? Make an explicit list of every pipeline, stack, and artifact store in your organization. Inventory is the foundation of control.
  • Are you and your users on 2FA? If not, implement it now. This is the single highest-leverage step for preventing account takeovers that lead to malicious package releases.
  • Do you trust your third-party dependencies? You can't verify the packages you install unless you track which ones you have. Maintain a full inventory, and check how the registries and publishers you rely on secure their own operations.
  • Have you audited your third-party integrations? Review every app and integration connected to your GitHub organization. Remove any that are unused, and give those that remain only the minimum access required for their function.