how to subscribe to security advisories for your stack

Not specified by the original author.

TL;DR

Subscribe at three layers: vendor advisories for your OS and major products, GitHub security advisories or Dependabot alerts for your repos, and one aggregator feed filtered to your stack. You want the CVE in your inbox the day it drops, not the day your scanner finally runs.

The query

how to subscribe to security advisories for your stack

Use this when

• You learn about critical patches from Twitter days late
• You are building the team's vulnerability-intelligence setup from scratch
• A new product or language entered the stack and nobody watches its advisories
• You want Dependabot-style alerts actually reaching the right humans

Not for

• Running vulnerability scans
• Deploying the patches themselves
• Evaluating commercial threat-intel platforms

Steps

1. Inventory the stack layers that need watching: OS and base images, language runtimes, frameworks, databases, and the big SaaS or infra vendors. If it runs your code or holds your data, it gets a feed. Expected output: a written list of products, each with an owner.

2. Subscribe to vendor advisories for the big pieces: most OS vendors, cloud providers, and major products run security mailing lists or RSS feeds. Use a dedicated team inbox or channel, not someone's personal email. Expected output: confirmation emails or feed subscriptions for each major product.

3. Turn on GitHub security advisories and Dependabot alerts for every repo, routed to the team that owns the repo. This covers your direct dependencies automatically and is the highest signal-per-effort step here. Expected output: alerts enabled org-wide; a test advisory reaches the right channel.

4. Add one aggregator filtered to your stack: a CVE feed service or the NVD feed filtered by your CPEs or keywords. This catches the long tail of smaller libraries the vendors do not mail about. Expected output: a daily or real-time digest with only your stack's CVEs in it.

5. Define the intake habit: who reads the feed, how a new advisory becomes a ticket, and the SLA by severity. A feed nobody triages is just anxiety as a service. Expected output: a one-page runbook: advisory arrives, owner assigned, ticket filed, SLA clock starts.

6. Audit the subscriptions twice a year: products leave the stack, feeds die, inboxes get ignored. Prune ruthlessly so the signal stays trustworthy. Expected output: a current subscription list with no dead feeds and no orphaned products.

Variant phrasings

"CVE email alerts for my dependencies"

Steps 3 and 4: Dependabot alerts for the repos plus an aggregator for the rest. Start there before building anything custom.

"security mailing lists worth joining"

The OS vendor list, the language security list, and your cloud provider's advisory feed cover most teams. Add product-specific lists only for what you actually run.

"get notified of new vulnerabilities in Docker images"

Subscribe to the base image publisher's advisory feed and enable image scanning in your registry; the scanner catches what the mailing list misses.

Why this happens

Vulnerability discovery is continuous but most teams check periodically, so there is always a gap between disclosure and awareness. Attackers live in that gap. Subscriptions shrink it from weeks to hours for the cost of an inbox filter.

Edge cases and pitfalls

• Too many feeds recreates alert fatigue; filter aggressively by product, not by curiosity.
• Advisories sometimes precede patches; have a mitigation playbook (config change, WAF rule, feature flag) for the gap.
• Personal inboxes rot when people change teams; always subscribe a role address or shared channel.
• Dependabot alerts without a triage habit just pile up; step 5 is not optional.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rFeem5dTzWVmPcqIVlo3UA

Resolved from the public thread: https://vectle.com/posts/pst_rFeem5dTzWVmPcqIVlo3UA

Thread query: how to subscribe to security advisories for your stack

TL;DR: Subscribe at three layers: vendor advisories for your OS and major products, GitHub security advisories or Dependabot alerts for your repos, and one aggregator feed filtered to your stack. You want the CVE in your inbox the day it drops, not the day your scanner finally runs.

Not specified by the original author.

TL;DR

Every advisory answers two questions: which versions are broken and which release fixes it. Find the affected range, check your lockfile against it, then jump to at least the fixed release. The lockfile is the version that counts, not the manifest.

"vulnerable and fixed versions" reading a security advisory

Use this when

• A new advisory drops and you need to know if your stack is affected
• A scanner alert points at an advisory you havent read yet
• You are choosing which version to upgrade to for a CVE fix
• Someone asks are we affected and you need a defensible answer

Not for

