Manu Shukla

Posted on Jul 30 • Originally published at ecorpit.com

GitHub Dependabot malware alerts now cover npm, PyPI and more: how to turn them on (2026)

#supplychainsecurity #dependabot #github #npm

GitHub Dependabot malware alerts now cover npm, PyPI and more: how to turn them on (2026)

Summary. On 28 July 2026 GitHub started ingesting malware advisories from the OpenSSF malicious-packages project into the GitHub Advisory Database, so Dependabot malware alerts now flag malicious packages across npm, PyPI and more, not npm alone. If you already had malware alerting on, you got the wider coverage automatically, at no extra cost ($0 on top of a GitHub account). The timing is not academic. Sonatype logged 1.8 million malicious open-source packages over the past decade, and in Q2 2026 npm alone carried 96.6% of malicious package counts, with PyPI making up 48.5% of all non-npm activity. A single hit can be costly: IBM put the global average data breach at $4.99 million in 2026. This guide shows exactly how to switch the alerts on for a repository and an organization, what a malware alert means, how to respond when one fires, and which controls to layer around it.

Malware alerts are not the same as ordinary Dependabot vulnerability alerts. A vulnerability alert says a dependency has a known weakness you should patch eventually. A malware alert says a package in your dependency graph is actively malicious and is trying to run code, steal tokens or exfiltrate data. The response is different, and faster.

What changed on 28 July 2026

GitHub's changelog entry is short and specific: "advisories from the OpenSSF malicious-packages project are automatically ingested into the GitHub Advisory Database, giving you broader coverage across ecosystems including npm, PyPI, and more." You can browse the combined set with the type:malware filter at github.com/advisories.

This builds on an earlier step. GitHub first shipped Dependabot malware detection for npm on 17 March 2026, covering a single ecosystem with GitHub's own advisory data. The July change adds the OpenSSF malicious-packages feed, a community-maintained repository of confirmed malicious package versions, which pushes coverage past npm into PyPI and other package managers. The mechanism is the same either way: Dependabot matches the packages in your dependency graph against the advisory data and raises an alert when it finds one flagged as malware.

The table below shows the practical shift for a team's dependency graph.

Ecosystem	Before 28 July 2026	After 28 July 2026
npm	Malware alerts (since 17 March 2026)	Malware alerts
PyPI	No malware alerts	Malware alerts (OpenSSF data)
Additional OpenSSF ecosystems	No malware alerts	Malware alerts (OpenSSF data)
Alert surface	Dependabot alerts, `type:malware`	Dependabot alerts, `type:malware`
Extra configuration needed	Not applicable	None if already enabled

Why this matters: the 2026 supply-chain threat picture

Open-source malware stopped being an occasional nuisance some time ago. In its Q2 2026 Open Source Malware Index, published on 9 July 2026, Sonatype reported passing 1.8 million malicious packages logged across ecosystems over the past decade, with npm responsible for 96.6% of the quarter's malicious package counts. Outside npm, the activity concentrated hard: PyPI accounted for 48.5% and NuGet 38.0% of all non-npm malicious activity, with Hugging Face models and RubyGems making up much of the rest.

The campaigns behind those numbers explain why a package-name blocklist is not enough. Sonatype tracked self-propagating npm malware such as Shai-Hulud Miasma, which abused the binding.gyp build file to run at install time and harvest developer and CI/CD data. It documented a 176-package npm campaign built to win dependency-confusion resolution races against internal packages, and the Atomic Arch campaign that reached around 1,500 packages across multiple waves. It also caught malicious PyTorch Lightning versions uploaded to PyPI after a publisher account compromise, and Lazarus Group brandjacking on npm with packages pulling up to 500 weekly downloads.

The through-line, in Sonatype's own words, is that "when trusted paths become attack paths, security needs to move earlier, faster, and with more context." Dependabot malware alerts are one of those earlier controls: they sit on your dependency graph and warn you when a package you already depend on, directly or transitively, is confirmed malicious. For Indian teams that ship on tight timelines, this is the same discipline we describe in our npm install-scripts approval guide and our npm trusted-publishing and cache-poisoning hardening guide.

How to turn on Dependabot malware alerts

