News: 1677069971

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Open source software has its perks, but supply chain risks can't be ignored

(2023/02/22)


Analysis Open source components play an increasingly central role in the software development scene, proving to be a boon in a time of continuous integration and deployment, DevOps, and daily software updates.

In a report last year, silicon design automation outfit Synopsys found that 97 percent of codebases in 2021 contained open source, and that in four of 17 industries studied – computer hardware and chips, cybersecurity, energy and clean tech, and the Internet of Things (IoT) – open source software (OSS) was in 100 percent of audited codebases. The other verticals had open source in at least 93 percent of theirs.

It can help drive efficiency, cost savings, and developer productivity.

[1]

"Open source really is everywhere," Fred Bals, senior technical writer at Synopsys, wrote in a [2]blog post about the report.

[3]

[4]

That said, the increasing use of open source packages in application development also creates a path for threat groups that want to use the software supply chain as a backdoor to myriad targets that depend on it.

The broad use of OSS packaging in development means that often enterprises don't know exactly what's in their software. Having a lot of different hands involved increases complexity, and it's hard to know what's going on in the software supply chain. A [5]report last year from VMware found that concerns about OSS included having to rely on a community to patch vulnerabilities, and the security risks that come with that.

[6]

Varun Badhwar, co-founder and CEO of Endor Labs – a startup working to secure OSS in app development – [7]called it "the backbone of our critical infrastructure." But he added that developers and executives are often surprised by how much of their applications' code comes from OSS.

Badhwar noted that 95 percent of all vulnerabilities are found in "transitive dependencies" – open source code packages that are indirectly pulled into projects rather than selected by developers.

"This is a huge arena, yet it's been largely overlooked," he warned.

Growing awareness of the threat

The trend toward using OSS packages isn't new. Developers have been doing it for a dozen years or more, according to Brian Fox, co-founder and CTO at software supply chain management vendor Sonatype and a member of the OpenSSF (Open Source Security Foundation) governing board.

Developers pull the source components together and add business logic, Fox told The Register . This way, open source becomes the foundation of the software.

[8]

What's changed in recent years is the general awareness of it – not only among well-meaning developers that are creating the software from these disparate parts.

"The attackers have figured this out as well," he said. "A big notable change over the last five or so years has been the rise of intentional malware attacks on the supply chain."

That came to the fore with the [9]SolarWinds breach in 2020, in which miscreants linked to Russia broke into the firm's software system and slipped in malicious code. Customers who unknowingly downloaded and installed the code during the update process were then compromised. Similar attacks followed – including Kaseya and, most notably, [10]Log4j .

Getting the picture through Log4j

The Java-based logging tool is an example of the massive consolidation of risk that comes with the broad use of popular components in software, Fox argued.

"It's a simple component way down [in the software] and it was so popular you can basically stipulate it exists in every Java application – and you would be right 99.99 percent of the time," he said. "As an attacker … you're going to focus on those types of things. If you can figure out how to exploit it, it makes it possible to 'spray and pray' across the internet – as opposed to in the '90s, when you had to sit down and figure out how to break each bespoke web application because they all had custom code."

Enterprises have "effectively outsourced 90 percent of your development to people you don't know and can't trust. When I put it that way, it sounds scary, but that's what's been happening for ten years. We're just now grappling with the implications of it."

Log4j also highlighted another issue within the software supply chain and woke many up to how dependent they are on OSS. Even so, an estimated 29 percent of downloads of Log4j are still of the vulnerable versions.

According to analysis by Sonatype, the majority of the time that a company uses a vulnerable version of any component, a fixed version of the component is available – but they're not using it. That points to a need for more education, according to Fox. "96 percent of the problem is people keep taking the tainted food off the shelf instead of taking a cleaned-up one."

Targeting the repositories

There is another rising threat related to OSS: the injection of malware into package repositories like GitHub, [11]Python Package Index (PyPI), and [12]NPM . Cybercriminals are creating malicious versions of popular code via dependency confusion and other techniques to trick developers into putting the code into their software.

[13]The world is 'clearly' not prepared for cyberwarfare

[14]Miscreants sure do love ransacking cloud networks, more so than before

[15]Dridex malware pops back up and turns its attention to macOS

[16]Still using a discontinued Boa web server? Microsoft warns of supply chain attacks

They may use an underscore instead of a dash in their code, in hopes of confusing developers into grabbing the wrong component.

