The Intersec Worldwide PCI-DSS 4.0 Transition Plan noted that Software Component Management is often challenging for many organizations to implement, which is why we ranked requirement 6.3.2.b within the Top 10 priorities companies should focus their efforts on.
For the purposes of this blog post, I will reprint the requirement as written in the PCI-DSS:
6.3.2.b Examine software documentation, including for bespoke and custom software that integrates third-party software components, and compare it to the inventory to verify that the inventory includes the bespoke and custom software and third-party software components.
The primary reason for this control is to ensure an organization understands the components used to support their software, and more importantly, vulnerabilities (or unknown risks) that may exist within those components. This concept is well documented in the following comic courtesy of XKCD (https://xkcd.com/2347/):
Since the publication of the standard and transition plan, we have received several questions regarding what we, as QSAs, will accept as evidence. Given the frequency of updates to underlying components and the required detail the use of spreadsheets is unrealistic. Fortunately, there is an emerging technology standard identified as the SBOM or Software Bill of Materials.
What is a Software Bill of Materials (SBOM)?
A Software Bill of Materials is essentially an inventory of all dependencies utilized by a given application. Like the comic above, modern software is often made up of multiple shared libraries, third-party libraries and services which increase developer speed and efficacy; write once, use many. Unfortunately, the use of third-party libraries also may allow for the introduction of vulnerabilities that are found (or introduced) within the underlying libraries.
Taken from manufacturing and supply change management, the “Bill of Materials” represents an inventory of all raw materials, parts, sub-assemblies, and assemblies used to manufacture products. Once this Bill of Materials is established, organizations can quickly tailor purchasing and supply of required materials to maximize profit and efficient manufacture of an item.
The Solar Winds breach and Log4j vulnerability highlight the critical need to understand and maintain software components. In the Solar Winds breach, a malicious actor was able to update an underlying component which provided a backdoor into all Solar Winds implementations. Then with Log4j, companies scrambled to figure out which applications used Log4j in order to patch it as quickly as possible. In many cases, companies were surprised to find Log4j embedded in third-party software they had little control over. If organizations had implemented SBOMs, they quickly would have been alerted of the fact that the installed components within their infrastructure were vulnerable to exploitation.
Due to the successful exploitation of Solar Winds and Log4j the US government pushed forward an executive order defining the need for a Software Bill of Materials (SBOM) for all critical software purchased by the federal government. The National Telecommunication and Information Administration (NITA.gov) has been tasked with developing and providing guidance on Software Bill of Materials standards and usage.
NITA has stated at a minimum this SBOM inventory should contain the following elements:
- Author Name
- Supplier Name
- Component Name
- Version String
- Component Hash
- Unique Identifier
In addition to establishing a baseline, NITA has identified three machine readable formats for an SBOM identified as:
- SPDX (https://spdx.github.io/spdx-spec/)
- CycloneDX (https://cyclonedx.org/)
- SWID (ISSO/IEC19770-2:2015: https://www.iso.org/standard/65666.html)
Good News: Your Organization Likely Already Has the Capability
Circling back around to what a QSA will accept to meet requirement 6.3.2.b, Intersec anticipates any one of the three SBOM formats listed above will be requested and accepted. Many of these formats are interchangeable and supported by both proprietary and open-source tools.
Furthermore, many organizations likely already have software composition analysis tools (Black Duck, Mend, NexusIQ, etc.) within their pipelines which can generate SBOMs, and simply need to enable the feature and determine a method for appropriate distribution to partners and QSAs.
To learn more about PCI 4.0 transition requirements and implementation and what you need to complete by March 2025, view our comprehensive PCI 4.0 transition plan now or reach out to our team for more information.
