Pulse feed

The pulse feed is the dashboard tab you'll spend the most time in once your sources are configured. It opens with a rollup of your whole dependency estate (below), then shows five kinds of activity, in this order:

• New releases for sources you track.
• Stale-source notices when a source hasn't published a release in a long time and may be unmaintained.
• Lockfile upgrades: a per-lockfile rollup of the available upgrades across your monitored dependencies, plus a count of open security issues (advisories against your pinned versions) and, prominently, how many are exposed with no upgrade path (fix_unreleased). A lockfile whose only signal is a security issue with no available upgrade still appears here, so a vulnerable-at-latest pin can't hide just because there's nothing to upgrade to. Drill down to the per-dependency detail.
• News & discussions: highly-engaged open GitHub issues on the repos you watch. These surface ongoing problems before they make it into a release or formal advisory.
• Security advisories for packages you depend on that have no fix release yet, e.g. a compromised package. They clear automatically when a release fixes them, or you can dismiss one once you've handled it.

Across your lockfiles #

Before your first lockfile, this slot is the prompt to add one, because that is the single action that turns the rest of the page on. See Getting started. Everything below describes Pulse once a lockfile exists.

The panel at the top of Pulse answers the question the per-lockfile rows below it can't: what is going on everywhere at once. It sums the security and upgrade picture over every lockfile you own, so you don't have to open each one to find out whether anything is on fire.

Six numbers, in two groups:

Group	Metric	What it counts
Security issues	Exposed, no fix	Advisories against your pins with no released fix reachable above them (fix_unreleased). The case an upgrade-shaped view structurally cannot show.
	Fix blocked	A released fix exists, but a parent constraint pins you below it (fix_blocked). Upgrade the parent or add an override.
	Fix available	A released fix is reachable above your pin (fix_available): upgrading resolves these.
Upgrades	High risk	Available upgrades rated high or critical: a major jump, documented breaking changes, or a security fix in the range.
	Blocked by a parent	Available upgrades a parent's version constraint excludes, so they aren't independently installable.
	Available	Every pinned dependency trailing its latest known release.

The security metrics use the same three fix_status buckets the lockfile detail view groups on, so the summary and the page it sends you to name the same thing the same way. Alongside them, the header shows the severity mix (how many of your open issues are critical and high) so a count of twelve can say how bad twelve is.

Selecting a metric lists the lockfiles it comes from, biggest contributor first, each a direct link into the matching section of that lockfile's detail page. The panel opens on the most urgent metric that has anything in it, so the first thing on screen is the thing most worth doing.

Two things the panel is careful about:

• The totals cover everything, not just what fits. The per-lockfile list further down the page is capped, but these numbers are computed over your whole set. Under-reporting exposure is the one direction a security count must never err.
• A zero isn't an all-clear if we never looked. If any of your lockfiles sit in an ecosystem we don't match advisories against yet, the header says how many, and an empty security total is stated as clear for the scanned part rather than clear outright. Where scanning does run it covers every pinned dependency, monitored or not.

The panel also carries the MCP server pointer: the same upgrades and advisories it summarises are exactly what the MCP tools serve to your AI agent, so the panel is either your reading list or your agent's work queue.

Collapsing sections #

Every section below the panel is a disclosure: click its heading to fold the list away. A collapsed section still shows its count and a one-line summary of what's inside (which sources, which lockfiles, how many critical), so folding one compacts a finding rather than hiding it.

