ADP UK

Over the past decade, there has seen a dramatic increase in the number of cyber vulnerability attacks on software applications used by companies worldwide. Many of these have been attacks on open-source software components included by software development teams to reduce development times. Some of these attacks have resulted in companies being held to ransom or being issued fines for not taking steps to remediate these issues soon enough.

One of the problems with open source is the provenance of the software. Open source relies on the development and distribution of common components contributed freely by anyone in the world. Whereas, internally, an organization can add software controls to the development of its proprietary code to ensure quality and security. The inclusion of open-source means that parts of that software do not have a transparent secure software supply chain.

In May 2021, President Biden signed and published the “Executive Order on Improving the Nation’s Cybersecurity”. This mandates that all US Federal systems and software used by these systems must meet or exceed specific security standards. This aims to reduce the likelihood of cyber-attacks and improve the speed to remediate future attacks. One of the directives in this order is to provide a Software Bill of Materials (SBOM) for all software used by Federal systems. The European Union has taken a similar initiative by proposing the Cyber Resilience Act in September 2022.

The concept of an SBOM is deceptively simple. Taking the analogy of a list of ingredients or components used in cooking a meal or manufacturing a device, an SBOM is a list of the proprietary and third-party components, versions, and patch levels used to build and deliver that software program to a live environment used by clients. In theory, it should not be hard to produce an SBOM because, when any software is built, the build systems need to know what components are used to create the artifact.

However, often, these recipes are not made visible to a wider audience after the artifact has been produced. In addition, the artifact must run on a platform not included in the build process. The platform can be as simple as an operating system or more complex as a platform as a service provided by a Cloud vendor.

Further, live systems are often updated with additional changes made after deployments such as patches, version updates, and configuration changes. Ideally, any SBOM should also cover license compliance to ensure an organization fulfills its mandatory legal obligations for software licensing governance. Some parts of the SBOM which refer to proprietary intellectual property may have to be masked.

"SBOM should also cover license compliance to ensure an organization fulfills its mandatory legal obligations for software licensing governance."

One issue is that any statically created SBOM will be out of date the day it is published since software vulnerabilities are found every day (zero-day vulnerabilities) and will need to be remediated. Rather than a static list, ideally, an SBOM should be updated as a real-time dashboard that can be monitored internally (or even externally by those who use this software). This will give confidence to consumers that software and systems are in continuous compliance with any cyber-attack remediations which are currently known. It can also ensure confidence in the software users that their assets stored or used by this software are not at risk of data loss (through exfiltration) or data locking (through ransomware). Such monitoring should be done by recognized software vulnerability scanners on code and artifact repositories, in particular open-source repositories. It would be inefficient to scan all open-source libraries individually for each product separately. It makes more sense to apply quality and security controls either in the open-source external libraries or create internal open-source mirrors which contained validated versions of open-source libraries used across an organization. Although this may limit the versions available, the advantage is that only approved secure versions would be used at build time and hence would reduce the likelihood of malicious actors being able to exploit software vulnerabilities.

The key to enabling this posture is to “shift left” the ability to discover issues earlier in the software development life cycle (SDLC). This needs to include up-skilling software development teams in more modern security concepts such as threat modeling before code development.

In addition, ideally, any integrated development environment should provide warnings to software developers of good coding practices and known vulnerabilities. This should prevent developers from injecting these into the code at code creation. Any build system should also prevent the use of unvalidated open-source components. Static and dynamic code analysis tools should also be used on all elements of the software – new, legacy, and first- or third-party components. These tools need to be used appropriately at each stage of the SDLC because any latency in code check-ins or build systems caused by executing these scans will impact developer productivity and creativity. It is also important for any triage to be able to rule out any false positives to reduce the effort to validate the scan findings.

Ensuring transparency of the cyber-state of all components of a software system using a central validated artifact library as well as creating a real-time transparent SBOM dashboard should enhance the ability of organizations to satisfy the growing number of regulatory requirements such as the Biden Executive Order. It also provides the organization with the ability to main a good security posture and move towards continuous compliance. Given the increase in awareness of the importance of cyber-security, this increased openness between suppliers and clients is likely to become a major sales differentiator in the future.