The phrase "shift-left" was useful when most security checks happened in production, after deploy, when the cost of a finding was already locked in. It made sense to push checks earlier, closer to the source, where remediation was cheap. But after a decade of shift-left rhetoric, many programs have over-rotated. They have moved everything to the developer's machine and assumed the rest of the pipeline is no longer interesting.
That assumption is wrong. Supply chain risk does not stop manifesting once the code leaves the IDE. New advisories are published daily. Maintainer accounts are compromised after merge. Transitive dependencies update silently. A program that fires only at the developer's keyboard misses everything that happens between commit and runtime.
The mature framing for 2026 is shift-everywhere. Catch risk at every stage where catching it adds value, and design the stages so they complement rather than duplicate each other. This post is a program-level look at how to structure a shift-everywhere model with Safeguard as the connective tissue.
Five stages, five jobs
A shift-everywhere program treats five stages as distinct, each with its own job.
Stage one: IDE-time. The developer is composing the change. The job is to surface the most decision-relevant context at the moment of lowest reversal cost. This is where you tell the developer "this package looks risky" before they hit save. Tooling: editor plugins, linters, completion hints.
Stage two: CLI-time. The developer is verifying the change locally. The job is to give them a quick, authoritative second opinion before they push. This is where you let the developer answer "is this safe?" without leaving the terminal. Tooling: standalone CLI, pre-commit hooks, local pre-push checks.
Stage three: PR-time. The change is under review. The job is to gate on a small, clear set of high-confidence risks and provide reviewers with the context to approve safely. This is where you stop the merge if the change introduces critical risk. Tooling: PR bots, status checks, review automation.
Stage four: Build-time. The artifact is being assembled. The job is to verify provenance, generate the SBOM, and re-check the dependency graph against the latest advisories — which may have changed since the PR was merged. Tooling: CI pipelines, SBOM generators, signing.
Stage five: Runtime. The artifact is deployed. The job is to monitor for new advisories that affect already-deployed code, and to flag deployed dependencies that have since been compromised. Tooling: continuous SBOM monitoring, runtime telemetry, advisory feeds.
Each stage has a different latency budget, a different audience, and a different cost-of-failure. A program that respects those differences allocates effort and tooling appropriately.
The hand-off problem
The hardest part of shift-everywhere is the hand-off between stages. Without coordination, each stage runs the same checks and developers see the same finding five times. Without coordination, each stage makes a slightly different decision and developers see contradictory verdicts. Without coordination, the security team has five different dashboards and no unified view of supply chain posture.
The coordination mechanism is shared policy and shared state. All five stages should evaluate the same policy, against the same dependency graph, with the same package metadata. A finding that fires at IDE-time should be the same finding that would fire at PR-time, with the same severity and the same suggested fix. A waiver granted at PR-time should suppress the same finding at runtime monitoring.
Safeguard implements this coordination through a single policy engine and a single findings store. The IDE plugin, the CLI, the PR bot, the build integration, and the runtime monitor all evaluate against the same policy bundle. When the policy changes, all five stages see the change in the same release window. When a finding is waived, the waiver propagates to every stage that would otherwise fire on it.
The consistency is not just an aesthetic preference. It is the property that makes the program scale. Without it, developers learn that the checks are flaky and start ignoring them.
Where to invest first
A common question from teams starting a shift-everywhere program is which stage to invest in first. The answer depends on the team's current state, but a useful heuristic is: invest where the marginal cost of a finding is highest.
If your team's biggest pain is production incidents traceable to known-bad dependencies, invest in runtime monitoring first. The IDE will not help if the bad dependency is already deployed.
If your team's biggest pain is failed audits because SBOMs are inconsistent across releases, invest in build-time first. The PR gate will not help if the artifact's SBOM does not match what was reviewed.
If your team's biggest pain is developers introducing risky dependencies that slip past code review, invest in IDE-time and PR-time together. The build will not help if the risk was approved by accident at review.
Most teams are somewhere in the middle, with pain at multiple stages. In those cases, we recommend starting with the stage that has the worst current developer experience. A noisy, slow PR gate is doing more harm than no PR gate. Fix that first, then expand outward.
The redundancy you do want
Not all redundancy is bad. Some checks should fire at multiple stages because the cost of missing them is high enough to justify the cost of running them twice.
License compliance is a good example. License risk should be flagged at IDE-time so developers can choose alternatives. It should be re-checked at PR-time because transitive licenses can change between IDE and merge. It should be re-checked at build-time because the lockfile that produces the artifact is the source of truth. And it should be monitored at runtime because some licensing changes — like a relicense of an upstream project — can happen long after deploy.
The discipline is to be deliberate about which checks deserve this multi-stage treatment. Critical-severity vulnerability scanning, license compliance, and supply chain incident detection are the three classes that we typically recommend running at every stage. Everything else should run at one stage and flow forward via the shared findings store.
Safeguard's default configuration ships with this triple-redundancy pattern preconfigured for the high-stakes classes, and single-stage evaluation for the rest. Teams customize from there, but the default is a reasonable starting point.
The org chart problem
A shift-everywhere program touches every part of the engineering organization. The IDE plugin is the developer tools team's territory. The PR bot is the platform team's. The build integration is the release engineering team's. The runtime monitor is the security operations team's. Coordinating across all of these is a program management challenge as much as a technical one.
The pattern that works is to designate a single owner for the supply chain program — usually a security engineer with a strong product sense — and to embed liaisons in each of the affected teams. The owner sets the policy, the standards, and the roadmap. The liaisons are responsible for the local implementation and for surfacing friction back to the owner.
The liaison model scales because it lets each team move at its own pace within a shared framework. The platform team might roll out the PR bot in a quarter; the runtime monitor team might take a year. Both are progress, and both are tracked against the same overall program plan.
Maturity milestones
A useful way to track program progress is a four-stage maturity model.
Stage zero: ad hoc. Some teams use SCA, some don't. Findings are inconsistent. No shared policy.
Stage one: shifted-left. IDE and CLI checks are widely adopted. Developers are catching issues early, but the rest of the pipeline is uncoordinated.
Stage two: shifted-and-gated. PR-time gates are in place with clear blocking rules and a fast override path. Build-time SBOM generation is automated.
Stage three: shifted-everywhere. All five stages are coordinated through shared policy and shared state. Runtime monitoring is connected to the same findings store. Developers see consistent verdicts at every stage.
Stage four: continuously improving. The program runs a regular review cycle on policy effectiveness, friction budget, and developer sentiment. The supply chain program is treated as a product, with a roadmap and a release cadence.
Most organizations sit at stage one or two in 2026. The path to stage three is mostly about coordination and tooling. The path to stage four is about culture and discipline. Both are achievable, and both are how supply chain programs survive contact with a real engineering organization.