Fix the vulnerability. Preserve what depends on it.
Built for the OpenAI Codex Community Hackathon in Bengaluru, CVE Twin connects incident investigation to a reviewable code change. The interface traces a vulnerability through packages, repositories, services, and customers. A local engine then uses Codex to repair a controlled target and returns the diff, tests, branch, and commit.
A patch can stop an exploit and still break the services that depend on the vulnerable component. The workflow needs evidence on both sides: demonstrate the vulnerability before editing, then verify security and compatibility after the change.
I developed the Codex remediation workflow and the comparison of competing patches against consumer contracts. My public commits document worktree isolation, attack replay, candidate scoring, and signed remediation records. The August build extends an earlier incident-investigation project with this local repair engine.
The engine first requires the security suite to fail on the vulnerable target. A suite that is already green—or produces no meaningful result—cannot establish a repair. This gives the final passing result a baseline instead of treating the agent’s explanation as proof.
Three isolated candidates attempt a minimal change, parser hardening, and a provider allow-list. Each faces the exploit, security tests, and contracts for three dependent services. Exploitable candidates are rejected; compatibility failures dominate the remaining risk score before change size is considered.
The result retains each candidate’s worktree and records the tests, attack replay, diff hash, and commits in an Ed25519-signed certificate. A separate verifier checks the record’s integrity and whether its evidence supports the verdict. A known signer still has to be trusted.
The hosted interface supports investigation, while remediation needs a local process capable of spawning the Codex CLI and Git worktrees. The server checks that capability before spending a credit. This prevents an impossible hosted run from being billed as if it could complete.
Start with the incident and follow its dependency paths to see the modeled exposure.
An illustrative view of the documented workflow. Positions and signals are conceptual.
Start with the incident and follow its dependency paths to see the modeled exposure.
Create an isolated worktree and run the exploit and tests against the vulnerable fixture.
Run the three repair strategies, then assess each against the same security and consumer-contract checks.
Inspect the selected diff, branch, commit, and evidence record before taking the patch further.
Inspect imagePassing tests after the recorded repair
Competing repair strategies
Dependent-service contract sets
In the documented local run, the security suite moved from 4 passing / 3 failing tests to 7 passing / 0 failing. The recorded comparison found all three candidates viable and selected the smallest change. These results concern the shipped demonstration target.
The repair target is a purpose-built fixture modeling the Log4Shell vulnerability class; arbitrary repository remediation is not implemented. The hosted site cannot execute the local engine, containment projections are modeled, and billing uses a single demo account. A self-signed certificate establishes integrity, not independent truth about its issuer. The development notes also record a Windows process-quoting failure that led to stricter baseline and empty-output checks.