Sections with more than five rows start collapsed. That keeps a busy account readable at a glance instead of thousands of pixels tall, while a quiet account still shows everything without a single click. Your choice per section is remembered across reloads, and a deep link into a section (for example the #lockfile-upgrades anchor) always opens it, whatever you last chose.

What each row tells you #

Row type	Key fields
Security advisory	Affected package, severity, how it reaches you (Direct / Dependency / Ecosystem), why there's no fix yet, link to the advisory.
New release	Source, version tag, release date, risk score, one-line summary.
Lockfile upgrades	Per-lockfile counts (upgradeable / major / security upgrades / high-risk / without release tracking: no source, so no upgrades; advisories still matched) plus open security issues and the no-fix (exposed, no upgrade path) subset, and where the lockfile lives (its repo and path for GitHub-connected lockfiles), with drill-down to per-dependency pinned → latest rows and the security-issues section.
Stale source	Source, last release date, suggested action (deactivate or keep).
News & discussions	Source, issue title, reactions/comments, heat score, link to the issue.

News & discussions #

We pull external context for the packages you track and surface it in two places. On a release summary we attach security and ecosystem news published around the same time, so you see the supply-chain context release notes alone can't provide (for example, the LiteLLM credential leak). Here on the Pulse dashboard, the News & discussions section surfaces highly-engaged open GitHub issues on the repos you watch, so you can spot ongoing problems before they ship in a release or formal advisory.

The News & discussions section ranks open issues by heat: reactions weighted 3×, plus comments, decayed about 7%/day. An issue with five fresh reactions outranks a month-old issue with twenty. We only surface issues with momentum, so a quiet bug report won't clutter the feed.

Each row links to the issue on GitHub. Dismissing one removes it from your feed; we don't currently support a "past" view for discussions: the goal is to spot brewing problems, not maintain an archive.

The feature ships for GitHub-typed sources today. HackerNews stories, project blog/changelog feeds, and broader web mentions are planned.

Click any row to open the detail page: full summary, diff highlights, and the specific signals that drove the score.

How advisories are ordered #

Every advisory carries a badge saying how it reaches you:

• Direct: it hits a package tied to a source you watch.
• Dependency: it hits a package in one of your lockfiles.
• Ecosystem: no package match at all; it's a critical/high advisory in an ecosystem you use (npm, PyPI, …), included as ambient context.

Matching is by package name, case-insensitively, using each ecosystem's own equivalence rules, so a PyPI advisory for my-pkg matches a my_pkg pin, which PyPI treats as the same package. Your lockfile's format tells us which ecosystem's rules to apply.

The Active list is ordered in two blocks. Direct and Dependency rows come first: all of them, before any Ecosystem row. Inside each block: severity (critical before high), then the badge above as a tiebreak (Direct before Dependency), then newest first.

The block split matters more than it looks. Ecosystem matching is only on the ecosystem, so that tier is effectively unbounded. Every critical npm advisory in the world is an ambient match if you have a package-lock.json. The section shows the first 50 rows, so ranking those purely by severity would let a busy disclosure day push your packages off the end of the list. Keeping them in front means the cut only ever loses ambient context.

Within the block you'd actually act on, severity leads absolutely: a critical never renders below a high. The badge is what makes the tiebreak legible, and it means a coincidental package-name match (plenty of ecosystems ship something called oauth) shows up as a Direct badge you can discount, instead of silently pushing a row up the list.

Advisories against packages you have are matched regardless of age: a still-unpatched advisory from years ago surfaces the same as one from this morning. Only the ambient Ecosystem tier is limited to recent activity, which is what that tier is for.

The Past list is ordered differently (see below).

Only critical and high advisories surface standalone. Lower severities still count toward a release's risk score and appear on the release they're attached to.

Active vs. past advisories #

The security-advisories section has an Active / Past toggle. Active lists advisories with no fix release yet. An advisory leaves the active list two ways:

• A release patches it. The advisory becomes resolved and links to the release that fixed it, which also appears under New releases.
• You dismiss it.

Switch to Past to review resolved and dismissed advisories. Resolved rows carry a "Fixed in" link to the release; dismissed rows can be restored back to the active list.

Past is a record of what you've already handled, so it reads newest first. The severity ordering above applies to Active only.

Triage workflow #

1. Start at the top of the security-advisories section. Your own packages come first, ordered by severity, so the most urgent rows are already at the top, so no scanning is required. Work down until you hit the first Ecosystem badge; everything from there on is ambient context rather than your exposure.
2. Release rows are ordered by risk too: starred sources first, then risk score descending, then recency, so the High band (70+) is already at the top of each group. Each row's score is a colour-coded badge (coral for High, amber for Medium, teal for Low), so you can confirm the band at a glance without reading the number.
3. For each High row, decide: update, pin around, or wait for a follow-up.
4. Mark resolved rows by clicking through and acknowledging; they drop off the active feed but stay in the source's history.

Realtime updates #

The feed updates as new analysis completes; no need to refresh. New rows animate in and the unread indicator updates as they land.

Frequently asked questions #

Where does the news come from? #

Four sources today: (1) GitHub Security Advisories, structured CVE/advisory data with package-version ranges; (2) OSV.dev, the open-source vulnerability database covering npm, PyPI, Go, Maven, crates, and RubyGems; (3) a curated allow-list of security RSS feeds for narrative incidents that haven't landed as CVEs yet, passed through an LLM classifier that extracts affected packages and severity; and (4) GitHub Issues on each tracked repo, ranked by reactions and comments. HackerNews search, per-source blog/changelog feeds, and broader web mentions are on the roadmap.

Do you track VS Code extension supply-chain attacks? #

Yes, VS Code and Open VSX extensions are a first-class ecosystem. Advisories affecting a compromised editor extension are surfaced under a dedicated "vscode" ecosystem tag. GitHub Security Advisories file these under their npm ecosystem, so we re-tag known extensions back to vscode, and the LLM classifier labels narrative coverage of marketplace compromises the same way. You can also track a specific extension as a source by pasting its Marketplace or Open VSX URL.

How does news affect release severity? #

News items contribute up to 25 points to a release's 0–100 risk score depending on how tightly they match: a direct critical match (a supply-chain compromise against the exact package) adds up to 25, a dependency-level critical match up to 10, and ecosystem-wide critical news up to 5. The total is still capped at 100.

How fresh is the news? #

The scraper runs every 4 hours by default and indexes items from the last 14 days. When a release is processed we only consider news published within ±14 days of the release date. Both the cadence and the lookback window are runtime-configurable without redeploying.

Why didn't a release I care about get flagged? #

The most common reasons: (1) the news item names the package differently than we do (we canonicalize PyPI names, but npm names must match exactly); (2) the item falls outside the 14-day window; (3) the RSS classifier couldn't extract a structured package name with high confidence; or (4) the package isn't in our OSV probe list yet. Email info@devupdate.io if you spot a missed link and we'll add the mapping.