Fixing a misconfiguration in production addresses the immediate instance, but it does not remove the flawed template that can recreate the problem. Fixing it in code corrects the source of the issue and helps prevent the same misconfiguration from spreading again. Mature teams usually do both, because runtime remediation alone leaves the underlying control gap intact.
Why the Difference Matters: Runtime Fix vs Source Fix
In infrastructure as code, the gap is not just where you apply the change, but what part of the system you actually repaired. A production-only fix changes the deployed state, while a code fix changes the template, module, or policy that will be used again. That distinction matters because infrastructure state is repeatable, so a bad definition can recreate the same exposure after the next deploy.
A production fix is therefore a containment action. It is useful when you need to stop exposure quickly, but it is not the same as eliminating the cause. A code fix is a source-of-truth correction, which is why it is the more durable control. CI/CD pipeline exploitation case study illustrates how configuration problems can be reinforced by the delivery path itself, not just by one bad runtime instance.
Practitioners should treat the two as different layers of control. Runtime remediation reduces immediate blast radius, but code remediation reduces recurrence risk across every environment that consumes the same module or template.
How Drift and Regeneration Create Repeat Exposure
Production-only fixes often introduce drift between the running system and the declared configuration. That drift can be intentional for emergency response, but it creates a hidden dependency on manual follow-up. If the underlying code is not updated, the next redeploy, autoscaling event, environment rebuild, or policy refresh can restore the original misconfiguration.
In practice, the most common failure mode is believing the incident is closed when only the symptom is removed. The code still contains the mistake, so the organisation is one pipeline run away from the same exposure. Millions of Misconfigured Git Servers Leaking Secrets is a good reminder that templated mistakes scale fast when the bad pattern sits in shared source.
Code fixes also support peer review, testing, and validation before deployment. Those controls are harder to apply to a one-off emergency change in production, especially when teams rely on manual console edits or ad hoc access during an incident.
What Mature Teams Change, and What They Verify
Mature teams usually correct the live issue and then update the codebase, so the production state and the declared state converge again. The code change should be treated as the durable repair, and the runtime change should be tracked as an exception that needs closure. CI/CD pipeline exploitation case study and Firebase misconfiguration exposure 2024 both show why the configuration source and deployment path need to be aligned, not just the live instance.
What matters operationally is evidence of convergence: the template, the deployed environment, and the pipeline checks should all reflect the same safe configuration. If the fix lives only in production, the team still has technical debt in the form of a recreated failure path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | IaC code is software that must be secured before deployment. |
| Recommendation — Review infrastructure code changes before promotion and block unsafe configuration patterns. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | The question is about changing a deployed configuration versus correcting the source configuration. |
| CM-6 — Configuration Settings | IaC misconfiguration is a configuration-state problem that must be fixed at the declared setting level. | |
| Recommendation — Require controlled review and approval for both live remediation and source changes. Standardise approved configuration settings in code and verify deployed settings match them. | ||
| NIST CSF 2.0 | PR.IP-1 — Configuration Baseline | The answer hinges on the difference between a one-off runtime fix and restoring a secure baseline. |
| Recommendation — Maintain a secure baseline in code and reconcile drift after emergency production fixes. | ||
| OWASP SAMM | STR — Strategy | This is a SDLC governance question about keeping security fixes in the source of truth. |
| Recommendation — Embed infrastructure configuration review into the delivery strategy and release gates. | ||
Practitioner Guidance
What to prioritise: Treat the production change as containment and the code change as the actual remediation. If the issue can be redeployed from code, the source update should be scheduled immediately, not deferred to a later cleanup ticket.
What to verify: Confirm that the corrected template, module, or policy now passes the same review and validation gates that would have caught the issue originally. Also verify that no environment-specific override is still reintroducing the defect.
Common mistake: Teams often close the incident after the live system looks healthy, even though the flawed definition still exists in version control or a shared module. That creates a recurrence risk the next time infrastructure is rebuilt.
Practitioner takeaway: The safest pattern is to repair the live exposure fast, then remove the defect from code so the fix survives the next deployment, rebuild, or scale event.
Related resources from NHI Mgmt Group
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between rotating a secret and revoking access?
- What is the difference between rotation and deprovisioning for NHIs?
- What is the difference between visual similarity and production-ready code quality?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
