Cyber Risk Alert: Threat report published 2025-03-10T20

Malicious Packages in the Open Source Supply Chain: What FortiGuard’s November 2024 – March 2025 Data Tells Insurers

In November 2024, a malicious npm package masquerading as a legitimate development utility was downloaded more than 2,100 times before it was flagged and pulled from the registry. By the time defenders noticed, the embedded credential-stealer had already phoned home with environment variables from dozens of CI/CD pipelines. That single incident is one of thousands catalogued in FortiGuard Labs’ ongoing telemetry sweep of public package registries, and it is the kind of event that now shows up with uncomfortable regularity on cyber insurance loss runs.

Between November 2024 and March 2025, FortiGuard Labs documented sustained activity across npm, PyPI, RubyGems, and NuGet ecosystems. The dataset is large enough, and the attack techniques varied enough, that the report has direct underwriting relevance. This post distills the operational picture, translates it into insurance concepts, and outlines what brokers, underwriters, CISOs, and risk engineers should be doing with the data.

What the Telemetry Shows

FortiGuard’s threat intelligence team tracks packages that exhibit malicious behavior at install time, post-install, or on subsequent dependency resolution. Across the five-month window, the team identified and analyzed a high volume of confirmed malicious packages, with the bulk concentrated on npm and PyPI — the two registries that dominate JavaScript and Python development pipelines.

Three patterns dominate the dataset:

1. Typosquatting and impersonation. Threat actors register names that differ by a single character, a swapped dependency, or a scoped namespace from a legitimate package. Examples include crossenv mimicking cross-env, and lookalike packages that mimic internal utility libraries used by large enterprises.

2. Dependency confusion and namespace hijacking. Internal package names published privately are being preempted by attackers publishing a higher-versioned malicious package to the public registry, so the next internal build pulls the trojanized public version instead.

3. Living-off-the-pipeline. Instead of dropping a noisy executable, attackers hide payloads inside install scripts, postinstall hooks, and pre-commit hooks that execute in the developer’s local environment or in CI runners. Stealers target .npmrc, .pypirc, AWS credentials, GitHub tokens, and SSH keys.

The geographic distribution of compromised developer environments is heavily weighted toward North America and Western Europe, which mirrors where most enterprise software development occurs but also where the highest-value credentials and cloud tenants tend to live.

Why This Matters for Cyber Insurance

The supply chain risk surface is no longer a fringe concern. From an insurance perspective, three factors make malicious package activity a meaningful driver of loss:

Claims frequency. A single malicious package can produce dozens of downstream victims through transitive dependencies. When a developer at an insured organization installs a compromised utility, the resulting incident often triggers first-party costs for forensic investigation, notification, and business interruption, plus potential third-party liability when customer data is exposed. Frequency has trended upward for three consecutive years.

Severity tail. Credential theft at the build pipeline level is particularly costly because it gives attackers lateral access to production environments, source code repositories, and cloud control planes. Incident response firms regularly report multi-week containment timelines and seven-figure remediation costs when build-system compromise is involved.

Systemic correlation. A single malicious package creates a portfolio-level correlation event. Multiple insureds can be compromised by the same package on the same day. This is the kind of accumulation risk that catastrophe modelers and reinsurers watch closely, and it is a frequent topic in Resiliently’s broader quantification work, including the analysis in cyber risk quantification tools for SMBs.

For underwriters, this means that two insureds with identical revenue, headcount, and security program maturity can have very different expected loss profiles depending on their software development practices. The exposure vector is invisible to a standard application questionnaire but material to the loss forecast.

Translating the Technical Picture for Business Audiences

The mechanics of a malicious package attack are worth understanding in business terms, because the controls that prevent them are organizational as much as technical.

How the attack lands. A developer searches for a utility, copies a command from Stack Overflow, or runs npm install <name> with a typo. The package installs without visible error. A preinstall or postinstall script executes silently. That script reads well-known credential file paths, base64-encodes the contents, and POSTs them to an attacker-controlled endpoint. In some cases the payload also drops a secondary implant for persistence.

Why traditional controls miss it. Endpoint detection tools see a legitimate package manager running a legitimate script. Network filters may not flag an HTTPS POST to an unfamiliar domain if the developer’s machine has permissive egress rules. Code review catches some of these packages, but transitive dependencies — packages pulled in automatically by other packages — are rarely reviewed by name.

What the attacker gets. In most cases, the immediate prize is source code and cloud credentials. Source code leakage is itself a covered event under many cyber policies when it triggers regulatory notification, intellectual property exposure, or downstream breach. Cloud credentials lead directly to S3 bucket enumeration, KMS key theft, and — increasingly — ransomware staging, where attackers use legitimate cloud APIs to encrypt or exfiltrate data using the victim’s own tooling.

