Vendor Breach Watch

Built with: GitHub Actions · Node.js · GitHub Issues · YAML watchlist

The problem

Third-party incident response starts with knowing, and knowing usually means someone happens to see a headline. Teams already have a vendor list, and the internet already has breach feeds. Below the budget line for a threat-intel platform, nobody connects the two.

Who it's for

The GRC or third-party risk owner at a small or mid-sized company who maintains the supplier register and gets the "were we affected?" question from leadership when a big SaaS vendor shows up in the news.

How it works

• The watchlist is configuration: vendor names, domains, and aliases in a YAML file.
• A scheduled GitHub Action sweeps public, keyless breach and incident sources twice a day and matches them against the watchlist.
• Matching is deliberately conservative: alias handling plus a suppression list, because a noisy alert channel gets muted within a month.
• On a match it opens one GitHub issue per incident, deduplicated across runs, with source links and a next-step checklist. Issues are the alert channel, so there is no new tool to adopt.
• The real deployment runs in a private repository, because a supplier list is itself sensitive: it maps your attack surface. The public demo runs the same matcher over a list of widely used SaaS vendors.

Try it

Open the Vendor Watch tab on the Security Feeds page to see the matcher running over the public demo watchlist.

The 30-second pitch

"When a vendor gets breached, the first question from your exec team is whether you use them. This answers that before anyone asks: your supplier list, checked against breach news twice a day, with a ticket and a checklist waiting when there's a hit."

What I'd ask in a first call:

1. Where does your supplier register live today, and how current is it?
2. The last time a vendor of yours was breached, how did you find out, and how long did that take?
3. Who owns the response, and what do they do in the first hour?

Trade-offs and limits

• It tells you a vendor is in the news, not whether your data was affected. The issue starts the human assessment; it does not replace it.
• Public sources only, so no dark-web monitoring and no paid intel feeds.
• Name collisions are the main false-positive risk (a vendor called "Apollo" will match a lot of things). The suppression list handles that, and it needs an owner.
• An early-warning layer based on canary credentials is designed but deliberately not built yet.