The Environment is the Policy: Real-Time Patching Across the Entire Stack

There is a comfortable version of supply chain security and a rigorous one. The comfortable version is a quarterly audit. You run a scanner, triage the findings, open some tickets, close some tickets, and write a report. It feels like security work. It is actually security theatre.

The rigorous version starts with a different question: what is the total attack surface of the system that produces and runs your software, and what is its current state at this exact moment? Not last quarter. Now.

That question exposes something most engineering organisations have not fully confronted. The attack surface is not just your application dependencies. It is the operating system your developers work on, the editor extensions they have installed, the GitHub Actions running your pipeline, the base images your containers are built from, and the runtime environment your application executes in. Every layer is a trust boundary. Every layer drifts.

Drift is the enemy. Not a specific vulnerability: drift. The slow, invisible accumulation of differences between what you believe is running and what is actually running. A developer whose local Node version differs from CI. A pipeline action pinned to a moving tag instead of a SHA. A Lambda runtime two minor versions behind. A transitive dependency that received a silent patch three weeks ago. None of these are individually catastrophic. Together, they are the condition under which supply chain attacks succeed.

DevSecOps is a Philosophy, Not a Role

Before the architecture, the philosophy, because the philosophy determines the architecture.

Most organisations hear DevSecOps and picture a person or a team. A security engineer embedded in the squad. A platform team that owns the hardening runbook. Someone whose job it is to care about this. That framing is well-intentioned and structurally broken.

If security is a role, it will always lose to velocity. The security person is the one saying no. The last review before the release. The bottleneck between the feature and the customer. This is not a people problem; it is a structural one. You cannot make security win consistently by making it someone’s responsibility, because it will always be in tension with other responsibilities that are easier to measure.

The philosophy version is different. Security is not someone’s job: it is a property of the system. The pipeline encodes the policy. The environment enforces the constraints. Nobody has to be the bad guy, because the gate is automated. The question is not “did security approve this?” but “did the pipeline pass?” If the pipeline is well-designed, those are the same question.

This reframing has a direct architectural consequence: the security posture of your system is only as good as the pipeline and environments you have built. You cannot bolt it on afterwards. It has to be in the substrate.

The Five Layers and Why Each One Drifts Differently

Every software system that goes from idea to production passes through five distinct environments. Each has a different attack surface. Each drifts in a different way. Each requires a different patching strategy.

The development environment. This is the laptop, the cloud IDE, the container the developer actually writes code inside. It is also, historically, the least controlled layer. Individual developer machines accumulate years of state: multiple Node versions, global packages from abandoned projects, VSCode extensions installed on a whim and never updated, dotfiles that override tool behaviour in subtle ways. A compromised VSCode extension is a real and documented initial access vector. A developer whose local environment differs significantly from CI is a bug factory. The development environment is not a sacred personal space: it is a trust boundary, and it should be treated as one.

The toolchain. Language runtimes, package managers, formatters, linters, test runners. These are the tools that transform source code into build artefacts. They are typically installed and forgotten. The Python version in the GitHub Actions runner is whatever the default was when someone set up the workflow. The version of Ruff or ESLint in the lockfile is whatever it was when someone last ran the initial setup. Toolchain drift is quiet and cumulative.

The pipeline. GitHub Actions, GitLab CI, whatever orchestrates your build, test, and deploy steps. The supply chain risk here is acute and underappreciated. An action pinned to uses: actions/checkout@v4 is not pinned: it is following a mutable tag that the author can move to any commit at any time. A compromised action maintainer can push malicious code that runs with your secrets in your pipeline. The pipeline is code, and it needs the same dependency hygiene as your application.

The application dependencies. npm, pip, cargo, go modules. This is where most supply chain security tooling focuses, and it is where the thinking is most mature: lockfiles, audit commands, Dependabot, Renovate. But maturity in tooling has not translated to maturity in practice. Most teams run npm audit in CI and ignore the output when it is too noisy. The signal is real; the process around it is not.

The runtime infrastructure. The AWS environment where the application runs. AMIs, Lambda runtimes, ECS base images, RDS engine versions. These are typically treated as set-and-forget: provisioned once by IaC, never touched unless something breaks. Immutable infrastructure helps, but only if you are regularly rebuilding from current base images. An infrastructure that was immutable when provisioned two years ago is just frozen drift.

The Containerised Development Environment as the Underrated Fix

Of the five layers, the development environment is the one where the gap between current practice and best practice is widest, and where the fix is most straightforward.

The fix is to stop treating the development environment as a machine and start treating it as a build artefact.

A development container defined in a devcontainer.json or Dockerfile is not a configuration: it is code. It lives in the repository. It is version-controlled. It is rebuilt from a base image every time you update it. It has the same dependency hygiene as anything else in the codebase. And critically: it is the same for every developer, every CI runner, and every agentic coding session. There is no “works on my machine.” There is one machine, defined in code, and everyone uses it.

This is where the Chromebook becomes interesting, not as a budget laptop but as an architectural statement. A Chromebook has no local state worth protecting. There is no accumulated environment to drift. The developer opens a browser, connects to a cloud-hosted container, and works inside it. The container is the environment. When you patch the container, you patch every developer’s environment simultaneously, without asking anyone to run an update script or restart anything. The patch is a new image. The developer gets it the next time they open their workspace.

