On this page · 10 sections
- What changed on 28 July 2026
- Why this matters: the 2026 supply-chain threat picture
- How to turn on Dependabot malware alerts
- What a malware alert means, and how to respond
- Companion control: GitHub Actions now holds suspicious workflows for approval
- What Dependabot malware alerts do not cover
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
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
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.
References
- Dependabot alerts on malicious packages across more ecosystems — GitHub Changelog, 28 July 2026.
- Dependabot now detects malware in npm dependencies — GitHub Changelog, 17 March 2026.
- OpenSSF malicious-packages repository — Open Source Security Foundation.
- GitHub Advisory Database, malware filter — GitHub.
- Configuring Dependabot alerts — GitHub Docs.
- About Dependabot alerts — GitHub Docs.
- GitHub Actions holds potentially malicious workflows for approval — GitHub Changelog, 28 July 2026.
- Q2 2026 Open Source Malware Index — Sonatype Research Team, 9 July 2026.
- The average cost of a data breach rises to almost $5 million — Infosecurity Magazine, on IBM Cost of a Data Breach 2026.
- Dependabot malware alerts concept — GitHub Docs.
- Managing Dependabot malware alerts — GitHub Docs.
_Last updated: 30 July 2026._
