Two commonly under-inventoried surfaces—crates executing during compilation and extensions running inside an editor—are reinforcing the same security lesson: the software supply chain begins before an application is packaged. A dependency does not have to survive into production runtime to cause damage if it can execute on a developer workstation or build runner.

The Rust and VS Code findings arrive alongside AWS adding supply-chain security to Security Hub Extended. These are separate developments, but together they make the case for connecting inventory, prevention, and incident response rather than limiting supply-chain work to application library scans.

What did the new reports find?

According to the analysis of the arrayref campaign, malicious versions of the Rust crate arrayref and other crates executed a backdoor at compile time. The report also found significant infrastructure overlap with recent supply-chain activity involving Mastra and axios, and associated those signals with DPRK campaigns.

The execution stage is the key technical detail. Compile-time code can reach the workstation or CI environment holding source and credentials, even when the final application artifact does not contain a backdoor in a form that runtime-focused scanning would readily expose.

On another surface, ProjectDiscovery audited Markdown Preview Enhanced, a VS Code extension reported to have roughly 9.5 million installs. Its Neo-based audit identified five CVEs across two attack surfaces, including a WaveDrom rendering flaw through which an ordinary Markdown file could lead to JavaScript execution in the preview.

These cases do not establish that every crate or editor extension is unsafe. They expose a trust-model gap: extensions can update automatically and run with the user's privileges, while developer tooling often remains absent from an application's software bill of materials.

Why is an application SBOM not enough?

An SBOM commonly describes components used to build or distribute a product. That view is useful, but it can miss tools that act on source code before the product exists, including editor extensions, compiler plugins, build scripts, package-manager hooks, and CI utilities.

A more operational inventory should distinguish at least three layers. Application dependencies affect the artifact; build dependencies affect how the artifact is produced; workstation tools operate near repositories, SSH keys, signing material, and registry credentials. A package can cross layers, but the appropriate controls are not identical.

This table is a recommended assessment framework, not a claim about the complete capabilities of any reported product. Its purpose is to identify where third-party code can execute and what authority it receives in that location.

Which controls should engineering teams change?

First, place extensions, build plugins, and local utilities in an owned inventory. For VS Code, an organization can define an approved extension list, review publisher and usage scope, and test updates in a lower-privilege environment before wider deployment.

Second, reduce the blast radius when untrusted code does execute. Avoid persistent credentials on workstations and CI runners unless they are essential; separate access to source, artifact signing, and package publishing; and restrict network access for sensitive build jobs. These measures will not prevent every compromise, but they limit what one execution path can reach.

Third, treat dependency changes as reviewable security events. Lockfile updates, new versions, publisher changes, and new build behavior deserve scrutiny proportional to their privileges. This approach complements a governed control-plane design, where policy, approvals, and audit trails are applied consistently rather than left to individual developers.

• Inventory extensions and tools capable of executing on development machines.
• Review scripts triggered during installation, compilation, and packaging.
• Separate publishing credentials from everyday code-editing environments.
• Alert on unexpected lockfile, publisher, or distribution-source changes.
• Prepare procedures to revoke tokens and isolate runners during an incident.

What does the AWS integration signal?

AWS has made Supply Chain Security the tenth category in Security Hub Extended. Its announcement says the initiative grew from 14 curated partners across nine categories to 23 partners across ten categories since February.

This does not mean a centralized dashboard can eliminate dependency or extension risk. The practical signal is that supply-chain findings are being connected to broader security operations, where output from multiple tools can enter a shared context for assessment and response.

The next question is integration quality. Teams should examine whether their coverage spans dependencies, build environments, and workstations; whether findings contain enough context for prioritization; and how quickly an alert can become a concrete response such as credential revocation, version blocking, or host isolation.

Conclusion

• Supply-chain exposure includes code running during builds and on developer workstations.
• An application SBOM does not replace an inventory of extensions, plugins, and build tools.
• Allowlisting, least privilege, and short-lived credentials reduce potential impact.
• Centralized visibility matters only when findings connect to a defined response process.

Related reading

• Ventura React: Is this lightweight component library still fit for new projects?
• Nova MCP turns Cursor and Claude into a product-building team
• Ansible Automation Orchestrator: Designing a Governed Control Plane

Sources

• Security Hub Extended adds Supply Chain Security as its tenth category
• Supply Chain Security Analysis of a 9.5M-Install VS Code Extension
• Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns