Zero-day attacks. Just the thought of them is enough to cause most security professionals’ hearts to skip a beat. Why? Because, no security professional ever wants to deliver the news that their organization has been breached.
The good news is that, according to Cycode research, zero-day attacks on production applications are becoming increasingly rare. The bad news is that attackers are shifting their focus to your less secure and easier-to-breach software supply chain.
Production Applications Are No Longer the Main Mark
Let’s be honest. Attackers are looking for the biggest payout for the least amount of work. If you were a malicious actor, which would you choose? The one-off hack that takes a lot of time and effort or the easy attack that can be replicated against a large number of targets?
Attackers generally take the easy way out, which means custom code is no longer the primary target. There are several reasons for this. Cracking proprietary code is hard and requires skill. The tools that protect this code – namely SAST, DAST, and WAF – are mature and widely adopted. Plus, the payoff is limited to one only company. While custom code may still be the target in high-value attacks, malicious actors value efficiency as much as the rest of us and are looking for attacks that they can leverage against multiple organizations.
Open source vulnerabilities became the new low-hanging fruit because the same attack could be leveraged against many companies and exploiting them required less skill than exploiting custom code. Furthermore, open source vulnerabilities are publicly disclosed, giving attackers a blueprint for how to breach an application. It isn’t that hard for attackers to scan the internet looking for vulnerable environments.
With the number of open source exploits on the rise, more and more organizations have adopted software composition analysis (SCA) tools to protect their open source software and third-party dependencies. Because many organizations have begun closing their open source security gap, attackers have moved on to the next easy target: your software supply chain.
The Software Supply Chain Is the New Target
Attackers are always looking for the path of least resistance. Because it is far more common for attackers to go after basic mistakes than complex ones, they are shifting their priorities away from production applications toward developers and software supply chains.
While compromising developer accounts isn’t a new exploit, developers have become even higher value targets due to the level of access their accounts now provide. Developers often have over-provisioned access to their organization’s environment based on the possibility that they might someday need access to a system or resource to do their jobs. While this may be great for developer efficiency, it goes against every good security practice and presents a huge problem should their credentials be compromised.
Hackers who access developer credentials can cause a host of issues such as inserting malicious code into applications, leaking or copying source code, stealing production or customer data, installing backdoors, and much much more. Additionally, attackers can use developer accounts as a foothold to move laterally across an environment. Compounding this issue are basic mistakes, such as the lack of multi-factor authentication, which make it easier to infiltrate developer accounts.
The tools that make up the software supply chain are also being targeted, and your attack surface is much bigger than you realize and likely less secure than it should be. These tools are attractive targets because of the sheer number of attack vectors. Malicious actors have found it easier to gain access to the software supply chain due to the wide range of entry points. In addition to developer accounts, this includes an array of repositories or misconfigured tools that could be compromised or leaked. Additionally, a successful exploit of one of these vectors often provides access to other tools as well as the production runtime environment and all its data.
The Secure Becomes Insecure
All too often, what you assume is secure becomes insecure. It’s easy to overlook the basics – like changing default configurations – when you’re focused on securing the complex stuff, but you can’t. The risk is simply too great. SolarWinds, for example, was a highly sophisticated nation-state attack, but it started by exploiting a known vulnerability in a build tool.
Today’s reality is that every software team owns at least four to five tools just to orchestrate the release of code. And that doesn’t take into account legacy apps, multiple disparate teams using different tools, and potential acquisitions that bring in new teams with their own tools.
Part of the reason the software supply chain is being targeted is that many of the automated tools are outside the purview of security in a “shadow dev” environment. Engineering owns the tools that make up the software supply chain and configures them for agility and productivity, not security. Forgetting to change the default settings to more secure ones means that anyone familiar with the tool has a way into your system.
You don’t have to look far to see that even great engineering teams make basic mistakes and that most exploits are simple – not sophisticated – attacks. A recent Nissan breach that leaked both code and sensitive data was directly attributed to a BitBucket server that was left exposed on the internet with the default username/password of admin/admin. The New York State Office of Information Technology exposed all its projects to the internet via a misconfigured Git repository. Several of the projects exposed in this leak included secrets and passwords, and the misconfiguration allowed anyone to create a user account, including accounts with admin privileges. Uber suffered a breach that exposed 57 million users worldwide and resulted in a $148 million fine after attackers gained access to an AWS server using credentials that were mistakenly left in a public GitHub repository by an Uber developer.
As noted above, a simple misconfiguration in GitHub could result in a leak. With Infrastructure as Code (IaC) increasingly residing in the same repository as feature code, this becomes even more dangerous. IaC is a declarative language. It is much easier to reverse engineer IaC code to find exploits than it is with feature code. If leaked, IaC essentially turns into a blueprint for would-be attackers, and many IaC and cloud configuration errors have led to exposure.
Securing Your Software Supply Chain
Organizations are investing in security, but are forgetting the basics. Conventional wisdom suggests that changing things like default passwords and not hardcoding secrets should be easy, so why are we so consistently bad at it? And why are there so many software supply chain attacks?
First, organizations lack the tools to coordinate their security posture across their highly diverse, extremely complex software supply chains. You can’t fix what you can’t see.
Second, the value of the target is increasing due to ease of lateral movement across the software supply chain. If an attacker’s goal is to steal production data, they no longer have to hack the production application to access its databases. Instead, an attacker could compromise a developer’s account and then update IaC settings to change database access from private to public. To make matters worse, the attacker may also be able to weaponize the code to attack downstream customers and users similar to the SolarWinds breach.
Protecting your software supply chain is imperative, but not always easy. To identify and remediate supply chain risks, you need a solution that gives you visibility into all the tools that make up the SDLC as well as how these tools work together. The solution must have the ability to apply consistent policies across all tools and teams. It must also be able to detect other security issues that might otherwise provide attackers an entry point into your software delivery pipeline, such as hardcoded secrets, IaC misconfigurations, and code leaks. Remediation should be as automated as possible, with remediation suggestions and code fixes embedded directly into developer workflows wherever possible.
Given the high value of your software supply chain, full visibility is required to remediate defects and prevent breaches. This process should be automated wherever possible. By following these best practices, you can ensure that a simple mistake won’t lead to a data breach. Don’t let your software supply chain be your weakest link.
