Deep Engineering #33: Why Lockfiles Are Part of Your Threat Model with Ivo Balbaert
PackageGate and Shai-Hulud 2.0 expose holes in the safety net
Multi-Agent Code Review That Catches Real Issues
Code review is stuck. It's slow (manual), noisy (tools), or misses things. Qodo 2.0 is different. With highest precision & recall, it finds critical issues other review tools miss, while limiting noise. Learning from your codebase & PR history, Qodo gives fixes developers actually use.
Qodo CEO Itamar Friedman in a conversation with Deep Engineering said that SWE-bench mainly measures code generation rather than maintainability or security—and that code can pass tests while still introducing serious issues. Read the full piece:
✍️From the editor’s desk,
Welcome to the 33rd issue of Deep Engineering!
On Jan 26, 2026, Oren Yomtov (Koi Security) wrote about finding six “PackageGate” bypasses across JavaScript package managers—bypasses that can undermine the two defenses widely repeated after Shai-Hulud: disable lifecycle scripts and commit lockfiles with integrity checks.
The lockfile is now part of the boundary you rely on, and the boundary can fail at the edges. This is the focus for today’s issue. We also bring you Ivo Balbaert’s (lecturer in web programming and databases at CVO Antwerpen and Packt author), fifth article in our ongoing Building with Mojo series. Today’s Mojo deep dive covers how Pixi structures environments and uses pixi.lock, and how modules and packages get imported and shipped as artifacts.
Let’s get started.
Your Lockfile Is Now Part of Your Threat Model
Late last year, the Shai-Hulud 2.0 incident underscored why lockfiles have become security-critical. This aggressive npm supply chain attack compromised over 700 packages and exposed credentials from some 25,000 repositories. Attackers hijacked maintainer accounts of popular projects (e.g. Postman, Zapier) and pushed malicious updates. In each infected package, a rogue preinstall script ran early, before tests or security scans, to surreptitiously install tools and exfiltrate secrets. Developer machines, CI pipelines, and cloud workloads that pulled these packages had credentials stolen and uploaded to attacker-controlled repositories. This worm-like malware spread rapidly through trusted package workflows – a masterclass in how our reliance on open-source packages can be turned against us. Traditional network defenses offered little protection when the attack piggybacked on legitimate package updates.
The immediate response across the JavaScript ecosystem was to double down on two measures: disable implicit code execution and pin every dependency. Security guides and corporate policies began advising developers to run package managers with “ignore scripts” flags (to block auto-running install scripts) and to check in lockfiles for all projects. The logic behind this was that If no untrusted postinstall code runs, and if every dependency version is locked, attackers can’t sneak in. In theory, “if malicious code can’t run on install, and your dependency tree is pinned, you’re covered”.
Holes in the Safety Net
However, the reality proved far more complicated. In January this year, Oren Yomtov, security researcher with Koi Security revealed “PackageGate,” a set of six zero-day vulnerabilities spanning multiple package managers (npm, pnpm, Bun, and others) that blew holes through these defenses. One flaw in pnpm (CVE-2025-69263) showed how a lockfile could be rendered toothless: pnpm was recording certain git or HTTP-based dependencies without any integrity hash in its lockfile, so a remote server could insidiously serve different code on each install – completely undermining the “locked” state. Another pnpm bug (CVE-2025-69264) let malicious git-hosted packages execute code during install despite script blocking features. Attackers found ways to bypass lockfile integrity and re-enable install scripts, enabling remote code execution even in projects that followed best practices.
The Shai-Hulud attackers (and copycats like “PhantomRaven”) were already experimenting with such techniques, such as sneaking malicious directives via nested git dependencies. It became clear that the lockfile itself is part of the threat model: any weakness in how it’s generated or enforced can be targeted. According to Javed Hasan, co-founder and CEO of Lineaje, this underscores “how brittle many existing trust assumptions remain” in our software pipelines. Even the largest package registry was not immune to complacency – npm’s maintainers initially declined to patch one of the reported exploits from Yomtov, deeming it “works as expected”. This response was scary: the very safety net (lockfiles and script blocking) installed after the worst supply-chain attack in npm’s history was proven to have holes, and not all providers rushed to fix them.
Treating lockfiles as security artifacts means ensuring they contain strong integrity guarantees and that your build process honors them. Modern lockfiles (whether pixi.lock, package-lock.json, or Cargo.lock) don’t just pin versions; they often embed a cryptographic hash for each package download. During installation, the package manager is supposed to verify the content against those hashes and fail if there’s a mismatch. This is how a lockfile acts as a gatekeeper: if an attacker compromises a registry or MITMs a connection, they can’t slip altered code past the hash check. However, the pnpm incident showed that if those hashes are omitted or not verified in all cases, the lockfile “provides no protection” at all. Similarly, if your tool allows alternate install flows (like git URLs or tarball links) without equal scrutiny, attackers will find that side door. Part of making lockfiles a security boundary is keeping your tooling up-to-date – in this case, upgrading pnpm promptly to get the patch that reinstates hash enforcement.
Hardening the Supply Chain
The wave of supply-chain compromises has prompted ecosystem-wide changes. One major vector in Shai-Hulud’s spread was stolen npm credentials – which allowed attackers to publish malicious versions of packages they didn’t own. In response, registry providers are tightening authentication and publishing workflows. For example, as of November 2025 GitHub (which operates npm) disabled classic long-lived npm tokens and required a move to fine-grained access tokens with 2FA enforcement and expiration. By mid-November, all legacy npm tokens were revoked and replaced by short-lived 2-hour session tokens for publishing. This means even if an attacker pilfers a token from a CI log or a maintainer’s machine, its window of use is dramatically narrowed. GitHub’s guidance to maintainers is to adopt “trusted publishing” – tying package publishing to your CI’s identity via OpenID Connect – and to mandate 2FA for any package modifications. This approach binds the act of releasing a new package to a verified workflow (for instance, a signed-in GitHub Actions job), removing the human weakness of stolen passwords or tokens from the equation. It’s a direct policy response to attacks: make the act of injecting a bad update much harder.
Other ecosystem measures complement the lockfile’s role in security. Services like GitHub’s Dependabot and Microsoft Defender for Cloud now alert on suspicious package behavior or known-compromised dependencies, encouraging teams to “freeze” or replace those dependencies quickly. Two defenses became “standard advice” after the Shai-Hulud worm attacks:
disable lifecycle scripts that run automatically during installation
Commit lockfiles with integrity checks (such as
package-lock.jsonorpnpm-lock.yaml) to version control.
Lockfiles record the exact dependency versions and integrity hashes, and on later installs the package manager checks downloaded packages against those hashes and fails if they don’t match—so a compromised package update should be blocked by the integrity mismatch. However, Yomtov argues that the two defenses remain worth following but do not fully hold if package-manager bypasses exist.
In Mojo’s Pixi workflow, as Ivo Balbaert demonstrates in today’s feature article, developers can use
pixi install --frozen(or setPIXI_FROZEN=true) to ensure CI installs only what’s in the lockfile and fails if the lock isn’t up to date. This mirrors analogous flags likenpm ciorpip install --require-hashesin other ecosystems. The overarching theme is consistency: the lockfile and the published packages must match, and any deviation is a potential intrusion. By enforcing this at multiple levels—developer machines, CI pipelines, and registry policies—we establish the lockfile as a firm security checkpoint rather than a passive snapshot.
If the code is the new perimeter in cloud-native apps, then the lockfile is quickly becoming the new gatekeeper in our build systems. It’s not a silver bullet; as we’ve seen, it can be bypassed if we get complacent. But when used in tandem with hardened tooling and policies, the lockfile is a powerful line of defense.
Best Practices
Pin and verify every dependency: Commit and maintain your lockfiles (e.g.
pixi.lock,package-lock.json). Use package managers’ integrity features so that each dependency’s content is verified against a hash. If your ecosystem supports it, require hashes for any external or git-based dependencies as well.Enforce frozen installs in CI: Configure CI/CD pipelines to install dependencies in locked mode (e.g. Pixi’s
--frozenflag ornpm ci). This ensures no new package versions or surprises slip in during automated builds. Any lockfile change should be deliberate and code-reviewed.Avoid unofficial sources and dynamic resolution: Prefer canonical registry packages over direct URLs or git references. If you must use a git or tarball dependency, pin it to a specific commit/tag and treat it with extra scrutiny. Unpinned artifacts can bypass lockfile guarantees.
Harden publisher credentials: Enable 2FA on package registries and migrate to fine-grained, short-lived tokens or OIDC-based trusted publishing. Eliminate long-lived secrets from your workflows; use ephemeral credentials tied to CI jobs so that stolen credentials quickly become useless.
Monitor and react quickly: Stay aware of security advisories for your package manager (e.g. pnpm CVEs) and apply updates that patch lockfile or installer vulnerabilities. Monitor dependency changes in your supply chain (via tools or manual review) and have an incident response plan (e.g. rapid credential rotation and dependency isolation) for suspected supply-chain compromises. Each lockfile update is a security event – treat it with the same caution you would a code change in your core application.
In Mojo’s Pixi workflow, as Ivo Balbaert shows in today’s feature on modules, packages, and Pixi, pixi.lock and pixi install --frozen offer a concrete example of how lockfiles act as a security boundary and under what conditions. Balbaert’s article also walks through Mojo’s module/package structure and import syntax, including re-exporting via __init__.mojo, and shows how to import packages from source or as compiled .mojopkg artifacts, plus how to pull in external Mojo community packages with Pixi.
🧠Expert Insight:
🛠️Tool of the Week
Cosign is a CLI and set of workflows for signing and verifying container images (and related supply-chain artifacts) using Sigstore’s model (including keyless signing via OIDC). It’s designed for teams that want cryptographic “who produced this?” and “has it changed?” checks that can be automated in CI/CD and enforced at deploy time.
Highlights:
Keyless signing with workload identity: Cosign can sign artifacts using OIDC-issued identities (no long-lived private key to manage), so signatures are tied to who/what ran the build (e.g., a CI workflow).
OCI-native signatures and attestations: It stores signatures (and can store SBOM/provenance attestations) alongside OCI artifacts in registries, so verification works wherever the image travels.
Policy-friendly verification primitives: Cosign supports verifying by identity claims (issuer/subject), signatures, transparency log inclusion, and certificate chains—building blocks you can wire into admission controllers or deployment gates.
📎Tech Briefs
GitHub eyes restrictions on pull requests to rein in AI-based code deluge on maintainers: GitHub is weighing tighter PR controls and filtering as maintainers report a surge of low-quality, AI-generated submissions overwhelming open-source review capacity.
Notepad++ updater was compromised for 6 months in supply-chain attack: Attackers hijacked Notepad++ update infrastructure to selectively deliver trojanized installers to targeted users, illustrating how “trusted update paths” become the distribution channel.
Xcode 26.3 adds support for Claude, Codex, and other agentic tools via MCP: Apple is integrating agentic coding tools directly into Xcode, including support for Model Context Protocol (MCP), pushing more automation into the IDE workflow.
CVE-2026-23890: pnpm path traversal in bin linking :NVD describes a pnpm flaw where malicious packages can create executable shims/symlinks outside
node_modules/.bin, turning installs into a filesystem write primitive.‘PackageGate’ flaws open JavaScript ecosystem to supply chain attacks: Coverage of the PackageGate class of issues where package-manager behavior can bypass script-blocking / lockfile-based assumptions and enable execution through attacker-controlled dependencies.
That’s all for today. Thank you for reading this issue of Deep Engineering.
We’ll be back next week with more expert-led content.
Stay awesome,
Divya Anne Selvaraj
Editor-in-Chief, Deep Engineering
If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want to advertise with us.