Your developer tools are part of the delivery system

A concrete signal

In mid-2026, security firm Arctic Wolf reported that since 26 June, at least 292 deceptive GitHub pages and repositories had impersonated legitimate software and security tooling vendors, distributing an infostealer to people who thought they were downloading a real tool (Arctic Wolf, 2026). German-language reporting by Heise described the same pattern: fake GitHub repositories serving infostealers instead of the developer or security tools they advertised (Heise, 2026).

What matters is how the campaign worked. It did not exploit a vulnerability in the impersonated brands. It abused trust: the reasonable assumption that a repository named like a known tool contains that tool. Nothing was broken into. The name was simply believed.

This should concern anyone running delivery, because trust is what your build depends on every day.

Tooling is how the work flows

Developer tooling is easy to file under background IT: the IDE extensions, CLI utilities, package managers, build scripts, CI/CD pipelines, and, increasingly, the model hubs that AI-assisted teams pull from. Background IT gets treated as someone else's concern, patched when convenient, otherwise invisible.

But these things are not adjacent to how work gets delivered. They are the path the work travels. A pull request becomes a running service through a chain of installed packages, executed build steps, and pipeline stages, each of which runs code the team did not write and mostly has not read. When a developer adds a dependency or installs an extension, they are not configuring their own machine in isolation. They are extending the set of code that executes, with trust, inside the delivery system.

Once you see tooling that way, the security literature reads less like a specialist concern and more like a description of your delivery surface.

The mechanism: automation, trust, and scale

Modern software ecosystems combine three things at once: automation, trust, and scale. Defending them means watching dependencies, CI/CD, network and credential use, and keeping an inventory of what you actually run (NCSC, 2026). Each of the three amplifies the others.

The scale is not abstract. Zahan et al. (2022) analyzed 1.63 million npm packages and proposed six "weak-link" signals for supply-chain risk; among their findings, 2,818 maintainer email addresses were tied to expired domains, a gap that could expose 8,494 packages to takeover. Duan et al. (2021), using a tool called MALOSS, identified 339 previously unknown malicious packages across PyPI, npm, and RubyGems; maintainers confirmed or removed 278 of them, and three had been downloaded more than 100,000 times each.

The attack surface is also well mapped rather than speculative. Ladisa et al. (2023) built a taxonomy of open-source supply-chain attacks covering 107 attack vectors, drawn from 94 real-world incidents and 33 safeguards, validated with 17 domain experts and 134 developers. Williams et al. (2025) group the major vectors into a short list: malware or vulnerabilities in third-party dependencies, components, and containers; compromise of build and deployment infrastructure; and social engineering aimed at the developers themselves.

The through-line: a small decision (one package, one extension, one convenient install script) can open a large downstream execution path. Automation means that path runs without a human present. Trust means it runs without inspection. Scale means no single person can hold the whole picture in their head.

Unmanaged tool trust is work in progress

In delivery terms: every tool and dependency admitted without a decision is a unit of executing code that the team now depends on but has not inspected, cannot easily patch, and often cannot explain. That is work in progress, just not the kind that shows up on the board.

It behaves like WIP because it generates the same downstream load:

• Review load, when someone finally has to understand what a dependency does before a release can go out.
• Incident risk, when a compromised or malicious package reaches production.
• Credential exposure, when an install or build script runs with access to secrets it never needed.
• Unplanned recovery work, when a suspected compromise forces rotation, rebuilds, and audits that were nowhere in the plan.

None of this is visible while things are working. Like other hidden WIP, unmanaged tool trust is free until it isn't, and then it arrives all at once, usually during a release you had promised.

A lightweight trust queue

The wrong response is a freeze on open source. Blocking the ecosystem does not remove the risk; it removes your ability to ship, and it pushes tool decisions into the shadows where they are even harder to see.

The workable response is an intake policy: a trust queue for tools and dependencies, deliberately kept small. The point is not to review everything. It is to decide, in advance, which things get to enter with full trust and which have to earn it. A short set of standing questions does most of the work:

