Kodus Caught Security-Relevant Differences in a FireHOL Migration

I have been getting better code reviews out of Kodus with Astra and Opus 5.5. A recent firewall migration gave me a useful example: it identified small differences in syntax and rules that would have changed security behavior.

The migration was away from FireHOL, into a custom firewall solution already used at work for years. That solution now supports FireHOL ipsets, leaves Docker’s rules alone, and uses a calculated hash to make changes to the rules evident.

There is plenty to get wrong in that combination. A conversion can look reasonable in a diff while changing what traffic gets through. Those are the findings I want a reviewer to spend its time on.

The rules have to mean the same thing

Moving between firewall systems requires more than translating their configuration syntax. The existing rules express decisions about which systems can talk to each other. Unless the migration deliberately changes those decisions, the replacement needs to preserve them.

Kodus was able to identify subtle differences in the conversion and flag their security implications. I am not publishing the internal rules or claiming a measured detection rate. What made the reviews useful was that the comments concerned behavior I needed to examine.

For someone planning a similar move, I would make the intended behavior explicit before asking an agent to convert anything. Which sources should reach each service? Which should remain blocked? What does each address set represent? Which rules belong to another service?

That last question matters here because Docker manages rules too. Leaving them alone is a requirement of this replacement. A firewall implementation that produces its own intended rules but interferes with a neighboring system still has a problem.

These requirements also give a reviewer something concrete to work against. “Review this firewall migration” is a much weaker instruction than providing the expected traffic policy and identifying the parts the migration must not touch.

A hash makes changes visible

The custom solution also uses a calculated hash to detect rules being changed, deleted, or added. That provides evidence that the rules differ from the expected state.

There are separate questions worth asking about any implementation of that idea: what is included in the hash, where the expected value is kept, and how legitimate changes are handled. A hash does not establish that the original policy was correct. Nor does detecting a change prevent it.

I would review those properties separately from the migration itself. Preserving the old policy and recognizing later changes are different jobs, even when the same tooling handles both.

The cost is becoming reasonable

Better findings are one part of why I am taking these reviews more seriously. The economics have improved too, particularly when repeated context can be served from a prompt cache.

As of October 3, 2026, Anthropic lists Opus 5.5 at $4 per million input tokens and $20 per million output tokens, 20% below Opus 5. Cache reads cost $0.20 per million tokens, down 60% from Opus 5.

OpenAI lists Astra’s standard rates at $10 per million input tokens, $1 for cached input, and $50 for output. Cache writes cost $12.50 per million tokens. Those are current rates, not evidence of a recent reduction in Astra’s base price.

The cache discount applies to eligible reused input, not the entire review. New content, cache writes, and generated output still contribute to the bill. Repository instructions and other stable context are useful candidates for reuse; whether that happens depends on how the requests are assembled and whether the cache is available.

That makes actual usage more useful than a headline discount. Kodus documents per-review token costs for its bring-your-own-key setup. I would compare those costs with the findings worth acting on before expanding coverage across hundreds of repositories.

What I would check before a firewall switchover

An AI review gives me another set of findings to investigate. I still want tests that exercise the intended policy: traffic that should pass, traffic that should fail, address-set membership, and services whose rules the new system must preserve.

For this migration, the encouraging part was seeing Kodus pick up on small differences with security consequences. That is a useful role for a code reviewer. Before switching a firewall over, I want those differences identified and resolved, however reasonable the translated configuration looks.