At DEF CON 34, the badge was more than something attendees wore around the conference. Around 27,000 people received the same piece of hardware built around the Baochip-1x, an open-source security chip designed by Andrew “bunnie” Huang. The conference moved from its opening directly into Bunnie’s presentation on the Baochip-1x, putting the chip in front of thousands of security researchers and hardware enthusiasts. The badge also had a life beyond DEF CON: its core module could be removed and converted into a standalone hardware security token.
As a collaborator in the design and tapeout of the chip, CrossBar was proud to contribute to the project and to see the Baochip-1x placed in the hands of such a large and technically capable community. The source code and hardware design were made available for examination, creating an opportunity for researchers to investigate not only how the system was designed, but also how the resulting silicon could be understood and tested. Once the Baochip-1x was placed in the hands of the DEF CON community, the question became what people would find when they started looking closely.
1. Inspectable: Open Source Starts With the Ability to Look
The Baochip-1x project makes its hardware and software resources available for examination, including the source code, core-module hardware design, and development materials. Researchers can therefore inspect the design itself rather than relying only on the finished device.
For silicon, inspection can go further through Infra-Red, in situ inspection (IRIS). The technique uses near-infrared light to image the chip through its backside without removing it from the circuit board, providing a non-destructive view of the physical implementation. At the block level, IRIS can help verify features such as RAM, CPU cores, peripherals, and bond pads. This creates another way to compare the published design with the physical silicon.
2. Attackable: DEF CON Turned Transparency Into Adversarial Testing
Once thousands of people had the same hardware, inspectability quickly became adversarial testing. DEF CON is an unusually appropriate environment for this because attendees bring a culture of experimentation and reverse engineering. The badge gave researchers a physical system to work with, while the published source gave them additional material to investigate.
AI-assisted analysis gave researchers another way to work through the published design alongside physical testing. LLMs can examine large amounts of code and technical material, flag potential issues, and help researchers explore areas that might otherwise receive limited attention.
Making source code public does not guarantee that someone will examine it. Researchers still have limited time and attention. AI lowers that barrier by making large amounts of technical material faster and cheaper to analyze. Issues that might once have remained unnoticed can now be surfaced much more quickly for human investigation.
3. Verifiable: Open Source Has to Withstand Scrutiny
More examination can also produce more potential findings, but more findings do not automatically mean more vulnerabilities. Automated analysis can produce false positives, incomplete reasoning, or issues whose practical impact is very different from their initial description. As AI becomes more involved in security research, verification becomes just as important as discovery.
A potential finding needs to be examined in context. Researchers can reproduce the behavior, identify the conditions under which it occurs, compare it against the architecture, and determine whether other security mechanisms limit its impact. This is particularly important for hardware, where the practical significance of a reported behavior can depend heavily on how the chip and the surrounding system are configured.
The lower cost of finding potential vulnerabilities also puts pressure on established disclosure practices. Traditional responsible disclosure generally assumes that a researcher identifies a potential issue, investigates it, and gives the affected party an opportunity to respond before the finding becomes public. AI-assisted analysis can compress that process dramatically. When potential vulnerabilities can be surfaced from public code at lower cost, the boundary between discovery, verification, and publication becomes less clear.
Whatever the disclosure model, a potential finding still needs to be evaluated based on whether it can be reproduced, what conditions are required, and what its actual impact is.
4. Improvable: Turning Testing Into Better Defenses
Security engineering also has to account for what happens when testing reveals a potential weakness. Hardware and software have different development cycles, and changes to manufactured silicon may require a future fabrication step. Architectural and software-level mitigations can provide ways to respond when changing the underlying hardware requires a longer development cycle.
Security should not depend on a single protection mechanism. Memory isolation, software controls, key-management strategies, and other architectural safeguards can provide additional boundaries when one layer is challenged. A Memory Management Unit (MMU), for example, allows system software to isolate and manage memory spaces dynamically, providing an additional architectural boundary alongside lower-level access controls.
Different security risks can be addressed through software, system architecture, or, when necessary, future hardware revisions. Improvement does not always mean starting over. It can mean strengthening one layer, adding another safeguard, or incorporating what was learned into the next revision.
5. Beyond “Secure”: A Better Way to Think About Security
The DEF CON experience also shows why security is not a binary state. A more useful question is whether a system's design, assumptions, and limitations are visible enough to be examined and challenged.
Open source makes that level of visibility possible. Researchers and users can understand how the system works, where its boundaries lie, and how its defensive layers respond when challenged. The goal is not to claim that a system is “impossible to break,” but to make its characteristics and limitations clear enough that security can be evaluated and improved over time.
Closing: Stronger Through Examination
DEF CON 34 put these ideas into a very physical setting. Tens of thousands of attendees received the same hardware, gained access to its design, and had an opportunity to test the system for themselves. AI expanded the scale of that scrutiny, while the need for verification and layered defenses became increasingly clear.
The stronger measure of open-source security is not whether a chip can carry a permanent label of “secure,” but whether its design and behavior are visible enough for others to question, understand, and improve.
—The CrossBar Team