• What is allowed to auto-update, and what is pinned until someone looks?
• Which dependencies and tools are permitted to run install or build scripts?
• Which tools can read credentials or source code, and do they actually need that access?
• Which updates require a human review before they land?
• Are release branches and CI secrets protected against unreviewed changes?
• Is provenance available for the artifacts you consider critical?
• Who approves exceptions when speed and risk pull against each other?
• What gets rotated the moment compromise is suspected?

Most of these map directly onto defender actions the NCSC (2026) lists: dependency review, monitoring of CI/CD and credential use, scanning, credential rotation, MFA, trusted registries, and a maintained inventory or SBOM. The queue is just the delivery-facing wrapper around those actions, a way to assign an owner and a decision to each one instead of leaving them implicit.

Keeping it lean

A trust queue earns its keep only if it stays cheap to run. The way to keep it cheap is to classify by execution power and blast radius rather than reviewing every line of every package.

A pinned library that renders text in the browser has little execution power and a small blast radius. A build plugin that runs arbitrary scripts with access to your CI secrets has both. The first can auto-update on a schedule; the second belongs in the review lane every time. Sorting tools this way means the expensive scrutiny lands where a compromise would actually hurt, and the long tail of low-power dependencies flows through without ceremony. Freezing everything and reviewing everything are both mistakes: they spend attention uniformly on a problem that is not uniform.

This extends to newer tool categories. Li et al. (2025) found evidence of typosquatting on the Hugging Face model hub, where a model pulled by a near-miss name is not what the developer intended. This is early evidence and narrower than the package-ecosystem work, but it points the same way: as teams pull models the way they pull packages, model hubs enter the same trust queue, under the same execution-and-blast-radius test.

Caveats worth stating plainly

Two honest limits.

First, none of the evidence above shows that this specific operating model improves your flow metrics. Security research measures attacks, weak links, and safeguards. It does not measure cycle time or throughput. The claim here is about a mechanism (that unmanaged tool trust behaves like hidden WIP and generates unplanned work), not a proven causal link between a trust queue and faster delivery. Treat the operating model as a reasoned bet informed by security evidence, not as a performance guarantee.

Second, the tooling that helps does not close the whole gap. SLSA v1.1 addresses provenance and integrity across source and build, and it is explicit that it does not cover all threats (SLSA, 2025). SBOMs help with transparency and risk work, but O'Donoghue et al. (2025) found adoption limited by tooling, format fragmentation, maintenance burden, false positives, hidden packages, tampering, and general overhead. Neither an SBOM nor a provenance standard decides for you whether to trust a given package in the first place, and neither stops a developer from being socially engineered. Those remain human decisions, which is exactly why they belong in a queue with an owner.

The takeaway

Flow is usually discussed as cycle time, how fast a unit of work moves from start to done. That framing is incomplete once you accept that your tools are part of the delivery system. The real question is whether the system can keep trusted work moving without silently increasing risk in the background.

A team can post excellent cycle time while quietly accumulating unmanaged tool trust, and then lose a quarter to a single compromised dependency. That looks fast, but it is really borrowing against its own delivery capacity without recording the debt. Managing the trust queue is how you keep the flow you measure from being an illusion.

Sources

• Arctic Wolf (2026). Fake GitHub Repositories Deliver BoryptGrab-Lineage Infostealer.
• Heise (2026). Fake-GitHub-Repositorys: Infostealer statt Security- oder Developer-Tools.
• Ladisa, P., Plate, H., et al. (2023). SoK: Taxonomy of Attacks on Open-Source Software Supply Chains. IEEE S&P.
• Zahan, N., Williams, L., et al. (2022). What are Weak Links in the npm Supply Chain? ICSE-SEIP.
• Duan, R., Alrawi, O., et al. (2021). Towards Measuring Supply Chain Attacks on Package Managers for Interpreted Languages. NDSS.
• Williams, L., Benedetti, G., et al. (2025). Research Directions in Software Supply Chain Security. ACM TOSEM.
• NCSC (2026). Software supply chain attacks: check your dependencies.
• SLSA (2025). Supply-chain Levels for Software Artifacts, v1.1.
• O'Donoghue, E., Hastings, J., et al. (2025). Software Bill of Materials in Software Supply Chain Security: A Systematic Literature Review. arXiv.
• Li, N., Zhao, Y., et al. (2025). Exploring Typo Squatting Threats in the Hugging Face Ecosystem. Internetware.