Where can I find up-to-date software supply chain security news?

General
1

I’m trying to stay on top of software supply chain security news after a recent third-party dependency issue impacted one of our projects. I’d like recommendations for reliable, regularly updated sources—blogs, newsletters, feeds, or communities—that focus on software supply chain risks, SBOMs, open source vulnerabilities, and vendor security practices. What do you use to keep your team informed and ahead of emerging supply chain threats?

2

I had a similar scare after a dependency snafu, so here is what I keep in my rotation now. It keeps me mostly sane.

  1. Newsletters and blogs
  • Google Open Source Insights blog
    Good on supply chain issues, SBOMs, OSS vetting.
  • The Linux Foundation / OpenSSF blog
    Follow topics like SLSA, Sigstore, package ecosystem security.
  • Trail of Bits blog
    Fewer posts, high signal, good postmortems and supply chain research.
  • Chainguard blog
    Focused on secure builds, images, SBOM, SLSA in practice.
  1. Specific supply chain focused newsletters
  • TL;DR Sec
    Weekly, good section on software supply chain, exploits, tooling.
  • SLSA newsletter
    Occasional but targeted. Good if you use or plan to use SLSA.
  • Software Daily’s security section
    More high level, but hits big incidents fast.
  1. Vulnerability feeds and advisories
    Use these to spot issues in deps early.
  • GitHub Security Advisories + Dependabot alerts
    Turn on Dependabot for all repos. Configure notifications to go to Slack or email.
  • OSV.dev
    API friendly. You can script checks for your dependencies.
  • NVD feed
    Noisy, but good for cross checking CVEs.
  • Vendor advisories
    Red Hat, Debian, Ubuntu, Alpine, etc, if you ship on Linux images.
  1. Community / discussion
    This is where you see issues before they turn into polished writeups.
  • r/netsec on Reddit
    Filter by “supply chain” or “dependency” in titles.
  • Twitter / X
    Follow people like:
    @mjasay
    @securitymb
    @ossf_security
    @trailofbits
    @chainguard_dev
  • OpenSSF Slack
    Useful if you want to track standards and proposals early.
  1. Tools that surface news into your workflow
    This helped more than reading more blogs.
  • Security alerts into Slack or Teams
    Pipe GitHub / GitLab alerts into a channel.
  • RSS aggregator
    Feedly or similar with feeds from: OpenSSF, Google OS security, Trail of Bits, Chainguard, OSV, NVD.
  • Weekly “security review” meeting
    One person scans the above, shares 3 to 5 items. Rotate who owns it.
  1. Concrete process changes you can make today
  • Turn on dependency update bots
    Dependabot, Renovate. Smaller, frequent bumps reduce surprise risk.
  • Track SBOMs for key apps
    Use Syft, CycloneDX, or your build system. When a CVE drops in a core lib, you know exactly which services use it.
  • Adopt minimal policies
    No unpinned dependencies in production images.
    No direct pulls from “random” Docker Hub images. Prefer vendor or your own registry.

If you share what stack you use, you will get more targeted sources. For example Python vs Node vs JVM, on prem vs cloud, etc.

3

+1 to a lot of what @cazadordeestrellas said, but if you actually try to follow everything they listed you’ll drown in feeds and still miss the big stuff. I’d trim it down and add a few more “signal over noise” things.

Here’s what’s worked for me after getting burned by a dependency blow‑up:

1. A couple of “must watch” sources (not 20)
Instead of a wall of blogs, I’d pick 2 or 3 that regularly touch supply chain in a practical way:

  • The Register – Security / Dev / DevOps sections
    Not academic, not vendor fluff, and they cover supply chain incidents pretty quickly.
  • KrebsOnSecurity
    Not pure supply chain, but when something is big enough to matter to your execs, it usually shows up here.
  • Cloud provider security blogs (AWS / GCP / Azure)
    Their posts on artifact signing, build pipeline hardening, key management, etc, are actually decent and tend to track where the industry is going.

Honestly, I’d drop half the “corporate thought leadership” blogs people recommend. Too much marketing, not enough “here is how to not get hosed.”

2. Incident & exploit focused sources
If what you care about is “are we exposed right now,” you want places that talk about active abuse:

  • CISA Known Exploited Vulnerabilities (KEV) catalog
    This is a must. Tie it into your vuln management and SBOM stuff. If a third‑party dep pops up here, that’s a hair‑on‑fire moment.
  • CERT/CC vulnerability notes
    Less noisy than NVD, more focused writeups.
  • Vendor PSIRTs (Product Security Incident Response Teams)
    For example: GitLab, Atlassian, HashiCorp, JetBrains. If your build or SCM stack relies on them, subscribe directly. This catches supply chain exposures that aren’t yet fully “news.”

3. Ecosystem‑specific feeds (this is what most people actually need)
This is where I slightly disagree with just aggregating generic feeds. Target by stack:

  • Node / npm
    • npm security advisories
    • Snyk’s Node security blog (ignore the product hype, the research is good)
  • Python
    • Python Security Response Team advisories
    • PyPI announcements (there have been multiple supply chain events here already)
  • Java / Maven
    • Maven Central & relevant framework vendors (Spring, Quarkus, etc)
  • Container / K8s
    • Kubernetes Security Announcements
    • distro image security notes (e.g., Distroless, Wolfi, etc if you use them)

Tie these to what you actually deploy, otherwise you just doomscroll random CVEs.