"The challenge with this is that the attack happens as soon as the developer downloads that component and these downloads happen by the tools," Fox said. "It's not like they're literally going to a browser and downloading it like the old days, but they're putting it into their tool and it happens behind the scenes and it might execute this malware.

"The sophistication of the attacks is low and these malware components don't even often pretend to be a legitimate component. They don't compile. They're not going to run the test. All they do is deliver the payload. It's like a smash-and-grab."

Defenses are going up

Despite the security risks inherent in OSS, there are advantages to using it. It's more visible and transparent than commercial software, Fox argued. He pointed to the response to the Log4j vulnerabilities: the team working on Log4j turned around a fix within a few days – something commercial organizations would likely not have been able to do.

Mike Parkin, senior technical engineer at Vulcan Cyber, agreed that the open source model of having more eyes on the code can help mitigate cyber threats, but it also makes it easier for potential attackers.

That said, "historically the tradeoff has usually favored the open source developers," Parkin told The Register .

The SolarWinds attack put a lot of focus on software supply chain security. Building on US president Biden's 2021 Cybersecurity Executive Order, the White House in September 2022 [17]ordered [PDF] federal agencies to [18]follow NIST guidelines when using third-party software – including self-attestation and software bills of materials (SBOMs) by the software makers.

There is a broad array of [19]efforts in train by vendors looking to harden the security of the software supply chain. These include the rise of multi-vendor frameworks like the Open Software Supply Chain Attack Reference, tools like the Vulnerability Exploitability Exchange (VEX), and other products being developed by cybersecurity vendors.

Still, there are other steps Sonatype's Fox would like to see – like requiring software makers to recall defective software components. Right now, they're made to work up an SBOM. Fox compared that to car manufacturers only having to give buyers a list of vehicle parts, which can then be stuck into a glove box and forgotten, without a responsibility to recall the car if any of those parts are defective.

"What we really need is something to basically mandate that they can do a recall, because that implies that they know all the parts and where they ship them and which versions of the applications have which open source dependencies, but it also means they're actually managing it and looking out for that," he said. "That drives you towards that proper behavior."

Fox wants the focus on actually maintaining the OSS packages. There is some movement by governments in that direction, he said, noting that the EU's Cyber Resilience Act talks about the need for recalls, even if it doesn't use the exact words. Fox said the Biden administration may be starting to warm up to the idea.

He also is broaching the idea of component-level firewalls that work in ways similar to packet-level firewalls, which can inspect network traffic and block malicious traffic before an attack can begin. Likewise, a component-level firewall could stop malicious code before it compromises the software.

"If you don't even know what's in your software to start with, you probably have no visibility into what's going on with the malware, which is almost a worse problem because it's not just the vulnerability that's latent, waiting for somebody to exploit," he said. "It's causing harm the moment you touch it. Not enough people are really getting their head around that part of the problem either."

Sonatype built that capability into its platform with the Nexus Firewall, which Fox said was modeled after credit card fraud protection. The firewall understands what normal behavior looks like and then, using artificial intelligence and machine learning techniques, can detect abnormal behavior. In 2022, the firewall flagged more than 108,000 malicious attack attempts.

"So many organizations don't even know that this is a problem," he said. "It's where the game is happening right now and the attackers are kind of having a field day, unfortunately."

A combination of SBOM and firewall-like capabilities is needed.

"Yes, you need to know where all those parts are, so when the next Log4j happens, you can remediate it immediately and not have to start triaging thousands of applications," Fox argued. "But that's not going to stop these malicious attacks. You also need to be perfect protecting the factory." ®

Get our [20]Tech Resources



