Some of the biggest and most infamous cyberattacks of the past decade were caused by a security breakdown in the software supply chain. SolarWinds was probably the most well-known, but it was not alone. Incidents against companies like Equifax and tools like MOVEit also wreaked havoc for organizations and customers whose sensitive information was compromised.

Expect to see more software supply chain attacks moving forward. According to ReversingLabs’ The State of Software Supply Chain Security 2024 study, attacks against the software supply chain are getting easier and more ubiquitous.

“For example, Operation Brainleeches, identified by ReversingLabs in July, showed elements of software supply chain attacks supporting commodity phishing attacks that use malicious email attachments to harvest Microsoft.com logins,” the report stated.

It is easier to conduct software supply chain attacks, so they are increasing at an alarming rate. The ReversingLabs report saw a 1,300% increase in threats coming from open-source package repositories last year. That’s the bad news.

The good news is that cybersecurity teams and government entities recognize the risks coming from the software supply chain, and there is a lot of action toward defending against these attacks and steps to solidify security before the software is released into the wild.

Who controls the software?

Who controls the software and who controls the device are the game-changers in software supply chain security, according to Xin Qiu, Sr., Director of Security Product Marketing and Management at CommScope. But that’s hyper-focused down to the developers and system engineers creating the software and setting up the systems. The problem is that there is little integration within an organization to enable effective control.

Companies have a lot of tools, but they are scattered around, says Qiu. Everyone is siloed, doing things in different ways. That approach has to change.

It is the federal government that is taking the lead in tackling software supply chain security with technical regulations and laws.

“To improve your software supply chain security, you need to have a common standard,” says Qiu. “I think this is a good way to fill those gaps.”

The most recognizable action taken by the government entities was the Executive Order(EO) from the Biden administration, which addresses the nation’s cybersecurity but especially emphasizes protecting the software supply chain. In conjunction with that EO, a cross-sector group representing different government agencies, the Enduring Security Framework (ESF) Software Supply Chain Working Panel, put together a comprehensive guide for recommended practices of security in the software supply chain for developers. NIST also has a framework to secure the software supply chain.

4 security solution trends for the software supply chain

But government guidelines and regulations only go so far, and it is up to organizations to better equip themselves with the tools, solutions and processes that allow developers, engineers and security and IT teams to address risks within the software supply chain. There are a number of ideas and tools out there, some initiated by the government, that are trending in the battle against vulnerabilities and threats.

1. Secure by design

At RSAC2024, CISA Director Jen Easterly and a panel of cybersecurity professionals gave a panel on CISA’s Secure by Design initiative. The idea is to build security into products and make it a business feature and core technical requirement rather than the more standard approach of treating security as a failure. “During the design phase of a product’s development lifecycle, companies should implement Secure by Design principles to significantly decrease the number of exploitable flaws before introducing them to the market for widespread use or consumption,” the initiative’s website states.

Part of the presentation was the introduction of the initial group of businesses that took the Secure by Design pledge. According to CISA, “By participating in the pledge, software manufacturers are pledging to make a good-faith effort to work towards the goals listed below over the following year.” The pledge includes a list of goals for developers and organizations to work toward. These goals include standards around MFA, reducing default passwords and better transparency around vulnerability disclosure and reporting. More than 200 organizations have taken the pledge so far.

2. Software bill of materials (SBOMs)

SBOMs are a nested inventory of all the components that make up a software application. The components can include open source, third parties, patch status and licenses. SBOMs have become a key part of the software supply chain security structure and are endorsed by CISA as a way for developers to build a community that works together to share ideas and experiences around operationalization, scaling, technologies, new tools and use cases. To encourage SBOM use and understanding, CISA facilitates regular meetings from those across the software development and design community and also offers a resource library.

SBOMs can help an organization identify risks, especially in third-party and proprietary software packages: track vulnerabilities within the different components; ensure compliance and help the team make better security decisions by being more aware of the component parts of their software.

3. Supply-chain levels for software artifacts (SLSA) frameworks

SLSA is a security framework to safeguard the integrity of software artifacts. It is a checklist of standards to better improve the integrity of the software, prevent tampering and exploitation and keep the infrastructure and application packages secure. The framework was based on Google’s production workloads and offers a structured approach to evaluating the security posture of software components throughout the supply chain.

4. Governance, risk and compliance (GRC) management

GRC management is used to mitigate security risks within a software development supply chain while ensuring the software meets required regulatory compliances and security standards. Some of the areas that GRC monitors include:

• Identifying risks across the entire software supply chain
• Vendor risk management and assessment of third-party security posture before integrating the software into your organization’s system
• Compliance management to meet industry and government standards
• Policy enforcement across the development lifecycle
• Incident response after a cyber incident caused by the software supply chain

GRC management tools can also be used with SBOM analysis.

The evolving puzzle of software supply chain security

This is just a sample of the tools and solutions used to protect the software supply chain from risk. As security is more consciously built into the software and developers and engineers share information in communities rather than working in silos, there is a fighting chance of slowing the threats against the software supply chain.

The post 4 trends in software supply chain security appeared first on Security Intelligence.

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.

The post Why do software vendors have such deep access into customer systems? appeared first on Security Intelligence.