Attack on the devs: Why data exfiltration is a top threat to 2025 supply chains

It’s been a tough quarter for open source security – and if you’re a developer working in a fast-moving CI/CD pipeline, it’s getting tougher.

According to Sonatype’s Open Source Malware Index for Q2 2025, 55% of malicious open source packages were designed for data exfiltration. That’s more than double the percentage in Q1, making it the most common malware objective this year – overtaking cryptominers, ransomware, and even trojans in volume and impact.

So what does this shift really mean for the developer community, especially in cloud-first environments like the ones booming across the MENA region? 

Devs caught in the middle 

The modern software supply chain is increasingly automated, distributed, and fast. And that’s exactly what makes it vulnerable. The same CI/CD pipelines that make rapid deployment possible can also be exploited to move malicious code at scale.

The Q2 report shows that most exfiltration-focused malware isn’t particularly noisy. It’s subtle, targeting .env files, credential stores, and SSH keys — anything that gives attackers a foothold in production infrastructure. These packages often use curl or HTTP requests to send secrets to attacker-controlled endpoints; or more worryingly, to insert backdoors directly into pipelines.

It’s important to note that this isn’t theoretical. The Sonatype team flagged packages such as peacenot, which was crafted specifically to target .env files and ship secrets off to a remote server – a tactic that’s becoming increasingly common.

From hobby hackers to organised groups 

As well as rogue developers uploading malicious packages, Sonatype noted a dramatic rise in activity linked to organised threat actors, including state-sponsored groups. Malware linked to North Korea’s Lazarus Group was embedded in dozens of open source packages that saw over 30,000 downloads combined – some of which were configured to exfiltrate sensitive data from compromised systems.

So for a growing number of attackers, developers aren’t just collateral damage. They’re a key target.

Open source security in the MENA region 

The MENA region has seen a surge in digital transformation projects – from fintech startups in Nigeria to economic diversification and government modernisation in Saudi Arabia and the UAE. Much of this innovation is being built on open source foundations, supported by cloud-native architectures and agile workflows.

That’s a good thing – but it also introduces risk.

Organisations that rely heavily on tools like GitHub Actions, Bitbucket Pipelines or GitLab CI/CD are at risk if secrets management isn’t airtight. Because .env files left exposed, hardcoded API keys, or poor role segmentation in cloud deployments can all turn a minor compromise into a serious breach. 

Organisations and devs need to protect their pipelines 

If you’re building software in 2025, you need to assume your dependencies might be compromised. Here are a few must-dos:

• Rotate secrets regularly – credentials should have expiration and be managed through tools (such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault).
• Segment your build systems – keep staging, development and production environments strictly separated with clearly defined IAM roles.
• Scan everything – use static and dynamic analysis tools that inspect packages before they reach production. Tools like Sonatype Nexus, Snyk, and GitHub’s Dependabot are a good start, but runtime analysis is critical too.
• Watch your logs – outbound traffic from build systems should be minimal. If you see unexpected connections, investigate.

Think like an attacker 

We’ve been writing a lot about the hacker mindset here lately. And the shift towards data exfiltration tells us that attackers want what developers have. Credentials, access tokens, and secrets are coveted keys – and stealing them is often easier than breaking through hardened perimeters.

But the good news is that with a few critical changes, dev teams can turn their pipelines from soft targets into hardened assets. Because today, protecting your code is about guarding the infrastructure that builds it.