extuno
Software supply-chain security across extensions and packages
The code you trusted at install time is not the code that runs after the next update. Supply-chain security is about watching the update channel, not just the first version.
What is a software supply-chain attack?
A supply-chain attack does not target your code directly. It targets something you already trust and pull into your environment: a browser extension, an npm or PyPI dependency, an IDE plugin. The attacker gains control of that trusted project, usually by taking over a maintainer account or compromising the publishing pipeline, then ships a malicious version through the normal update channel. Users who installed a clean release receive the poisoned one automatically.
Because the package name, the publisher, and the review history all look legitimate, nothing in the metadata signals danger. The malice lives in a specific version. See supply-chain attacks for the full attack pattern and real incidents.
Why do point-in-time scans miss the poisoned update?
Most scanning happens once, at install or at the moment a dependency is added. That scan sees the clean version and passes it. The problem is that the dangerous code arrives later, in version N+1, long after the gate already approved version N. A single snapshot has nothing to compare against, so a newly introduced exfiltration endpoint or eval-from-network call reads as just more code in a package that was already trusted.
This is the core gap supply-chain security has to close. Extuno treats every version as a candidate and compares it against the previous one. The headline signal is version-diff detection: an alert when behavior crosses from benign to dangerous across an update. The reasoning is documented in the methodology.
How does version-diffing work as a control?
Version-diffing archives each release and compares the new one against the last known good version. It diffs the manifest (new permissions, broadened host access, a changed update URL, weakened CSP) and the code (a new network destination, a new obfuscation family, a dynamic eval that was not there before). Benign updates produce quiet diffs; a poisoned update produces a high-signal delta because the dangerous behavior is, by definition, absent in the old version and present in the new one.
Each delta carries evidence: the file, the line, why it is dangerous, and the recommended action. That keeps the alert actionable instead of a bare risk number. Read more under version-diff detection and how it applies to package security.
What does the attack look like in real incidents?
Two documented cases show the pattern. In late 2024, a browser extension publisher was phished and a poisoned update pushed to users who had a clean version installed; the new release added session and cookie theft code. Read the breakdown in the Cyberhaven 2024 attack writeup.
On the package side, the event-stream incident showed a new maintainer adding a malicious transitive dependency that targeted a specific downstream wallet application. The malicious payload lived in a point release, not the original library. See the event-stream incident. In both cases a version-by-version comparison surfaces the introduced behavior that a one-time scan over the trusted name would wave through.
What surfaces does supply-chain security cover?
Extuno applies the same model across twelve ecosystems: Chrome, Firefox, VS Code, JetBrains, Eclipse, Discord client mods, npm, PyPI, WordPress, Composer, and Maven. Browser extensions update silently in the background and carry broad host permissions, which makes them a high-value target; see browser extension security. Developer packages and IDE plugins run inside build pipelines and developer machines with file and process access, covered under package security and IDE extension security.
Across all of them the analysis runs three layers: static rules read the code without running it, an isolated network-segmented microVM sandbox observes runtime endpoints and data sent, and AI code analysis correlates findings across versions as advisory context.
How do you operationalize this in a pipeline?
Detection is only useful if it gates the right things. Extuno produces SARIF and JSON output plus a pass/fail gate, so a CI job can block a build when a dependency or extension version introduces a blocking finding. Continuous monitoring re-checks tracked extensions and packages and re-scans only when the published version actually changes, so the update channel itself becomes the trigger.
For ongoing awareness, the malicious database tracks extensions and packages already flagged as malicious across the supported stores. Combined with version-diffing, that gives you both a forward control on new releases and a reference for known-bad artifacts. The full evidence and scoring model is documented in the methodology.
ALERT band-escalation: benign -> dangerous ext: example-extension 1.4.2 -> 1.4.3 + new network destination: https://collect.example-cdn.tld + new permission: cookies evidence: background.js:212 why: cookie read flows to new host
Frequently asked questions
What is a software supply-chain attack?
It is an attack that compromises a trusted third-party project, such as a browser extension or a package dependency, and ships malicious code through that project's normal update channel. Users who trusted an earlier clean version receive the poisoned version automatically.
Why do normal security scans miss supply-chain attacks?
Most scans run once, at install or when a dependency is added, and pass the clean version. The malicious code arrives in a later release. A single snapshot has nothing to compare against, so a newly introduced dangerous behavior in a trusted package reads as ordinary code.
How does version-diffing catch a poisoned update?
It compares each new version against the previous one and alerts when behavior crosses from benign to dangerous, for example a new exfiltration endpoint, broadened permissions, or a new eval-from-network call. Benign updates stay quiet because nothing dangerous was introduced.
Which ecosystems does Extuno cover for supply-chain risk?
Eight: Chrome, Firefox, VS Code, JetBrains, Eclipse, Discord client mods, npm, PyPI, WordPress, Composer, and Maven. The same static, dynamic sandbox, and AI analysis layers apply across all of them.
Can this run in CI?
Yes. Extuno emits SARIF and JSON plus a pass/fail gate so a build can block on a blocking finding, and continuous monitoring re-scans tracked artifacts when their published version changes.