What’s in the commercial and open-source software you use? How much was written by the vendor and how much of it is third party code? Can all that code be trusted?
The threats are real
The recent wave of high-profile cyber-attacks amply demonstrates the knock-on effects of aggressive cyber incidents. The SolarWinds hack exposed their customers̵
In both cases, the attack on the organizations downstream flowed to others in that ecosystem: the customers. Attacks that cripple critical infrastructure have a much greater impact. It’s not just customers of the affected organization or service that are affected – the ripples are spreading to unrelated industries and wider society.
The May 2021 ransomware attack on the Colonial Pipeline Company led to the closure of a 5,500-mile pipeline. In addition to other refined fuels, the pipeline supplies 45% of the gasoline supply – 2.5 million barrels of gasoline per day – to the East Coast. The gas supply just stopped. Prices at the pumps skyrocketed and panic buying started. Thousands of gas stations had to close due to lack of supplies.
The Colonial Pipeline Company attack was financially motivated. It was a ransomware attack, a common form of digital extortion. Colonial Pipeline paid cyber criminals a ransom of 75 Bitcoins – about $ 4.4 million, depending on exchange rates – to have their systems restored to them.
But if this had been an act of cyber terrorism or cyber warfare, there would have been no option to purchase the decryption program needed to get the affected systems back online. A nation-state with cyber-offensive capabilities cannot enable another country to function internally through a campaign of strategic cyber-attacks.
RELATED: Do you have to pay the ransom? Negotiate first
Responding to the Threats
On March 21, 2021, President Biden signed an executive order to improve the country’s cybersecurity. It contains a set of standards and requirements that all federal information systems must meet or exceed.
Section 4 of the Implementing Decree deals with ways to improve the security of the software supply chain. This imposes date-bound tasks on government departments to provide guidelines, standards, and procedures for many aspects of software development and procurement. Software vendors must meet standards and follow procedures to qualify for government software vendors.
Transparency is mentioned as a requirement. Software vendors must disclose all third-party components and libraries used in the development of their products. That requirement continues down the supply chain, so that the suppliers of those libraries and components must in turn list any external software components they have used in their products.
Open source software is specifically mentioned. The executive order speaks of “safeguarding and confirming, as far as practicable, the integrity and provenance of open source software used in any part of a product.”
This is not surprising. A 2021 report on open source security found that the average number of open source components in non-trivial commercial projects is a staggering 528. That’s a 259% increase from five years ago, when the average was 84 open source components per project.
RELATED: How to safely use open source code in your project
Open source as a consumable
It is clear that open source projects must comply with the standards and procedures that will be introduced as a result of the Implementing Decree. At first glance, the transparency part should be simple. Open source projects hang their source code for any kind of control. But of course, open source projects use other open source components, which use other open source components, and so on, nested like Russian dolls.
Software applications also have dependencies. They depend on other software packages to work. By choosing to include a single open source component in your own development project, you could inadvertently include many other open source products as dependencies.
So it is not enough to have your source code available for review. You must provide a list of the software ingredients in your product, as well as the list of nutritional and chemical ingredients on a candy bar wrapper. In the software world this is called a software bill of materials or an SBOM.
The software bill of materials
Security starts with knowledge. You need to know what you have to make sure you’ve secured it. That is why IT resource registers and data processing registers are so important. An SBOM – pronounced ess-bomb – is an application-specific document that lists all software elements that make up a software product.
That is valuable knowledge. Having it allows the users of that software to make security decisions. Knowing the components of the software, the risks associated with each, and the severity of each risk will help you make informed and informed choices.
You could read the list of ingredients on a candy bar wrapper and find that it contains something that you are allergic to. With an SBOM, you can view the build versions, release numbers of the software ingredients, and decide whether to proceed or not. For example, you can outright refuse to use a product that contains (for example) telnet, or a product that uses a version of SSH that has a known vulnerability.
Compiling a detailed SBOM is not a five-minute task. But it must be accurate and sufficiently detailed, otherwise it will not serve its purpose. As a minimum baseline, an SBOM for each software component in a software project should have:
- name of supplier: The vendor or people who wrote the software.
- Component Name:: The name of the item.
- Unique Identifier: A universally unique identifier (UUID).
- String version: The build and version details of the part.
- component hash: A cryptographic hash of the component. This allows a recipient to verify if a binary file provided to them has been modified if there is any suspicion.
- Relationship: The relationship between software components describes the dependencies between components and which components are compiled and linked to other components.
- Licenses: The type of license under which the software component was released.
- Author name: The author of the SBOM. This is not necessarily the software supplier.
If there is to be widespread acceptance of SBOMs, there must be a standard that defines the data formats, data content and accepted processes and standards. This is likely to appear as part of the guidelines the executive order has requested to be drafted.
There are several competing SBOM standards. The three leaders in this field are Software Package Data Exchange (SPDX), the ISO standard 19770-5: 2013 Software Identification (SWID) and CycloneDX. It will be interesting to see if any of these are adopted by the federal government as their preferred standard.
Automation can help
Different types of tools can assist in the production and use of SBOMs. Software packages are available that can scan projects, determine dependencies and generate SBOMs – or nearly complete SBOMs in which you can drop some finishing details.
SBOMs will likely be made available as downloads or as part of the packaged software, much like a “readme file”. Once you are in possession of someone else’s SBOM, you should review it.
That’s going to take time. Each component should be checked to make sure it is allowed according to the criteria set by your organization, and that the licensing of each component does not cause any conflict for you.
There is software available that can perform these checks for you. The most comprehensive packages list the known vulnerabilities for each component and the severity of those vulnerabilities.
Security starts with knowledge
The origin of software packages and all their constituent parts becomes an essential tool for software consumers to assess and make purchasing decisions. It will also be a differentiator for software vendors and producers, whether they create software that can be used by other developers or end users.