GitHub vs SourceForge: Supply-Chain Attacks Redraw Trust Lines

Two hosts, two different jobs

The old GitHub-versus-SourceForge argument used to be about developer experience. In 2026 it is mostly about trust. GitHub is still where open source development happens. It is also where attackers have done some of their most effective work this year. SourceForge spent a decade trying to live down its adware era and now pitches itself as a download service where every file is scanned. Anyone who ships or installs open source security tools now has to weigh both platforms by who and what they can trust, not by which interface is nicer.

The two platforms no longer compete head-on. Comparison guides published this year broadly agree that GitHub is the place to build software and SourceForge is the place to hand it out. One 2026 roundup describes SourceForge's mirror network as strong for desktop software with a wide end-user audience. The same guide calls its development tools dated, its CI/CD support weak, and its reputation still dented by past bundling controversies. It recommends SourceForge as a distribution channel next to a modern forge, not as a project's main home25. Another analysis says many teams already work this way: they develop on GitHub and push release binaries to SourceForge for its CDN reach, a setup SourceForge officially supports28.

The gap in scale is large. SourceForge reportedly hosts about 500,000 projects and serves roughly 2.6 million downloads a day28. GitHub's built-in automation shows its size from a different angle: Dependabot alone runs across more than 30 million repositories9. GitHub also offers GitHub Actions for CI/CD, while SourceForge has no native pipeline and relies on webhooks to trigger outside systems2830.

GitHub's year of supply-chain attacks

GitHub's openness made it the center of open source. In 2026 that same openness made it the main target. In June, attackers compromised several Microsoft open source projects on GitHub. They added code built to steal credentials from developers using AI coding tools such as Claude Code, Gemini CLI and VS Code1. Microsoft took dozens of repositories offline during its investigation. GitHub notices pointed to at least 70, and Ars Technica counted 73 flagged packages, according to one report1. Researchers said it was Microsoft's second known open source repository compromise in a matter of weeks1.

A month earlier, an automated campaign called Megalodon pushed 5,718 malicious commits into 5,561 GitHub repositories in six hours, according to SafeDep researchers. Using throwaway accounts and fake bot identities, it planted GitHub Actions workflows that sent CI secrets, cloud credentials and SSH keys to an attacker-controlled server3. Security-focused trackers have also listed self-propagating worms. One is Mini Shai-Hulud, said to have compromised more than 170 npm and PyPI packages. Another is GlassWorm, estimated to have hit 433 components across GitHub, npm and VS Code extension marketplaces2. The group behind Shai-Hulud reportedly went further and published its own malware source code to GitHub, deployment instructions included, through what appear to be compromised accounts6.

Not every campaign needs a breach. One reported operation created 109 fake repositories across 103 accounts. It cloned real open source projects and replaced their documentation with download buttons that delivered infostealers2. Another reportedly built 44 fake repositories posing as admin tools such as PsExec, AzCopy and Sysmon2. Fakes like these are aimed squarely at system administrators and security staff, the people most likely to go looking for that kind of software.

Reading across this coverage, the attacks share a pattern. GitHub's core features are reused as attack infrastructure: Actions workflows, account identities and the expectation that code shows up there first. Some of the most vivid totals come from vendor blogs and threat-intel aggregators rather than independent audits. Even so, the reporting from mainstream outlets and security firms points the same way.

GitHub's response: shared malware data

GitHub's most concrete response this year was to plug into community data instead of building its own detection for every ecosystem. In August it extended Dependabot malware alerts from npm alone to eight ecosystems, including PyPI, Maven, RubyGems, NuGet, Go, crates.io and PHP Composer9. The data comes from the OpenSSF malicious-packages repository, a public OSV-format feed. It launched in 2023 with more than 15,000 reports and has grown every day since9. The feed covers typosquats, dependency-confusion packages, account takeovers and malicious prebuilt binaries4.

This matters for open source as a whole. The defensive layer GitHub now offers its users rests on a shared, openly licensed dataset that anyone can use, not on an in-house blacklist. GitHub's own npm findings already flow back into that feed. The engineering team found that more than half of the new monthly npm reports were GitHub's own advisories coming back to it, and had to filter them out9. The data now moves in both directions between the platform and the community feed.

SourceForge's scanning promise and its limits

SourceForge's pitch is the reverse of GitHub's. It does less, but it checks everything it serves. The company says every upload and download is scanned for malware and unwanted software11. Its history explains why it leans on that claim. In 2013, GIMP pulled its downloads over misleading ads and a bundling installer. In 2015, SourceForge took over the pages of projects that had left the site and served adware-laden downloads, GIMP among them12. Nmap's maintainer said publicly at the time that his project's account had also been taken over14. After BizX bought the site in 2016, the bundling ended, and in May of that year SourceForge began scanning all projects and showing warnings where malware was detected12.

SourceForge president Logan Abbott has repeatedly said the platform has had no malware or adware incidents in downloads since then19. Independent reporting complicates that claim without flatly contradicting it. In 2025, Kaspersky documented a campaign that used a SourceForge project called "officepackage". The project copied a legitimate Microsoft GitHub repository, while its free sourceforge.io subdomain led visitors to a cryptominer and the ClipBanker clipboard-hijacking trojan16. Kaspersky's data showed 4,604 users running into the scheme between January and March, most of them in Russia16. Abbott told BleepingComputer that no malicious files were hosted on SourceForge itself. He said the project was removed almost immediately, and that project websites can no longer link to files hosted elsewhere13.

How you read that depends on where you draw the platform's boundary. Abbott's point holds if you count only files served from sourceforge.net. For a user who arrives from a search engine on a page with SourceForge's name in the address, the difference hardly matters. In this analysis, the episode shows the weak spot of the scanning model: it protects the file, not the page that sends people to it. The same campaign also fetched a later-stage script from GitHub1316. The attack ran across both hosts, and neither one's controls stopped all of it.

The particular problem with security tools

Open source security software makes all of this harder, because the code is often meant to look dangerous. SourceForge says it treats penetration-testing projects as an exception. They are still scanned, but files that trip its detectors get a bright orange warning in place of the normal download button11. That is a blunt but honest approach. It tells users the tool is intentionally offensive rather than quietly hiding it.

GitHub is much more permissive and much bigger. Its malware topic page lists thousands of public repositories5. They range from defensive blocklists and memory-forensics frameworks to theZoo, which hosts live malware samples in encrypted archives for research510. Its cybersecurity topic covers tens of thousands of repositories, from the Wazuh SIEM to AI-driven pentesting agents7. Most of the field's research and collaboration now happens there. That same openness means a fake "admin tool" repository can look almost exactly like a real one.

The verdict

Neither platform is safe enough to trust on its own name, and the coverage suggests the industry is slowly accepting that. GitHub has the developers, the tooling and a growing defense built on shared data, but its scale and automation make it the busiest target in open source. SourceForge offers a narrower but clearer promise of scanned downloads and labeled offensive tools, and it still carries the memory of 2015. Commentators differ on how much that history should count. Some guides call the site widely trusted27, while others tell readers to weigh the hit to their brand before using it29.

The practical answer for most projects is the hybrid model the 2026 guides already describe: develop on GitHub, mirror signed releases wherever users will find them, and assume both channels can be spoofed2528. For people downloading security tools, the takeaway from this year's reporting is simple. Neither host's brand proves a download is safe. Check that the account behind it is the project's official one, compare checksums, and make sure the code really came from the maintainers.