﻿<?xml version="1.0" encoding="UTF-8"?>
<b:Sources SelectedStyle="" xmlns:b="http://schemas.openxmlformats.org/officeDocument/2006/bibliography"  xmlns="http://schemas.openxmlformats.org/officeDocument/2006/bibliography" >
<b:Source>
<b:Tag>talk:brucker:pentesting:2026</b:Tag>
<b:SourceType>Misc</b:SourceType>
<b:Author>
<b:Author><b:NameList>
<b:Person><b:Last>Brucker</b:Last><b:First>Achim</b:First><b:Middle>D</b:Middle></b:Person>
</b:NameList></b:Author>
</b:Author>
<b:Title>When Pen Testing is Not Enough</b:Title>
<b:Comments>Were often told ”don’t roll your own crypto” or ”don’t build your own auth.” Its great advice for most, but it begs the question: What about the people who have to build the stuff everyone else relies on? When youre developing the core libraries, kernels, or protocols that the rest of the world trusts, ”best effort” security testing is simply not enough. Standard tools like fuzzing and static analysis (SAST) are world-class at finding bugs, but they are inherently reactive. They can tell you that you have a vulnerability, but they can never prove that you don’t. This raises the question of what we canand shoulddo when we need to go beyond the ”find-and-patch” cycle. In this talk, I will explain the ideas underlying widely used security testing techniques such as fuzzing and static analysis, examining their strengths and weaknesses. This will be contrasted with a plain-English look at how formal verificationwhich offers the promise of being ”mathematically proven”allows us to show the absence of entire vulnerability classes. I will also discuss why ”mathematically proven” isn’t a silver bullet and address the practical limitations of verifying complex systems. If youve ever wondered how the foundations of the internet are secured, or if you are building a component where a single bug constitutes a catastrophic failure, this session will show you how to move beyond the ”Whac-A-Mole” of bug hunting.</b:Comments>
</b:Source>
</b:Sources>