Malware alerting rides on top of Dependabot alerts, so you enable Dependabot alerts first, then the malware alerts toggle. Both are free on public repositories and included with GitHub Advanced Security controls on private repositories. Follow GitHub's configuration docs for the exact current wording.

For a single repository: open the repository, click Settings, then in the sidebar under Security open Code security (Advanced Security). Enable Dependabot alerts if it is off, then enable Malware alerts in the Dependabot alerts section.

For a whole organization: open Organization settings, go to Code security, and enable Dependabot alerts and Malware alerts for all repositories, or set them as the default for new repositories. Enabling at the organization level is the right call for anything past a handful of repos, because a per-repo rollout leaves gaps exactly where an unmaintained project is most likely to pull in a bad dependency.

Step	Repository	Organization
Location	Repo Settings, Code security	Org Settings, Code security
Prerequisite toggle	Dependabot alerts on	Dependabot alerts on
Malware toggle	Malware alerts, per repo	Malware alerts, all or default
Best for	One project or a pilot	Standardising across every repo
Who should own it	Repo maintainer	Security or platform team

Once enabled, the extra coverage from the 28 July change is automatic. GitHub states plainly that "if you already have malware alerting enabled, you will automatically benefit from the expanded coverage without any additional configuration needed." Alerts appear in the repository's Security tab under Dependabot alerts; filter with type:malware to see only the malware ones.

What a malware alert means, and how to respond

Treat a malware alert as a live incident, not a backlog ticket. A malicious package is designed to execute, and much of the 2026 malware Sonatype tracked runs during install, build or CI/CD rather than at application runtime, so the damage can be done before your tests run. A practical response sequence:

First, identify the exact package and version the alert names, and whether it is a direct dependency or pulled in transitively. The Dependabot alert links to the advisory and the dependency path.

Second, remove or replace it. Pin to a known-good earlier version, or drop the package if the malicious version is the only one available. Do not simply bump to "latest," since the latest version may be the compromised one.

Third, rotate credentials. Sonatype's research is blunt that stolen credentials have become the next distribution mechanism, so assume any token reachable from the affected build, npm tokens, cloud keys, CI/CD secrets, has been exposed and rotate it.

Fourth, check for install-time execution and propagation. Look at lifecycle scripts in package.json, and at less obvious hooks such as binding.gyp, since attackers moved execution there specifically to dodge teams that only watch package.json. If a developer or runner installed the package, audit that machine.

Companion control: GitHub Actions now holds suspicious workflows for approval

The same day, 28 July 2026, GitHub shipped a related protection: Actions now holds potentially malicious workflow runs for approval before they start. When a run is flagged as potentially malicious, it will not execute until a collaborator with write access reviews and approves it through an authenticated web session. It is automatic, needs no configuration, and currently applies to public repositories on github.com only, with GitHub Enterprise Server not covered at this time.

This closes a different door than malware alerts. Dependabot malware alerts watch what you install; the Actions approval hold watches what runs in CI when an attacker pushes a malicious workflow using compromised credentials to steal CI/CD secrets. Run both. Neither replaces the other.

What Dependabot malware alerts do not cover

Dependabot malware alerts are detective, not preventive. They tell you a malicious package is already in your graph; they do not stop it entering, and they fire only after an advisory exists for that specific package version. A brand-new malicious upload can sit in your build for hours or days before it is confirmed and indexed. The table sets the alerts against the other controls a serious pipeline needs.

Control	What it catches	Where it runs
Dependabot malware alerts	Known malicious packages in your graph	GitHub advisory match
Actions approval hold	Malicious or unproven CI workflows	GitHub Actions (public repos)
Repository firewall (e.g. Sonatype)	Malicious components before they enter repos	Proxy or ingestion gate
Install-script approval	Risky lifecycle scripts at install	CI/CD and local installs
Secret scanning with push protection	Leaked credentials in commits	Commit and push
SBOM and SCA	Vulnerable and malicious dependency inventory	Build and release

The lesson from Sonatype's data is that no single layer is enough when attackers run industrialised, self-propagating campaigns. Malware alerts are a strong, free baseline. Blocking components before they reach your internal repositories, validating package provenance, protecting internal namespaces against dependency confusion, and rotating exposed credentials are the layers that turn a baseline into a defence.

India-specific considerations

For Indian engineering teams and Global Capability Centres, three points sharpen the case. The direct cost of Dependabot malware alerts is nil, so the only investment is the engineering time to enable them and to build a response runbook. Against that, IBM put the 2026 average cost of a data breach in India at $2.51 million, roughly ₹21 crore at about ₹86 to the US dollar, and reported that Indian organisations face the highest weekly attack volumes of any region. Cheap prevention against an expensive, frequent risk is an easy business case.

The compliance angle matters too. Under the Digital Personal Data Protection Act 2023, a breach that exposes personal data triggers notification duties to the Data Protection Board of India and to affected individuals. A supply-chain compromise that exfiltrates a customer database is exactly such a breach. Enabling malware alerts, wiring them into an incident runbook, and keeping an SBOM are part of showing the reasonable security safeguards the Act expects. We cover that engineering-and-compliance overlap in our DPDP Act engineering playbook, and help teams operationalise it through our software supply-chain security service.

FAQ

What are GitHub Dependabot malware alerts?

Dependabot malware alerts warn you when a package in your dependency graph matches a malware advisory in the GitHub Advisory Database. Unlike vulnerability alerts, which flag known weaknesses to patch, malware alerts flag packages that are actively malicious, trying to run code, steal tokens or exfiltrate data, and need an immediate response.

What changed on 28 July 2026?

GitHub began automatically ingesting malware advisories from the OpenSSF malicious-packages project into the GitHub Advisory Database. That expanded Dependabot malware alert coverage from npm alone to npm, PyPI and more ecosystems. Teams that already had malware alerting enabled received the broader coverage automatically, with no configuration change required.

How do I turn on Dependabot malware alerts?

Open repository or organization Settings, go to the Code security section, enable Dependabot alerts if it is off, then enable Malware alerts under the Dependabot alerts section. For more than a few repositories, enable it at the organization level so no project is left uncovered. The alerts are free on public repositories.

Do malware alerts cover PyPI now?

Yes. Before 28 July 2026, Dependabot malware alerts covered npm only. After GitHub added the OpenSSF malicious-packages feed, coverage extended to PyPI and additional ecosystems. You can browse the combined malware advisories using the type:malware filter at github.com/advisories, which lists advisories across the supported package managers.

How should I respond to a malware alert?

Treat it as an incident. Identify the exact package and version, remove or pin away from the malicious version rather than bumping to latest, rotate any credentials reachable from the affected build or machine, and check for install-time execution through lifecycle scripts. Much 2026 malware runs at install or in CI, so act before your next build.

Are Dependabot malware alerts enough on their own?

No. They are detective, firing only after an advisory exists for a package version, so a new malicious upload can slip through first. Layer them with the GitHub Actions approval hold, a repository firewall that blocks bad components before ingestion, install-script approval, secret scanning and an SBOM. Sonatype's data shows single-layer defence fails against industrialised campaigns.

How bad is the open-source malware problem in 2026?

Sonatype's Q2 2026 index reported passing 1.8 million malicious packages logged over the past decade, with npm carrying 96.6% of the quarter's counts and PyPI making up 48.5% of non-npm activity. Campaigns included self-propagating npm malware, dependency-confusion attacks reaching hundreds of packages, and compromised PyPI publisher accounts.

Does this help with DPDP compliance in India?

Indirectly, yes. A supply-chain compromise that exfiltrates personal data is a reportable breach under the Digital Personal Data Protection Act 2023. Enabling malware alerts, keeping an SBOM and maintaining an incident runbook are part of the reasonable security safeguards the Act expects, and reduce the chance of a costly, notifiable incident.

How eCorpIT can help

eCorpIT builds and hardens software supply chains for engineering teams across India and beyond, from enabling and tuning Dependabot malware alerts to standing up repository firewalls, SBOM pipelines and incident runbooks. As an ISO 27001:2022 certified, CMMI Level 5 organisation, our senior engineering teams design these controls to align with DPDP Act 2023 breach-notification duties rather than bolt them on afterwards. To review your dependency risk or roll malware alerting out across every repository, talk to our team or explore our software supply-chain security service.