Part 3: A Shifting Industry

Most companies are still driven by one thing: the desire to innovate faster than the competition and gain market share. Companies are coming to recognize that “out innovating” also means quality, security and maintainability.

Further, increasing government regulations, changing industry standards, and growing focus on open source licensing, are transforming how the world thinks about software development. In this section, we’ll dissect some of these external factors affecting software supply chain management.

Supply Chain Adversaries

Almost 9 years ago, the world witnessed the first prominent Apache Struts vulnerability. In this case, Apache responsibly and publicly disclosed the vulnerability at the same time they offered a new version to fix the problem. Despite Apache doing their best to alert the public and prevent attacks from happening, many organizations were either not listening, or did not act in a timely fashion, resulting in widespread exploits in the wild. Simply stated, hackers profit handsomely when companies are asleep at the wheel and fail to react in a timely fashion to public vulnerability disclosures.

Since then, the community has witnessed Shellshock, Heartbleed, Commons Collection, and most recently the Log4j exploit and Spring4Shell. All of these followed the same pattern of widespread exploit post-disclosure.

The reality, however, is that these are not uncommon - and in fact 29% of popular open source components contain a known vulnerability.

Malicious Attacks on Software Supply Chains

Shift forward to today, however, and bad actors are now creating their own opportunities to attack. 

This newer form of attack on our software supply chains, where open source project credentials are compromised and malicious code is intentionally injected into open source libraries, allows hackers to poison the well. The vulnerable code is then downloaded repeatedly by millions of software developers who unwittingly pollute their applications to the direct benefit of bad actors.

These types of software supply chain attacks are growing at an alarming rate: 2021 saw a *650%* increase in the number of cyber attacks aimed at open source suppliers. At Sonatype, we’ve proactively found more than 63,000 attempts to alter components.

Source: Sonatype’s 2021 State of the Software Supply Chain

Attacks in this space are unique in three ways:

• 1. They frequently put extra effort towards appearing legitimate, since they wish to fly under the radar and become part of the software supply chain.
• 2. Few are outright service attacks, like a Distributed Denial of Service (DDOS)
• 3. Rarely target any one group or individual. Components are aimed at wide usage and ease of distribution.

Upstream software targets, cascading to downstream victims

Traditional attacks on software have been focused on either users or their destination. Common tactics by bad actors include tricking people into opening malware, sharing their credentials, or using published software vulnerabilities to strike unpatched servers. These would be considered “downstream” in the software supply chain as they are unconnected to the development process.

Some examples of common malicious, software supply chain attacks:

• Typosquatting - One of the oldest and still in wide use, this attack is named for malicious components that “squat” or setup with similar software and similar names to other popular tools. “Typo” refers to how developers may have entered the wrong name or used a slightly different spelling, such “collor” vs. “color”
• Brandjacking - Similar to typosquatting, but convincingly named after technology brands, websites, and projects.
• Dependency confusion - Cleverly disguised malware can sometimes trick development tools into downloading same-named public repository components instead of internally-created packages. Major companies were caught off guard in early 2021 by this attack.
• Project hijacks - If the above tactics don’t work, some popular project owners are targeted.

All of these attacks can result in data loss, cryptominer installation, or worse. Additionally, the earlier in the software supply chain a package is compromised, the more targets it may affect.

Rapid turnover of revealed vulnerabilities into attacks

As the overall pace of software development has increased, so too have exploit preparation by bad actors. Although companies had almost a month on average to respond to major supply chain vulnerability notices a decade ago, that window is closing. The 2017 Struts vulnerability (most notably resulting in the widely-publicized Equifax breach) had a 5 day window. 

Then, late in 2021, the Log4j vulnerability window was down to just two days:
Adapted from IBM X-Force / Analysis by Gartner Research (September 2016)

As a result, rapid internal development processes are no longer just about a competitive edge, but also a necessary security function. And the trend is clear: organizations need ongoing improvements to respond effectively to vulnerabilities.

More than reputation damage: breaches mean lawsuits

While there is a long list of ways that companies can minimize the damage from a breach, poor remediation may now also result in legal complications. In the wake of the Log4j vulnerability, US companies were notified that they may face litigation by the Federal Trade Commission for not making the effort to shore up their own systems. 

This is indicative of how software supply chain understanding is more than just a concern for developers – it has economic and national interests.

Standards compliance requirements

Unfortunately, as software continues to extend its reach into more industries, there is no single standard for software compliance that ensures software supply chain integrity. Most standards and compliance requirements are still industry-specific.

For compliance standards, software may be a victim of its own success: the variety of ways software affects our lives is compounded by legislation at the state, territory, federal, and international level. Meanwhile, development itself continues to evolve. As such, we can only recommend continuing research for your own industry to find ongoing training, best practices, effective policies, and process monitoring.