AI has moved quickly into engineering workflows, but most of it still stops at the same point: suggestion. It can flag an issue, recommend a fix, or generate a draft. Then the process stalls. Someone still has to validate the output, rewrite it for the environment, test it, and push it through production controls. That is where the real bottleneck lives. The gap is not awareness. The gap is execution.
Gomboc closed that gap for infrastructure by providing a deterministic remediation model in Infrastructure-as-Code (IaC). Instead of handing teams another alert, it translated policy into exact, reviewable code changes that could be merged safely. The result was predictable fixes, consistent outcomes, and a workflow that engineers could trust.
ORL (Open Remediation Language) builds on that foundation and expands it. The same deterministic model now applies beyond IaC to other parts of the stack where policy and security intent need to become real code changes. In other words, deterministic remediation is no longer limited to infrastructure. It can now be used anywhere teams need to turn rules into reliable, merge-ready fixes.
Use Case 1: Cloud Misconfiguration Remediation at Scale
The clearest place to see ORL’s value is where Gomboc started: cloud misconfiguration remediation at scale. This is a familiar pain point. Security tools detect issues, generate alerts, and create tickets. Then the work shifts to engineers, who must interpret, fix, and validate changes manually. Backlogs grow, and risk remains in production longer than it should.
Gomboc changed that model by turning policy into precise IaC fixes. Instead of alerts, teams receive merge-ready pull requests. The output is deterministic, consistent, and safe to review and deploy within existing workflows.
ORL extends that same approach. The model does not change. It remains policy-driven, deterministic, and reviewable. What changes is the scope. A capability that proved itself in IaC now applies more broadly across the stack. This is not a new direction. It is a proven model expanding outward.
Use Case 2: Dependency Remediation
The next test is whether this model holds up outside clean, structured IaC environments. Dependency remediation is where that question gets answered, and Log4Shell is the clearest example. When that vulnerability surfaced, fixing it required more than a single change. It required version upgrades, configuration adjustments, and support across multiple build systems. Each environment looked slightly different. Each fix required interpretation. In most organizations, that meant slow, inconsistent remediation under significant time pressure.
ORL approaches this differently. It takes CVEs, policies, and best practices and translates them directly into executable fixes. Those fixes apply across common ecosystems such as Maven, Gradle, and Kotlin-based Java environments, without requiring teams to manually map guidance to implementation. The result is not another advisory. It is a set of precise, reviewable changes that can be applied consistently across environments.
The Log4Shell response makes this concrete. More than 20 rules were applied in under 24 hours. Multiple dependency patterns were handled without custom effort. Both upgrade paths and mitigation strategies were supported, covering scenarios where immediate version changes were not possible. Changes were enforced at both the configuration and code levels, ensuring the issue was fully addressed, not just partially.
This is the difference that matters. The outcome is not detection or guidance. It is executable remediation, applied consistently at scale. This is where deterministic remediation proves it can handle real-world complexity, not just controlled IaC scenarios.
Use Case 3: Dockerfile & Build-Time Security Enforcement
The same pattern shows up in Dockerfiles, where small omissions can create outsized risk. Teams often inherit outdated base images, skip OS patching steps, or carry forward old build instructions that no longer match current security standards. Fixing those issues is rarely difficult in theory, but it is easy to delay in practice. Someone has to spot the problem, identify the correct remediation pattern, update the Dockerfile, rebuild the image, and verify that nothing breaks. That work usually gets pushed aside until a scan fails or a release is blocked.
ORL brings that work into the normal development flow. It scans Dockerfiles against policy, flags issues such as base image mismatches or missing OS updates, and then applies the fix directly in code. In the demo, ORL adds the required OS upgrade step to the Dockerfile so the image is patched during the build. The change is explicit, reviewable, and ready to merge.
What matters is where this happens. The fix is made at build time, inside the artifact developers already own. There is no triage ticket, no handoff to another team, and no separate translation step from policy to implementation. Security enforcement becomes part of the code itself, not an external process layered on afterward.
The Shift From Guidance to Execution
Taken together, these use cases show that deterministic remediation is not a future concept. It is already operating across multiple layers of the stack. What started in Infrastructure-as-Code now applies to dependencies and containers, and the pattern holds even as complexity increases.
At the center of that pattern is a simple abstraction. Policy, CVEs, and best practices serve as the input. The output is a precise code change. There is no intermediate step where guidance needs to be interpreted or rewritten. The system translates intent directly into implementation.
That consistency is what allows the model to scale. The same logic applies across environments and technologies without variation. There is no dependency on individual expertise to understand or apply fixes. The outcome is predictable because the process is repeatable.
It also aligns with how engineers already work. Fixes are delivered as pull requests. They can be reviewed, tested, and merged through existing workflows. Every change is visible and traceable. Nothing happens outside the system of record.
And this model does not stop at static code. It extends to live environments as well, where drift between deployed infrastructure and source code can be reconciled with version-controlled systems. The same principle applies. Detect the gap, generate the change, and bring systems back into alignment through code.
This is what turns remediation into a practical, production-ready capability rather than another layer of analysis.
A Proven Model, Applied Everywhere
ORL does not introduce a new model. It extends one that has already been proven in production. Gomboc demonstrated that deterministic remediation can work reliably for infrastructure by turning policy into safe, reviewable code changes. What these use cases show is that the same approach applies beyond IaC, across the broader software stack where complexity is higher and the margin for error is smaller.
That progression matters. It confirms that this is not a narrow solution tied to a specific domain. It is a consistent way to translate intent into execution, whether the problem sits in infrastructure, dependencies, containers, or live environments. Each example reinforces the same outcome. Policies become code. Fixes become repeatable. Workflows remain intact.
The question is no longer whether remediation can be automated. It is how far that model can extend.