[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y-ZKNHu43PsWbUUL7QSysAAAAAQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[2] https://www.synopsys.com/blogs/software-security/open-source-trends-ossra-report/

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y-ZKNHu43PsWbUUL7QSysAAAAAQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y-ZKNHu43PsWbUUL7QSysAAAAAQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[5] https://tanzu.vmware.com/content/ebooks/state-of-software-supply-chain-2022

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y-ZKNHu43PsWbUUL7QSysAAAAAQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[7] https://www.businesswire.com/news/home/20221208005272/en/Endor-Labs-Unveils-New-Research-on-Impact-of-Open-Source-Software-on-Supply-Chain-Security

[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y-ZKNHu43PsWbUUL7QSysAAAAAQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[9] https://www.theregister.com/2022/11/04/solarwinds_settlement_sec_enforcement/

[10] https://www.theregister.com/2022/11/16/iranian_cyberspies_log4j/

[11] https://www.theregister.com/2023/01/04/pypi_pytorch_dependency_attack/

[12] https://www.theregister.com/2022/08/11/npm_pypi_security/

[13] https://www.theregister.com/2023/01/24/armis_cyberwarfare_report/

[14] https://www.theregister.com/2023/01/20/cloud_networks_under_attack/

[15] https://www.theregister.com/2023/01/06/dridex_macos_microsoft_malware/

[16] https://www.theregister.com/2022/11/23/microsoft_boa_web_server/

[17] https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf

[18] https://www.theregister.com/2022/09/14/white_house_software_security_guidance/

[19] https://www.theregister.com/2023/02/05/supply_chain_security_efforts/

[20] https://whitepapers.theregister.com/



More problems and no magic

b0llchit

The supply-chain risk is about just as high or higher for proprietary software. The vendor gets "hacked" and you, the downstream, pay handsomely for a backdoored piece of software. The problem starts when you want to do some auditing, either you yourself or hired auditing. The proprietary system is much harder to look into. There is the open version much more accessible.

True, the centralisation of repositories and wideband of contributors is a substantial risk too. However, if you really want to be sure, then you always have been following all the libraries and applications you use more or very closely anyway.

When you blindly accept anything you have already lost. And here we are again... software is hard work and no magic method exists to make it cheap, fast and secure. You have to choose from the limited set and it always will be compromises in one or the other way.

"daily software updates"

Mike 137

The last bloody thing we need if we want to be reasonably secure. One of the most important contributions to robustness and resilience is good knowledge of the state of our systems so vulnerabilities can be allowed for and countermeasures applied (which is why we spend a lot of dosh on pen tests). If that state changes daily, we haven't a hope in hell of protecting said systems, all the more as "updates" can be as bug ridden as the software they're updating.

always the same

tiggity

"effectively outsourced 90 percent of your development to people you don't know and can't trust.

.. which equally applies to proprietary software - at least with open source if an issue arises you can (if you have the abilities, fix the code yourself)

I have frequently used open source code - however never gone the auto pull stuff in approach.

Downloaded the open source components, audited for vulnerabilities and licence compliance, (plenty of tools to help be it commercial stuff such as Mend (AKA whitesource) through to open source free stuff) and tested them and added to source control.

That way you know what you are including - none of this randomly pulling the latest & greatest version from online & hoping for the best.

It has its drawbacks - when there is zero day you cannot just rely on your software picking up the latest & greatest fix when its available, instead you have to wait and incorporate it into your software (after testing it).

But, so long as your own software has ability to auto update (though ideally with user approval) then its not that much of an extra delay (just the time for you pull new version of open source component, audit and test it and update your source control repo).

Though the upside is that testing makes sure the fix does not break your software or have other issues (as with "emergency" bug fixes do sometimes see situations where initial "fix" is sub optimal and further fixes soon get rolled out)

Other drawback is, have to regularly do pull, audit and incorporate periodically anyway - be it for new versions for less critical bugs, improved performance etc. - but in "mature" open source components, you fortunately don't have to update that often as depends on your usage of that code and what has changed in the open source component: Scenarios where it's quite OK to run an older version without any issues tend to be common.

More hard work with this approach, but you're insulating yourselves from random code poisoning via the internet .

So the problem is *really* just lack of professionalism?

that one in the corner

> But he added that developers and executives are often surprised by how much of their applications' code comes from OSS

Developers don't know what is in their s/w? For pity's sake, go and LOOK!

Executives don't know? You're letting your devs get away with not telling you? I thought you lot thrived on making everyone write reports[1]

> The trend toward using OSS packages isn't new. Developers have been doing it for a dozen years or more

A dozen or more? Try 30 or more! Or is he just reporting from when anyone admitted they were doing it (in which case, see above).

[1] TPS cover sheets notwithstanding

Are you a parent? Do you sometimes find yourself unsure as to what to
say in those awkward situations? Worry no more...

You wouldn't understand.
You ask too many questions.
In order to be a man, you have to learn to follow orders.
That's for me to know and you to find out.
Don't let those bullies push you around. Go in there and stick
up for yourself.
You're acting too big for your britches.
Well, you broke it. Now are you satisfied?
Wait till your father gets home.
Bored? If you're bored, I've got some chores for you.
Shape up or ship out.