Vendor security advisory feeds: 16 verified RSS and Atom addresses

Microsoft’s security update feed held 4,912 entries on 19/08/2026 — 3,913 distinct CVE numbers, the oldest dated 20/05/2026. That is one subscription. A mid-sized estate needs roughly twenty-five of them, and the addresses have to be collected one at a time. Here they are, grouped by what you actually operate, every one of them fetched and counted on the same day.

How this list was checked

Every address was requested once on 19/08/2026, and four things were written down per entry: the source with its address, the feed format, how much the document held at that moment, and the date of the check. Anything that did not answer with XML is not in the tables.

The check date sits in every single row on purpose — feed addresses do not last, and a row without a date is a claim without a shelf life. The volume column is not a quality rating either. It says how far back a feed reaches, and therefore how long your reader may be down before something passes you by.

Operating systems and browsers

The Ubuntu row is the important one. Ten entries, and on the day of the check they covered 17 to 18 August — under two days. A reader that runs once a week sees a fraction of what Ubuntu published. Microsoft is the opposite problem: one entry per CVE, revisions included, 1,233 of them carrying a date from the preceding 31 days. Subscribe unfiltered and you take over a thousand items a month, most of them about products you do not run.

SUSE is the gap in this class. Its security pages point only at the general SUSE news feed; a security-specific address was not discoverable in the delivered HTML on the day.

The perimeter: firewall, VPN, router

Fortinet calls its file ir.xmland titles the channel “IR Advisories”, which reads like incident response. The channel description says what it actually is: issues resolved in Fortinet products, coordinated by the Fortinet PSIRT. The name misleads, the contents do not.

Storage, servers and applications in house

Two rows deserve a second look. Synology’s feed reaches back to November 2013 — 439 entries, an archive you can search rather than a window you have to catch. QNAP held twenty entries whose newest was dated 17/06/2026, two months before the check. Whether two quiet months mean nothing happened or the feed stopped being filled cannot be decided from outside, and that ambiguity is itself the argument for a check date next to every address.

Proxmox and Veeam have no security-specific feed at all: Proxmox announces in its announcements forum, Veeam in its knowledge base, so both feeds carry everything else as well. Workable, but the filtering moves to your side.

Open source without an advisory feed

Many projects publish advisories on GitHub and nowhere else, and GitHub’s Atom address for advisories answers HTTP 406 without a session — checked on 19/08/2026. What works for everyone is the release feed: append /releases.atom to a repository URL, as with nextcloud/server or zabbix/zabbix, both holding ten entries on the day. Be clear about what that is: a release feed, not an advisory feed. It tells you a version exists, not which flaw it closes. For Mozilla and OpenSSL no feed address was discoverable in the delivered HTML of their advisory pages at all.

Aggregators — two of them in German

The CERT-Bund feed is the only one here that puts the severity into the title itself — entries read like [NEU] [hoch] Oracle MySQL: Mehrere Schwachstellen, in German. It is also the loudest: of its 250 entries, 118 carried the date of 17 August and 113 that of 18 August, the remainder the day of the check. That is a good hundred notices on an ordinary day, across every vendor there is.

An aggregator does not replace the vendor feed. It arrives later, it is coarser, and it decides for you what counts as news. It does replace fifteen feeds from vendors you only touch at the edges — which is exactly the trade you want for those.

Three ways a feed subscription dies

One: the address is gone. HTTP 404, your reader shows an error, you notice. This is the harmless case.

Two: the address answers, but with a web page.The vendor rebuilds the site, the old feed path now serves the new advisory page, and the server returns HTTP 200. Most readers read that as “no new items” and stay quiet, so the subscription looks alive and delivers nothing. Synology’s older security path does exactly this on 19/08/2026 — 200, and HTML. Two commands tell the cases apart, and what you check is the content type, not the status code:

curl -sL -o /dev/null -w '%{http_code} %{content_type}\n' \
  https://ubuntu.com/security/notices/rss.xml
200 text/xml; charset=utf-8

curl -sL -o /dev/null -w '%{http_code} %{content_type}\n' \
  https://www.synology.com/en-global/support/security/rss
200 text/html; charset=UTF-8

Do not look for application/rss+xml specifically — Ubuntu serves text/xml, Debian application/rss+xml, GitLab application/xml. The rule that holds is: it must say xml, and it must not say html.

Three: the feed is fine but shorter than your polling gap. Elastic publishes its security announcements through a forum category feed. On 19/08/2026 it held 25 entries and all 25 carried the same date, 13/08/2026 — a single publication day had filled the entire feed. Feeds like that are a shop window, not an archive: miss the day and the entries are simply not there any more.

Which is why a quarterly re-check is not bookkeeping but the actual work: once a quarter, run the two commands above against every address you subscribe to and hold the newest timestamp against your own memory of what shipped.

The arithmetic: about twenty-five subscriptions

Count what a fairly ordinary estate needs, one line per class:

• Operating system, one Linux distribution, one browser — 3
• Firewall, VPN gateway, switch or router — 2 to 3
• Hypervisor and backup — 2
• Network storage — 1 to 2
• Mail, directory, database — 3
• Server applications: git, CI, monitoring, wiki, reverse proxy, ticketing — 6
• Desktop software with no channel of its own: PDF, archiver, remote support, second browser — 4
• Aggregators — 2 to 3

That lands between 23 and 26 depending on how you count, so: about twenty-five. This is arithmetic, not a measurement — your estate will differ. What does not differ is the second number behind it. Twenty-five addresses times four checks a year is a hundred verifications, and every one of them is the kind of task that quietly stops happening.

Twenty-five feeds to maintain, or one email

Both are costs, not convictions. Twenty-five feeds in a reader cost a morning to set up and four rounds of re-checking a year; in exchange you get the vendor’s own wording, unfiltered, with nobody in between. The other route costs ticking boxes: patchletter watches version states and emails you when a new one appears — on the FortiOS product page, for instance. If you would rather stay in your reader, every product page carries the same state as its own feed at /en/software/<product>/feed.xml, linked for autodiscovery, so that route stays open too.

The difference is worth naming plainly: a vendor advisory feed reports the flaw, patchletter reports the version that closes it. One does not replace the other. What the second answers is the question that comes first on a Monday morning — is there something to touch here or not. What is demonstrably being exploited sits on the CVE page, what is running out of support on the end-of-life page.

The honest limitation

This list is the snapshot of one day. Several of the addresses in it were found only after an older, widely circulated one had stopped working, and there is no reason to think that stops. Treat every row as valid up to its check date and no further.

Gaps remain that I could not close. Red Hat, Broadcom (VMware) and Citrix deliver their advisory overviews through JavaScript; the HTML that comes off the wire carries no feed address. Sophos was not reachable from the checking machine at all. In none of those cases does that mean no feed exists — it means I could not produce one, and a list that invents its missing rows is worse than a list with holes in it. The volume column, likewise, measures the day and not the vendor: a feed with twenty entries is not worse than one with four hundred, it is shorter, and that matters only in relation to how often you actually look.

All feed figures from our own retrieval on 19/08/2026: each address requested once, then HTTP status, content type, number of item or entry elements and the oldest and newest timestamp in the document recorded. Feed addresses and their contents change; the check date in each row is the only guarantee this text gives.