From Competition Artifact to Shared Infrastructure
The post-competition story of AIxCC turns on a practical question: what does it take to make a cyber reasoning system usable after the contest’s cloud, APIs, and operating assumptions are gone? The OSS-CRS project addresses that question by separating the finalist systems’ analysis logic from the platform services around it. That separation makes the difference between source code that can be inspected and a CRS that can actually be run, compared, and composed against a new open-source target.
This distinction matters because AIxCC’s results exposed exactly the kinds of boundaries that infrastructure controls. A fuzzer needs a reproducible build and instrumented target. A patcher needs the right source, crash evidence, and a way to rebuild and test an edit. Multiple systems need isolated resources, a common way to exchange artifacts, and a limit on language-model spending. If every team implements those services again inside a monolith, the research remains tied to the environment that first made it work.
Why open source was not enough
After the final competition, all seven finalist systems were open-sourced in principle. Yet the OSS-CRS study found that the releases were largely difficult to use outside their original teams. This was not primarily because the algorithms disappeared. It was because the algorithms were attached to a collection of deployment assumptions that a new operator would have to reconstruct.
The first barrier was infrastructure duplication. Each team independently built overlapping platform roles: container orchestration, middleware for coordination and persistence, language-model routing, budget tracking, cost enforcement, target-build environments, and patch-validation machinery. The exact tools differed—teams used combinations of Kubernetes or Helm, message queues or databases, and different proxy arrangements—but the underlying responsibilities converged. Every team needed to launch workers, move artifacts, meter expensive calls, compile targets, and check proposed repairs.
That duplication has a long tail. A team that embeds its own model proxy must adapt when providers change APIs or model names. A team that writes its own cost tracker must preserve accounting across retries and parallel workers. A team that builds its own patch environment must handle the target project’s build system and instrumentation. Repeating these tasks seven times consumes engineering effort that could otherwise improve vulnerability analysis, and it creates seven subtly different execution contracts. Results then become difficult to compare because a difference in output may reflect a platform assumption rather than an analysis technique.
The second barrier was cloud lock-in. The competition gave finalist teams dedicated Azure virtual machines and Kubernetes-based orchestration. That environment supplied compute allocation, storage, network separation, service discovery, and scaling behavior. After the finals, the environment was decommissioned, but released code still expected it to exist. The OSS-CRS paper gives ATLANTIS as a concrete example: the first-place system required more than 20 Azure virtual machines, 42 TiB of cloud storage, and runtime Azure SDK calls to scale Kubernetes node pools.
Cloud dependence is more than a deployment bill. It also hides resource ownership. In a managed competition cluster, a team can assume that a node pool will be created, that a proxy endpoint will be available, and that containers will receive a known amount of space. A local operator must decide who owns CPU cores, memory, disk, network access, credentials, and model costs. If those decisions are absent from the interface, “run locally” can mean little more than “start debugging the missing cluster.”
The third barrier was monolithic design. The finalists developed distinctive and often complementary techniques, but none exposed a component-level interface through which a researcher could extract one fuzzer, patcher, or analyzer and combine it with another team’s work. A researcher could read that ATLANTIS had a strong fuzzer and BUTTERCUP had a different patching approach, yet could not test the combination without reimplementing one inside the other.