Remediation as Code: Treating Fixes Like Software

Remediation as code is not a folder of shell scripts. It is the decision to make every repeatable security fix versioned, reviewable, testable, limited, and provable before it touches production.

The problem is not that engineers cannot write fixes. The problem is that the reasoning around those fixes disappears into ticket comments, chat messages, and terminal history. Six months later, nobody can explain which evidence justified the change, which version ran, what targets received it, or whether the finding stayed closed.

Code gives a repair the same discipline as software. A diff shows what changed. Review creates accountability. Tests expose broken assumptions. A release identifies the approved artifact. Deployment limits contain failure. Verification shows whether the unsafe state is gone.

What is remediation as code?

Remediation as code is the practice of expressing a security repair and its operating controls as a versioned artifact. The code may be an Ansible role, a PowerShell script, a cloud policy change, a Terraform update, a package rule, or an orchestration workflow. The artifact also carries the conditions for use, approval boundary, target limit, recovery step, and verification test.

The phrase matters because a command is not enough. systemctl disable telnet.socket may be correct on one Linux host and wrong on a legacy gateway whose business owner still depends on it. The code must say where it applies and what should happen when a prerequisite is false.

Infrastructure as code declares the intended environment. Policy as code evaluates whether that intent is allowed. Remediation as code moves an observed unsafe state toward the approved state and proves the result. Sometimes the durable fix belongs in the infrastructure source. Sometimes it belongs in a package or endpoint control. The correct authority is part of the repair.

Why do fixes managed through tickets fail?

Tickets are good at ownership and status. They are poor execution artifacts. A sentence such as “upgrade OpenSSL” leaves out the affected package source, fixed build, service dependency, restart decision, target filter, maintenance limit, health check, recovery path, and final version query. An operator has to reconstruct the missing contract on every asset.

The cost shows up in breach data. Verizon published the 2026 Data Breach Investigations Report on May 19, 2026. Vulnerability exploitation caused 31 percent of initial access, while the median time to full resolution for a critical vulnerability reached 43 days. A queue can be perfectly documented and still leave exploitable state open for six weeks.

Simple math makes the reuse case. If a team performs 300 similar fixes each quarter and spends 18 minutes rebuilding context, commands, and closure evidence for each one, that is 90 hours. A reviewed contract that removes 12 of those minutes recovers 60 hours every quarter. The larger win is consistency. The 300th target receives the same safety conditions as the first.

What belongs in a remediation as code contract?

Keep the contract small enough to review and complete enough to operate. It should name the security condition, supported platforms, required observations, exact state change, owner, approval rule, target ceiling, health test, rollback action, final verification, evidence destination, and expiry or replacement rule.

This is an internal contract example, not a public standard. The exact schema can change. The operating questions should not. A reviewer must be able to tell which state permits execution, which artifact will run, how far it can spread, and what proof ends the work.

How should the remediation repository be structured?

Separate contracts, implementation, tests, and evidence templates. Put each repair family behind one stable identifier. Keep platform differences inside roles or modules rather than copying the full workflow. Store example inputs that contain no secrets. Version the inventory query or target selector beside the action so scope changes receive review.

Keep generated evidence out of the source repository when it contains host names, vulnerability details, logs, or customer data. The repository holds the approved logic and evidence schema. The execution system holds scoped run records with access controls and retention.

Which review gates matter?

Require technical ownership and security ownership for new repair families. Technical owners judge service behavior and recovery. Security owners judge whether the precondition and verification actually address the finding. Routine version changes can use a narrower review path after the contract has production history.

The pull request should show the unsafe state, proposed state, affected platforms, changed authority, target ceiling, test results, expected interruption, and rollback evidence. Reviewers should reject broad selectors, hidden network calls, unpinned dependencies, plaintext secrets, commands that always report success, and verification that merely repeats the deployment status.

GitHub's secure use reference for Actions says pinning an action to a full commit SHA is the only way to use an action as an immutable release. It also recommends minimal token permissions and review before a job receives protected environment secrets. A remediation pipeline has production authority, so its own dependencies deserve the same scrutiny as the fix.

What tests should run before release?

Test syntax, idempotence, unsupported inputs, false preconditions, successful change, service health, final security state, and recovery. Run the action twice in a disposable environment. The second run should make no change. If it restarts services or rewrites files every time, the artifact is not stable enough for broad use.

