tl;dr

Today, we are releasing AGHAST, an open source framework that combines static discovery with AI prompts to find code-specific and company-specific security issues.

If you want to try it out, you can find information here in the Github repository.

Here is a brief video introduction:

If you want to understand more about the background, read on!

Introduction

Every security team has asked some version of this question: “Can our scanner check for that?” Usually, the answer is no - or at best, “it’s complicated.” That frustration is exactly where this story begins.

The Gap in Generic Scanning

A couple of years ago, we started thinking about a particular problem in application security. There were loads of generic code scanning tools that would tell you about basic technical vulnerabilities, things like SQLi, XSS, the usual suspects. But what if we wanted to find something that was code-specific or company-specific?

Some of the scanning tools provide a custom rules mechanism, which is often very complicated. It was not until Semgrep came about that a powerful but simple way of writing custom code scanning rules was available.

The Questions Nobody Else Could Answer

The sorts of questions we wanted to answer were:

• Has this custom business verification been implemented correctly?
• Has the company’s custom authorization mechanism been used correctly and consistently?
• Are API endpoints returning too wide a data set?

These are questions that are specific to a codebase or organization, and basically impossible for generic static security scanners to answer. They require context to understand how things should work, not just what is technically vulnerable.

From Research to Real-World Use

Working with Michal Kamensky, we delivered a talk and eventually a training course focused around this area of custom tests. The research initially focused on static testing, and for the training course also included dynamic testing.

The aim was simple: provide a straightforward way to get an answer to a codebase-specific or company-specific question.

We also started using this mechanism with clients to secure their codebases. However, the simplicity was sometimes a drawback. Diagnosing certain problems could be very complex or even impossible for a static rule alone to establish.

Something was missing. Static rules could get us part of the way but were not good enough for every circumstance.

Enter LLMs

Thankfully at this point, LLMs came to the rescue. Suddenly we had LLMs and coding agents that were very good at understanding and interpreting code.

We started by moving from static rules to LLM prompts and quickly discovered that once you reached a certain codebase size, the results became unreliable. Feeding an entire codebase to an LLM and asking “find the problems” is a bit like asking someone to proofread the internet: technically possible, practically useless.

That led to a key realization: why not combine these two techniques?

• Use static rules to narrow down to particular areas of the codebase.
• Use an AI prompt to investigate that specific area in depth.

Think of it as a metal detector on a beach: the static rule tells you where to dig, and the AI carefully examines what you find.

The Orchestration Problem

That approach works conceptually, but it introduces another challenge:

How do you orchestrate this at scale, in a repeatable way, and in a way that integrates with existing processes?

Running a one-off combination of a Semgrep rule plus an LLM prompt is one thing. Doing it consistently across multiple codebases, in CI pipelines, with structured output requires slightly more plumbing.

The Answer: AGHAST

The answer is AGHAST.

This is a framework that has been germinating for about six months.

AGHAST stands for AI-Guided Hybrid Application Static Testing, and it allows us to orchestrate tests based on this custom test philosophy.

Today, we at Bounce Security are open sourcing this tool for you to use and build on as well.

What AGHAST Does

AGHAST helps you run three types of checks:

• Pure AI scanning rules - let the LLM do all the analysis
• A combination of a static mechanism and an AI scanning rule - the sweet spot for most use cases
• Purely static rules - for completeness, when a traditional static rule is all you need

The beauty of the approach is what you don’t need:

• You don’t need to modify the code
• You don’t need to build something into the codebase
• You don’t need to write code in the language of the codebase

All you need is:

• Access to the codebase
• An understanding of the problem you are trying to discover
• The ability to write some simple rules

There are almost certainly other ways of achieving this, but to our mind, this approach is straightforward, deterministic, and very powerful.

Built for the Real World

Aside from the basic function, there are several features designed to make AGHAST easy to use and integrate into your existing workflow.

1. CI Pipeline Integration

From the beginning, AGHAST was designed to work easily within automated CI pipelines, utilizing a simple install process, text based configuration and a single CLI call to run.

We anticipate that most teams will find it most useful in this context in the long run. Set it up once, and it runs with every build.

2. Pluggable Components

The current implementation uses Claude Code and the Claude Agent SDK for AI analysis, and Semgrep Community Edition for static scanning.

However, the design intentionally allows for pluggability across the stack:

• Different LLM and API providers
• Different SAST engines (e.g., OpenGrep or other static discovery mechanisms)
• Language agnostic by design

No vendor lock-in here - use whatever works best for your team.

3. Pluggable Outputs and Actions

Output formats are designed to be pluggable - currently supporting JSON and SARIF, with other formats straightforward to add.

Beyond output formats, the platform could also be extended to support pluggable actions, enabling integration with ticketing systems, notifications, or other downstream workflows.

4. Flexible Configuration Mechanism

AGHAST includes a flexible configuration mechanism.

This allows checks to be specified in multiple ways:

• Per-codebase configuration - tailor checks to individual projects
• Central configuration containing definitions for multiple codebases - manage everything from one place

This makes it easy to define a CI job in one place using a single configuration file, which can then apply across multiple codebases that use the same CI job.

Protection of our work

We want AGHAST to be widely available, whether you are a practitioner using it in your own environment, or a consultant implementing it for clients.

AGHAST is licensed under AGPL to keep it open and ensure improvements flow back to the community. If you are interested in commercial licensing, professional support, or help implementing AGHAST in your organization, get in touch.

Prior and Parallel Work

No tool exists in a vacuum. We want to acknowledge some prior and parallel work in this area that both inspired and validated the direction we took.

Semgrep

Firstly, we want to give a shout out to the team at Semgrep, Inc for building a fantastic tool for simple static scanning. They truly revolutionized this space and we stand on their shoulders as do many others.

Semgrep Community Edition is a key part of AGHAST today, although the system is also extensible and could support OpenGrep or other static discovery mechanisms.

Anthropic Code Security (et al)

A few weeks ago, Anthropic released their code security product to much fanfare (and gnashing of shareholder teeth) followed by similar releases from other LLM providers.

That product appears to focus on giving an LLM a codebase and seeing what vulnerabilities emerge.

AGHAST differs in a key way:

• Those tools are exploratory - “tell me what you find”
• AGHAST is goal-driven - “tell me about this specific thing”

AGHAST looks for specific issues you define and returns a specific, well-formed answer about those issues.

RAPTOR

⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣤⣤⣀⣀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣾⣿⣿⠿⠿⠟
⠀⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣀⣀⣀⣀⣤⣴⣶⣶⣶⣤⣿⡿⠁⠀⠀⠀
⣀⠤⠴⠒⠒⠛⠛⠛⠛⠛⠿⢿⣿⣿⣿⣿⣿⣿⣿⣿⣿⠟⠁⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⣿⣿⣿⡟⠻⢿⡀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣾⢿⣿⠟⠀⠸⣊⡽⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⡇⣿⡁⠀⠀⠀⠉⠁⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠻⠿⣿⣧⠀ Get them bugs.....⠀⠀⠀⠀⠀⠀⠀⠀
                                                 

