Collaboration

What I am most interested in building, breaking, and arguing about.

The best work here usually starts with two engineers comparing notes on a difficult problem. If you are designing an authorization model, testing an API, improving one of the tools, or researching a vulnerability class, I would like to hear what you are working on. Send me a message.

Topics I'm Interested In

Not an exhaustive list, but this is where I am most likely to be useful.

Primary interest

Authorization and access control

BOLA, IDOR, tenant isolation, privilege boundaries, and the general problem of proving that your access rules do what you think they do. This is the thing I care most about and the reason most of the tooling exists. If you are designing a permissions model or trying to test one, this is the conversation I most want to have.

Open source

Contributing to the tools

Issues, pull requests, feature arguments, and "this design is wrong because…" are all welcome on any published repository. If you have used VardrGate or VardrMap on real work and it got in your way, that feedback is worth more to me than a star. Security issues in the tools themselves: please report those privately first.

API security

Authentication flows, token handling, rate limiting, and the OWASP API Top 10 as it actually shows up in real codebases.

Secure design review

Threat modeling a feature before it ships, or a second opinion on an architecture decision while it's still cheap to change. Earlier is always better than later.

Research and writing

Co-authoring a writeup, reviewing a draft, or digging into a vulnerability class together. I learn more from this than from almost anything else.

Students and career changers are welcome too. I came into this from the Marine Corps and a fire department, not a computer science degree, and people answering my questions early on is a large part of why I got anywhere. Ask.

How I Like to Work

Whatever the shape of it, a few things hold.

Show the work

Claims come with reproducible evidence, or with the uncertainty stated plainly. That applies to a pull request review the same way it applies to a finding.

Scope first

Security testing requires written authorization and a defined scope. Scope allowlists are compiled into the tools rather than left to memory.

Plain language

Severity reflects demonstrated impact, and uncertainty gets labeled as uncertainty. If I am guessing, I will say so.

Tell me what you're working on

A question about one of the tools, a permissions model you are unsure about, an idea you want to argue about, or just an introduction. I read everything that comes in.