Checked, Dated, Stuck On: A Maintenance Tag for Every Dependency

There is a kettle in our office kitchen with a sticker on its base. It says the appliance was inspected in March, tested by someone called D. Okafor, and is next due in March of the following year. Nobody has ever stood up in a meeting to celebrate that sticker. And yet, if it vanished, someone would notice — because the sticker is the only reason anyone knows the kettle has been looked at at all.

Your dependency tree is a drawer full of kettles. Some are cheap and cheerful, some are wired directly into the mains, and a few have been sitting there since a project that no longer exists. Most teams treat the whole lot the same way: ignore it until an alert fires, then panic. Portable appliance testing offers a better pattern, and it isn't really about electricity.

What PAT testing actually does

A common misconception is that PAT testing proves an appliance is safe. It doesn't. It proves that a competent person looked at it on a given date, applied a defined set of checks, and recorded the outcome. The value is in the record and the rhythm, not the certificate.

That distinction maps almost perfectly onto dependency review. You cannot prove a package is free of vulnerabilities. You can prove that on the twelfth of May, someone read the changelog, checked who maintains it, looked at what it pulls in, and decided it was still acceptable. That's a very different — and much more achievable — claim.

So the first move is to stop chasing certainty and start producing evidence.

Sorting the drawer into three classes

The IET's guidance leans on risk-based intervals rather than a blanket annual test, and that's the bit worth stealing. Classify your third-party packages rather than treating them as a flat list. Three buckets is plenty:

Class A — the hard-wired stuff. Anything that handles authentication, parses untrusted input, touches payment flows, sits in the runtime path of a public service, or ships to the browser. Also anything with a post-install script, because that's a kettle with a live wire dangling out of it. Review these quarterly.

Class B — the working appliances. Build tooling, test helpers, formatting, anything in CI. They can't take down production directly, but a compromised build tool can sign a poisoned artefact, so they're not harmless. Review twice a year.

Class C — the desk lamp. Dev-only conveniences, type definitions, that one package that reads a config file and does nothing else. Annual visual inspection is fine. Some of these you could honestly just delete, and that's a valid review outcome too.

Two extra flags push anything up a class regardless of what it does: a single maintainer with no recent releases, and a dependency count that would embarrass a monorepo. Both are cheap signals and both are worth acting on.

Put the sticker in the repository

The sticker is the whole trick. It makes the invisible visible and it stops the next person re-doing the work. Put it somewhere the team already looks — a plain YAML file beside the manifest, reviewed in the same pull request as any version bump.

# deps-review.yml
- name: left-pad-alternative
  class: B
  reviewed: 2026-05-12
  next_due: 2026-11-12
  reviewer: d.okafor
  notes: maintainer active, 3 transitive deps, licence MIT

Three things fall out of this almost for free. First, the file becomes a diffable history — you can see when a package was last touched by a human rather than a bot. Second, it gives new starters a map of which dependencies the team actually worries about. Third, and most usefully, a short CI check can fail the build if next_due is in the past and the package is Class A. That is a warning light, not a gate — let it announce itself, don't let it block a hotfix.

Keep the file next to the code, not in a wiki. Wikis go stale the moment someone leaves, and nothing in a wiki ever fails a build.

Stagger the dates, or you'll do it all in January

The classic failure mode of any periodic review is synchronisation. Everything gets flagged at once, the team spends a miserable fortnight on it, then ignores the whole thing for eleven months because the memory is still painful.

So don't set intervals, set dates. When you review a package, pick next_due so that roughly a twelfth of your Class A list falls due each month, and spread the rest. If you're onboarding an existing tree, hold a single triage session — an afternoon with the manifest open and a shared document — purely to assign classes and staggered dates. Don't review anything that day. Just label and schedule. The reviewing comes later, in small, survivable doses.

Twenty minutes, not a day

What does a review actually involve? Less than people fear. Read the release notes since your pinned version. Check the repository is alive — commits, issues being answered, a maintainer who hasn't gone quiet. Look at what the version adds to your dependency count. Check the licence hasn't shifted. Skim the diff of anything with a post-install hook. Write two lines of notes and a date.

That's it. If it takes longer than half an hour, either the package is doing something genuinely alarming or you're doing an audit rather than a check. Both are fine; neither should be the default.

Some stickers come off

The underrated outcome of any inspection regime is condemnation. A PAT tester who finds a frayed cable doesn't write "monitor" — they cut the plug off. Give yourself the same permission. If a package is unmaintained, two versions behind a fix, and replaceable with forty lines of your own code, the correct note in deps-review.yml is not a new due date. It's a removal ticket.

A surprising number of dependencies survive on inertia alone. A review cadence that expects some removals every quarter keeps the tree honest in a way that a vulnerability scanner never will, because the scanner can only ever see known problems. It can't see that nobody has understood a package since 2021.

The sticker isn't the point

Nobody loves compliance theatre, and it's worth being clear that a filled-in YAML file is not security. A team could tick every box and learn nothing. But the reverse is also true: a team doing genuinely careful dependency work with no record of it is one resignation away from starting over.

The humble kettle sticker works because it's cheap, visible, and dates things. Do the same for your packages and the annual panic quietly turns into a Tuesday afternoon with a cup of tea. Which, appropriately enough, brings us back to the kettle.