Vulnerability Management Without a Security Team

A flaw scoring the maximum 10.0 was published on September 9 against Google's Agent Development Kit for Python, allowing remote code execution with no authentication on exposed instances. If your reaction is that you have no idea whether anything in your business uses that, you have identified the actual problem, and it is not the flaw.

The four steps

1. Know what you run. A written list of software that touches customer data or faces the internet. Your website and what it is built on, your booking or e-commerce platform, anything a contractor built, anything self-hosted, and the integrations wired between them.

2. Hear about problems. Automatic updates for everything that can take them safely. Security or release notifications for the handful of things you host yourself. A named contractor obliged to tell you about the rest.

3. Decide what matters. Sorting by your exposure rather than by the published severity, which is the step where most advice goes wrong.

4. Fix and confirm. Apply it, then check the version number changed. Plenty of updates fail quietly, particularly on servers nobody logs into.

Step one is the one almost nobody has. Without a list, every advisory is a research project and after three of those you stop reading them.

What a severity score does and does not tell you

CVSS rates a vulnerability from 0 to 10 on how bad it is in the worst realistic case. The Google toolkit flaw published this week scored 10.0 because it needs no authentication, no user interaction, and gives an attacker full control of the host.

The score describes the flaw, not your risk. A 10.0 in something you do not run is a zero for you. A 6.5 in the booking system your customers log into every day may deserve more of your Tuesday than a 9.8 in an internal tool that lives on one laptop.

That last row is doing real work. A great deal of security anxiety in small businesses comes from reading headlines about flaws in software they have never installed, and a list lets you dismiss those in ten seconds instead of an afternoon.

Trying to patch everything is the failure mode

Advice aimed at enterprises assumes a team, a maintenance window and a test environment. A ten-person company has an owner who also does payroll. Treating every advisory as urgent burns that person out inside a month, after which nothing gets read at all, which is worse than a triage rule that occasionally defers something.

Patching also has a real cost beyond time, since updates break things and rollbacks are expensive when nobody tested first. We went into the tension between speed and safety in patch management, fast but not instant. The compromise most small businesses land on is automatic updates for low-risk software, a monthly window for the rest, and an exception path for anything internet-facing and unauthenticated.

The AI layer nobody has on the list

Two years ago your software inventory was your website, your accounting package and Microsoft 365. Now it may include an agent framework a developer installed, a handful of AI tools staff signed up for individually, and an assistant connected to your CRM by a contractor who has since moved on.

Those components are new, they are moving quickly, and they are exactly where flaws are being found right now. They are also the least likely to appear on any list, because nobody procured them through a process. The tooling side of this is covered in free AI tools and what they cost your business, and the supply-chain side in malicious AI skills.

Add one column to your inventory for who installed it and one for who would patch it. The blanks in those two columns are your actual exposure, and they take an afternoon to find.

Three questions for anyone who builds for you

Most small businesses have software written or hosted by somebody else, and the arrangement usually covers features rather than maintenance. Ask at the start of an engagement, in writing:

What does this depend on? A list of frameworks and libraries, so an advisory naming one of them means something to you.

How will you tell us when one of them has a serious flaw? By what channel, within what timeframe, and does it still apply after the project ends.

Who applies the fix, and is it billable? The answer is often nobody, and finding that out during an incident is expensive. The related conversation after something goes wrong is in what to ask an AI vendor after an incident.

Start this week

Open a spreadsheet. One row per piece of software that touches customer data or the internet. Columns for what it is, who installed it, whether it updates automatically, and who would fix it. Most businesses fill this in under an hour and find two or three rows where the last two columns are empty.

Those rows are the work. Everything else in vulnerability management is process around them, and the specific flaw that prompted this post matters far less than knowing whether it applies to you at all. If you want to see how that one worked, we broke it down in the perfect-10 flaw in Google's agent toolkit.

Frequently Asked Questions