How to make software supply chains resilient to cyber attacks

Join online with today’s leading executives at the Data Summit on March 9th. Register here.

Imagine if someone told you to drink a glass of liquid without telling you what is inside or what ingredients can do. Will you drink it Maybe, if it was given to you by someone you trust, but if that person says they can’t be sure what’s inside? You may not participate.

What IT departments do every day consumes the unknown. They install software and updates on complex systems without knowing what’s inside or what they do. They trust their suppliers, but the thing software suppliers don’t tell IT departments is that they can’t be sure about all their upstream suppliers. Protecting all parts of the software supply chain, including those outside the control of IT, is almost impossible. Unfortunately, bad guys are taking full advantage of this huge “attack surface” and winning big in cyber breaches.

The big problem is growing

The most famous example was the 2020 hack of Solarwinds, a business software developer based in Austin, Texas. The attackers inserted malicious code into software that was widely used by industry and the federal government. IT departments installed malware-containing updates and large amounts of sensitive and classified data were stolen.

Other software supply chain attacks have hit companies such as IT management software company Cassia where hackers added code to install ransomware and Kodakov, a tool provider whose software was used to steal data. And tampered versions of the “coa” and “rc” open-source packages have been used to steal passwords. These names may not be familiar outside of IT, but they have huge user bases to exploit. Coa and rc have millions of downloads.

Quite obviously, attackers have discovered that it is much easier to hack software that people voluntarily install on thousands of systems than to hack each system individually. According to the Argon Security report, there has been a 300% increase in software supply chain attacks between 2020 and 2021. This problem is not going away.

How can this be?

There are two ways hackers can attack software supply chains: they compromise software build tools or they tamper with third-party components.

There has been a lot of focus on securing the source code repositories of build tools. Google’s proposed SLSA (Supply Chain Level for Software Artifacts) framework allows organizations to benchmark how well they have “locked down” these systems. This is important because there are now hundreds of commonly used build tools – many of which are easily accessible in the cloud. Earlier this month, the open-source plugin Argo CD revealed significant vulnerabilities, allowing build and release systems to unlock secrets. Argo CDs are used by thousands of organizations and have been downloaded more than half a million times.

On SolarWinds, attackers were able to access where the source code was stored, and they added additional code that was ultimately used to steal data from SolarWinds users. SolarWinds created its software without realizing that malware was being included. It was like giving an incredible person access to the ingredients in that glass of liquid.

Even if companies control their own build environment, the use of third-party components creates large-scale blind spots in the software. Gone are the days when companies were writing complete software packages from scratch. Modern software is assembled from components built by others. Some of them use components from third parties Fourth and fifth parties. Only one sub-sub-component is required to include malware and the final package now includes that malware.

Especially in the open-source world, examples of compromised components are surprisingly common. “Namespace confusion attacks” are cases where someone uploads a package and claims it is a legitimate new version. Alternatively, hackers submit malicious code to add to legitimate packages, as open source allows anyone to contribute updates. When a developer adds a compromised component to their code, they inherit all current and future vulnerabilities.

Solution: The structure of permissions

Industry groups such as the Commerce Department’s National Telecommunications and Information Administration (NTIA) and government agencies are developing a standard and plan to use the executive order to make the use of software bill of materials (SBoM) mandatory for government-purchased software. SBoM is a list of software components that help identify what all components are but unfortunately does not indicate if they were hacked and misbehaved. Hackers will not list their code in components.

Developers can improve the security of build tools that they control and list third-party components from their suppliers, but that is not enough to convince them or their users that none of the components have been compromised. IT needs more than a list of components. It requires a software developer to describe how the code and components are expected to behave. IT teams can verify those announcements and make sure they are consistent with the purpose of the software. If a program is supposed to be a calculator, for example, it should not contain behavior that says it will send data to China. The calculator does not need to do that.

Of course, a compromised calculator may not say that it intends to send data abroad because hackers will not disclose that the software was compromised. The second step is necessary. When the software is running, it should be blocked from doing things that it did not disclose. If the software does not say that it intends to send data abroad, it will not be allowed.

It sounds complicated, but examples already exist with mobile phone apps. When installed, applications ask permission to access your camera, contacts, or microphone. Any unauthorized access is blocked. We need a framework to implement the concept of permissions like mobile application on data center software. And companies like mine and many other companies in our industry are working on it. There are two challenges here.

One, if someone allows “sending data out of my company”, does that mean all the data? Anywhere? Listing all types of data and all destinations is too detailed to review, so this becomes as much a technical challenge as it is linguistic and taxonomic. How can we describe risky behaviors in a high-level way that makes sense to humans without losing important differences or specific details that the computer needs?

Two, developers will not use tools that slow them down. That is a fact. Accordingly, much of the work – and should be – in disclosing how software is expected to behave can be automated. This means that developers are scanning the code to find out what behaviors they have in order to present the findings for review. Then, of course, the next challenge for everyone involved is to determine how accurate the scanning and evaluation is.

These challenges are not insurmountable. It is in everyone’s interest to develop a framework of permissions for data center software. Only then will we know that it is safe to drink.

Lou Steinberg is the founder and managing partner of CTM Insights, a cybersecurity research lab and incubator. He has been at the forefront of network security and technology innovation throughout his career. Prior to CTM, he was the CTO at TD Ameritrade, where he was responsible for technology innovation, platform architecture, engineering, operations, risk management and cybersecurity.


Welcome to the VentureBeat community!

DataDecisionMakers is where experts, including tech people working on data, can share data-related insights and innovations.

If you would like to read about the latest ideas and latest information, best practices and the future of data and data tech, join us at DataDecisionMakers.

You might even consider contributing to your own article!

Read more from DataDecisionMakers

Similar Posts

Leave a Reply

Your email address will not be published.