To define malicious code: it is any code, script, or program deliberately written to harm a system, steal data, or gain unauthorized access — regardless of the language it is written in or how it reaches the target. The term covers everything from a decades-old file virus to a modern payload smuggled into an open-source package. What unites them is intent: the author meant to cause harm.
The distinction that trips people up is intent versus effect. A buggy script that accidentally deletes files is not malicious code — it is a defect. Malicious code is authored to do damage. Understanding the categories matters because the defenses differ sharply between them.
The classic categories
Traditional malware taxonomy still holds up, because the mechanisms persist even as delivery changes.
Viruses attach themselves to a legitimate file or program and spread when that host is executed. They need a carrier and a user action to propagate.
Worms are self-propagating. Unlike a virus, a worm does not need a host file or a user to run it — it exploits a vulnerability to copy itself across a network automatically. This self-replication is why worms historically caused the fastest, widest outbreaks.
Trojans disguise themselves as something useful. The user installs what looks like a legitimate tool, and the hidden payload runs alongside or instead of the advertised function. Trojans rely on social engineering rather than self-replication.
Ransomware encrypts a victim's data and demands payment for the key. It has become the dominant financially-motivated malware because it monetizes access directly.
Spyware and keyloggers run quietly and exfiltrate data — credentials, keystrokes, screenshots — without disrupting the system, so they can persist for a long time undetected.
Rootkits hide the presence of other malicious code by subverting the operating system itself, making detection by ordinary tools difficult.
The modern shift: malicious code in the supply chain
The categories above describe what malicious code does. The bigger change over the last several years is how it arrives. Increasingly, it does not come as an email attachment — it comes as a dependency.
A developer runs npm install, pip install, or pulls a container image, and malicious code executes inside the build or on the developer's machine. Common patterns include:
- Typosquatting: a package named almost identically to a popular one (
reqeustsforrequests) that runs malicious code on install. - Dependency confusion: a public package published with the same name as a company's private internal package, tricking the resolver into pulling the attacker's version.
- Account takeover: a legitimate, popular package gets a malicious new version after its maintainer's credentials are compromised.
- Install-time scripts:
postinstallhooks that run arbitrary code the moment a package lands, often exfiltrating environment variables and tokens.
This matters because the malicious code executes in trusted environments — CI runners and developer laptops — that hold cloud credentials, signing keys, and source access. A traditional antivirus scanning your Downloads folder does nothing about a compromised transitive dependency five levels deep in your build.
How malicious code executes
Regardless of category, malicious code needs to run. The main execution paths:
- Direct execution: the user runs a Trojan or opens an infected document with macros enabled.
- Exploitation: the code exploits a vulnerability (a memory-safety bug, a deserialization flaw) to run without any user action — the worm model.
- Build and install hooks: package manager lifecycle scripts that run automatically during dependency installation.
- Injection: code injected into a running application through an unvalidated input, as in cross-site scripting or SQL injection, where the "malicious code" is data the app mistakenly treats as instructions.
That last category blurs the line between malicious code and application vulnerabilities. Cross-site scripting, for example, is malicious code (usually JavaScript) delivered through a flaw in how a web app handles untrusted input.
Defending against each type
No single control stops all malicious code. Layer defenses to match the delivery paths.
For traditional malware: endpoint detection and response, application allowlisting, and least-privilege user accounts. Keep systems patched so worms have no vulnerability to exploit.
For supply-chain malicious code: this is where most engineering teams are underinvested. Pin dependencies with lockfiles, disable install scripts by default and allowlist the few that need them, and run software composition analysis to catch known-bad package versions before they reach production. An SCA tool such as Safeguard can flag a flagged or malicious package anywhere in your transitive dependency tree, including the deep transitive layers a human reviewer never reads. Our SCA overview covers how this works in practice.
For injection-based code: validate and encode all untrusted input, use parameterized queries, and set a strict Content-Security-Policy. Dynamic testing against the running app catches the paths that reach an injection sink — see our DAST product.
For everything: least privilege limits blast radius. Malicious code that runs as an unprivileged user with no network egress and no secrets in scope can do far less damage than the same code running in an over-permissioned CI job.
Detection signals
Even with strong prevention, assume some malicious code gets in. Watch for:
- Unexpected outbound network connections, especially from build environments
- New or modified files in system directories
- Processes with unusual parent-child relationships
- Spikes in resource usage that do not match workload
- Install scripts making network calls during dependency resolution
The supply-chain signals are the ones most teams do not monitor. A postinstall script reaching out to an unfamiliar host during npm install is a strong indicator, and it is trivial to miss without the right instrumentation.
FAQ
What is the simplest definition of malicious code?
Any code written with the intent to harm a system, steal or destroy data, or gain unauthorized access. Intent is the defining feature — an accidental bug is not malicious code even if it causes damage.
Is malware the same as malicious code?
Malware is a subset. "Malicious code" is the broader term and includes injected scripts (like XSS payloads) and malicious package versions that people do not always call "malware." In everyday use the terms overlap heavily.
What's the most overlooked type of malicious code today?
Supply-chain payloads delivered through dependencies. They execute in trusted build environments, bypass endpoint antivirus, and hide in transitive dependencies that no one reviews. Composition analysis is the main defense.
Can antivirus stop all malicious code?
No. Antivirus is effective against known file-based malware but does little against injection-based code, zero-day exploits, or malicious dependency versions inside your build pipeline. You need layered controls, not a single scanner.