That 64-out-of-100 bundled-JS blind spot stands out in your sample. Once esbuild or webpack collapses node_modules into a single extension.js, any manifest scanner walking extension/node_modules/*/package.json sees zero dependencies even when a vulnerable minimist or semver code path survived tree-shaking.
On the chronological gap you traced with Live Server, generating a CycloneDX or SPDX SBOM alongside the .vsix at build time would let the Marketplace re-score already-published extensions against new OSV advisories without waiting for maintainers to push a new release.
Agreed on the SBOM. That’s also the only way I see to cover the 64 bundled extensions, since there’s nothing left in the .vsix for a manifest scan to read. If vsce package produced one by default, the Marketplace re-check would be a cron job over files it already has.
Creator of GithubStarsManager — an open-source, local-first tool that organizes GitHub stars with AI: auto-categorization, semantic search, release tracking, and an MCP server for star library.
The Live Server chronology is the part that stuck with me — the maintainer shipped a clean dependency in February and an advisory landed on that exact version five months later. It makes the case for re-auditing already-published releases much better than any severity count does. I also appreciated the honesty about the evidence levels: publishing at Present, and saying so plainly, is exactly what makes the 19/100 number usable instead of alarming. One question: for the February re-run, will the diff between runs be the main signal, or are you thinking about adding a Loaded check — even a rough one, like instrumenting the extension to see which bundled modules actually get required?
Thanks for your comment. For February the diff is the main signal: which rows disappeared, which appeared, and how long it took an extension to ship a fix after its advisory. A Loaded check is tempting, but instrumenting 19 extensions by hand doesn’t scale, so I’d start with the top few. Live Server is the obvious first one, since live-server pulls in faye-websocket for its main feature. If that works, it becomes a column in the dataset.
Creator of GithubStarsManager — an open-source, local-first tool that organizes GitHub stars with AI: auto-categorization, semantic search, release tracking, and an MCP server for star library.
That makes sense — starting with the top few is the only way it scales, and Live Server is the obvious first column since the faye-websocket dependency sits right at the heart of what it does. Thanks for the follow-up, looking forward to the February diff.
Creator of GithubStarsManager — an open-source, local-first tool that organizes GitHub stars with AI: auto-categorization, semantic search, release tracking, and an MCP server for star library.
Perfect, thanks. The row I'll watch first is Live Server itself — whether the faye-websocket CVE is gone by February, and if so, how long the fix took from disclosure to release. That single timeline says a lot about how fast these big extensions actually move once a CVE is public.
Same row I’m watching. Small correction for the record: the CVE is in websocket-driver (0.7.4). faye-websocket is just how it gets pulled in. And a fixed version, 0.7.5, has existed since the advisory came out on July 15. So the upstream side is done. All Live Server needs is a rebuild and a new release. As of today that clock is at four months and counting. If it’s still 0.7.4 in February, that’s seven months for a one-line fix that’s sitting right there. That number will be in the post either way.
Analyst focused on AI security
Adversarial evaluation of local LLMs, censorship and rejection rate, prompt injection testing, log analysis and defensive automation. Visit: sammideblas.com
Pinning an extension to a version and re-scanning its dependency tree on a schedule is a stronger signal than trusting the marketplace review. The gap is that most extension authors never run a dependency audit, so the CVE stays in the lockfile until someone installs it. A per-extension SBOM would make that visible before install.
Agreed on the SBOM, and on scheduled re-scans. One nuance though: in the Live Server case an audit on release day wouldn’t have helped. npm audit in February would have come back clean, because the advisory only appeared in July. So it’s less that authors skip audits and more that nobody re-checks the bundle after it ships. An SBOM next to the .vsix would make that re-check cheap for anyone, the Marketplace included.
Have you seen any extension actually publish one?
We're a place where coders share, stay up-to-date and grow their careers.
That 64-out-of-100 bundled-JS blind spot stands out in your sample. Once
esbuildorwebpackcollapsesnode_modulesinto a singleextension.js, any manifest scanner walkingextension/node_modules/*/package.jsonsees zero dependencies even when a vulnerableminimistorsemvercode path survived tree-shaking.On the chronological gap you traced with Live Server, generating a CycloneDX or SPDX SBOM alongside the
.vsixat build time would let the Marketplace re-score already-published extensions against new OSV advisories without waiting for maintainers to push a new release.Agreed on the SBOM. That’s also the only way I see to cover the 64 bundled extensions, since there’s nothing left in the .vsix for a manifest scan to read. If vsce package produced one by default, the Marketplace re-check would be a cron job over files it already has.
The Live Server chronology is the part that stuck with me — the maintainer shipped a clean dependency in February and an advisory landed on that exact version five months later. It makes the case for re-auditing already-published releases much better than any severity count does. I also appreciated the honesty about the evidence levels: publishing at Present, and saying so plainly, is exactly what makes the 19/100 number usable instead of alarming. One question: for the February re-run, will the diff between runs be the main signal, or are you thinking about adding a Loaded check — even a rough one, like instrumenting the extension to see which bundled modules actually get required?
Thanks for your comment. For February the diff is the main signal: which rows disappeared, which appeared, and how long it took an extension to ship a fix after its advisory. A Loaded check is tempting, but instrumenting 19 extensions by hand doesn’t scale, so I’d start with the top few. Live Server is the obvious first one, since live-server pulls in faye-websocket for its main feature. If that works, it becomes a column in the dataset.
That makes sense — starting with the top few is the only way it scales, and Live Server is the obvious first column since the faye-websocket dependency sits right at the heart of what it does. Thanks for the follow-up, looking forward to the February diff.
Will do, I’ll tag you when the February run is up.
Perfect, thanks. The row I'll watch first is Live Server itself — whether the faye-websocket CVE is gone by February, and if so, how long the fix took from disclosure to release. That single timeline says a lot about how fast these big extensions actually move once a CVE is public.
Same row I’m watching. Small correction for the record: the CVE is in websocket-driver (0.7.4). faye-websocket is just how it gets pulled in. And a fixed version, 0.7.5, has existed since the advisory came out on July 15. So the upstream side is done. All Live Server needs is a rebuild and a new release. As of today that clock is at four months and counting. If it’s still 0.7.4 in February, that’s seven months for a one-line fix that’s sitting right there. That number will be in the post either way.
Pinning an extension to a version and re-scanning its dependency tree on a schedule is a stronger signal than trusting the marketplace review. The gap is that most extension authors never run a dependency audit, so the CVE stays in the lockfile until someone installs it. A per-extension SBOM would make that visible before install.
Agreed on the SBOM, and on scheduled re-scans. One nuance though: in the Live Server case an audit on release day wouldn’t have helped.
npm auditin February would have come back clean, because the advisory only appeared in July. So it’s less that authors skip audits and more that nobody re-checks the bundle after it ships. An SBOM next to the .vsix would make that re-check cheap for anyone, the Marketplace included.Have you seen any extension actually publish one?