Onboarding DilDog: Christien Rioux on What Comes After Static Analysis

Best known to many by his handle DilDog, Christien Rioux was part of the L0pht hacker collective, co-authored L0phtCrack and wrote Back Orifice 2000. He later co-founded @stake, where he built SmartRisk Analyzer, the binary analysis technology that became Veracode, which he also co-founded in 2006. Since then, he has built internal application security tooling at Apple, been a Distinguished Engineer at Lacework, and founded Veilid, an open-source peer-to-peer privacy framework released at DEF CON in 2023.

The latest move in Christien’s long yet ever-prescient career is to join Octane as Chief Scientist. As Chief Scientist, Christien will lead work on the next phase of Octane’s capabilities, starting with binary analysis and endpoint analysis, while making our continuous whitebox analysis more valuable to the teams already running it every day.

We asked Christien what the first generation of static analysis got right, where it hit its limits, what AI changes, and what serious security systems need beyond a frontier model and a big context window.

Here’s what he thinks comes next.‍

1. You helped build the binary analysis technology that became Veracode. Twenty years later, what do you think AI powered security analysis can do that the first generation of static analysis fundamentally couldn’t?
   ‍
   Static analysis has two components: modeling software in a searchable way, and finding the conditions that lead to vulnerabilities. AI systems treat software models like any other language used to convey semantics and meaning. This makes them an exceptional means to reason about a large system of constraints without requiring the rigor and scale of formal methods or whole program analysis. Instead of one tool for ‘source code’ and one for ‘infrastructure as code’ and one for ‘dynamic scanning’, a single system can connect it all together. It’s scale economics that classical tools don’t have.
   ‍
2. You’ve also worked on application security at Apple and Lacework. What did you see in Octane’s vision and technology roadmap that made you want to become our Chief Scientist?
   ‍
   Octane understands the economic problems associated with security analysis. Finding provably exploitable vulnerabilities that other frontier models and human-assisted systems aren’t finding means you don’t pay the big company price or wait for the overworked researcher to finish the audit. The companies that win in the security space are the ones that can do it quietly, efficiently, and easily. Octane’s findings speak for themselves, and it’s fast and affordable.
   ‍
3. Security teams have heard plenty of claims about AI finding vulnerabilities. What evidence should a potential user actually ask for before trusting an AI security product on production code?
   
   Ask how much human effort is involved in producing the results. If it’s just a person on the backend manually filtering false positives out of a noisy scanner, then it’s not going to scale with your needs.
   
   Look for CVEs and actual zero-days published by the company. If they don’t actively publish issues, it might just be because they can’t.
   
   ‍Octane’s value comes from finding real exploitable issues, not just ‘bad coding patterns’. If your system is just running rules and not actually reasoning, then you’re just pattern matching. You can only get so far with pattern-matching.‍
   ‍
4. At Lacework you worked on connecting code security with what actually runs in production. How much should runtime evidence change the way an offensive security system prioritizes vulnerabilities? How do you visualize Octane making this leap?
   
   The reality of how applications run in production overlaid on top of a model of the expected behavior of an application is the holy grail of security analysis. Your code gets static analysis, and your runtime gets dynamic analysis. Knowing where the hotspots are, and where the reachable-but-unexplored areas of the system are, is the kind of coverage map that bounds exhaustive search. Beyond the cost and time savings, it is the kind of multi-domain analysis that classical tools stop short of being able to reason about and extract value from.
   ‍
5. AI can increasingly find bugs and increasingly write the fixes. What has to happen for you to trust their recommendations?
   
   Being able to generate a working exploit means you can also make an integration test to verify the patch. For me, pushing Octane’s technology frontier means automating the generation of those integration tests so you find a bug, you try the patch, and in the same sprint you can verify your code with the same tests. Don’t just trust the patch, trust the tests.
   ‍
6. You’ve warned that overusing AI can produce a “creative monoculture and a drought of critical thinking.” When do you think an exceptional security researcher should and shouldn’t rely on models?
   
   The right tool for the job always presents itself. Security research and human effort is always a valuable layer on top of good tools, but to make the most of your exceptional security analysts’ time, the tools have to be truly exceptional too. Today’s AI systems are exceptional for finding ‘needle-in-a-haystack’ problems at scale, but knowing what to look for is still the realm of human judgement. Relying on frontier models to assess risk is why we have useless pull requests littering Github Issues to the point that open-source maintainers have had to stop reading them. Outsource the heavy lifting. Don’t outsource judgement. It’s up to us to make AI part of the solution and not part of the problem.
   ‍
7. And finally, frontier models are getting better at coding and securing that code very quickly. What makes a system like Octane outperform simply running your codebase through the best general-purpose model?
   
   Models are a great tool for understanding the meaning of code, but software is a complex system that doesn't fit entirely inside a single agent's context window. Managing that context and orchestrating the work of many agents across overlapping but distinct domains requires a purpose-build and expert-informed agentic workflow. The model is the chainsaw that puts the lumberjack out of a job, but if you try to build furniture with a chainsaw it isn't going to be pretty. Software security requires precision and design-oriented thinking. Teaching agents to focus on what matters is the difference between a hallucination that looks believable, and an actionable report with real data to back it up.