(We had to reproduce their funky ASCII art)

At the start of the year, our friends Gadi Evron, Daniel Cuthbert and others released RAPTOR, which performs agentic code scanning for various scenarios.

It is particularly strong for offensive work and moving from vulnerability discovery to exploitation.

While we initially considered building on Raptor, the design philosophy differs enough that it ultimately made more sense to build separately.

OpenAnt

More recently, Gadi Evron and team released OpenAnt. We saw it about a week before release and thought their approach for focusing the LLM’s attention on particular areas of code at a time was super interesting.

The key difference again is that AGHAST is oriented around specific checks and explicit criteria that determine which parts of the codebase are examined. That said, we liked the OpenAnt approach enough that AGHAST now supports OpenAnt datasets as an input source. This means you can use OpenAnt as a discovery method for targeted checks, feeding pre-extracted code units with call graph context into AGHAST’s AI analysis pipeline.

It was encouraging to see them independently arrive at the same conclusion:

A key differentiator for LLM-based analysis is guiding the model to the specific area of the codebase it should examine rather than trying to load a whole codebase into context.

What Comes Next

We think tools like AGHAST are going to be an important step in taking static code analysis to the next level of usability and accuracy. The combination of deterministic static rules and intelligent AI analysis opens up possibilities that neither approach could achieve alone.

We are looking forward to seeing your feedback - and even more, to seeing what custom checks you build with it!

I wrote the original version of this blogpost back in 2022 and then an updated 2023 version which simplified things by using SSH commit signing instead of GPG.

Since then, my setup has changed quite a bit. I moved from Linux/WSL to native Windows and started storing my SSH keys in 1Password instead of as local files. The 2023 solution relied on ssh-agent and core.sshCommand which worked but had an annoying problem: 1Password’s SSH agent would offer all of its keys in order and I had to manually deny the wrong ones before it tried the correct one.

In this updated post, I want to summarize how I solved that problem using SSH host aliases, IdentitiesOnly, and URL rewrites so that the correct key is used automatically every time.

Please read it carefully as there are some fixes and some updated gotchas! 😀

Git your configuration on

The setup

Git the right version number

Note that I am using Git for Windows rather than the git that comes with WSL. Make sure you have a reasonably recent version installed as some of the features used here (like SSH commit signing) require version 2.34 or higher.

Let me Google that for you

My primary resources for how to get the multiple users set up was a combination of the following two links which were really useful but I got caught in a few issues on the way, (not necessarily the fault of the posts through).

• https://www.freecodecamp.org/news/manage-multiple-github-accounts-the-ssh-way-2dadc30ccaca/
• https://blog.gitguardian.com/8-easy-steps-to-set-up-multiple-git-accounts/#stepbystep

The first thing I liked from the GitGuardian link was having two separate paths for Work and Personal projects using two separate GitHub identities.

Based on their instructions, I created “Work” and “Personal” folders, created the relevant ssh keys (now stored in 1Password) and then the relevant configuration files. Each identity has its own folder on disk and its own per-directory gitconfig loaded via includeIf in the main ~/.gitconfig. Obviously I also had to copy my ssh public keys into the relevant page of the GitHub UI for each account.

If you want to sign commits using the same SSH key you use for authentication, note that you will need to upload it twice in the GitHub UI. Once as an authentication key and once as a signing key.

Git configuration files

Here are the git configurations I ended up with. I will add some more information about parts of them below. Note that the heading within which each configuration line sits is important.

# ~/.gitconfig

[includeIf "gitdir:C:/Users/josh/Documents/Personal/"]  #redacted path
path = C:/Users/josh/Documents/Personal/.pers.gitconfig  #redacted path

[includeIf "gitdir:C:/Users/josh/Documents/Work/"]  #redacted path
path = C:/Users/josh/Documents/Work/.work.gitconfig  #redacted path

[core]
excludesfile = ~/.gitignore
sshCommand = C:/Windows/System32/OpenSSH/ssh.exe
autocrlf = true

Note that I am using Windows-style paths in the includeIf sections. I am also specifying sshCommand globally to use the Windows OpenSSH client since 1Password’s SSH agent integrates with it.

# ~/Work/.work.gitconfig

[user]
email = josh@acmesecurity.com  #redacted email address
name = joshacmesecurity  #redacted username
signingkey = ssh-ed25519 AAAA...ilry  #redacted public key

[github]
user = joshacmesecurity  #redacted username

[gpg]
format = ssh  #specifies that we want to use ssh signing

[gpg "ssh"]
program = "C:/Users/josh/AppData/Local/Microsoft/WindowsApps/op-ssh-sign.exe"  #redacted path

[commit]
gpgsign = true  #should force signing on commits

[core]
sshCommand = C:/Windows/System32/OpenSSH/ssh.exe

[url "git@github-work:"]
insteadOf = git@github.com:

# ~/Personal/.pers.gitconfig

[user]
email = jzzzzzzzzz@hotmail.com  #redacted email address
name = tghosth  #username
signingkey = ssh-ed25519 AAAA...R7pY  #redacted public key

[github]
user = tghosth  #username

[gpg]
format = ssh  #specifies that we want to use ssh signing

[gpg "ssh"]
program = "C:/Users/josh/AppData/Local/Microsoft/WindowsApps/op-ssh-sign.exe"  #redacted path

[commit]
gpgsign = true  #should force signing on commits

[core]
sshCommand = C:/Windows/System32/OpenSSH/ssh.exe

[url "git@github-personal:"]
insteadOf = git@github.com:

A few things to note about these configuration files:

• signingkey is set to the actual SSH public key from 1Password. Git uses this together with the op-ssh-sign.exe program from 1Password to sign commits.

• core.sshCommand points to the Windows OpenSSH client. The correct key selection for each identity is handled by the SSH config (explained below).

• The url rewrite section at the bottom of each per-directory gitconfig is the magic that makes everything work automatically (more on this shortly).

Git Gotchas

There were a couple of issues at this stage that had me scratching my head for a while during various iterations of doing this so I thought I would preserve them for posterity!

Browsing to the wrong path

Since I am using Windows paths in includeIf, the configuration will only work if I navigate to the repository using the same path style. If I somehow browse to the same folder via a different path (e.g. a mapped drive or a symlink), the includeIf won’t match and the wrong identity might be used.

Wrong file names

I had used dots in my file names for the personal and work configuration files whereas the main configuration file from the GitGuardian link used hyphens. This took me longer than I care to admit to figure out… This was certainly a PEBKAC issue.

Messed up double quotes

I was getting parsing errors for a very long time on my main configuration file. I tried all sorts of things including not using soft-links but using the full paths from the root instead. After much faffing, I realised that when I copied the same configuration files from the GitGuardian site, it had used “curly double quotes” instead of the regular double quotes and this was tripping up git 🤦‍♂️.

SSH authentication and Signing

The problem with 1Password’s SSH agent

