Why Vendor Security Advisory Subscriptions Matter
Vendors often warn contract customers before the public. Why your vendor security advisory subscriptions need an owner, and how to close the gaps.
Vendor security advisory subscriptions matter because many vendors tell contract customers about a flaw before they tell the public. EG Secure Solutions notified SiteGuard Server Edition customers with direct support contracts on 29 September 2026, and published the exploited SiteGuard CVE-2026-106931 on 14 October. Teams that were not on that list lost two weeks. The fix is to make sure every product you run has a named owner who receives its vendor security advisory.
What is a vendor security advisory?
A vendor security advisory is the vendor's own notice of a vulnerability in its product, with affected versions, fixed versions, workarounds and sometimes indicators of compromise. It is the primary source; CVE records, CERT alerts and news coverage are built from it.
Advisories arrive through different channels: a public web page, an RSS feed, a mailing list, a customer portal or a direct email to contracted customers. The last two are the ones teams most often miss.
Why do vendors notify some customers first?
Vendors notify contract customers early to give them time to patch before attackers learn details from a public advisory. It is a common part of coordinated disclosure, and it is reasonable when a flaw is not yet exploited.
The problem is who is left out. Customers who bought through a reseller, who let support lapse, or whose contract contact left the company do not get the early notice. When the flaw is already being exploited, as with SiteGuard, those customers are exposed for the whole private window without knowing it.
Where do advisory gaps usually come from?
Most gaps are ordinary administrative drift, not missing tools.
- The contact is a person, not a role. The advisory email goes to whoever signed the contract three years ago.
- Purchases went through a reseller. The vendor's customer record lists the reseller, and the reseller does not forward security notices.
- Products nobody thinks of as products. Web server modules, WAF agents, backup plugins and firmware are installed once and forgotten.
- Language and region. Regional vendors may publish first in their home language. The SiteGuard alert was published in Japanese; the English JVN entry appeared the same day, but not every vendor has an English channel.
- Expired support. Some vendors only email customers under active maintenance, even when they ship patches for end-of-life versions, as EG Secure Solutions did.
How do you close the gap?
Treat advisory intake as a control with an owner, not a side effect of buying software.
- Build the list from your inventory. For every product, record the vendor, the edition, who owns it and where its advisories are published. Include software that runs inside other software, such as a host-based WAF.
- Use role addresses. Register a shared mailbox or ticketing address with each vendor portal, so advisories survive staff changes.
- Check reseller purchases. Ask each reseller whether the vendor sends security notices to you or to them, and get your own address registered.
- Add the national CERT feeds. JPCERT/CC and JVN, CERT-FR, BSI and others publish alerts that cover regional vendors. CISA's KEV catalog tells you which flaws are confirmed exploited.
- Test the channel. Once a year, pick three vendors and confirm you received their last advisory. If not, find out why.
Who should own vendor advisories?
The team that patches the product should own its advisory subscription, with security operations watching a combined feed as a backstop. Splitting it that way means the people who can act receive the notice directly, and a second team catches anything that slips.
Record the owner next to the product in your asset inventory. If an advisory arrives and no one owns the product, that is a finding in its own right.
What to do when you learn about a flaw late
If you discover a flaw only at public disclosure and the vendor says contract customers were told earlier, assume the private window was part of your exposure. Start any hunt from the date of the private notice, not the public one. For SiteGuard that means looking back to at least 29 September.
Before patching an exploited product, follow the order in how to preserve evidence before patching a server so the update does not erase what you need to find out whether you were hit. Then fix the subscription so the next advisory reaches you on day one.