Vulnerability Management in the Era of Personal Software

I build a fair bit of my own software now. A couple of open-source security tools, an app or two, some as vibe-coded side projects like TripSplit, and most of the infrastructure I use to deploy them. I’ve tried my best to build all of it securely and for the last few years I managed to keep it secure as well myself. That part was never the problem.

My approach is manual (ikr). Every two or three weeks I look at the libraries my projects depend on and check whether any of them have any recent patches, and update them. It is a little boring, and it works. But it works because I have not built that much. A handful of projects over a few years is a small enough pile that one person can hold it in their head.

Building your own software

This is the part that has started to bother me. I am not someone who builds a lot. I am careful, I know what to look for, and I can still feel the edges of what I am able to keep up with. So what happens to the people who build far more than I do, and who do not do this for a living?

Because that is who is building now, and it is not only senior, security-aware developers. Over the last couple of years it has become normal for almost anyone to build software for themselves: a small web app to solve one annoyance, a tool to tie two services together, a script that grew into something they now rely on every day, a simple web dashboard to monitor a water meter at home. This is a good thing. Software that fits one person’s life exactly is worth more to that person than anything general ever was. I welcome this change and I do more of it every year.

But almost nobody goes back to see if what they built is still secure. Why would you change an app that has worked perfectly since the day you made it? You change software when you want a new feature, or when someone tells you it is broken. A quiet vulnerability does neither. It does not ask for anything. It just sits there, in something you finished and stopped thinking about months ago.

The vendor’s hidden work

When you used to buy software, a company carried a pile of work you never saw. They wrote it with some idea of security in mind. They tested it, at least a little. And across the whole life of the product, somebody on their side was meant to be looking for new weaknesses, looking at its impact and making sure that it gets fixed before anyone else finds it. That last job has a name - Vulnerability Management, and it is part of security: the slow, unending business of knowing what you have, knowing what is wrong with it today that was fine yesterday, and dealing with it.

Security decays

When you build your own software, you keep the features and quietly drop all of Vulnerability Management. Securing it once is the easy half, and it is getting easier every month. You can ask an AI to help you write it securely, check your configuration, point out the obvious mistakes, and at the moment you build it will do a decent job. But security is not a state you reach and then keep. It comes apart slowly. The libraries underneath you grow new holes. The configuration that was secure drifts. The access you opened to test one thing stays open. The secret key you pasted in to get it working is still sitting there a year later. And the app you stopped thinking about six months ago is still running, still connected to your accounts, still reachable by anyone who looks.

None of this is being checked, because checking is a job, and a job needs someone with the time to do it and the knowledge to suspect what might be wrong.

The next attack surface

There is a version of this I would only talk about with another security peer over a coffee. A lot of the new attack surface everyone keeps talking about - the idea that AI and vibe coding will keep us employed because they open new holes - a big chunk of it is going to come from personal software. From the millions of small things people are now building and quietly running for themselves.

What that really means is that a lot of people are about to be pulled to the front of a fight they were mostly shielded from. When your software came from a company, you had some protection - not always because the company was good at security, but because it was regulated. There were rules about how your data could be handled, people who could be held responsible, a standard it had to at least pretend to meet. Personal software has none of that. It is you, your code, and whatever you did or did not know to do.

You could argue the opposite, and I have. Maybe this makes people safer. Your data is no longer sitting in one company’s database waiting to be taken all at once; it is spread across your own small things, a far less interesting target. That is a fair point. But it runs into a simple question: how many people do you know, personally, who could keep their own software secure over years? I can count mine on one hand, and most of them do this for a living. Of course, I am not defending the companies. They can be just as careless. The difference is that someone is at least watching them.

What to do

So what do you actually do about it? If you built the software yourself, you already have some idea of how code and deployment work, so this is not about turning you into a security engineer. It is a few habits that fit someone who builds in their spare time. The aim is simple: have less to look after, and let a machine watch the rest.

Start with a list. One file or note you will actually keep, with every project you have built, what each one can touch (your data, your money, your accounts), and where it runs (your laptop, a server, the internet). You cannot look after something you have forgotten you deployed.

Cut down what is reachable. Most bad outcomes begin with something being on the internet that never needed to be. Keep a thing on a local network, or behind a VPN or Tailscale, if only you use it. When it does need to be public, put real authentication in front of it, give every API key and database user the narrowest scope that still works, and keep secrets in environment variables or a secrets manager, never hard-coded or committed to the repo.

Let a machine do the watching. Turn on Dependabot or Renovate so you get a pull request the day a dependency has a known problem. Add a scheduled job - a GitHub Action on a cron is enough - that runs npm audit, pip-audit, or osv-scanner against your projects, plus a secret scanner like gitleaks to catch a key you pasted in by mistake. This is the one part of the professional workflows that shrinks to a single person, and once it is set up it runs without you.

Kill what you no longer use. Every few months, go down your list and ask whether each thing still earns its place. If it does not, take it offline and revoke its keys and tokens. An app you abandoned but left running, still holding live credentials, is the quietest risk you own.

And keep one idea in your head: secure on the day you built it is a snapshot, and snapshots go out of date.

The upkeep is yours

None of this turns you into a security team, and it is not meant to. Building your own software is one of the better things the last few years have opened up, and I would rather more people did it, not fewer. But the vendor used to do the unglamorous part quietly in the background, and now there is no vendor. There is just you. The least worth doing is knowing the job exists, and doing the small part of it that fits the life you actually have. Most people do not know it exists yet.

This is something I find myself thinking about more each day, and I do not pretend to have the full answer. If you have ideas, tools, frameworks, or skills that could help ordinary people keep their own software secure over time, I would genuinely like to hear them. I will keep thinking about it…