Earlier this week, PHP2Shell was all over my X feed. Two critical vulnerabilities in PHP, exploits circulating, everyone scrambling to patch.
Then came Node2Shell, a vulnerability in Node.js's Brotli decoder. Soon people were calling it HTTP2Shell as the discussion expanded to other software using Brotli.
I was in the middle of building Heywolf, a personal money agent, and had one question:
Does any of this affect us?
I didn't know.
So I did what I'd usually do. Copy the advisory into Claude Code, ask it to check our dependencies and configs, paste in another link, ask it to double-check something, and go back and forth until I felt reasonably confident we were fine.
Sometimes I'd hear about an issue from another CTO. Sometimes from X. Sometimes I'd find out days later.
Claude Code was actually pretty useful for investigating these things. But I was still the one who had to discover the threat, start the investigation, feed it the right context, and remember to do it all again next time.
What bothered me wasn't just the manual work. It was everything I never thought to ask about.
I wanted something that already knew our stack
I've spent the last few years building infrastructure and AI products. We've worked on observability, AI SRE, and now Heywolf.
And somehow I was still relying on my X feed and conversations with other founders to find out when something might be wrong with our infrastructure.
I didn't need another feed of vulnerabilities. There are already good ones.
And I didn't need another AI tool I had to remember to prompt.
I wanted something that already knew what we were running, followed security developments on its own, and told me when there was something worth investigating.
So I started building InfraStack for ourselves.
The idea was pretty simple: tell it your stack once, and let it keep checking new security threats against it.
It lives in Slack because that's where I wanted the answer. Not in another dashboard I had to remember to open.
The first scan
I started by giving InfraStack the files that describe our setup.
It checked the week's security events against those files and came back with a table.
Not just severity scores. Actual verdicts.
PHP2Shell was marked No based on the stack information available.
The Node/Brotli vulnerability, also called HTTP2Shell, was Likely. A Dockerfile referenced node:24-alpine, but that alone wasn't enough to establish the exact version running in production.
And an advisory about uv's bundled CA store, which trusts a compromised emSign root, came back Yes: our gateway's build stage pins uv 0.13.1.
The distinction mattered. A version pinned in a build file isn't proof that a running service is exploitable. But it gives you something concrete to check and a reason to prioritize it.
InfraStack's first scan of Heywolf. Verdicts reflect the evidence available from our stack files, not independently verified production exposure.
This was closer to what I'd wanted all along.
Instead of having to start a new Claude Code investigation every time I stumbled across another security issue, I had a short list of things to look at, with the evidence attached.
And I could ask questions about it right there in Slack.
It doesn't know everything. Yet.
There are some important limitations in this first version.
InfraStack can inspect the files and stack details you give it. It doesn't automatically know what version is running on your production servers. Our initial Heywolf scan used supplied files rather than a live runtime inspection.
Models help process and structure new threat information. Important findings get additional checks, but not every new assessment starts out independently verified.
That's why I'm trying to make the evidence visible. If something is inferred from a Dockerfile, it should say that. If it needs another piece of information, it should ask.
I'd rather have a useful Likely than a confident No that's wrong.
There's a lot still to improve, and I'm sure the first few teams will find things we've missed.
The best alert is sometimes no alert
I don't want InfraStack sending a message every time another CVE gets published.
That would be easy to build. It would also be incredibly annoying.
I want it to follow what's happening, check it against our setup, and leave us alone when there's nothing useful to say.
And when there is something relevant, I want to know why, what to check, and what to do next.
If I can't patch something this week, tell me whether there's a workaround. If a vendor has published a mitigation, tell me what it covers and what it doesn't.
And if the answer depends on something only our team knows, just ask.
That's the kind of security tool I wish we'd had while building Heywolf.
Opening it up to a few teams
InfraStack started as a tool for ourselves, but I'm curious whether other small engineering teams have the same problem.
Especially teams building with AI coding agents and MCP tools, where new attack techniques seem to arrive almost as quickly as the tools themselves.
I'm onboarding the first ten teams personally. Happy to jump on a call, help set up your stack, and work through the first scan together.
No infrastructure agents or code changes required. Your first scan is free.
If you'd like to try it, add InfraStack to Slack, or just reach out at [email protected].
I'd genuinely love to know what it gets right, what it gets wrong, and what would make you trust it enough to leave it watching your stack.
Aykut