Time to detection. Median detection time for credential-stealing packages is measured in weeks, not hours, because the activity looks like normal developer behavior. This delay directly affects business interruption calculations and the cost of forensic reconstruction.

Underwriting Signals and Coverage Implications

For underwriters evaluating a risk, the malicious package threat translates into several concrete signals worth probing during submission:

• Software development footprint. Insureds that develop software in-house, operate CI/CD pipelines, or contribute to open source projects face a meaningfully different exposure profile than those that consume only commercial off-the-shelf software. A simple question about whether the insured maintains its own code repositories is now a worthwhile underwriting data point.

• Software bill of materials (SBOM) maturity. Insureds that can produce an SBOM on demand and have automated tooling for vulnerability and malicious package detection are exercising a control that materially reduces frequency. Treat SBOM capability as a positive rating factor.

• Secrets management hygiene. Environment variables, hardcoded credentials, and long-lived API keys stored in developer workspaces are the primary payload targets. Insureds using short-lived credentials, hardware-backed keys, or secrets managers reduce severity if a package executes successfully.

• Egress controls and developer workstation segmentation. Insureds that segment developer environments, enforce egress allowlists, and monitor outbound traffic from build infrastructure shorten the time-to-detection window.

On the coverage side, several gaps warrant explicit attention:

• System failure versus security failure. Some policies exclude losses arising from non-malicious code defects while including losses from malicious code. The line between a deliberately malicious package and a vulnerable package in which malware was accidentally introduced is not always clean, and coverage disputes often turn on attribution rather than impact.

• Funds transfer and social engineering exclusions. Credential theft from a developer often enables business email compromise or wire fraud at a later stage. Whether these downstream events fall under the original theft, or get carved out under social engineering sublimits with materially lower caps, can determine whether a loss is recoverable in full.

• Reputation harm and source code disclosure. When proprietary code is exfiltrated through a developer compromise, notification costs and competitive harm can be substantial. Confirm whether source code is treated as confidential business information or as a regulated data category under the policy form, since the trigger language often differs between the two.

• Bricking and rebuilding coverage. A serious supply chain compromise may require rebuilding build infrastructure, rotating every secret, and reissuing every signed artifact. Confirm whether the policy responds to the cost of reconstruction when no data subject is ultimately notified.

Recommendations by Role

The FortiGuard data suggests a short list of practical actions for each side of the insurance and security relationship.

For underwriters:

• Add supply chain hygiene questions to submission forms, including whether the insured maintains private package repositories, uses dependency pinning, and runs automated malicious package scanners in CI.
• Weight SBOM maturity and secrets management positively in rating models. Both are observable during the application process and correlate with reduced frequency and severity.
• Build accumulation scenarios tied to the most widely used registries and the most commonly installed utilities. A handful of packages account for a disproportionate share of transitive dependencies.
• Use Resiliently’s broker scorecard to benchmark control maturity across a portfolio and identify insureds whose supply chain exposure is materially above peers.

For brokers:

• Position SBOM adoption and secrets management as coverage differentiators during renewal conversations, not just as IT hygiene talking points.
• Walk insureds through supply chain scenarios during renewal, including a worked example of how a single compromised utility could affect their policy triggers, sublimits, and exclusions.
• Flag developer tool usage — including npm, PyPI, RubyGems, and NuGet — as a rating factor worth disclosing upfront, since underdiscovery at submission can complicate claims handling later.
• Encourage insureds to quantify their supply chain exposure using Resiliently’s cyber risk calculator before renewal, so that conversations about coverage are anchored in loss figures rather than abstract risk language.

For CISOs and risk managers:

• Implement automated malicious package detection directly in CI/CD pipelines, with build failure as the default response to a confirmed match.
• Enforce pinned dependencies with hash verification so that an attacker who publishes a higher-versioned malicious package cannot silently replace a trusted dependency.
• Rotate credentials on short cycles, prefer workload identity over long-lived keys, and audit .npmrc, .pypirc, and shell history for residual secrets.
• Segment developer workstations from production, enforce egress allowlists, and forward build-runner logs to a monitored SIEM so that unusual outbound traffic triggers an alert within hours rather than weeks.

Closing Thought

The FortiGuard dataset confirms what incident responders have been saying anecdotally for several years: the open source supply chain is now a primary loss vector for cyber insurance portfolios, and the gap between well-governed and poorly-governed development environments is widening. Underwriters who can read the technical signals, brokers who can translate them into coverage conversations, and CISOs who can demonstrate the right controls will all be better positioned as this exposure continues to compound.

The data is public, the patterns are documented, and the controls are well understood. The remaining work is closing the distance between what the threat actors are doing in the registries and what the policy form actually responds to after a loss.