1Password has a great SSH agent feature that stores your SSH keys securely and provides them to SSH when needed. The problem is that when you have multiple keys, the agent offers all of them in sequence. For every git operation, I would get prompted to deny the wrong keys before the right one was tried. This was really annoying.

The solution: SSH host aliases with IdentitiesOnly

The fix involves three pieces working together: public key files, SSH host aliases, and URL rewrites.

1. Public key files (~/.ssh/)

I exported the public key for each identity from 1Password into its own file in ~/.ssh/:

• ~/.ssh/personal_github.pub
• ~/.ssh/work_github.pub

These are the same public keys that appear in each gitconfig’s signingkey field. They are used by SSH to tell the 1Password agent which private key to use, without the private key ever leaving 1Password.

2. SSH config (~/.ssh/config)

I created host aliases which are fake hostnames that SSH resolves to the real server but with a specific key pinned:

Host github-personal
    HostName github.com
    User git
    IdentityFile C:/Users/josh/.ssh/personal_github.pub  #redacted path
    IdentitiesOnly yes

Host github-work
    HostName github.com
    User git
    IdentityFile C:/Users/josh/.ssh/work_github.pub  #redacted path
    IdentitiesOnly yes

The key setting here is IdentitiesOnly yes. This tells SSH to only offer the key specified by IdentityFile, instead of letting the agent offer everything it has. Combined with pointing IdentityFile at the public key file, SSH tells the 1Password agent exactly which private key it needs.

3. URL rewrites in per-directory gitconfigs

Each folder’s gitconfig already gets loaded via includeIf in ~/.gitconfig. The URL rewrite section in each one handles the final piece:

[url "git@github-work:"]
insteadOf = git@github.com:

This makes Git silently rewrite git@github.com: to git@github-work: for any repo under that folder. So when you clone, fetch, or push with a normal GitHub SSH URL, Git transparently routes it through the correct SSH host alias, which uses the correct key.

You never need to type github-work yourself. Just use the normal SSH URL from GitHub and everything works.

How it all connects

Here is what happens when you run a git operation in the Work folder:

flowchart TD
    A["git fetch\n(in Work/ folder)"] --> B["gitconfig URL rewrite\ngit@github.com: → git@github-work:"]
    B --> C["SSH config lookup\ngithub-work → github.com + work key only"]
    C --> D["1Password agent\nasked for that specific key"]
    D --> E["✅ No more 'deny the wrong key' prompt"]

This means cloning is now a single step too. I just copy the SSH URL from GitHub, run git clone in the correct folder, and the URL rewrite ensures the right key is used automatically.

You can see the correct clone link for SSH in this image:

Signing Commits

If you followed the instructions above, commit signing should work seamlessly. The per-directory gitconfig tells git to force signing (gpgsign = true), to use SSH format (format = ssh), and which public key to sign with (signingkey). The op-ssh-sign.exe program from 1Password handles the actual signing using the private key stored in 1Password.

No GPG, no ssh-agent, no passphrases to enter. 1Password handles it all. If it is all working you should see the commits as verified in GitHub.

In closing

Thanks for reading, I hope this is a useful summary and makes it easier for you to set up this functionality. If you have comments or feedback, the easiest option is to reach out to me on Bluesky, Mastodon, Twitter, or LinkedIn!

On paper, this should be easy: there’s guidance floating around that suggests setting the CLAUDE_CONFIG_DIR environment variable so each instance uses a different “home” or “config” directory.

However, in reality, Claude Code doesn’t only store state under ~\.claude\. It also keeps global state right in ~\.claude.json. This means that when both instances share the same real home directory, they will inevitably step on each other.

Rather than wrestle with extensions and ad-hoc env vars or other weird copying solutions, I made each instance run with a fully separate home directory, to avoid conflict plus a couple of symbolic links to avoid duplicating binaries and tool state.

Here’s what I did (obviously with Claude’s help).

What was conflicting?

Claude Code maintains a mix of:

• Project settings: .claude\settings.json / .claude\settings.local.json inside a repo
• Global settings: Mostly stored inside ~\.claude\ including files and folders such as .credentials.json, file-history, plugins, tasks, etc.

Why mostly? Because it also stores config inside ~\.claude.json. When you try to run two accounts against the same ~ (home) directory, even when you specify different config directories, this file becomes the shared point of failure.

Step 1: Use the native installation for Claude

I followed the instructions from here to do a native PowerShell install of Claude.

Maybe you can make it work in other ways as well, but this seemed simplest and should hopefully ensure automatic updates keep working.

Step 2: Stop relying on the IDE extension

This was the first pragmatic decision.

The IDE extensions felt janky for this specific setup, and I couldn’t get them to consistently respect the environment overrides anyway.

So I disabled the extension entirely and ran Claude Code from a terminal inside the IDE. I haven’t yet missed the lack of IDE integration…

Step 3: Create a dedicated “home” per account

I’m using PowerShell as my primary shell, so I added a helper function to my PowerShell profile.

Where is the PowerShell profile?

For PowerShell 7+ on Windows, the common path is:

• $HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

You can also just print your actual profile path:

$PROFILE

The idea

Create two folders like:

• C:\Users\<you>\.claude-split\.claude-personal\
• C:\Users\<you>\.claude-split\.claude-work\

Then, when starting Claude Code, set environment variables so the process believes that folder is home.

The variable that seems to matter on Windows is $USERPROFILE.

The path variable

Claude will also expect to find claude.exe at ~\.local\bin\claude.exe. I had hoped to do something funky with symbolic links to the original install to avoid multiple copies of claude.exe. In practice, I could not make it work, because the symlink seemed to keep getting overwritten by the actual executable. If you manage to do it, please let me know 😀.

Example: PowerShell launcher functions

In order to automate this, add something like this to your PowerShell profile:

function Invoke-ClaudeWithProfile {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory = $true)]
        [ValidateNotNullOrEmpty()]
        [string]$ProfileName,

        [Parameter(ValueFromRemainingArguments = $true)]
        $ClaudeArgs
    )

    # Build the base directory, fake home directory,
    # and profile-specific bin directory Claude will use.
    $baseDir = Join-Path $env:USERPROFILE ".claude-split"
    $targetPath = Join-Path $baseDir $ProfileName
    $profileBin = Join-Path $targetPath ".local\bin"

    # Create the fake home directory and the fake claude directory
    New-Item -ItemType Directory -Path $profileBin -Force | Out-Null

    # Store the current user home and path variables
    $oldUserProfile = $env:USERPROFILE
    $oldPath = $env:PATH

    try {
		
        # Set the USERPROFILE variable to our fake directory
        $env:USERPROFILE = $targetPath
        # Add the fake Claude directory to the PATH variable
        $env:PATH = "$profileBin;$env:PATH"
        Write-Host "--- Claude Instance: [$ProfileName] ($targetPath) ---" -ForegroundColor Cyan

        # Run claude (with these variables set) and whatever arguments were passed
        & claude @ClaudeArgs
    }
    finally {
		
        # Return the USERPROFILE and PATH variables back to their
        # previous values when claude exits
        $env:USERPROFILE = $oldUserProfile
        $env:PATH = $oldPath
        Write-Host "--- Profile Restored ---" -ForegroundColor Gray
    }
}

