Supply chain attacks on payroll software: how to defend

Why payroll software is a prime target

A single payroll database is enough for large-scale identity theft or payment fraud. But a well-protected application resists direct attacks. A dependency runs on the inside, with no authentication, and with access to everything the process can see: environment variables, configuration files, internal network.

A modern Node, PHP or Python application ships hundreds of transitive dependencies. You only chose a small fraction of them.

The four vectors to know

1. The compromised legitimate package

The attacker takes over a maintainer account (phishing, reused password, stolen publish token) or gets handed maintenance of an abandoned project, then publishes a poisoned version. The textbook case is event-stream in 2018: a new maintainer added a dependency, flatmap-stream, that targeted the wallets of one specific bitcoin application. The xz-utils backdoor in 2024 showed the same logic over several years, at the operating system level.

2. Typosquatting

A package with a name almost identical to a popular dependency (a swapped letter, an extra dash, a plausible prefix) waits for a typo in an npm install or pip install. Its install script runs immediately.

3. Dependency confusion

Your internal package names leak (published lock files, error messages, job ads). An attacker publishes a package with the same name on the public registry with a higher version number. A misconfigured package manager prefers the public one. The technique was publicly demonstrated in 2021 against many large companies.

4. The build chain

A third-party GitHub Action referenced by a mutable tag (@v3) can be changed after the fact. If your workflow gives it access to deployment secrets, it reads them. Same risk with an unpinned Docker base image.

For a per-ecosystem overview, see our article on npm, Composer and pip attacks.

What the attacker actually gets

Poisoned code rarely runs "in production" the way you picture it. It runs:

• at install time (npm postinstall, setup.py), so on developer machines and in CI;
• at build time, where deployment secrets live;
• at runtime, with access to DATABASE_URL, payment provider keys and the payslip storage service.

A database key or a cloud service account is then enough to read the whole database without ever touching the application again.

How to test it

1. Inventory: generate the full dependency list, transitive ones included (npm ls --all, composer show -t, pip freeze or a CycloneDX SBOM). Count them.
2. Lock files: check that every repository has a committed lock file and that CI installs in strict mode (npm ci, composer install without update, pip install --require-hashes).
3. Install scripts: list the packages that declare preinstall or postinstall scripts. Each one needs a justification.
4. Internal names: for each private package, check whether a package with the same name exists on the public registry. Make sure your configuration forces the private registry for your scope.
5. CI/CD: review your workflows. Every third-party action must be pinned to a commit hash. Check which secrets each job actually receives.
6. Reachable secrets: from a production container, list the environment variables. Every secret there is readable by any dependency. Also check your Git history.
7. Network egress: check whether your servers can reach any Internet address. Exfiltration needs a way out.

How to fix it

• Lock: lock files, strict installs, updates reviewed through pull requests (Dependabot or Renovate, never auto-merged to the main branch).
• Reduce: remove unused dependencies. Each one is third-party code running with your rights.
• Disable install scripts by default (npm config set ignore-scripts true) and allow them case by case.
• Partition secrets: test CI does not need production keys. In production, prefer short-lived workload identities over static keys.
• Filter egress from application servers to an allowlist of hosts.
• Separate the marketing site from the application: a compromised WordPress plugin must offer no path to the payroll database.
• Prepare the response: be able to tell within hours which versions ran where and which secrets were exposed, so you can revoke them and scope the breach notification.

What changes when an AI agent joins the chain

AI agents add a new category of dependencies: the MCP servers, plugins and tools they load. An MCP server installed from npm runs with the agent's rights and sees what it sees. The npm worm and fake postmark-mcp server episode showed that a harmless-looking tool could silently copy the emails sent by the agent.

The same rules apply: pin MCP server versions, read their code before installing, give them only the secrets they need, and monitor what they send outside. If an agent in your product handles payroll data with third-party tools, the Agent Red Team Express checks in five days what a poisoned tool or an injection could make it exfiltrate.