Building an Intake Process for Vendor Security Advisories

An intake process for vendor security advisories is a repeatable way to collect advisories from a defined set of sources, check them against what you actually run, decide how urgent each one is, give it an owner and track it until it's closed. You need one because your vulnerability scanner can't see everything. Appliances, firmware and SaaS services often never show up in scan results, and even for systems a scanner covers, the vendor's advisory usually arrives before the scanner has a check for it.

This post covers where to get advisories, how to triage them and how to make sure none of them get lost.

Why do you need a formal intake process?

Without a process, advisories land wherever they happen to land. One administrator subscribes to a vendor mailing list, another follows a news site, and a third finds out when a colleague mentions it. Coverage depends on who's paying attention that week.

A defined process fixes three problems:

• Coverage. Every product you run has a known source for its advisories.
• Consistency. Every advisory gets the same triage questions, whoever reads it.
• Accountability. Every relevant advisory has an owner and a recorded outcome.

It also fills the space between disclosure and detection. Scanner vendors need time to write checks, and some products never get them. Your intake process is how you act in the meantime.

Where should you get vendor security advisories?

Most organizations need a handful of source types. The goal is to cover every product in your inventory without drowning in duplicates.

Vendor advisories come first

For any given product, the vendor's own advisory is the primary source. It tells you which versions are affected, which versions fix the problem and whether a workaround exists. Aggregators and databases are useful for coverage, but always go back to the vendor for the details you act on.

Many vendors let you subscribe by product. Some only publish inside a support portal that requires a login, so check each vendor rather than assuming a public page exists.

CISA and NVD fill the gaps

CISA's Current Activity posts and Alerts flag issues that need wider attention, often with links to the relevant vendor advisories. The weekly bulletins summarize newly recorded vulnerabilities, which makes them a useful cross-check against your own list.

The National Vulnerability Database, run by NIST, adds CVSS scores and CPE product names to CVE entries. Those names are what make automated matching against an inventory possible. NVD analysis can lag behind publication, though, so don't wait for it before acting on a vendor advisory.

Machine-readable advisories

Some vendors publish advisories in the Common Vulnerability Reporting Framework (CVRF), an XML format maintained by the standards body OASIS. CVRF version 1.2 became a committee specification in September 2017. It describes products, vulnerabilities and remediation status in a structured way, so advisories can be parsed automatically instead of read by hand.

Adoption isn't universal. Treat CVRF as a useful input where it exists, not as something you can build your whole process on.

Keep the source list short and owned

Write down your sources and review the list every quarter. For each product in your inventory, record where its advisories come from. If you can't name a source for a product, you've found a blind spot.

Route everything to a shared mailbox or channel, not a personal inbox. Advisories shouldn't stop arriving because someone is on leave.

How do you match advisories to your inventory?

An advisory only matters if it affects something you run. Matching requires an inventory that records, at minimum, the vendor, product, version, where it's deployed and who owns it.

For each advisory, answer four questions:

1. Do we run this product? If not, log the advisory as not applicable and close it.
2. Do we run an affected version? Check against the vendor's list of affected and fixed versions.
3. Is the vulnerable component or feature in use? Many advisories only apply to specific configurations or optional modules.
4. Where is it deployed? Note which instances are internet-facing and which support critical services.

Product naming is the hardest part to automate. Vendors, scanners and inventory tools often use different names for the same product. CPE names from NVD help, but expect to keep a manual mapping for products whose names don't line up.

Record "not affected" decisions along with the reason. When someone asks months later whether you checked, you'll have the answer.

How should you triage vendor advisories?

Triage turns a matched advisory into a priority and a deadline. Use the same criteria every time:

• Exposure. Is the affected system reachable from the internet, or only internally?
• Severity. What rating does the vendor give, and what's the CVSS base score?
• Exploitation. Does the vendor or CISA report active exploitation, or is exploit code publicly available?
• Asset importance. Does the system support a critical service or hold sensitive data?
• Fix availability. Is there a patch, a workaround or neither yet?

A simple priority scheme is enough for most organizations:

Align the targets with the remediation deadlines you already use for scanner findings. Advisories and scan results should feed the same queue, with the same clocks.

Who should own each advisory?

There are two different jobs here, and it helps to separate them.

The intake owner reads incoming advisories, matches them to the inventory and assigns a priority. In a small team, this is often a rotating duty, reviewed daily. Name a backup so the duty never lapses.

The remediation owner is the person or team responsible for the affected system. They apply the patch or workaround, or make the case for accepting the risk. Every triaged advisory should have one named remediation owner, even when several teams are involved.

If you can't find a remediation owner for an affected product, escalate that as its own problem. An orphaned system will keep generating orphaned advisories.

How do you track advisories to closure?

Open a ticket for every advisory that affects you. A useful ticket records:

• Advisory identifier and link, plus any CVE IDs
• Affected products, versions and specific assets
• Priority and due date
• Remediation owner
• Chosen action: patch, workaround, or risk acceptance
• Evidence of closure

Define what "closed" means before you need it. Reasonable closure states are: fixed and verified, workaround applied and verified, not affected (with the reason), or risk accepted with an approver and an expiry date.

Vendors revise advisories, too. They add affected versions, publish new fixed releases or change workaround guidance. Watch for revisions to advisories you've already closed, and reopen the ticket when a change affects your decision.

What about products your scanner doesn't cover?

This is where an intake process earns its keep. Several kinds of products rarely appear in scan results, or appear with too little detail to act on.

Network and security appliances

Firewalls, VPN gateways, load balancers and storage arrays run vendor firmware that many scanners can only fingerprint roughly. Keep their exact firmware versions in your inventory, pulled from the management console or configuration backups, and check each advisory against them directly.

Firmware

Server management controllers, system firmware, printers and other networked devices all receive security updates. These are easy to forget because they don't update with the operating system. Add them to your inventory with a version field and a named owner.

SaaS and hosted services

With software as a service, the provider applies the fix. Your job is to read their security notices and act on anything they ask of you. That might mean updating a desktop client, changing a setting, reviewing an integration or rotating credentials used by a connector.

Log these notices like any other advisory. The ticket closes when you've confirmed that nothing is required from you, or that you've done what was required.

Keep a separate watch list

For every product in these categories, keep a list with its current version, the advisory source and the owner. Review the versions on a schedule, such as monthly, because nothing will flag drift for you automatically.

Frequently asked questions

How many advisory sources should we monitor?

As few as give you full coverage. Start with the vendors of every product in your inventory, then add CISA and NVD as cross-checks. If two sources always carry the same information, drop one.

Who should run advisory intake in a small IT team?

Anyone who understands your environment well enough to match an advisory to a system. A daily rotation among two or three people works well. What matters is that the duty is named, scheduled and has a backup.

What should we do when there's an advisory but no patch yet?

Apply the vendor's workaround or mitigation if there is one, and record it in the ticket. Keep the ticket open until a fix is released, then schedule the patch. If there's no workaround, reduce exposure where you can, for example by restricting access to the affected service.

Do we still need an intake process if our scanner updates its checks daily?

Yes. Scanner checks follow advisories, often by days, and some products never get checks at all. An intake process covers that lag and the products your scanner can't see.

Next steps

1. List every product you run and write down its advisory source.
2. Subscribe a shared mailbox or channel to those sources, plus CISA's alerts and bulletins.
3. Name an intake owner and a backup, with a daily review.
4. Adopt a short set of triage criteria and priority levels that match your existing remediation deadlines.
5. Ticket every advisory that affects you, with a named remediation owner and defined closure states.
6. Build a watch list for appliances, firmware and SaaS, and check versions monthly.