To the naked eye, organizations are independent entities trying to make their individual mark on the world. But that was never the reality. Companies rely on other businesses to stay up and running. A grocery store needs its food suppliers; a tech company relies on the business making semiconductors and hardware. No one can go it alone.

Today, the software supply chain interconnects companies across a wide range of industries. Software applications and operating systems depend on segments of the software supply chain to offer improved functionality. But while the software supply chain has improved efficiency and productivity for most organizations, it also means that if there is a vulnerability or a glitch in the software, it can halt business operations at hundreds or thousands of companies. Even the security programs that are used to protect users from cyberattacks can release exploitable software or an update with a coding mistake that can result in anything from massive data breaches to canceled flights to shutting down medical facilities because they can’t access patient records.

These software supply chain failures don’t just hurt the company. Millions of people are impacted. So why do software vendors have such deep access to an individual organization’s system so that one problem could create a nightmare scenario?

The evolution of computing

To understand why systems are so interconnected, you have to look at the evolution of both computing and software applications, according to Shiv Ramji, President of Customer Identity with Okta.

“We started from a world where programmers write on mainframes, and then we went from mainframes to the cloud and a distributed computing model,” Ramji explained during a conversation at the Oktane conference.

The benefit is that companies can now deploy applications faster, and they can be scaled with elasticity. Applications in the cloud are faster. There are a lot of benefits to architecting applications embedded in the cloud and network systems.

However, says Ramji, this also means that the application stack becomes more complicated and more sophisticated.

“The classic example would be if I had to store if I had an app that was a social media app or photo sharing,” explained Ramji. If the user relied on a single data center and single storage mechanism, scaling would become more difficult and expensive.

“But today, you can scale this really fast because you can use S3 from Amazon for storage, and you can scale your compute,” Ramji adds. “And so, it doesn’t matter if I have two users or end up having 200 million users; I’m able to address the needs.”

This evolution in computing has brought application stacks that have become much more complex, with a lot of interdependencies across the system. Cloud computing services, security services and networking capabilities work seamlessly because they are able to be embedded into an organization’s infrastructure.

Locking in with a vendor

These interdependencies are increasingly making organizations overly reliant on specific vendors and applications to keep their business operations running smoothly. The upside to this is having third-party partnerships that integrate with your infrastructure and can be built out seamlessly. The downside is added costs from not shopping around for better deals and the greater risk of a security flaw taking down your system without warning. One bad piece of code due to an embedded vendor application can cause irreparable damage.

According to research from Dashdevs, “vendor lock-in is proven to lead to unanticipated costs and technical debt.” Reliance on these embedded applications is “proven to increase risks and vendor-specific vulnerabilities.”

When these embedded applications have a flaw — a vulnerability exploited or misconfigured code, for example — the fix can be complex. It might look as easy as deleting the bad file or applying a patch, but what happens if the problem doesn’t allow you access to the system at all? To do that, you have to identify which program is causing the problem and where within your system it is located. Is it a problem that can be fixed once via the cloud and will automatically change across all devices, or will it require updating individual machines? Finally, what is the communication between the vendor and your organization? Is the problem something you discovered or was it revealed to you, and how willing and quick is the third party able to take responsibility?

Unfortunately, there are no easy answers. It will come down to the individual situation — the type of vendor, how the application is embedded into your network and the problem that it causes.

“Some of those systems, some of those controls that you have in place have the potential from a resiliency standpoint to mean the difference between your customers having your service being on and available or having a complete destruction caused by an outage similar to what we’ve seen with other vendors recently,” says Charlotte Wylie, Deputy CSO with Okta.

How vendors can keep customers secure

Vendors can take steps to protect their customers from a software breakdown, beginning with recognizing their role inside their customers’ infrastructure. Wylie provided the following tips on how vendors and customers can work together to add security to embedded applications:

• Implement access with least privilege permissions on both sides
• Have controls and protocols in place if there is a degradation of service
• Have well-managed accounts that are maintained and secured with your organization’s IAM team

“I think least privilege and having the right identity is super important,” says Wylie. “And then testing that on a regular basis so you have the right enterprise resiliency in place and know that your disaster recovery plan is ready to go — these are your backup plans when you have a collaboration of vendors.”

Every organization has become more reliant on the software supply chains and applications used across their complex network architecture. It’s almost impossible to run a business efficiently today without this interdependence on third parties who have deep access to not just your system directly but also through the other applications and software you use. Failure will happen. Being prepared with a recovery plan for any worst-case scenario and thinking about how to best architect networks with third-party vendors to work through failure will prevent the downtime from turning into a news event.