Some subtleties about what is happening here

When you run this function for the first time (assuming we are running it for .claude-personal), this is what happens:

1. We add our fake home directory to PATH.

2. PowerShell looks for claude.exe at C:\Users\<you>\.claude-split\.claude-personal\.local\bin\claude.exe, but it won’t find it because it doesn’t exist yet.

3. PowerShell then looks for claude.exe at C:\Users\<you>\.local\bin\claude.exe, which the original Claude install put on the system path. It should find it and run it.

4. Since the fake home directory is set, Claude itself expects claude.exe at C:\Users\<you>\.claude-split\.claude-personal\.local\bin\claude.exe, doesn’t find it, and downloads a fresh copy to that location.

On subsequent uses of this function, it immediately uses claude.exe at C:\Users\<you>\.claude-split\.claude-personal\.local\bin\claude.exe.

Aside from duplicating .exe files, one downside is that C:\Users\<you>\.local\bin\claude.exe may not get updated if you always launch Claude through profile functions. In practice, that should not be a major issue in this setup.

Step 4: Calling this function

You would then create shortcut functions for each separate Claude instance you want to run.

So for example, I might have:

function claude-work {
    Invoke-ClaudeWithProfile -ProfileName ".claude-work" @args
}

function claude-personal {
    Invoke-ClaudeWithProfile -ProfileName ".claude-personal" @args
}

This forces each instance to have its own:

• ~\.claude.json
• ~\.claude\...

…beneath the fake home folder we defined, which should prevent cross-account corruption.

Step 5: Fix the weird side effects with symbolic links

Once you “fake” a different home directory, some tools start looking for binaries and configs in places you didn’t expect.

To avoid maintaining duplicate copies (and to keep tools happy), I created some symlinks. In the end, the only one I kept was for the glab-cli config directory, as the others either didn’t work out or were not necessary. You may need to do something similar for other CLI tools you use.

As I noted above, I tried doing this for claude.exe, but it didn’t work out, so I have to live with some duplication there.

Important: On many Windows setups, creating symlinks requires an elevated PowerShell session (Run as Administrator). Some machines allow Developer Mode symlinks without elevation, but assume you’ll need admin unless you know otherwise.

Symlink for GitLab CLI config

I had to do this for GitLab CLI (glab).

On Windows, glab stores its config under:

• %LOCALAPPDATA%\glab-cli\ (including config.yml)

(At least in my installation.)

With our fake home directories, we may want each Claude profile to see the same glab state.

Run in elevated PowerShell:

$realGlabDir = Join-Path $env:LOCALAPPDATA "glab-cli"
$homeGlabDir = "C:\Users\<you>\.claude-split\.claude-work\AppData\Local\glab-cli"

New-Item -ItemType Directory -Force -Path (Split-Path $homeGlabDir) | Out-Null
New-Item -ItemType SymbolicLink -Path $homeGlabDir -Target $realGlabDir

GitHub CLI note

Interestingly, I didn’t have to add extra symlinks for GitHub tooling in my setup. It just worked with Claude having the fake home directory…

Current status

So far, I haven’t found any unwanted side effects.

There may be additional state Claude Code relies on that could get confused in edge cases, but for now, this approach has been stable: two accounts, one Windows PC, no cross-contamination.

Let me know how you get on and if you find any bugs!

<rant>

Why is everyone so insanely terrible at explaining security vulnerabilities? I don’t care how technically clever it is, or how many different steps you had to go through in order to achieve this. Well, that’s not true. I do care actually. I do appreciate a good high-quality vulnerability. But right now, what I want to know is:

• How bad is this?
• What is the risk?
• How fast do I need to deal with this?
• What is going to happen if someone exploits this?

These are the questions that I need answered if I’m going to decide how fast to fix it. Do I walk? Do I run?

I’m currently dealing with two cases in parallel where I am struggling desperately to understand: What is the problem here? What could actually go wrong?

Case Study 1: The DLL Hijacking That Wasn’t

In the first case, from the initial explanation, I thought it was like DLL hijacking on Windows—where a low-security process could write a malicious DLL file to a location on disk, and the vulnerable application would read that DLL file before it gets to the actual DLL file it should be reading, and therefore execute some code in the context of the application.

Now, yes, that would be bad. That is an understandable outcome.

But no, that’s not quite the case. After much digging, it turns out that the risk is that if an attacker is able to write into the application folder itself, then they can escalate to code execution—effectively escalating a write primitive to a code execution primitive.

Now, that is not ideal. I’d rather that didn’t happen. But it certainly doesn’t require me to run and fix this, especially because the only way of doing this bypasses various other platform-level controls we wouldn’t expect a regular user to be using anyway.

The amount of back and forth it took to discover that that was actually the case was just ridiculous.

Case Study 2: The HTTP Smuggling Mystery

The second case related to a bug bounty with an HTTP smuggling vulnerability—or maybe it was a desync. It doesn’t really matter. I’ve got two levels of triage investigating this to decide whether it’s a real issue or not.

All I want to know is: What can an attacker actually do in our application with this vulnerability?

I understand how these attacks work. I just want to know what is going to happen in this case. What is the attack scenario? What is the step-by-step?

The Toilet Plunger Parable

In the end, I tried to come up with a parable to try and illustrate to the people in both cases what I am talking about. The parable is as ridiculous as I felt the situation warranted.

1. The attacker throws a toilet plunger very hard at a wall
2. It sticks to the wall
3. The attacker calls the user’s name
4. The user runs towards the attacker who is standing near the wall
5. The user runs into the handle and knocks themselves out, Looney Tunes style
6. The attacker steals the unconscious user’s wallet

Now I don’t care:

• What the wall is made out of
• What glue was on the head of the plunger
• Whether a normal person could throw hard enough to make this work

I just want to understand: What is the attack scenario? What is the series of events that has to happen in order for this to become a problem?

The Bottom Line

I cannot understand for the life of me why people are so bad at explaining this.

When you’re reporting a security vulnerability, please, for the love of all that is holy:

1. Start with the impact - What can an attacker actually do?
2. Describe the attack scenario - What sequence of events leads to the bad outcome?
3. Explain the prerequisites - What access or conditions are needed?
4. Then, and only then, dive into the technical details

Your job as a security researcher or engineer isn’t just to find the vulnerability—it’s to communicate it in a way that allows stakeholders to make informed decisions about risk and remediation priority.

The coolest vulnerability report in the world is worthless if nobody can understand what they need to do about it.

Rant over.

For now.

Update 4-Dec-2025: Further to this, Jeff Williams wrote a great article a few years ago about how to report vulnerabilities in a clear way! https://www.linkedin.com/pulse/how-vulnerability-jeff-williams

Introduction

Your course is confirmed and you’re ready to go? Fantastic! That’s a major milestone worth celebrating. 🎉 Now that you’re past the proposal phase, it’s time to think about the practical preparations that will ensure your course is not just delivered, but delivered smoothly and memorably.

