BirdyFoot

Find the gaps before someone else does

I'm Josh Fischer. I look at systems and work out where they give way. Applications, the services behind them, cloud accounts, identity, the network underneath. Then I help close what I found.

BirdyFoot is my practice. I've been running it on my own since June 2025.

What that looks like

• Security assessment

  I go looking for the gaps. Application logic, the services behind it, cloud configuration, identity and access, network paths, the build pipeline that ships all of it. The findings worth having usually sit between two layers, where each side assumed the other was handling it. You get what I found, ranked by what I would fix first, and a roadmap your team can actually run.

• Purple team engagement

  I run the attacks with your team. We watch what gets through, what your tooling caught, and what it missed. Then we fix both.

• CMMC Level 1 readiness

  Fifteen controls, self-assessed, affirmed in SPRS every year. It's phasing into DoD contracts now, so it's coming either way. I get them working for real and written down, so next year isn't a scramble.

• Training and workshops

  Hands-on sessions in person with your team and architecture.

What to expect

Your team is busy. Whether your company is logistics, construction, software, or something else, that's your focus and that's what keeps the business going. Every system has holes. I find them all the time. What matters is that you know where yours are and have a plan to close them.

I run each engagement personally. I come in, assess your system, and give a readout to your team. You get a prioritized roadmap of what to fix and in what order. My team can help you close the gaps, or your team can take it from there.

The writing and labs are free and always will be. Take whatever's useful. If you'd rather have someone look at your system, I'll come in at any stage. A design review, a first deploy, or after ten years of accumulated decisions.

Who it's for

Teams running complex systems that handle real data. A customer record, a payment, an internal service, a production database. Somewhere in there, something can usually be talked into acting on someone else's behalf. That's the part worth looking at.

The technology keeps changing. The shape of the problem doesn't. Something ends up trusted with more reach than anyone meant to give it, and the layer above assumed the layer below was checking. That was true of service accounts and cron jobs long before anything had a model attached to it.

That's why I don't stop at the application. The same bug can be nothing or a real problem, depending on what the account behind it is allowed to touch.

Start a conversation

Tell me what you're running and what keeps you up about it. I read everything that comes through here and reply myself. No email sequences, no SDR, no calendar wall. Just me.