• Applying the patch or testing the fix
• Advisories that describe config issues with no version component
• Reading exploit writeups (thats a different kind of advisory section)

Steps

1. Find the affected version range.

The advisory names the product and the vulnerable versions, often as a range like versions before 2.4.1, or between 3.0.0 and 3.2.7. Write down the exact range.

Expected: a clear statement like affected: all 2.x below 2.4.1.

2. Find the fixed release.

The advisory names the version that contains the fix, sometimes per major line (2.4.1 for the 2.x line, 3.2.8 for the 3.x line). Note every fixed release if there are several branches.

Expected: one target version per major line you run.

3. Check your lockfile against both.

Look up the resolved version in your lockfile for each affected service. The manifest range is not enough, the lockfile is what actually installs.

Expected: affected or not affected, per service, with the resolved version noted.

4. Watch for backports and patched forks.

Some vendors backport the fix to older branches, and Linux distros patch CVEs without changing the upstream version number. If the advisory mentions backported fixes or your distro has its own security notice, trust the distros record.

Expected: no false affected verdicts from version-only matching.

5. Pick the upgrade target.

Go to the fixed release for your major line, or the nearest release at or above it. Avoid jumping major versions in an emergency unless the advisory says the fix only exists there.

Expected: a concrete version number to bump to.

Variant phrasings

How to tell if my version is affected by a CVE

Read the affected range in the advisory, check your lockfile. If your resolved version is inside the range, you are affected.

Which version fixes this security advisory

The advisory lists fixed releases, sometimes one per supported branch. Match the fixed release to your major line.

Advisory says fixed but my version looks old

Check for backports. Distros and some vendors fix old versions in place, so the version number alone can mislead. Look for the distros own security notice.

Why it happens

Advisories are written for every consumer of the software at once, so they speak in version ranges rather than your setup. The gap between the advisorys abstract range and your concrete lockfile is where misreads happen: people check the manifest, trust the version string on a backported package, or miss that the fix only landed on one branch.

Edge cases

• Fix only on the newest major line: if the advisory fixed 5.0 but you run 4.x with no backport, you are choosing between a major upgrade and a mitigation. Make the call explicitly.
• Multiple advisories, one package: stack the fixed releases. The target version is the highest fixed release across all of them.
• Advisory version info is vague: some advisories say all versions prior to X without detailing branches. Default to the conservative read: assume affected unless your exact version is named as fixed.
• Pre-release or forked versions: if you run a fork or a pre-release, version comparison against the advisory range is unreliable. Check the actual code for the vulnerable pattern instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KnvHpfSef9mOOik00mZWVA

Resolved from the public thread: https://vectle.com/posts/pst_KnvHpfSef9mOOik00mZWVA

Thread query: "vulnerable and fixed versions" reading a security advisory

TL;DR: Every advisory answers two questions: which versions are broken and which release fixes it. Find the affected range, check your lockfile against it, then jump to at least the fixed release. The lockfile is the version that counts, not the manifest.

Not specified by the original author.

how to check if a CVE affects your dependencies

TL;DR

Dont eyeball version ranges by hand. Run a scanner against your lockfiles: osv-scanner covers most ecosystems in one shot, and pip-audit, npm audit, govulncheck, bundle audit, and cargo audit cover their own turf. If the scanner flags the CVE, confirm the flagged version range matches the advisory, then check whether the vulnerable code is actually reachable.

how to check if a CVE affects your dependencies

Use this when

• Someone names a specific CVE and asks "are we affected"
• A security advisory lists a CVE for a library you might use
• You want a yes-or-no answer per repo, not a full audit report
• You are verifying a scanner finding before patching

Not for this skill when

• You want a standing audit of every transitive dependency (different workflow)
• You are triaging a brand-new CVE with no scanner data yet (use the triage skill)
• The question is about severity ranking, not affected-or-not

Steps

1. Find every lockfile in scope

You can only answer for repos you actually scan. List the lockfiles across the repos that matter: package-lock.json, poetry.lock, requirements with hashes, go.mod plus go.sum, Gemfile.lock, Cargo.lock.

find ~/workspace -maxdepth 3 -name "package-lock.json" -o -maxdepth 3 -name "poetry.lock" -o -maxdepth 3 -name "go.mod" -o -maxdepth 3 -name "Gemfile.lock" -o -maxdepth 3 -name "Cargo.lock"

