The build that should have failed:
a gutted npm package, four years as latest, and the gate that refuses it

What happened

faker was one of the most depended-on packages on npm, a generator of fake names, addresses and text used in test suites everywhere. In November 2020 its maintainer wrote that he would no longer support large companies with his free work. On 5 January 2022 he published faker 6.6.6. The package.json still points at index.js; the file is not in the tarball. The README consists of one line, a question about Aaron Swartz. A day later the same maintainer pushed a colors.js release that printed "LIBERTY" in an infinite loop, which is the incident most people remember. Those were two different sabotages: colors was made noisy, faker was made empty.

GitHub suspended the account. npm reverted colors to a safe version. faker was handled differently: the community forked the working code to @faker-js/faker, and the original package was left as its author published it. That is the state of the registry today. The latest dist-tag is 6.6.6, the version is not deprecated, and in the week ending 6 September 2026 the package was downloaded 1,894,806 times.

Nothing in the toolchain says no. The registry serves it, the install succeeds, and the build breaks somewhere else, later.

Why scanners did not stop it, and mostly still do not

This is the shape of every supply-chain incident, not just this one. The hijacked axios release earlier this year, the event-stream backdoor, ua-parser-js, coa, rc: in every case the malicious version was live and installable for hours or days before an advisory existed. Vulnerability databases are a record of what has been written up. A CI pipeline needs a decision about what it is about to install right now.

Timeline

• November 2020The maintainer of colors and faker states publicly that he will no longer support commercial users with free work.
• 5 January 2022faker 6.6.6 published. No functional code in the tarball. Becomes the latest tag.
• 6 to 8 January 2022colors 1.4.44-liberty-2 and 1.4.1 published with an infinite loop. Thousands of downstream builds fail. GitHub suspends the account; npm reverts colors.
• 9 January 2022BleepingComputer reports both sabotages. faker is later forked to @faker-js/faker by a community team.
• 22 March 2022GHSA-5w9c-rv96-fr7g published for faker 6.6.6, severity High, 76 days after the release.
• September 20266.6.6 is still latest, not deprecated, 1.9 million weekly downloads. The CyberXYZ gate refuses it on a live pull request every time the check runs.

Indicators

What DepAlert does with that build

DepAlert is the CyberXYZ dependency gate for CI. It runs before the pipeline installs anything, reads the manifests in the repository, sends the resolved package list to the same decision engine that answers our install-time proxy, and turns the build red if any package comes back malicious or quarantined. It does not wait for a CVE. It fails closed: if the engine cannot be reached, the job fails with its own exit code rather than letting an unchecked package through.

This is the real output from the pull request we keep open on the action's own repository. It bumps an example app to faker 6.6.6 and the gate has refused it on every run.

▸ Run CyberXYZSecurity/depalert-action@v1
  xyz depalert scan package-lock.json
  XYZ DepAlert: scanning 2 packages

                        1 Threat(s) Detected
  Package@Version    Decision   Scores       Signals   Safe Version
  faker@6.6.6        BLOCK      CVSS 7.5     2         5.5.3
                                XYZ 3.7
                                EPSS 0.59%

  1 clean  1 blocked  0 quarantined  0 alerted
  Gate FAILED: 1 threat(s) detected (worst: BLOCK)

fig. 01 · the failed check on the live example · express 4.19.2 in the same lockfile passed

Three ways to add it

One step on GitHub Actions, from the Marketplace:

One include on GitLab, from the CI/CD catalog:

Or let the CLI detect the provider from the git remote and write the file, on GitHub, GitLab or Azure DevOps:

In every case the one thing that cannot be automated is adding the API key as a CI secret named XYZ_API_KEY. The key is created in the CyberXYZ dashboard with read and scan permissions only; never give a CI secret admin rights.

What it is not

DepAlert checks what the manifest says will be installed. It does not watch network traffic or processes on the runner, and it does not block lockfile drift. To gate what is actually fetched during npm install, pip install or go get, the CyberXYZ proxy goes on the runner as well; the gate and the proxy return the same verdict from the same engine. And DepAlert is not a replacement for a vulnerability scanner: scanners tell you what is known to be wrong in the tree you already have, the gate stops the next thing from getting in.

MITRE ATT&CK

Recommended actions

Short term: set the gate to quarantine once you have a week of baseline, so day-zero signals such as new-dependency injection, version jumps and lifecycle-hook changes also fail the build. Put the CyberXYZ proxy on the runners for installs that bypass the lockfile.

Long term: treat the registry's latest tag as an input, not a decision. What gets installed should be decided by something that has an opinion about the version, on the day it is published, whether or not anyone has written an advisory yet.