Negative tests matter more than demos of the expected path. Remove a required variable. Present an unexpected package manager. Make the health endpoint fail. Deny privilege. Corrupt the backup. Confirm the workflow stops and produces a useful record. Production will eventually supply every condition the test suite ignores.

How do releases protect the fix pipeline?

Merge is not approval to execute forever. Create a named release, record its digest, restrict who can publish it, and keep execution tied to the approved version. A mutable branch can change between approval and deployment. That breaks the evidence chain even when the new code is harmless.

GitHub announced immutable releases in public preview on August 26, 2025. The feature protects release assets and tags from later changes and adds signed attestations. GitHub documentsgh release verify <tag> and gh release verify-asset <tag> <asset> for validation. That development gives remediation teams a practical way to prove the deployed artifact matches the reviewed release.

How should code move into production?

Promotion should be explicit: lab, representative canary, limited production group, then approved population. Each step uses the same artifact and different scope. Do not rebuild between stages. Rebuilding produces a different object and weakens the evidence gathered in the prior environment.

Set a maximum target count and a failure limit in the contract. Stop on business health failure even if the security change succeeded. A patch can remove a CVE and still break authentication. Security proof and service proof are separate conditions, and both must pass.

Rollback should be code, versioned with the forward action, but it is not always reversal. Restoring a vulnerable package may be unacceptable after active exploitation. A safer recovery may isolate the host, remove it from service, or restore configuration while keeping exposure blocked. Name that decision before release.

What proves remediation as code worked?

The action output proves only that the tool ran. Verification must observe the security condition again. Query the installed version, effective configuration, listening path, account state, or cloud policy through an independent read. Then test the business behavior that the change could affect.

Store the finding identifier, evidence before change, commit, review, release digest, target set, execution identity, output, failures, recovery events, evidence after change, and final decision. That record supports operations, audit, and later improvement. It also reveals contracts that close briefly and recur.

Who should own remediation as code?

Security should own the risk condition and closure test. Platform or application teams should own the change behavior and service health. A shared automation team can own the framework, release process, credentials, and execution service. Nobody should own the entire decision alone.

Treat emergency changes as releases too. Shorten the approval path, narrow the initial target, and increase observation. Do not abandon versioning or evidence because the deadline is short. Incidents are when provenance matters most.

Every contract also needs a retirement path. A repair can become unsafe when a package name changes, an operating system leaves support, a new policy source takes authority, or the verification test stops observing the real condition. Mark supported versions, last review, owner, replacement, and expiry in the contract. Block new runs after expiry while preserving old releases for audit.

Review usage every quarter. A contract invoked 500 times with no changes may have become part of the desired baseline and should move into image or configuration policy. A contract that fails on 20 percent of eligible targets has a bad assumption, not an exception problem. Repair the shared logic before asking operators to work the failures one at a time.

How should a team start remediation as code?

Choose a repair that has occurred at least five times and has an agreed manual procedure. Write the contract from the procedure. Put the current commands behind tests. Run it in recommendation mode and compare its plan with operator decisions. Fix the contract until the differences are understood.

The automated remediation pillar provides the full control model. The automated remediation definition and eligibility guide helps decide which fixes deserve code. For endpoint execution, use the Ansible security remediation playbook patterns. If AI drafts an action, apply the review boundary in our AI generated remediation script guide before it enters the repository.

Frequently asked questions

Is remediation as code the same as infrastructure as code?

No. Infrastructure as code declares and creates infrastructure. Remediation as code corrects observed unsafe state. The durable repair may update infrastructure code, but endpoint, identity, package, and incident actions can use other authorities.

Does every remediation need a pull request?

Every reusable action needs controlled review and versioning. A pull request is a practical mechanism, not the only one. Emergency execution can use a shorter approved path if the artifact, reviewers, target, and evidence remain recorded.

Can AI write remediation as code?

It can draft a contract, implementation, tests, and rollback. Artemes uses deep endpoint context with AI driven analysis to produce reviewable remediation guidance. Generated output still needs deterministic tests, scoped authority, and practitioner approval before production execution.

What is the first metric to track?

Track time from confirmed finding to fresh closure evidence for one repair family. Pair it with failed change and rollback rates. A faster pipeline that produces uncertain state is not an improvement.

Executive takeaway

Take one repair your team repeated last month. Put its preconditions, exact action, target ceiling, health test, recovery, and final proof in a repository. Require a diff and named review. Release one immutable version. Run it on a canary and retain the record. If the same finding returns, improve the artifact instead of writing another ticket.