In this post, I’ll walk you through essential pre-course considerations, from visa planning to organizing handouts, so that nothing catches you off guard when it’s go time.

Visa Considerations: More Than Just a Stamp

While not strictly a financial issue, visa planning is a must-do if you’re delivering a course abroad. Skipping this step could derail your training before it begins.

Getting a Visa to Enter the Country

Ask yourself: How easy is it for me to enter the country where I’ll be training?

If you don’t have the privilege of a streamlined entry process (like the US ESTA or the upcoming EU ETIAS), start early. Some visa applications take weeks or even months. Even the time between your course being accepted and the conference date might not be enough, especially if there is a backlog.

Getting a Visa That Lets You Get Paid

Here’s where things get tricky. I’m not a lawyer (technically, I’m an accountant but I’ve never practiced), so this isn’t legal advice. However, be aware: Getting paid to train abroad might require a different visa than just attending a conference.

Check whether you’ll legally be allowed to work (i.e. deliver training) and get paid while in that country. Conferences often won’t have definitive guidance on this either so it’s your responsibility to do the homework.

Note that the US in particular has gotten stricter about this and in some cases people were detained at immigration for attempting to come in to work on the wrong visa.

Supplementary Materials: Going the Extra Mile

Beyond your core curriculum, it’s a great idea to prepare supplementary materials that enhance the learning experience. These can include physical goodies, printed handouts, or digital resources. Let’s break them down.

Goodies and Extras

If you’ve promised participants anything extra (such as stickers, USB drives, branded gear) now’s the time to deliver. But beware: You might not know your final headcount until right before the event.

At Black Hat 2023, my attendee numbers jumped by 50% in just two weeks.

So, plan generously. It’s better to have a few extras than run out and disappoint attendees. For expensive items, consider a cutoff: for example, “Free hardware kit for sign-ups received 3+ weeks in advance.”

Course Materials

For in-person training, I’m a big fan of printed materials. When exercises require referring to multiple documents, printed copies save participants from constantly alt-tabbing between different screens.

I always print and bring these materials myself to ensure quality and timing. The exception? At Black Hat, they print a course workbook for you which is a nice touch!

Pro Tip: Never pack your printed materials in checked luggage. Ask me why one day :)

On one occasion where I wanted to go a little above and beyond, I ordered plastic document folders via Amazon to the venue. Each participant got one to organize their handouts, plus some extras like sticky dividers and branded stickers.

Printed materials are great during the course, but soft copies are critical for long-term reference. I provide PDFs unless I want students to edit the files themselves.

I “drip feed” exercise materials throughout the course, which adds a bit of complexity but keeps students from jumping ahead. For slides, I always ensure the numbering on the handouts matches the numbering on screen. This keeps everyone on track.

Don’t Overthink It: Focus on Delivery

While all this prep helps, don’t lose sight of what truly matters, the content and the experience. Your delivery, your energy, and the interactions you create with participants are what make your course memorable.

Handouts and goodies? They’re just the icing on the cake.

Looking for more?

That’s a wrap for now but I have more ideas in the pipeline. Did you find this helpful? Let me know what you’d like to hear more about or which questions you want answered next.

Let’s make your next training the best one yet. 🚀

Introduction

So your course got accepted? Congratulations! 🎉 That’s a huge win and shows your proposal resonated with the review board. But now comes the real challenge: getting people to actually attend.

However, on this specific topic, I cannot pretend to be an expert or to have seen major success when doing this. I will try and provide my perspective and ideas but your mileage will certainly vary. There are plenty of other things you might want to try and maybe even consult with other people with more expertise.

Size of the Field, Size of the Audience

Before diving into promotion tactics, it’s worth understanding the competitive landscape.

Three big factors influence how easy or hard it will be to sell your course:

1. How many people usually attend training at the conference?
2. How many other courses are being offered?
3. Can you attract people to attend the conference specifically for your course?

For example:

• OWASP Global AppSec events often run up to 10 courses in parallel, with around 100-200 total attendees at the training and around 800 attendees at the conference.
• Black Hat USA, on the other hand, may feature ~140 courses. I remember seeing a lunch room packed with 1,000+ people during training days.

Whilst the numbers at Black Hat may sound particularly promising, note that distribution isn’t equal. Some courses are held in huge rooms with dozens of students, while others are tucked away with small groups.

This makes it crucial to stand out. I’ve already discussed finding your niche at length in previous posts. In addition to this, I have also tried ensuring the course appears relatively high up in the course list through an “optimised” title and also adding an explanatory video to the course description wherever possible (but more on videos further down).

I can’t say it dramatically boosted my numbers, but who knows what would’ve happened if I had named the course “Zebra Security Essentials”? 🤷‍♂️

Either way, don’t rely solely on being listed on the website. You probably want to do more than that.

What You Actually Get from the Conference

Many conferences do minimal marketing for individual courses.

Most conferences might tweet or post once or twice on LinkedIn or other social media networks. I haven’t trained at TyphoonCon, but it’s one of the only instances I’ve seen a conference do promoted tweets for individual courses.

You can sometimes ask organizers to amplify your own posts — but their support is limited and often hinges on you already having a strong social media presence.

Building Your Social Media Presence

If you have a strong social media presence then you are clearly already good at self-promotion so that will help a lot in this context. You can probably skip this section (although I’d love to hear your tips 😀).

I made an effort to increase my social media activity a little (specifically on Twitter and LinkedIn) in the run up to these courses. I grew my follower count slightly and made an effort to post more frequently and try and engage with other posts. I would usually focus on subject matter related to my course including sometimes mentioning work I was doing on developing the course.

I also made an effort to prepare some short videos as this seemed to be a good way of communicating information in an effective way and be in line with how many people seem to consume information right now. I was also able to outsource the video editing which saved time. I varied between videos specifically about the course and also short videos on related topics.

Some interesting discussions developed from both text and video posts and in general I think that having an active social media presence has professional benefits anyway. It does however require a lot of effort to have an impact.

Other Ways to Build Awareness

If social media isn’t your thing (or isn’t enough), here are some alternative channels I explored:

🎤 Conference Talks

Speaking at conferences, specifically on your training topic or even on other related topics, is a great way to build credibility, expand your presence in the industry, and push your course at the same time.

I couldn’t fund travel to overseas events, but I looked for conferences that cover speaker expenses. My largest target was Black Hat USA 2023 so I pushed particularly hard in late 2022/early 2023.

This resulted in:

• October 2022 - OWASP Global AppSec San Francisco (Training + Talk)
• January 2023 - NDC Security in Oslo + OWASP Oslo Meetup
• February 2023 - OWASP Global AppSec Dublin (Training)
• April 2023 - QCon London (Speaking)
• June 2023 - DevTalks Bucharest (Speaking)

I’d often mention my course at the end of talks or during conversations at these events.

🎙️ Podcasts

Podcasts are another great channel. Less travel but plenty of reach.

I got some great benefits from being a podcast guest including:

