Artisan Build logo
Start a project

There's No Such Thing as Stable

Ed Grosvenor

Needy apps that throw exceptions and crash from time to time might be less dangerous than the ones that never cause you headaches.

There's No Such Thing as Stable

If you've been doing this work for long enough, you have some applications that you've deployed and completely forgotten about because they just work. You're not getting exception or downtime notifications on them. They just sit there quietly crunching away at whatever task you've given them for weeks, months, or even years without any intervention or attention from you. This should be the dream, but it can set you up for disaster.

I got a call recently from a client whose email address had suddenly started sending tens of thousands of phishing emails. I tracked it down to an application that had last been deployed almost four years ago. Since that deployment, it was running so well that nobody ever thought to check on it. But over that time, several critical vulnerabilities had been identified in both the application's dependencies and the server software. Those were never patched because the client took the (at the time fairly reasonable) approach of mitigating vulnerabilities as part of every-day work on their applications. But this app didn't get any every-day work. It was stable.

We used to accidentally benefit from security through obscurity. If you deployed an app without doing anything to broadcast its existence (creating an SSL certificate, for example), it was pretty likely that nobody would ever bother to probe it for vulnerabilities. Insecure code could run happilly for years without anyone trying to break in. We don't live in that world anymore. If you have insecure code on an internet-accessible machine, it will eventually be found and exploited.

Mitigating these risks can be pretty straightforward, particularly for the kind of app that you're inclined to lose track of. You can schedule server software updates and reboots. You can turn on Dependabot and simply auto-merge its PRs. But it's kind of hard to recognize when a project is evolving from something that you actively manage to something that's just on autopilot until the end of time. You can't really know when you push up a commit that it'll be the last time the application will ask for your attention.

This incident prompted me to build OurCVEs.com, and I deployed it across the client's fleet this morning. The results were eye-opening. Even with their "we keep things up to date whenever we have to touch anything" approach, every server in their fleet and all but one GitHub repository had at least one critical vulnerability identified. I installed the OurCVEs MCP server in Claude Desktop and after about 30 minutes of chatting about downtime tolerance and who at the company is responsible for what, we had a mitigation plan and a couple dozen PRs shipped and assigned. By tomorrow morning, they'll be on a good footing.

If your team is focused full-time on shipping and just trying to keep one eye on security, OurCVEs might be a good addition. It collects a manifest of all the software running on your servers and all dependencies in your applicatons and constantly matches them against known vulnerabilities. It's AI-first, exposing an MCP server that you can use to ask your agent "where am I vulnerable and what should I do about it?" We built it so that staying on top of application and server security can be something we do for a few minutes every day rather than something that's waiting to knock us off track at the worst possible moment.

Let’s talk

Tell us about your product, timeline, and what success looks like. We’ll reply with a concise plan of attack.

  • Calm, predictable cadence
  • Accessible, testable components
  • Transparent reporting & demos

Ready to start the conversation?

You can book a quick intro call or send us an email. No pressure, no forms — just a friendly hello.