Tips & Tricks: CI/CD Hardening and the Security Operating Model

pull_request_target discipline

Audit every workflow in your repositories that uses pull_request_target. The Pwn Request pattern is two years old and still landing, most recently inside one of the most widely used JavaScript libraries on npm. The rule is simple: fork-supplied code should never be checked out into a context that holds your secrets.

Separate your read-only PR-check workflows from your publish-capable workflows. If a workflow needs to do both, split it. The same primitive was the proximate cause of the April 2025 Grafana Labs CI/CD incident; this is not a niche risk.

Cache scope and OIDC tokens

The GitHub Actions cache is not just data; it is a code path that the next workflow will load. Caches that cross the fork-to-base trust boundary are an injection vector. Scope cache keys so PR runs cannot poison base runs. Short OIDC token lifetimes are good hygiene but only matter if nothing inside the runner can read /proc/<pid>/mem. Treat the runner process itself as part of your threat model.

Build-environment runtime telemetry

A signed attestation only proves the build identity, not the build behaviour. Telemetry from inside the runner is now a security control: Runner.Worker process events, OIDC token redemption patterns, post-merge artefact diffs, unusual cache key reads. If your SRE team has been doing high-cardinality CI tracing for years, the security team needs a seat at that table this quarter.

Verify, then question

Verify SLSA attestations as you always have. Then ask the harder question: does this attestation describe a pipeline that did what it was supposed to do? Diff attestations across builds. Anomalies in dependency lists, new network IO, or new build steps are now security signals.

Behavioural baselines for publish events are a small engineering investment with a high return. If you can answer "what did our last hundred legitimate publishes look like, and how does this one compare," you can detect the May 11 attack class in the runner, not just clean up after it in the registry.

Audit your artefact economics

For each artefact your team produces or consumes (SBOMs, SOC 2 reports, attestations, PR reviews, audit binders), answer two questions: how cheap is it to produce now, and how long does it take to evaluate well? If production has scaled by an order of magnitude over the past five years and evaluation has not, you have a sizing problem, not a tooling problem. This is a budget conversation, not a vendor conversation.

Five role moves to plan

Evidence work as engineering work: rescope GRC analysis as controls engineering, with structured evidence emitted continuously from the platform.

Detection engineering against the artefacts themselves, grown out of SecOps rather than AppSec. SecOps already thinks in signals; this is signals-as-code on the same query infrastructure SRE has been running for a decade.

Pipeline-runtime telemetry as a named role, sitting between platform engineering and security. The job description looks more like SRE than AppSec, with security responsibilities layered on.

AppSec as agent-orchestrated review-at-scale: agents run the breadth pass on every change, humans enrich and judge. The asymmetry that breaks the rest of the model becomes AppSec's leverage point.

Vulnerability response as coordination, not throughput: the SCA-driven side dissolves into Detection Engineer and AppSec Engineer; the disclosure-coordination side becomes Vulnerability Response Lead, a role measured by state-machine integrity rather than tickets closed.

Name the work that does not transition

Some of the current security work transitions cleanly into the new operating model. Some of it does not. The leadership job is naming which is which, and being honest with the people doing the work that does not. This is the part of the conversation that does not fit on a slide, and it does not get easier by being postponed.

The 90-day plan

The vendor pitch deck on the table is not the right artefact to be reading. The right artefacts are three: the org chart, the hiring plan, and an honest list of work products that no longer earn their place when the cost of producing them drops by an order of magnitude.

Get these three on the table for the next quarterly review. Whatever tooling decision is being argued about will follow from them, not the other way around.