• Exposure to new audiences
• Valuable feedback on course content
• Deeper conversations that helped refine the material

Many podcasts welcome guest suggestions — especially if you have an interesting perspective or topic to pitch.

💸 Paid Marketing (Spoiler: Meh)

We tried a small LinkedIn ad campaign. Honestly? No real impact.

Paid ads likely require consistent investment and long-term strategy to pay off. Not ideal for one-off training sessions or a short-term effort.

The Hard Part: Self-Promotion is Draining

In truth, I found this part exhausting.

• I’m not a fan of social media pressure.
• I don’t want to be constantly travelling.
• Conference prep takes a toll on time, not just money.

All this meant I wasn’t as consistent or aggressive in promoting as I could have been.

For me, the bottom line was that every time I asked course attendees how they found out about the course, they almost exclusively said it was from browsing the conference website and not from social media posts or any other channel.

So lately, I’ve toned it down. Just a few social posts and that’s it.

The Stress of GO/NO-GO

As I mentioned in a previous post, there’s often a GO/NO-GO decision looming.

• Will enough seats sell to justify running the course?
• Will it hit both your and the conference’s break-even point?

That decision can be stressful. And a little embarrassing if the course gets pulled after a few people have already signed up.

In 2023 I made this more difficult for myself as I planned a family vacation around Black Hat USA. If the training had been cancelled, I’d have had to pay all my own expenses to get to the conference or skip the conference but still travel to the US for holiday.

Luckily, it worked out. But I stressed about it for months. The feeling of relief and excitement I felt when Black Hat confirmed my course was running was unreal.

A Specialist Discipline

Let’s be realistic, sales and marketing is a specialist skillset. You’ll find countless experts who can speak to it better than I can. Hopefully this section provided some useful context although I accept that it is not super actionable.

My most active period was late 2022 through early 2023. While I can’t say how much the self-promotion effort changed the outcome, the opportunity to train at Black Hat and attend DEFCON made it absolutely worthwhile.

Only you can decide how much time, energy, and budget to invest in promoting your course. What’s right for you might not be right for someone else.

Next Post: Make Your Preparations

If your course is confirmed, amazing! In the next post, I’ll walk through the preparations you’ll want to make to help ensure it’s a success.

Introduction

You’ve figured out your finances, carved out your niche, and built exercises that pack a punch. Now comes a critical step: getting your course accepted by a conference.

In this post, we’ll dive into how to write a compelling Call for Training (CfT) submission that catches the eye of both review boards and potential attendees.

Plan Ahead: Timing is Everything

CfTs (Calls for Training) often open earlier than the main Call for Papers (CfP). For example, Black Hat and OWASP usually open their CfTs more than six months before the event, and they might only stay open for a month.

Failing to plan here could mean missing your window altogether. This means you are going to want to put CfT dates in your calendar and prepare your materials well in advance.

Know Your Audiences

Crafting a strong CfT submission requires you to speak to two distinct audiences:

1. The Conference Review Board

This group is experienced, discerning, and reviewing dozens (if not hundreds) of submissions. You generally have lots of space to provide them with information about the course and you want to try and differentiate it from the many other submissions they are reviewing.

The key things they care about will be:

• How your course stands out from the rest.
• Its technical depth and relevance.
• Your credibility as a trainer.
• How interactive your course is.

💡 Pro Tip: Include testimonials, past success stories, and why you’re uniquely positioned to teach this subject.

2. Your Potential Attendees

Potential attendees will often only see a small portion of your submission — usually the abstract or summary. You need to ensure that you include the right information to help them make a decision. You may also have character/word limits to comply with here. (However, I invite you to compare the Black Hat abstract word limit to the length of the abstracts on the training pages 🙃)

Potential attendees are going to want to know:

• “Is this course useful to me?”
• “Will it help me solve real problems?”
• “Will I walk away with tangible skills?”

Arguably the third audience is your potential attendee’s manager who they are going to have to justify the course to but I think the considerations are similar to those of the potential attendee. To be absolutely clear, you are writing a sales pitch and you need to be thinking and writing accordingly.

Writing for Both: Key Tips

Here’s my approach to balancing both needs:

• Keep it short, punchy, and scannable.
• Address a relatable pain point. You want to make your reader think, “That’s me! I need help solving that problem!”
• Be clear on what participants will do during the course.
• Make it sound like fun to take part in the course!
• Highlight clear, actionable takeaways.

Align with Conference Guidance

Each conference will have its own specific perspective and content that it is looking for. If you are clearly not aligned with that, your submission may be doomed from the start.

Read the CfT guidelines carefully and align your submission accordingly. If the guidance includes sample abstracts or criteria, read through them and ask yourself how well your submission compares to them.

For First-Time Trainers

New to delivering public training courses? You’ll likely need to prove you can teach effectively. For example, Black Hat requests new trainers to provide ~60 slides of training material plus other information as well so make sure you have that ready in time for the CfT as well.

Any prior experience or videos or whatever else you can provide at this stage will help if you are not a well known trainer. I have also provided ratings and testimonials I have received when training and speaking at other venues.

Mission Essential Task List (METL)

Full credit for this point has to go to Daniel Cuthbert from the Black Hat Training Review board who has made it clear on a number of occasions that this is something he expects to see from submissions. Also to AviD, my boss at Bounce Security who has made this standard procedure within Bounce for training course preparation.

A METL is a detailed course breakdown, how long you’ll spend on each topic and what will be covered.

This shows you’ve done more than brainstormed ideas, you’ve planned and structured the course in a logical way. It should include:

• Topic breakdowns with time estimates
• Timings for hands-on to show the lecture-to-exercise ratio
• How learning outcomes map to course segments

As a some-time CfT reviewer, I can tell you: if your submission lacks this level of clarity, it’s unlikely to make the cut.

Get Feedback Before You Submit

Even seasoned trainers benefit from a second pair of eyes.

Tips:

• Ask a former CfT reviewer if possible.
• At the very least, someone familiar with the material.
• If English isn’t your first language, get a native speaker to review.

At Bounce Security, our internal review process made a huge difference — right down to workshop titles and tagline polish.

It is highly unlikely you will get feedback from the conference or the review board during the CfT process, regardless of how early you submit. It is possible you might be able to get some feedback if the submission gets rejected but that is already a little too late…

Add Goodies (If You Can)

Extras can make your course more appealing:

• Hardware courses might include take-home tool-kits.
• Some courses provide pre-configured VMs or helpful documents.
• One course at Black Hat even included a laptop for every attendee (ambitious, but memorable!).

I don’t think these bonuses necessarily replace a compelling course proposition but they might sweeten the deal..

I include special working documents in my course. We’ve also considered offering follow-up consulting hours though we haven’t gone forward with that for now. I did notice however that this year Sensepost is offering an extended Q&A session after their courses.

The Waiting Game

Once you’ve submitted… now you wait.

Don’t be discouraged by rejections, they happen to all of us.

I have been rejected multiple times, even after I have been accepted at previous events from the same organisation. E.g. I have never been accepted by Black Hat Asia and was accepted by Black Hat EU for a couple of years but then rejected the following year.

