Software supply chain risk
Supply Chain
Attack Prevention
An attacker hides one bad change inside a normal update. The rest of that update is genuine, so a list of changed files tells you nothing.
A registry scanner checks one source, the public package registry. Vigilance checks the machine.
5
Documented attacks that reached companies with no public package install.
Five attacks, and how each one arrived
- SolarWinds, 2020
- A vendor's build system
- Codecov, 2021
- An altered build script
- 3CX, 2023
- A signed vendor installer
- xz-utils, 2024
- A release archive
- polyfill.io, 2024
- A browser script tag
No developer typed npm install for any of these five. A tool that reads the public registry sees none of them.
Sources: CISA advisory AA20-352A, Codecov post-mortem, 3CX and Mandiant, the xz-utils disclosure, Sansec on polyfill.io.
What a supply chain attack is.
An attacker does not enter your network. The attacker changes software you already trust. Then you install it yourself, from your normal source.
The payload is one file, or one line in one file. It runs a command, reaches the internet, reads saved passwords, or survives a reboot. The rest of the release is the software you asked for, and it works correctly.
How each one reached a company.
| The attack | How it arrived | Who installed it |
|---|---|---|
| SolarWinds, 2020 | A network monitoring update, signed by the real vendor, that carried a backdoor in one library file. The attackers changed the code inside the vendor's own build system. CISA ordered every federal agency to disconnect the product. | IT, at government agencies and large companies |
| Codecov, 2021 | An altered upload script that ran inside build pipelines for two months. It sent the passwords and keys held in the pipeline to the attacker. | A build engineer |
| 3CX, 2023 | A desk-phone update, signed by the real vendor, that carried a backdoor. The vendor's own build server produced it. | IT, at 600,000 companies |
| xz-utils, 2024 | A backdoor hidden in the release archive of a compression library, which Linux links into remote login. One researcher found it days before it reached a stable release. | Linux vendors, in test builds |
| polyfill.io, 2024 | One script tag on more than 100,000 websites. The domain changed owner, and the new owner served malware from the same address. | A web team, years earlier |
Two sources, and most tools read one.
The developer's source. A developer adds a public package. A registry scanner reads that package in its cloud, scores it, and blocks it at the pull request. This works. If your developers pull public packages, run one.
Every other source. The other source is everything else you install: a vendor installer, a signed agent, a container image, a build robot, or your own release output. A registry scanner reads none of those. The team that owns the machines owns all of them.
One question covers every source.
Vigilance does not ask where a file came from. It needs no reputation score and no name for the attack. It asks one question: can this file do something that the version before it cannot do?
Check an update before you trust it. Give Vigilance both versions.
vigi diff --old ./current --new ./updateAsk what one file can do before it runs.
vigi profile --artifact ./installer.msiAdd --report to any check. It writes one plain HTML page, black on white, that prints and survives a mail client.
A new capability needs review. It does not prove that an update is malicious. Vigilance reports what it finds. Your team decides what to install.
Read the comparison guide →Side by side.
The two tools do different jobs. A registry scanner guards the packages your developers pull. Vigilance guards everything else that arrives on the machine.
| Question | A registry scanner | Vigilance |
|---|---|---|
| Checks a public npm or PyPI package | Yes | Yes |
| Blocks a bad package at the pull request | Yes | No |
| Checks a vendor installer, an MSI or a zip | No | Yes |
| Checks a container image | No | Yes |
| Checks your own build output | No | Yes |
| Watches software already on the machine | No | Yes, on a schedule |
| Needs the attack to be known first | For some of its checks | No |
| Needs a cloud account | Yes | No. Pro opens no connection at all |
| Needs a developer to run it | Yes | No, IT installs it |
For enterprise IT
Built for the team that owns the machines.
IT installs most of the software on a company's machines. A developer chooses almost none of it. Three parts of the product are for that team.
The check belongs to the administrator. It asks for a password once, at install. After that the program, the timer and the record belong to the administrator. A program that runs as a normal user cannot switch it off.
One line adds a machine. Push it from Intune, Jamf, a GPO or your image. There is no agent, no service, and no console to sign in to.
A missing report is an alarm. Each machine signs its own receipt into a folder that your backup already covers. One command turns that folder into one page. The page shows every machine that went quiet.
See how the fleet page works →Common questions.
What is a software supply chain attack?
An attacker changes software you already trust. Then you install it yourself. The real vendor signs the update, and it arrives from your normal source. The payload is one file, or one line in one file.
Is Vigilance a dependency scanner?
No. A dependency scanner reads public packages in a cloud and scores them. Vigilance reads the files on your own machine, whoever sent them. It reports the file that can do something the version before it cannot do.
Do I need a registry scanner as well?
If your developers pull public packages, yes. A registry scanner blocks a bad package at the pull request, which Vigilance does not do. Many teams run both.
Does it need the internet or a cloud account?
The Free plan runs online and reports every run. Pro opens no network connection at all, so it works on an air-gapped network with no cloud account.
Who runs it, IT or the developers?
Either. IT installs most of the software on a company's machines. The schedule and the record belong to the administrator. A program that runs as a normal user cannot switch it off.
What does it not do?
It does not know what a CVE is. It holds no reputation list, and there is no AI in it. It will not tell you that a package is popular, or that a maintainer looks suspicious. It reports the file that gained a capability, and nothing else.
Check your next update.
Compare two versions in the browser, or download Vigilance to scan your own files.