Supply chain software security: Remediating the Curl effect

The release of a patch today for the vulnerability in Curl would have likely drawn a slight sigh of relief from many infosecurity professionals – but the task of remediation remains arduous. Curl, an open-source tool that is used for data transfer, is estimated to have over 20 billion installations. This means that every modern operating system running on the host will likely need to be updated as Curl is bundled by default almost everywhere – Windows 11, MacOS, and various distributions of Linux.
 
Additionally, almost every Container – the software packaging format used by nearly every cloud-native app – will need to be updated, re-built, and re-deployed. For example, the "HTTPD" container was downloaded 4 million + times last week alone – so each of these developers who downloaded this Container will now need to do so again! There are some other Containers too that are maintained by other open-source communities, including Python and MySQL, both with over one billion downloads. 
 
These statistics provide a convincing perspective on how this vulnerability in Curl makes security across the software supply chain sort of defenseless. Developers inherit the security risk but have no control over the code they use or influence over the open-source software developers.
 
The business impact of these supply chain software vulnerabilities is tangible. One only has to look at recent events such as Log4j and MOVEit, the latter being the largest hack in recent history.
 
What can software developers and enterprises do to potentially mitigate the risk of Curl? Immediately, understanding what is running and where it is running is critical. To this end, having tooling that can assist in generating a Software Bill of Materials (SBOM) and then analysing that SBOM is key. An open-source tool to generate the SBOM will help identify usage of the Curl binary as well as Libcurl, the library used by many other binaries besides Curl along with their versions.
 
However, SBOM alone is not the long-term answer. SBOM is a foundation that expands on identified vulnerabilities and cannot be entirely relied on. The management of software supply chain security requires the proactive use of additional tools and techniques, including software composition analysis (SCA), code signing, and risk management framework, among others.
 
Alongside this and crucially, enterprises must ensure that despite all the measures undertaken, should a security attack be successful, their end users must be equipped with the processes and knowledge to react in a way that helps to mitigate its impact. There is simply no way around this – end-user security awareness training is indispensable.