Always ask for feedback (if available) and iterate on your submission.

Coming Up: Selling Your Course

If you got accepted, congrats! That’s a huge achievement. 🎉 🎉

But now comes the next big challenge: getting people to sign up.

In the next post, I’ll talk about marketing your course in an attempt to turn your hard work into a full classroom.

Introduction

Let’s be honest: nobody’s signing up for a training course just to sit and listen to someone talk for 7–8 hours a day.

People come to do the things, to get their hands dirty, apply what they’ve learned, and leave with new skills they can actually use. And that’s your edge.

In this post, I talk about how to make the hands-on elements of your course not just functional, but an integral part of the course.

Splitting the Day: Labs vs. Lectures

The Black Hat Call for Training (CFT) recommends at least 40% of your course be practical. That’s great news as it means you only need to talk for 4–5 hours a day.

But here’s the catch: you now need to figure out how to entertain your attendees the remaining time.

I can tell you that the practical segments are the part attendees remember most and will define their takeaway experience. You therefore need to make these segments sound compelling enough for the review board and the potential attendees.

Traditional, Practical Labs

If you’re teaching a very hands-on skill such as offensive security, reverse engineering, cloud config hardening, practical labs are likely your core.

But just saying “we have labs” isn’t enough, how are these labs going to work.

Initial Considerations

Here’s what you need to think through — trust me, these details matter:

• How do you make tasks challenging yet solvable?
• Are the exercises accessible and achievable by people at a variety of skill levels?
• Will you want to centrally track attendee process and if so, how?
• Is it a competition or self-paced?
• Can you stretch your most advanced students?
• How can you test that your labs still work before each run? Is that manual or automated?
• How will you keep lab content up to date if your subject moves fast?
• How many students can you realistically support and troubleshoot for at once?
• Do you have an automated way to reset your labs to a known good state?

Providing Lab Access

One of the biggest questions: how will students access the labs?

• Do they need to install software?
• Is specific hardware/software required?
• Do they need a virtualization tool?
• Will they need admin access?

If the answer to any of these is yes, expect friction and maybe a few frustrated emails.

Hosted Labs: The Modern Standard

In the old days, trainers would lug laptops and servers into conference venues. Now? Cloud-hosted labs are the norm.

Sensepost set the gold standard for this almost 10 years ago as they discuss in their blogpost here. Nowadays, this should probably just be the standard.

But don’t let the cloud fool you into thinking it’s simpler. It comes with its own set of questions:

• Can your labs scale to support dozens (or hundreds) of users?
• How will you automate provisioning for each user?
• Do students authenticate individually? How will you set this up
• Have you secured your environment from… creative attendees?
  • Yes, someone once deployed ransomware in someone’s training lab environment. Be ready!
• Will students have post-course access? (Bonus points if yes.)

When “Hacking” Isn’t the Goal: Creative Practical Exercises

What if your course isn’t about hacking or coding? Then you’ll need to get creative.

In my case, I built two distinct types of exercises from scratch and they actually became the highlight of the course.

(I go into quite a lot of detail here but I hope it helps other people with their thought process. Feel free to skip if you don’t want the details)

Vulnerability Triage

The first was a vulnerability triage challenge.

Students worked in groups, reviewing fictional findings from tools like SAST, DAST, and SCA. They had a simulated codebase or running app as a reference, but running tools wasn’t the goal or even part of the exercise.

Instead, they had to prioritize the vulnerabilities and more importantly, explain their reasoning.

Why? Because the course and therefore the exercises focused on process and decision-making, not tool mastery.

This exercise built on the lectures and gave students a chance to the new ideas in a low-stakes setting.

Organisational Process

The second type of exercise asked: How do you roll out a security tool across an organisation?

Students had to plan an implementation using a working document based on the content in the lectures. Sounds fun, right? Well I had to work a little on the fun part.

Since attendees came from diverse backgrounds I created a fictional company case study for everyone to work from. I also prepared a tech stack, fake team leads, and a slightly sinister app to keep things fun. All teams worked from the same case study as I felt it would make it easier for teams to compare notes afterwards.

But how would they provide their feedback?

Enter: The Simulated Stakeholder

Rather than each team presenting their plan to the entire class (which might be a little repetitive), I introduced the simulated stakeholder, in most cases the CTO of the simulated company.

(I think this was probably inspired by exercises we did back when I worked at Deloitte as part of training for more senior roles.)

Each team nominated one person to role-play the CTO. All the “CTOs” joined me in a breakout session, where I worked through the working document with them and guided them on the kinds of questions and expectations a real executive might have and how best to interact with the teams.

Then, each CTO joined a different team, and that team had to justify their plan to a skeptical senior stakeholder.

Aside from the simulated stakeholders getting much amusement from their sudden promotion to CTO (although I think on one occasion a stakeholder was actually a CTO in their day job), this was a great way to give the teams something to work towards and also stimulate discussion.

It was also an important illustration of one of the key lessons from the course which is the importance of getting senior level buy-in.

Other Ideas

I’ll save the story about the time I built a multi-player game based on the ASVS entirely in Google Sheets for another post, or over a beer. 🍻

Just know that even if it sounds weird, it might actually work.

The Real Point

Yes, I wanted to show off some my cool ideas but the real message is this: You can go beyond traditional “labs” and build creative, impactful exercises that magnify the impact of your course.

Don’t limit yourself to hacking and code. Remember that the rarest and most valuable skill in security is the ability to communicate and persuade. Think about courses which build that muscle as well.

Next Post: Putting pen to paper

So now, having figured out your financials, your niche, and your exercises, you now need to actually get accepted by a conference.

In the next post, I’ll walk through how to write a compelling Call for Training (CFT) submission.

Introduction

If you’re thinking about creating a training course, one of the biggest questions you’ll face early on is: Will anyone actually want this? In this post, we’ll explore how you can evaluate whether your course idea stands a chance in an already packed marketplace for professional training.

Market Research

In a previous post, I mentioned that I already had a good grasp of the application security training landscape, which gave me an edge in knowing which topics were oversaturated. If you’re not yet as familiar with your own niche, I would suggest you do some market research. Here are some areas you might want to consider.

History of training courses at your target conferences

Conferences will often maintain historical websites where you can see the courses they have previously offered.

Black Hat maintains an archive of past training courses with predictable URL patterns, making it easy to explore previous years’ offerings. Keep in mind that not all Black Hat events are created equal, Black Hat USA is significantly larger than its counterparts in Asia and Europe.

As for satellite events like Black Hat Spring Trainings, I have never seen a formal Call for Training. It’s possible these are invite-only affairs, favoring trainers with a strong sales history, but that’s just a theory.

If you’re targeting an OWASP event, they also have a historical record of courses available though it might require a bit of sleuthing. (Hint: all recent OWASP websites have been based in GitHub).

For smaller or more specialized conferences, you’ll need to do your own detective work to uncover historical data.

Check out Offensive Security