This is what “the environment is the policy” means in practice. You do not need developers to follow a hardening checklist. You ship them a hardened environment and they work inside it.

Real-Time Patching Means Automated, Not Instantaneous

A word on “real-time,” because it is easy to misread as “automatically apply every patch the moment it is available,” which is a different thing and not what you want.

Real-time patching means the patching process is continuous rather than periodic. It means a new CVE that drops tonight triggers an automated PR by morning, not an agenda item for next quarter’s security review. It means the gap between “vulnerability exists” and “we know about it and have a path to fixing it” is measured in hours, not weeks.

What it does not mean is auto-merging every dependency update without review. That path leads to a 3am broken build from a major version bump that introduced a breaking API change. The resolution is a separation of concerns: automated detection and PR creation, deliberate merge decisions. The automation surfaces the work. The human approves it. Tests and severity ratings determine urgency.

The practical cadence: critical CVEs get an expedited PR that blocks deployment until resolved. High severity get a 48-hour SLA. Medium and low batch into a weekly update PR. Toolchain and base image updates follow the same pattern, triggered by upstream releases rather than CVE databases.

The Pipeline as a Trust Boundary

SHA-pinning GitHub Actions is table stakes and most teams are not doing it.

uses: actions/checkout@v4 means “run whatever code the actions/checkout maintainers decide to put at the v4 tag.” If that maintainer’s account is compromised (and account compromises of popular action maintainers have happened), your pipeline runs attacker-controlled code with access to your repository secrets, your signing keys, your deployment credentials.

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 means “run this exact commit.” It cannot be silently changed. It is auditable. It is what SHA-pinning means.

Pinning creates a maintenance burden: you have to update the SHA when you want a new version. This is solved by Dependabot or Renovate configured to watch GitHub Actions dependencies. The tool opens a PR when a new version is available. You review and merge. The burden is a PR review, not a manual SHA hunt.

Beyond pinning, the pipeline itself should generate provenance: a signed attestation of what inputs produced what outputs, following the SLSA framework. This is the difference between “we think this is what built this artefact” and “we can prove it.” AWS and GitHub both have native support for this now. It is not a research project.

What the Locked-Down Workflow Actually Looks Like

End to end, a team operating this philosophy looks like this:

Developers work inside a container defined in the repository. The container image is rebuilt on a schedule: nightly, or triggered by upstream base image updates. When the image rebuilds, it pulls the current versions of pinned tools, runs a security scan on the image itself, and pushes to a private registry. Developers get the updated image the next time they rebuild their dev container (VSCode will prompt); for EC2 deployments, the running instance must be replaced to pick up the new image, and the workspace EBS volume reattaches, so no data is lost.

The pipeline is fully SHA-pinned. Renovate runs on a schedule (installed as a GitHub App rather than a workflow you maintain) and opens PRs for action version bumps. Dependency updates across all package managers are managed by the same Renovate configuration: a single renovate.json that knows about npm, pip, cargo, Docker, and GitHub Actions. Everything flows through PRs, and every PR waits for a human. Nothing updates silently.

Every build generates an SBOM (a software bill of materials) as a signed artefact. The SBOM is scanned on every build. Critical findings block the deploy. Everything else creates a ticket.

Infrastructure is defined in Terraform or CloudFormation. AMIs are refreshed on instance replacement (immutable pattern). A single drift report (scripts/audit.sh) walks all five layers in one pass: dev container image age and CVEs, unpinned Actions, application lockfiles and outstanding security PRs, SBOM scan results, and Lambda runtime age (via infra/lambda-runtime-check.sh). Run it as part of your review process to catch drift in any layer before it reaches production.

The result is a system that patches itself, continuously, with humans in the loop for merge decisions and exception handling. Nothing drifts silently. Every change is a PR. Every PR is auditable.

Where to Start

The concepts here are not new. The gap is that they are rarely assembled into a single, opinionated, end-to-end workflow that a team can actually adopt.

The immutable-dev-env repository is an attempt to close that gap. It is a reference implementation of everything described here. The Chromebook model is concrete: a browser-first cloud workstation: code-server (VS Code in the browser) on EC2, reachable by browser, SSH, or Mosh, all sharing one filesystem and one tmux session, on an instance whose workspace volume survives replacement. For teams who would rather branch across repos on their own machine, there is a local devcontainer configuration with the same immutable pattern. Around both: a Renovate setup that covers all dependency types, a GitHub Actions pipeline that is fully SHA-pinned with automated update PRs, an SBOM generation and signing step, and a scripts/audit.sh that reports drift across all five layers in a single pass.

Clone the repo for reference, then run scripts/install.sh from inside your own project to scaffold in the devcontainer, pipeline, Renovate, and audit files. The CUSTOMIZE: markers tell you what to change for your stack. There is no application code in this repo: it is a template, not a monolith. You bring your own language, framework, and tests; the repo provides the security substrate around them.

This is not a product. It is a starting point: the same architectural decisions, encoded in a form you can audit, extend, and make your own.

→ github.com/0x1337c0d3/immutable-dev-env

The agent doesn’t change what a secure environment is. It just makes the cost of not having one visible immediately.