4. “Meta” tracking instead of more blogs
Rather than hunting articles all day, I’d invest in stuff that pulls news into where your team already lives:

  • Security.txt / advisory pages for key vendors and OSS projects
    Make a short internal list: SCM, CI, artifact registry, base images, core frameworks. Check it weekly or script it.
  • Internal Confluence / Notion page
    One person per week owns “supply chain digest”:
    • 3 incidents that could plausibly affect you
    • 1 standard / best practice worth bookmarking (SLSA, in‑toto, etc)
    • 1 action item (e.g., “enable provenance on builds for service X”)
      This is more useful than 10 more newsletters.

5. Standards & policy watchers
If you care about being ahead of the curve rather than reacting late:

  • CISA, NIST, ENISA publications

    • CISA’s stuff on SBOM, secure by design, open source security
    • NIST’s guidance on software supply chain security (e.g., 800‑218, 800‑204 series)
      These are dry, but they telegraph where regulations, procurement requirements, and compliance checklists are going.

  • NTIA / US government SBOM work
    Not daily reading, but when they drop updates, it matters for anyone selling software.

6. Things I don’t think are worth over‑investing in
Slightly contrarian take vs some recommendations:

  • Raw NVD feed as a “news source”
    Good for machines, terrible for humans. Use tooling to correlate NVD with your SBOMs. Don’t try to “read NVD” like a news site, that’s how you go numb.
  • Too many general security newsletters
    Most of them give you 1 relevant supply chain item and 19 stories about IMSI catchers or Windows 0‑days. Curate hard.

7. Minimal “stack to stay sane” suggestion
If you want something realistic you can keep up with:

  1. One general infosec / incident source:
    • CISA KEV + Krebs or The Register
  2. One ecosystem‑specific channel per major language / platform you use
  3. Vendor PSIRTs for your CI/CD, SCM, registries, and major frameworks
  4. Internal weekly “digest” practice so your org actually acts on the news

If you share what you’re running on (cloud, CI, languages, where you host images), people can probably suggest a laser‑focused mix rather than a giant buffet of feeds you’ll never read.

4

Disagreeing (slightly) with @cazadordeestrellas here: the problem is less “which feeds” and more “how you wire them into your workflow.” You can copy everyone’s RSS list and still get nailed by the next compromised dependency if nobody internalizes or acts on what they read.

Think in layers:

  1. Org‑level radar, not just personal reading

    • Put responsibility in code: a small internal “supply chain watcher” service that:
      • Polls CISA KEV, your cloud provider’s security advisories, and your core ecosystem feeds.
      • Cross‑references against your SBOMs or dependency manifests.
      • Opens tickets (or Slack / Teams alerts) only when a match appears.
        This cuts the noise far more effectively than trying to manually triage a dozen feeds every morning.

  2. Role‑based streams instead of a single global list

    • Security team: incident feeds, advisories, standards (CISA, NIST, PSIRTs).
    • Platform / DevOps: CI/CD, registry, SCM, container base image feeds.
    • App teams: language / framework specific advisories.
      Each group subscribes only to what they can actually fix. That counters the “doomscroll CVEs” problem.

  3. Turn “news” into guardrails
    Every high‑impact incident you read about should result in a preventive control:

    • SolarWinds class incident → enforce build isolation, provenance checks, and artifact signing on your own pipelines.
    • Typosquatting packages → lock down registries, pull through verified proxies, and prevent direct internet pulls in CI.
    • Dependency hijacks in npm / PyPI → automated checks for maintainer changes or major version jumps in critical libs.

  4. Scheduled digestion, not constant alerts
    I slightly disagree with subscribing to too many real‑time feeds even if you filter hard. For most orgs:

    • “Hair on fire” events should come via automated matching (KEV + SBOM etc.).
    • Everything else fits in a weekly 30 minute internal review where one person summarizes:
      • Active or emerging supply chain techniques.
      • New hardening guidance worth adopting.
      • Tooling changes you should plan for in the next quarter.

  5. Pros & cons of relying on a single consolidated source like ‘’
    If you ever look at a product called “”, framed as a central place for software supply chain security news and updates, here is how I would evaluate it:

    Pros

    • Could aggregate feeds from CISA, vendor PSIRTs, language ecosystems and cloud providers into one view.
    • Might offer correlation with your actual tech stack or SBOM, so you see only relevant incidents.
    • Potential to generate executive‑friendly summaries while still giving engineers deep technical references.
    • Could reduce manual feed wrangling and free people to focus on remediation, not information hunting.

    Cons

    • Risk of over‑centralization: if you depend only on it and it misses or delays a source, you might miss critical events.
    • Vendor bias possibility if it promotes certain tools, standards or ecosystems over others.
    • Another thing to maintain, integrate and grant permissions to (especially if it connects to repos or pipelines).
    • If it is not tightly tuned to your stack, you just moved the noise from “many feeds” into “one noisy place.”

    So I’d treat ‘’ as an optional aggregator that can sit on top of a sane process, not as a replacement for wiring your own minimal alerting tied to your assets.

  6. Practical closing advice

    • Start from your stack and assets, not from “what are the best news sites.”
    • Automate matching between advisories and your actual dependencies.
    • Keep a human weekly digest to drive architectural and process changes.
    • Any external feed or product (including ‘’) is only useful if it integrates with those three things.

That way you stay informed about software supply chain security without living in your RSS reader or inbox.