Malware
Supply-chain attack
Supply-chain attack is compromising something you depend on, such as a plugin, a package, a CDN script, or a vendor account, so the attack arrives through the trusted route.
How it is measured
Map what you depend on: composer and npm lockfiles, WordPress plugins and themes, third-party script tags, build tools, and service accounts. For each, track version, source, and who can publish. A change you did not make, such as a new maintainer or an unexpected version, is the signal.
Detection is by comparison: lockfile hashes, Subresource Integrity on external scripts, and file-integrity checks after updates. Watch advisories for the components you use.
Worked example
A developer runs npm install for a small Astro blog, and a transitive dependency, 'color-helper-lite', has a new minor version published by an account that took over from the original author. Its postinstall script reads ~/.npmrc and POSTs it to an unfamiliar host.
The lockfile in version control pins the old version, so CI stays safe, but the developer's laptop had no lockfile check. The npm token on that laptop has to be revoked and the package version blocked.
How it differs
Typosquatting tricks you into picking the wrong name, so you install the attacker's package yourself. A supply-chain attack goes further: the thing you meant to use, or a dependency under it, is itself tampered with. Squatting needs your mistake; compromise of the real package needs none.
Common errors
Pinning direct dependencies and ignoring transitive ones. Updating blindly on a schedule. Running install scripts with publishing tokens in the environment. Loading unversioned scripts from third-party CDNs. Assuming popularity equals safety.
In practice
Commit lockfiles and install from them, review diffs for dependency updates, and turn off install scripts where you can. Add SRI to external scripts or self-host them. Keep publishing tokens off developer laptops and out of build steps that do not need them.