Offensive Security offers a well-known set of training programs. You can probably guess where their focus lies. If your topic overlaps with theirs, take a hard look at how your course differentiates itself. Their content is well-established and widely respected so if you’re in their arena, you need a unique angle.

Review the SANS catalogue

SANS offers a massive range of courses often at premium prices but keep in mind that many of them run for six full days. That means a shorter, more affordable course on a similar subject might still appeal to time and budget conscious learners.

Explore other sources

Don’t stop there. Depending on your topic, there may be other educational offerings in your space: self-paced labs, YouTube tutorials, Massive Open Online Courses (MOOCs), and more.

Ask yourself: What will learners gain from your course that they can’t easily get from free or low-cost resources? Your value proposition needs to go beyond content, it should include engagement, interaction, depth, or application.

Finding the niche

The sweet spot for your course lies at the intersection of three things:

1. A subject you’re passionate and knowledgeable about
2. A real gap in the current training market
3. A compelling reason for someone to pay for it

If you’re struggling to identify that gap, don’t be discouraged. It is a tricky balancing act. The ideal topic needs to be fresh and interesting to the conference review board and relevant enough that your potential attendees can justify the time and money it takes to attend.

On the other hand, the cybersecurity field in particular is constantly evolving. New technologies and threats emerge regularly each one a chance for you to carve out your own area of expertise. There are plenty of unsolved problems and overlooked areas that need attention.

Remember, your audience will often have to convince their manager that your course is worth the investment. Help them make the case by choosing a topic that solves real problems, enhances valuable skills, or supports strategic goals.

Next Post: Practical Exercises

In the next post, we’ll focus on the major differentiator that can elevate your course above the rest: hands-on activities. Because let’s face it no one wants to sit through two days of lectures. What participants get to do during your course is just as important as what they learn.

Introduction

In my previous post, I briefly touched on the financial realities of delivering training courses. In this post, I’ll explore this topic in greater depth.

Making your millions??

If your goal is a big financial success, training courses will probably not be your golden ticket. That is why I want to tackle this topic up front. You will need to think about this but you also need to be realistic.

Developing a course requires significant upfront investment, and even after launch, it demands ongoing “care and feeding”. Keeping content fresh and relevant is crucial, and that means regularly:

• Updating material to reflect industry changes
• Incorporating new insights and experiences
• Ensuring training exercises still function as intended
• Revising and updating technical components of exercises
• Adapting exercises to maintain relevance
• Applying feedback from previous course sessions

If you can identify a subject that is broad enough to appeal to a large audience, different enough from existing options to generate demand, and also low-maintenance in terms of updates, then you might have a high-profit opportunity.

But let me know if you do manage that as it is pretty tough…

In my case, the course I built falls into a slightly specialized category. While maintenance isn’t overwhelming, I have only delivered it 5–8 times so far.

Non-financial benefits

On the other hand, there are other benefits that may be attractive to you.

The experience of preparing and delivering a course at this level may itself be valuable to your professional development. It may also bring a boost to your public profile and your resume.

Depending on your planned career trajectory, these aspects may be more valuable than money. However, your current employer may not see things this way. 🙃

Recouping your investment

Before you make a profit you are going to need to cover your initial investment.

The most basic investment is any actual money you spend to deliver the course in person. There are a bunch of considerations for this so I will cover it in more detail a little further down.

The real cost however is (or at least should be) the time you spend building the course. You certainly don’t want to spend a lot of time building a course which no one wants to attend.

To try and mitigate this risk for my course, I took a phased approach. I started by delivering a one-hour overview at the Open Security Summit, followed by a one-day version at OWASP Global AppSec.

These smaller commitments helped me gauge audience reception and refine my content. The one-day course also allowed me to test my experimental exercises (more on that later). While this phase didn’t compensate for all the time investment, it provided some validation that the course was worthwhile and effective and therefore I should continue investing in it.

Striking the right balance is key: invest enough to prove the concept and demonstrate viability, but avoid committing excessive resources to an untested idea that might not work out.

Breaking even on an single course session

If you are able to afford to pay expenses to deliver training “for the exposure”, then you don’t need to worry about this. In most cases however, you will need to have a plan.

Virtual training is simpler financially: as long as you cover your time cost, you’re in the clear. In-person training, however, introduces a host of additional expenses and complications and I will try and cover some of these here.

For in-person training, you need to figure out what your break even point is. Specifically, how many people need to register to get the revenue required to break even. Obviously the first thing you need to know is what share of the course income you will receive from the venue which is hosting the training. This might be fixed or flexible depending on the conference.

You can then start building a break even and profit calculator based on your expected expenses. I usually prepare an Excel spreadsheet or Google Doc to work this out and recalculate dynamically.

Key Expenses to Consider

Different conferences handle costs in different ways. Expenses that conferences might cover for you (wholly or partly) include:

• Flight costs
• Hotel costs
• Venue costs including food and beverage.

Examples that I have seen:

• Black Hat publishes information on the public CFT page.
• OWASP covers all venue costs but not hotel and flight.
• Other conferences equally split costs and then equally split the profit as well.

All conferences I have seen also give trainers a free conference ticket which could also be worth a lot.

Beyond travel and accommodation, factor in additional costs such as:

• Airport transfers
• Meals and per diems
• Printed materials or giveaways for participants, (I have a bunch of print-outs I prepare and hand-out over the duration of the course and I often buy and bring snacks as well)

The Hidden Cost: Your Time

If you’re self-employed or consulting, or you are doing this separate to your employer, your time has an opportunity cost. Time spent training is time you could have spent on client work or other revenue-generating activities. Don’t forget to include travel days as well.

Revenue Per Course Day

Different conferences handle pricing and revenue shares in various ways:

• OWASP charges attendees a flat daily rate for training, meaning a three-day course costs three times as much as a one-day course, with no discounts. Trainers receive 40% of net revenue up to $10,000 USD, and 50% of net revenues above $10,000 USD (this is public information).
• As can be seen on the public training page, Black Hat training ticket costs vary between courses and there are also various early-bird stages. Interestingly, a four-day Black Hat course doesn’t necessarily cost attendees twice as much as a two-day course.
• Some conferences pay a fixed rate per course, contingent on meeting a minimum number of registrants.

Note that at Black Hat USA, trainers can deliver the same two-day course twice (Sat-Sun and Mon-Tues).

Set Your minimum up-front

Most conferences will ask what your financial minimum is upfront and you should be able to use the information above, plus the conference’s specific terms, to figure that out. You’ll need to maintain close communication with them to determine when to make a GO/NO-GO decision.

The conference’s minimum

Conferences themselves will generally have financial break-even points, and they won’t run training that doesn’t meet minimum registration numbers. Be clear on these thresholds and when there conference team will make their final decision.

Also, keep in mind that waiting on a conference decision could mean higher flight costs if you delay booking.

Next Post: Figuring out your selling point

The financial aspects are only a small part of the equation. To truly succeed, you need a compelling reason for people to choose your course over others in a crowded market. In the next post, I’ll discuss how to carve out your unique value proposition and attract the right audience.