Follow advisories for your own stack by combining three things: security alert watching on your key repositories, saved searches in an advisory database filtered by ecosystem and package, and registry feeds for the packages you care most about. Then read a short list, not the whole news cycle.
Why filter at all
Security news is a firehose. Most of it concerns software you do not run. Reading all of it feels responsible and mostly produces anxiety. A short, filtered list lets you spend your attention where an item can actually change your week.
The goal is not to miss the five items a quarter that matter, while ignoring the hundreds that do not.
Option 1: watch security alerts on your repositories
GitHub's notification documentation describes custom watch settings. For a single repository, you can choose to be notified only about certain event types: issues, pull requests, releases, security alerts or discussions. Choose security alerts for the repositories that matter most.
Two limits from the docs are worth knowing. You can watch at most 10,000 repositories. And notifications in the web inbox are kept for three months unless you save them, so copy anything you need into a ticket.
Option 2: search the advisory database by ecosystem and package
The GitHub Advisory Database is open for anyone to browse, and its search supports qualifiers. The documentation lists several that suit this job:
| Qualifier | Example use |
|---|---|
| ecosystem | ecosystem:npm limits results to npm packages |
| affects | affects:lodash limits results to one library |
| severity | severity:high filters by level |
| type | type:malware shows malware advisories |
| sort | sort:updated-desc shows recently changed records first |
Run a search such as ecosystem:npm type:malware sort:created-desc once a day, or whenever news breaks. The sort:updated-desc option is handy for catching edits to records you already read.
The docs also describe seeing which of your own repositories are affected by an advisory, through the Dependabot alerts link on the advisory page, if you have access to alerts for those repositories.
Option 3: use registry feeds for critical packages
PyPI documents RSS feeds, including a project releases feed with a URL of the form https://pypi.org/rss/project/PROJECT_NAME/releases.xml. Subscribing to the feed for a handful of critical Python dependencies means a new release shows up in your reader, which helps when a quiet package suddenly ships something.
A setup checklist
- List your top ten critical packages per ecosystem, from your inventory.
- Turn on security alert notifications for the repositories where they run.
- Save one advisory database search per ecosystem you use.
- Subscribe to release feeds for the packages where a bad release would hurt most.
- Pick one owner and one time of day to read the list.
- Write down where each item goes: ticket, chat channel or ignore.
Revisit the list quarterly. Stacks change and so should the filters.
A worked example
Take a small team that ships a web app on Node and a data job on Python. Their inventory shows about 400 direct and transitive packages, but ten matter most: the web framework, the authentication library, the database driver, the HTTP client, the build tool, plus a handful in Python for data access and scheduling.
They set up three simple things.
- Each of the two repositories is set to notify on security alerts only. No issue chatter, no release noise.
- Two saved advisory searches. One looks at npm advisories with the malware type, sorted newest first. The other filters npm and pip advisories affecting each of the ten named packages, sorted by recently updated.
- Release feeds for the four Python packages that matter most, delivered to a shared reader.
Every weekday at 09:30 one person spends ten minutes on the three sources. Most days the list is empty or irrelevant. Once in a while an item names one of the ten packages, and it goes straight to a ticket with a primary source link and a first check. The rest of the team reads one short note a week.
How to pick your critical list
Your critical packages are not the most popular ones. They are the ones where a bad release would hurt you most. Ask these questions about each direct dependency.
- Does it run during build or deploy, where it can read secrets?
- Does it handle authentication, sessions or cryptography?
- Does it sit on the path of user data?
- Is it hard to replace quickly?
A yes to any of these puts a package on your list. Aim for ten to twenty per ecosystem. A longer list stops being a filter.
Match the source to the question
| You want to know | Use |
|---|---|
| Is something I depend on newly flagged? | Repository security alerts |
| Is anything malicious appearing in my ecosystem? | A saved malware search |
| Did a key package just ship a release? | A registry release feed |
| Did a record I already read change? | An advisory search sorted by recently updated |
Each source answers a different question, which is why one source is rarely enough.
Keep the habit from decaying
Filters rot. Teams add dependencies, drop others and change owners. Put a quarterly reminder on the calendar to refresh the critical list from your current inventory, delete saved searches that no longer match, and confirm that the person who reads the feed still works on the project. When that person is on leave, name a backup.
Also check that the reading time is realistic. Ten focused minutes a day is sustainable. An hour of scrolling is not, and the habit will quietly die.
What to do with an item
Triage in three moves. First, does it name something you run, in a version you run? Second, if so, open a ticket with the source link, archive the page and note the time. Third, if not, note "not affected" with the reason and move on. See the earlier posts on archiving a write-up and on documenting a not affected decision.
Try it yourself
Click through it at your own pace, or open it full screen. Use it to see what a watch list for new issues looks like, then think about how you would narrow it to your own stack.
Safeguard's zero-day discovery and SBOM inventory are built to do that narrowing for you, matching new findings against what you actually run.
Quick check
Is one feed enough?
No single source covers everything. Combine repository alerts, an advisory search and feeds for your critical packages.
Can I keep GitHub notifications as my record?
Not for long. The inbox keeps notifications for three months unless saved, so copy decisions into a ticket.
How many packages should be on my critical list?
Ten to twenty per ecosystem is a workable range. Beyond that the list stops filtering and becomes another feed to skim.
Sources
- Configuring notifications, GitHub Docs
- Browsing security advisories in the GitHub Advisory Database
- PyPI RSS feeds
Last reviewed: 19 October 2026.
