CI/CD Under Siege: Supply Chain Cyberattacks

This afternoon I came across an intriguing article about a new class of CI/CD attacks affecting major projects. It got me thinking about the evolving cybersecurity landscape, especially in software supply chains. These new CI/CD attacks are a real concern. They're exploiting parts of the software development process we rely on heavily, like GitHub actions in self-hosted runners.

The impact of these attacks is significant. They don't just disrupt systems; they erode the trust we have in our development tools and processes. The rise in these attacks, especially against major IT and crypto companies, shows a worrying trend. Attackers are getting smarter, targeting deeper into our tech infrastructure.

One key issue is how open source and community trust can be manipulated. For example, if an attacker makes a legitimate contribution to a project, subsequent malicious commits might get auto-approved. This raises a big question: should this default behaviour in software development still be acceptable? The article mentioned:

If the default fork pull request approval requirement is in place for the repository, only the attacker’s first request would require approval, meaning that the attacker would then be able to execute code on the runner and set up persistence without arousing suspicion.

https://www.securityweek.com/major-it-crypto-firms-exposed...

In the realm of CI/CD we all know that automation is the key to rapid delivery but how much of a double-edged sword is this? When changes in code or dependencies are automatically approved, it bypasses critical checks and balances that are essential for maintaining security.

1. Bypassing Manual Review: Automatic approvals mean that changes can be merged into the main codebase without thorough vetting. This lack of oversight can allow malicious code to slip through unnoticed.
2. Trust Exploitation: Attackers can exploit this trust by submitting seemingly innocuous changes or by hijacking trusted accounts. Once they have an initial change approved, subsequent malicious changes may automatically pass through, given the established trust.
3. Rapid Propagation of Malware: If an attacker successfully injects malicious code, the CI/CD pipeline's efficiency can work against security. The infected code can rapidly propagate across various parts of the system, amplifying the impact of the attack.

Dependencies are another weak spot. We often use external libraries in software development, but this creates risks. A vulnerability in one library can put the whole project at risk. Attackers can also trick systems into using compromised libraries, making things worse.

So, what can we do? We need a balance between convenience and security. This might mean more manual reviews and regular checks on dependencies. Also, integrating automated security tools, like SAST, DAST, or SCA, can help detect problems early in the pipeline.

In conclusion, as we embrace automation in CI/CD, we must also up our game in security. It's not just about building software faster; it's about making it safer too. We all need to be proactive, staying updated and vigilant against these new cyber threats.