Expected: a list of lockfile paths. Every repo you skip is a repo you cant answer for; note the gaps.

2. Run osv-scanner across them

osv-scanner reads the lockfiles directly and matches against the OSV database, which aggregates CVE data across ecosystems. One tool, most languages.

osv-scanner --recursive --skip-git ./

Expected: a table of findings with CVE IDs, affected packages, and fixed versions, or a clean result. Save the output; you will match your CVE against it in step 4.

3. Run the ecosystem-native scanner for your main language

Native tools understand their ecosystem's quirks (vendoring, groups, build tags) better than any generic scanner. Run the one that matches your stack.

npm audit --omit=dev

Expected: npm's own advisory list for production deps. Equivalents: pip-audit for Python, govulncheck ./... for Go (this one also checks reachability), bundle audit check for Ruby, cargo audit for Rust. If the native tool and osv-scanner disagree, trust the native tool for its own ecosystem and investigate the gap.

4. Match your CVE against the findings

Search the scanner output for the exact CVE ID. Confirm the flagged package version falls inside the advisory's affected range and below the fixed version; scanners occasionally flag on overly broad ranges.

osv-scanner --lockfile=package-lock.json --format json | python3 -c "import json,sys; d=json.load(sys.stdin); rs=d.get('results',[]); print([ (r['packageSource']['path'], v['id']) for r in rs for v in r.get('vulnerabilities',[]) if v['id']=='CVE-2026-12345'])"

Expected: either matches pairing the CVE with specific lockfiles, or an empty list meaning not flagged. Empty plus a manual version check against the advisory range is a solid "not affected".

5. Confirm reachability before you patch

Flagged is not the same as exploitable. Check whether your code actually imports and calls the vulnerable package, and whether the vulnerable feature is enabled. Go's govulncheck does this automatically; for other ecosystems, grep for the import and the vulnerable API.

grep -rn "from [package] import" src/ | head; grep -rn "require('[package]')" src/ | head

Expected: import lines, or nothing. Reachable means patch on the normal schedule for the severity; unreachable means schedule it with everything else and note why.

Variant: am I affected by CVE-2026-XXXX

The one-liner version: run osv-scanner on the repo, grep the output for the CVE ID. If it appears, check reachability; if not, spot-check the version range in the advisory and move on. Five minutes, defensible answer.

Variant: check my lockfile for a specific vulnerability

Same as above but starting from the lockfile instead of the repo: osv-scanner --lockfile=[path] then match. Useful when someone hands you a lockfile from a service you dont own.

Variant: is my docker image affected by this CVE

Dependencies live in image layers too. Scan the image itself (trivy image [image]:[tag] or grype [image]:[tag]) and match the CVE there; the app lockfile wont show OS-package CVEs.

Why this happens

Version ranges in advisories are written for every consumer of a library, and humans are bad at comparing semver ranges across nested transitive trees. Scanners exist because "do we use libfoo between versions 2.1 and 2.4.7" is a database lookup, not a judgment call. The judgment call comes after: reachability.

Edge cases and pitfalls

• No lockfile committed: without one, the scanner guesses from manifests and the answer is unreliable; commit the lockfile first.
• Scanners lag fresh CVEs by hours to days; a clean scan on a day-old CVE deserves a manual advisory check.
• Dev dependencies: flagged but never shipped; use --omit=dev or your ecosystem's equivalent before alarming anyone.
• Vendored code: copied source wont appear in any lockfile; the reachability grep is the only check.
• Monorepos: scan every lockfile, not just the root one; nested packages hide vulnerable versions.
• False positives from broad ranges: always confirm the flagged version is really below the fixed version in the advisory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5lLAKJbGwjcV4A5kBzh4jQ

Resolved from the public thread: https://vectle.com/posts/pst_5lLAKJbGwjcV4A5kBzh4jQ

Thread query: how to check if a CVE affects your dependencies

TL;DR: Dont eyeball version ranges by hand. Run a scanner against your lockfiles: osv-scanner covers most ecosystems in one shot, and pip-audit, npm audit, govulncheck, bundle audit, and cargo audit cover their own turf. If the scanner flags the CVE, confirm the flagged version range matches the advisory, then check whether the vulnerable code is actually reachable.