At a time when “software supply chain attack” has become a household phrase, the recent vulnerability discovered in the Apache Log4J has delivered a wake-up call to both developers and software consumers: the days of blindly trusting third-party software are over.
The vulnerability in Log4J, which is used in applications ranging from Minecraft to infrastructure servers running Apple’s iCloud and Amazon Web Services, allows attackers to take control of devices running certain versions of this logging utility. This is the latest in a series of software supply chain attacks including SolarWinds, REvil, and Urgent/11.
In the face of these security threats, developers are continually pressed to deliver applications with speed and efficiency which leads to more use of third-party code and open-source libraries such as Log4J. To avoid sacrificing security, organizations are increasingly relying on technologies that can generate a software bill of materials (SBOM) that catalogs the contents of a software application and any associated vulnerabilities they contain.
Like any bill of materials in the enterprise, the SBOM defines the components of the finished product, so if a problem is detected, the root cause can be remediated while minimizing disruption. SBOMs are recognized as the foundation of software supply chain security; they allow developers to build more secure applications, provide security teams with threat intelligence and enable IT departments to maintain more resilient environments.
The three ‘Ds’ of SBOMs
SBOMs provide valuable insights at three different stages of the software development life cycle (SDLC) – in development, in delivery, and in deployment, as described below.
Develop: building programs from scratch is expensive, time-consuming and simply impractical for organizations that have to move at the speed of business and on a budget. In the past five years, the use of in-house developed code for IoT projects has shrunk to 50% and there’s no reason to think it will not continue to drop further.
Developers must use third-party and open-source components to keep up, and while integrating testing of components into the workflow is a best practice, developers often go on trust. Generating an SBOM during this stage gives development teams more visibility into these components, so they can spot any known (N-day) or Zero-day vulnerabilities that may be lurking, and make sure they are using licensed and updated versions of the program.
Regularly analyzing components and generating SBOMs can give development teams the confidence of knowing that they are meeting quality and security standards, while enabling them to proactively manage their component libraries.
Deliver: the surge in cybercrime seen during the Covid pandemic put a spotlight on security, so software development teams and vendors are under the gun to deliver products that meet tougher standards. Too much of the software used today could be prey to unknown vulnerabilities lurking in its third-party code, so new products need to be checked thoroughly to meet quality assurance standards. When Osterman Research analyzed commercial off-the-shelf software, it found all programs had open-source components and vulnerabilities; 85% had critical vulnerabilities in their open source components.
Before release and deployment, compiled software should be run through a security assurance check to produce an SBOM. At this stage, the scan can identify the use of open source and check for any vulnerabilities that need to be fixed or mitigated. This is a key step to ensure that software released to the market is as secure as possible and free of known vulnerabilities, and it’s only a matter of time before it’s a requirement across the board.
The 2021 Presidential Cybersecurity Executive Order issued in response to recent supply chain cyberattacks singled out SBOMs as an effective cybersecurity tool. The order mandates that ultimately SBOMs for software vendors working with the Federal government will need to be included as part of the best-practices guidelines it would recommend to all enterprises, via the National Institute for Standards and Technology of the Commerce Department. Meanwhile, a number of industries have begun requiring SBOMs when delivering critical products such as medical devices and infrastructure controls.
Deploy: with everything from office printers to critical systems now connected via the internet of things (IoT), there is a much greater attack surface for finding and exploiting vulnerabilities. As more processes get digitized, companies are devoting increasing budgets to the software necessary to run them; Gartner has forecast spending on enterprise software will be near $670 billion in 2022, up 11.5% annually.
Software developers and vendors are improving practices for delivering secure software, but enterprise cybersecurity teams are ultimately responsible for ensuring commercial software being deployed is safe. They must trust, but verify, and generate their own SBOMs.
By analyzing purchased software, information security teams can get visibility into the software their organization is either using already or considering. This can help them improve their security posture, make more intelligent decisions and speed up threat response if another vulnerability such as Log4j appears.
Fortunately, creating SBOMs is within reach of virtually any organization thanks to software composition analysis (SCA) technology. These tools can generate an SBOM through either source code or binary analysis. Binary SCA tools analyze compiled code, the actual finished software that is being delivered and deployed by organizations. This gives them an advantage because they can run without access to the source code and scan software components, libraries and packages within applications to generate an SBOM.
With the frequency and sophistication of supply chain attacks on the rise, the value SBOMs provide cannot be underestimated when it comes to identifying and mitigating security risks in software that organizations develop, deliver or deploy.
This article was originally published on Embedded.
