Developers routinely utilize third-party code to build their applications for the sake of efficiency and time savings. However, this reliance on external components, particularly open-source software (OSS), introduces significant risks, including vulnerabilities and licensing issues. According to a 2023 GitHub survey, 31% of developers consider finding and fixing security vulnerabilities their second most important task, right after writing code (32%).
Consequently, many organizations are worried about their reliance on OSS as it is frequently targeted by hackers. Organizations face challenges with increased vulnerability across the software supply chain and with understanding how to effectively mitigate risk in the wake of recent high-profile attacks.
A research report by ESG reveals that 91% of organizations have experienced a software supply chain incident in the last 12 months. The most common incidents include:
Prominent vulnerabilities like Log4J, Curl, Apache Struts, and OpenSSL have all led to numerous instances of operational damage. These highlight the severe impact posed to organizations when a single weakness within the software supply chain is exploited. In response to these growing risks, regulatory bodies around the world are emphasizing software transparency and security. The adoption of a Software Bill of Materials (SBOM) is becoming a key strategy for managing software supply chain risks.
SBOM Regulations Gain Momentum
SBOM regulations are increasingly widespread. Many governments have published recommendations regarding SBOM implementation. In the US, SBOM recommendations are included in several government guidelines, including:
In Europe, the EU Agency for Cybersecurity (ENISA) has published “Guidelines for Securing the Supply Chain for the Internet of Things,” offering organizations valuable insights into improving cybersecurity and managing software-related supply chain risks.
Other countries have issued similar guidelines, including:
Advises organizations to use SBOMs to assess the risks associated with the software components they utilize and to identify and address vulnerabilities in those components.
In “Information Security Manual: Guidelines for Software Development,” the ACSC recommends using SBOMs to enhance cyber supply chain transparency, facilitating the identification and management of security risks linked to individual software components used in applications.
How the PCI DSS Necessitates SBOM Generation
Recognizing the escalating risks to payment card data, the Payment Card Industry Data Security Standard (PCI DSS) has become a driving force for SBOM adoption. The latest version, PCI DSS 4.0, mandates the use of SBOMs, underscoring their critical role in safeguarding sensitive information. By providing a detailed inventory of software components, SBOMs empower organizations to identify and address vulnerabilities proactively, reducing the risk of costly data breaches and financial loss.
Established in 2004, the PCI DSS is a comprehensive security standard designed to protect credit card information. It outlines a set of rigorous requirements for businesses handling credit card transactions, tailored to the volume of transactions processed annually. The 2022 release of PCI DSS v4.0 introduced significant changes, including the SBOM mandate, to address evolving threats. Compliance with PCI DSS v4.0 is mandatory by April 2024, with specific requirements phased in by March 31, 2025.
Source: PCI DSS V4.0 at a Glance
By mandating SBOMs, the PCI DSS empowers organizations to gain a comprehensive understanding of their software ecosystem, enabling them to identify and address vulnerabilities proactively. This approach significantly reduces the risk of costly data breaches and financial loss.
A newer version of the PCI DSS, version 4.0.1, was released in mid-2024. This means the previous version, 4.0, will no longer be valid after December 31, 2024. However, the new version doesn't add or remove any rules and doesn't change the deadlines. Therefore, the information about SBOM requirements in this blog applies to both versions 4.0 and 4.0.1.
Complying with PCI DSS Requirement 6.3.2
The SBOM requirement in PCI DSS v4.0 is part of the broader enhancements made to the PCI DSS in its latest iteration. Introduced as part of the 64 new requirements added in version 4.0, the SBOM requirement specifically addresses the need for organizations to maintain an inventory of software components, particularly focusing on bespoke and custom software.
This requirement is categorized under PCI DSS Requirement 6 which mandates the creation and upkeep of secure systems and applications through the implementation of strong security measures and the regular performance of vulnerability assessments and updates. This requirement is essential for reducing the risks posed by software vulnerabilities and safeguarding cardholder data. Section 6 covers five primary areas:
- 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
- 6.2 Bespoke and custom software are developed securely.
- 6.3 Security vulnerabilities are identified and addressed.
- 6.4 Public-facing web applications are protected against attacks.
- 6.5 Changes to all system components are managed securely.
More specifically, requirement 6.3.2 is an important update which resulted from several breaches where vulnerabilities in third-party components, or breaches of third-party component providers, led to a compromise of cardholder data. The requirement reads as follows:
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.
Organizations must thoroughly document and manage the specific components and services used in their applications. While some of this information may have been covered in data flow diagrams, the new requirements demand much more detailed documentation. Keeping track of these details can be challenging as components are updated and changed. It's advisable to use a standard template for capturing this information. Additionally, some source code repositories, like GIT, may offer tools to export a list of components in use. At a minimum, your inventory should include:
- Application Components (typically repository projects)
- List of third-party components
- List of application dependencies (i.e. Tomcat, Jboss, .NET, Middleware)
- List of Authorized Payment Page Scripts
How OPSWAT SBOM can Help Meet PCI DSS Requirements
Regulations increasingly call for SBOMs to ensure software supply chain security. However, organizations are struggling to build accurate inventories of their software code composition.
Source: EGS Report 2024
The creation of accurate and comprehensive SBOMs, however, presents a substantial challenge for organizations. These documents demand meticulous inventorying of software components, necessitating detailed information about their origins, versions, and interdependencies. Without precise SBOMs, organizations struggle to effectively identify, assess, and mitigate the risks inherent in their software supply chain.
Guidelines for Generating SBOMs
OPSWAT SBOM automates the generation of SBOMs for both code and containers, enhancing security and aiding compliance within the software supply chain.
- Identify All Components and Dependencies
Accurately identify all software components, including open-source and third-party libraries, along with their versions and dependencies. This forms the foundation for a robust SBOM. - Assess OSS Risks
Evaluate the potential risks associated with OSS components. Consider factors such as license compliance, security vulnerabilities, and maintenance status. Prioritize components based on their criticality to the software. - Scan for OSS Vulnerabilities
Utilize vulnerability scanning and SBOM generation tools to identify known vulnerabilities within the OSS components. Prioritize vulnerabilities based on their severity and potential impact on the software.
Using OPSWAT SBOM
OPSWAT SBOM automates the generation of SBOMs for both code and containers, enhancing security and aiding compliance within the software supply chain.
Here’s how you can utilize OPSWAT SBOM to generate SBOMs effectively:
By providing an inventory of all open-source libraries and components used within an application, OPSWAT SBOM helps manage dependency vulnerabilities in the software supply chain, empowering users to identify and fix vulnerabilities in applications efficiently.
In addition to identifying vulnerabilities, OPSWAT SBOM validates licenses associated with each software component. This ensures compliance with licensing terms and avoids potential legal pitfalls. Learn more about the crucial role of license detection in OSS.
OPSWAT SBOM supports over 10 programming languages, including Java, JavaScript, Go, PHP, and Python. This broad support ensures comprehensive vulnerability detection across various software development ecosystems.
Penalties for Non-compliance
Organizations that do not comply with PCI DSS standards, including the SBOM requirement, can incur financial penalties ranging from $5,000 to $100,000 per month. These fines can escalate over time if compliance issues remain unresolved.
In addition to financial penalties, non-compliance with PCI DSS can lead to significant legal and operational challenges. Legal consequences may include lawsuits, defense costs, and substantial settlements. Moreover, non-compliance could trigger federal audits by agencies such as the Federal Trade Commission (FTC), leading to additional penalties.
Next Steps for PCI DSS 4.0 Compliance
The integration of SBOM into the PCI DSS 4.0 framework signifies a pivotal shift towards a more secure software supply chain. By leveraging advanced tools like OPSWAT SBOM, organizations can effectively manage open-source risks, enhance compliance, and protect against costly data breaches.
Utilizing SBOMs is no longer an option but a necessity. By taking proactive steps to understand and address software dependencies, organizations can build a robust security foundation that safeguards their operations and builds customer trust.
Improve Your Security Posture with OPSWAT
Start managing open-source
dependencies now.
