When Pen Testing is Not Enough

By Achim D. Brucker.

Were often told "don’t roll your own crypto" or "don’t build your own auth." Its great advice for most, but it begs the question: What about the people who have to build the stuff everyone else relies on? When youre 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 canand shoulddo 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 verificationwhich 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 youve 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.

Please cite this work as follows:
A. D. Brucker, “When pen testing is not enough,” presented at the BSides Exeter, Exeter, UK, Apr. 25, 2026.

BibTeX
@Unpublished{ talk:brucker:pentesting:2026,
  author     = {Achim D. Brucker},
  date       = {2026-04-25},
  title      = {When Pen Testing is Not Enough},
  eventtitle = {{BSides} {Exeter}},
  language   = {english},
  areas      = {security},
  venue      = {Exeter, UK},
  abstract   = {Were often told "don't roll your own crypto" or "don't
                build your own auth." Its great advice for most, but it
                begs the question: What about the people who have to build the
                stuff everyone else relies on? When youre 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 canand shoulddo 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
                verificationwhich 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 youve 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.},
}