Build Pipeline Hardening

Find it by running the build in a sandbox with outbound access denied and seeing which step fails. Replace the fetch with a declared input pinned by content digest, fetched and verified in a separate phase before the sealed build runs.

Find out why the hatch is used before removing it: it usually marks a gap in the paved road. Make every use attributed, dated and reported, close the gaps, then narrow the hatch to an approved exception and delete it.

Enumerate every trigger — branch pushes, tag pushes, path-filtered runs, schedules, manual dispatch — and record for each who can cause it and what code it executes. Then remove credentials from any job an unreviewed ref can reach.

Approval gating stops the credential from ever being injected into jobs that run unreviewed code. A poisoned build step cannot read a value that was never placed in its process — an authorization decision, not a redaction.

Start from what the step can reach, not how popular it is: does it need a secret at all, who publishes it, is the pinned source readable, what does it do at run time, is a first-party alternative cheaper.

Decide by the trust level of the code the job runs and the value of what lives on the host, not by team convenience. Persistence is an exception with an owner, an expiry, and compensating controls you actually enforce.

The shard is an unverified input to the model with no record of who produced it, and tampering breaks nothing: training succeeds and only the model's behaviour changes. Caching derived data moves integrity risk into data nobody reviews.

Attribution needs a per-job egress identity - a source address or proxy credential that puts the job id in every log line - intersected with retained per-step timestamps. Bytes sent versus received then separates exfiltration from a downloaded payload.

A double-quoted Groovy string is interpolated by the pipeline engine before the command text reaches the agent, so a branch name a contributor chose becomes part of the command. The fix: keep the value out of the program text.

Two declared sources mean the origin of a component is decided at build time by whichever index answers, not by your declaration. Hermeticity wants exactly one resolvable source, no fallback on a miss, and a build record naming the source and hash for each resolved component.

Rarely from the artifact alone. Detection comes from rebuilding on known-clean infrastructure and comparing, from build records kept off the host that say which host and toolchain produced each artifact, and from integrity monitoring of the tool-cache path.

A contract is not a technical control. Run partner merge requests like any untrusted fork: no credentials, disposable runners, no internal network position. If they genuinely need internal access, bring them inside the repository where it can be scoped and audited.

Draw it by reachable blast radius, not by org chart: identities that can reach production or another team's source get a real boundary. Start deny-by-default for new projects, then inventory and expire existing cross-project grants.

Require a stable, non-reusable identifier in the subject, a tenant-specific audience, one role per environment, and change control over the issuer itself - because whoever administers that CI server now effectively administers the cloud roles it can assume.

Make the hardened path the fastest route to production so complying costs less than not complying, absorb the migration work centrally, keep the off-road route available but expensive, and measure adoption by supported version rather than by mere presence.

Vendor when you need what a pin cannot give: the ability to modify the step, durability if upstream disappears, and one choke point to patch. Otherwise pin, because a stale fork nobody upgrades is worse.