Security Basics 06｜Where to read security advisories: you do not have to follow them, but you need to know who does

Every time the news reports another major vulnerability in some piece of software, you may feel a jolt: where does this sort of news actually come from? As the owner, am I supposed to tour the big technical sites every morning?

The answer is no. Following security advisories is the daily work of technical staff, not something a business owner should be carrying. That does not mean you can ignore it entirely. Having established your versions and your hosting responsibilities in Security Basics 01｜An advisory just landed: how do you know whether it affects you and the previous piece, this one — the sixth in the series — deals with the next critical move: you do not need to follow advisories yourself, but you do need to know who is following them for you, whether the places they look are the right ones, and whether this is genuinely happening at all.

Why an owner reading the news does not help

By the time you see a vulnerability trending in general business news or a social post, it may have been public for several days. Worse, second-hand coverage chasing attention tends to inflate the severity while dropping the conditions that actually decide the matter — which versions are affected, whether a patched release exists, and what configuration has to be in place for it to trigger.

The UK's National Cyber Security Centre (NCSC) is explicit about this in its 10 Steps to Cyber Security: Vulnerability management guidance: every system should have a defined software update policy that sets out in advance how updates are done, when they are done, and who is responsible for carrying them out and checking them. And when assessing a vulnerability's severity and risk, you should look first at the vendor's own vulnerability advisory information, because that is the most accurate and most current first-hand source, then bring it back and compare it against your own environment.

In other words, following advisories has two conditions, and neither can be missing. First, whoever is reading must read the software vendor's or project's own first-hand advisory, rather than waiting for the news to pass it along. Second, they must have a technical inventory of your system in hand, so they know which languages, frameworks and external services you actually use — otherwise they can read all week and still miss the one thing you are running.

Where people who genuinely follow advisories are looking

You do not need to subscribe to any of this yourself, but it is worth knowing how a technical team that does this work actually reads. Take our own weekly round-up, Security Weekly 2026-W43: PHP, GitLab, and Eight Leaked Intermediate CA Keys: when we read security information we separate it strictly into two tiers, and "every item is labelled with which tier its source belongs to: [Official] is the vendor's or project's own advisory, [Research/Media] is what a security firm or a publication says, and it is ranked after the official source":

• Tier one is the vendor's and project's own official advisory: programming languages (PHP, Node.js, Go, Java), web frameworks (Laravel, Next.js), version control platforms (GitLab, GitHub), browsers and certificate authorities, and national cyber security centres. Only the patched version numbers and affected ranges written at this tier can be taken as fact and used directly to schedule an update.
• Tier two is reporting by security research firms and the media: they may be slightly ahead of the vendor, but the severity assessments and impact ranges inside are the researchers' own inferences, and they occasionally differ from what the vendor finally confirms. Where the two disagree, the vendor's advisory wins. You cannot leave something alone because a publication said it was fine, and you cannot frighten yourself with a headline alone either.

More importantly, this tracking list cannot be decided by mood — watching one thing today and skipping another tomorrow. Without a fixed list aimed at the technical foundation your company's system actually sits on, you miss the database this week and the certificates next week. From the outside everything looks calm; in reality you have no idea what you have missed.

How to confirm someone is watching for you, and it is not just a word

Ask an engineer or an outside supplier whether they keep an eye on security advisories and they will usually nod. But browsing technical forums now and then is a long way from regularly checking your particular system against the advisories. As Hosting, Monitoring, Security Updates: How Much Time DIY Really Costs worked out, quarterly package updates alone come to an hour checking versions, two to four hours running it through a test environment and another hour on production — and once you add the occasional emergency vulnerability, that eats several hours up to a full day of focused time.

If that time is not formally in a calendar or written into a maintenance contract, then whenever everyone is busy shipping features, reading advisories and applying updates will always be the first thing sacrificed. You can lay the three states side by side:

Three questions you can put to whoever runs your systems today

To confirm your system is in that third state, you do not need to understand a single technical term. You only need to put these three questions to the person managing your systems now:

• Who is responsible for reading the security advisories for the core languages and frameworks we use: establish first whether that is a specific named engineer or a supplier under a maintenance contract, rather than everyone assuming the other side is reading them.
• Do they have a list of the versions our system is currently running: if nobody has even written down which version is live, then an official advisory stating the patched release still cannot tell you whether you are affected.
• In the past quarter, which advisories applied to us, and what was done about them: this is the most concrete of the three. If someone really is reading them regularly, they will be able to tell you that a package published an advisory last month but you were already on a newer release so it did not affect you, or that they upgraded you to the patched version last week. If there has never been any report at all, then quite possibly nobody is doing this.

Nerd Technic is a systems software company that came out of custom development, and what we do now is the long-term maintenance of AI systems. We publish a weekly security round-up openly on our own site, and long-term maintenance is about having a fixed rhythm for security updates, with urgent vulnerabilities handled separately, so you do not have to watch the news every day to remind us. If you are not sure which technologies the system you have is built on, or whether anyone is watching the matching advisories for you, a system health check is a place to start: Book a system health check