A Trojan horse is a program that appears useful but contains hidden malicious code that runs when you launch it. Unlike a virus or worm, it does not copy itself; it depends on someone choosing to run it. The same trick now shows up in software supply chains, where the disguise is a trusted package.
How do standards define a Trojan?
NIST's glossary gives two close definitions. One, from CNSS and RFC 4949, calls a Trojan horse a computer program that appears to have a useful function but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting the legitimate authorizations of the entity that runs it. Another, from NIST SP 800-28, says it is a useful or seemingly useful program that contains hidden code of a malicious nature that executes when the program is invoked.
Two parts matter: the visible function is real or plausible, and the hidden function runs with the permissions of whoever invokes it.
How is it different from a virus or a worm?
NIST defines a virus as malicious software that propagates itself by modifying other programs to include a possibly changed copy of itself, and that runs when the infected program is invoked. A worm is a self-contained program that can propagate itself through systems or networks, and NIST SP 800-28 adds that it does so without needing a host program or user intervention.
A Trojan does neither. It carries a payload, but it does not spread by itself. It spreads because people share it, download it, or install it from a source they trust. That is why the common phrase "Trojan horse virus" is a little off: a Trojan is not a virus under these definitions, though a Trojan can deliver one.
How does a Trojan reach people?
MITRE ATT&CK describes the user-facing side as User Execution, where adversaries rely on users to take an action: running a downloaded file, enabling a remote access tool, running malicious JavaScript in a browser, or pasting and executing code manually. Tech-support scams are one pattern, with phishing or phone calls steering victims to malicious sites.
It also describes Masquerading, where the name or location of an object is manipulated so it looks legitimate to users and security tools. That includes manipulating file metadata, tricking users about the file type, and giving malicious files the names of legitimate tasks or services.
What is the supply chain version?
ATT&CK's Supply Chain Compromise technique covers manipulation of products or delivery mechanisms before the final consumer receives them. Its list of stages includes development tools, development environments, source code repositories, source code in open-source dependencies, and software update or distribution mechanisms, plus replacement of legitimate software with modified versions.
That is a Trojan at a larger scale: a package or update that does what you expect and also does something you did not choose. The user in this case is a build system, which runs installation scripts with real credentials.
A constructed example
A developer searches for a helper library for parsing a file format and installs one with a plausible name and a working README. It parses files correctly. During installation, a script reads environment variables, including a cloud access key in the build environment, and sends them to an external address. The library worked, which is why nobody suspected it. The hidden function was invoked by the install step and ran with the developer's permissions.
How to check or apply this
- Install software only from sources you can verify, and prefer signed releases.
- Do not let installation scripts run with broad credentials. Use short-lived, narrowly scoped credentials in builds.
- Review new dependencies before adding them: age, maintainers, download history, repository activity, and whether the name closely resembles a more popular one.
- Pin dependency versions and review changes in lock files.
- Keep an SBOM so you can answer "do we use this package?" within minutes when one is found to be malicious.
- Restrict what users can run on endpoints, and keep users trained to question unexpected prompts.
- Monitor outbound connections from build systems.
Safeguard's dependency scanning and zero-day discovery help find malicious or vulnerable packages in your dependency tree, and policies and gates can stop a new dependency from merging until it is reviewed. It does not replace endpoint protection.
Quick check
Does a Trojan horse replicate itself?
No. Under NIST definitions a virus or worm propagates itself. A Trojan relies on a user, or a process, choosing to run it.
Can a package manager dependency be a Trojan?
Yes. It can behave as advertised while carrying hidden code that runs at install time or at runtime, which is the supply chain form of the same idea.
Sources
- NIST CSRC Glossary, Trojan horse
- NIST CSRC Glossary, virus
- NIST CSRC Glossary, worm
- MITRE ATT&CK, User Execution (T1204)
- MITRE ATT&CK, Masquerading (T1036)
- MITRE ATT&CK, Supply Chain Compromise (T1195)
Last reviewed: 18 October 2026.
