Software supply chain attacks, the attack vector where insecure setups and less secure components are exploited, experienced an explosive 650% growth in 2021!
As a supply chain security vendor, the growth is far from surprising for us at Bytesafe - with the supply chain being a noticeable security blind spot for many organizations.
A massive 62% of organizations claim to have been impacted by supply chain attacks in 2021 alone. Incidents like log4j, ua-parser-js and colors.js/faker.js have once again shown that it’s vital to use services like the Bytesafe Dependency Firewall.
Log4j has been described as one of the most serious exploits ever, with its simplicity to exploit and hundreds of millions of devices affected. But log4j was far from the only security issue to see widespread impact and discussions. Dependency confusion, the role and responsibilities of open source maintainers and account security have all been hot topics.
Let’s review key supply chain risks, making sure your organization is protected - and ready to break the trend in 2022.
Software supply chain in short
A software application may consist of hundreds or even thousands of code dependencies - most of them open source software (OSS). It is simply more efficient to reuse building blocks from others than having to write it yourself. The software supply chain contains all that external code that your applications depend on.
Open source is everywhere, 99% of codebases use open source components in some way - from small one-off apps to large enterprise applications.
… and with that comes inherent risk
It’s vital to ensure that the code you depend on is secure and available. Broken dependencies result in broken builds - or in the worst case compromised CI/CD and developer environments. Still many companies don’t analyze their software composition or know their applications dependency on open source.
Like most things in life open source software needs safeguards to make sure everyone is playing by the rules. The Executive Order on Improving the Nation’s Cybersecurity seems to agree…
Open source maintainers - responsibilities and account security
Discussions on the role, responsibility and compensation for open source maintainers have divided developers across the globe.
The fact that modern software infrastructure relies heavily on components that in many cases are hobby projects has many wondering about the possible security implications.
With lack of proper compensation (or in many cases monetization), what requirements and expectations can you put on open source developers?
Proving the point: a few high-profile incidents have occured - with account takeovers, malicious packages and intentional sabotage of packages as the result.
Weak point: Expired email domains & unmaintained packages
Expired email domains are a potential weakness for open source ecosystems (and in security in general) with email addresses strongly linked to identity management.
Registering an expired email domain could indirectly give you access to someone else’s accounts through password resets. And in the case of public package repositories, grant full access to publish new malicious versions (assuming no other form of two-factor authentication, 2FA).
This point was highlighted by security researcher Matthew Bryant showing how lists of email addresses for open source maintainers can be used by a threat actor to scrape the web and check for expired domains - and take over accounts.
In this case, it was npm that provided the information, directly from their API for the world’s largest open source package registry.
UA-parser-js: Account takeover & package hijacking
Back in October 2021, the hijacking case of ua-parser-js had companies across the world scramble to identify any trace of the package in their vast and distributed environments.
Three compromised versions containing trojans were published as the latest major, minor and patch versions, ensuring that unguarded supply chains would automatically install the malicious versions.
In the few hours of the incident, the new versions saw widespread distribution as the library had close to 8 million weekly downloads and was used as a dependency by 1200+ other packages.
Two weeks later, the pattern repeated itself, this time for the packages rc and coa - in a hijacking from what is likely the same hijacker.
The aftermath after ua-parser-js, rc and coa made one thing apparent. The biggest issue wasn’t figuring out if your applications used ua-parser, instead it was trying to figure out if you were exposed - in any environment, in any way, across hundreds of developers.
That the attacks came from account takeovers also sparked debate on security requirements when accessing package ecosystems. As little as 10% of all npm maintainers used two-factor authentication (2FA) to secure their accounts in 2020. Even accounting for a potential increase in 2021, this makes account takeover a very real threat.
After ua-parser-js, rc and coa, Npm introduced mandatory 2FA requirements for their top 100 packages based on dependents.
A step in the right direction, but far from ensuring proper secrets management for all.
Colors & faker: Open source activism
Intentional corruption of packages by the rightful maintainer - shining light on their own agenda. These were the events of colors (colors.js) faker (faker.js) with countless broken builds as a result.
What initially was interpreted as a supply chain attack, upon further investigation turned out to be a manifestation aimed towards big companies using FOSS without compensation.
The overall opinion on the incident in the open source community was divided. Many developers are considerate on making open source work more sustainable.
But any action that intentionally corrupts a package dependency is by nature malicious and the overall census on the execution was negative - breaking an unspoken trust between developers and wasting resources.
Log4Shell
THE security finding of 2021 with the most widespread impact, undoubtedly goes to the log4j zero-day vulnerability (CVE-2021-44228, dubbed log4shell). The critical vulnerability in the popular Java framework was disclosed in December 2021 and allowed attackers to execute arbitrary code on servers that used it.
Since the disclosure, organizations have struggled in identifying if they were affected and where to best patch the vulnerability - pointing to a systematic lack of insights into the software composition of applications and a lack of SBOMs.
Vulnerable version of log4j automatically quarantined by the Bytesafe Dependency Firewall, preventing it from being used in your organization
Log4j has been described as the biggest vulnerability ever. Five days after it was disclosed almost half of all corporate networks globally have been probed for the weakness. Highlighting the widespread reach and impact of security issues in popular libraries.
The work related to log4j continues in 2022 - with immense resources dedicated to the effort (one can only imagine the cost).
Stay ahead of the curve: Secure your supply chain with Bytesafe
The Dependency Firewall turns the insecure supply chain into a secure one. Block open source risk from ever entering your supply chain - preventing malicious packages from accessing your developers or CI/CD systems.
Use unique policies like Delay upstreams and Freeze to stay safe from malicious new versions, without impacting development speed or broken builds.
Software Composition Analysis (SCA) in Bytesafe allows organizations to track software components used across both registries and linked source repositories. Making sure to always stay on top of what code dependencies are used and where.
Combine it with SBOM generation for your software asset - make sure to comply with the Executive Order on Improving the Nation’s Cybersecurity with easy exports in a compatible CycloneDX format.
Want to know more? Join one of our upcoming webinars! Or go ahead and Sign up for Bytesafe and get started for free.
