By
The security and resilience of software and digital services have never been more critical. The United States took the lead with the Joe Biden executive order 14028 of May 21, 2021 (link here: https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ )
Recognizing this urgency to act, the European Union has introduced the Cyber Resilience Act (CRA), a landmark regulation aimed at elevating the baseline of cybersecurity across all digital products and services. This act introduces comprehensive measures to ensure that digital offerings are not only secure by design but also maintain their security posture throughout their lifecycle. This new legislation requires EU companies to switch to a secure software supply chain.
Among its key provisions, the CRA emphasizes the necessity of Software Bill of Materials (SBOM), attestation, risk scoring, and Vulnerability Exploitability Exchange (VEX). This blog post delves into these concepts, exploring their significance and the impact they are set to have on the digital ecosystem.
Software Bill of Materials (SBOM)
An SBOM is a detailed inventory of all components that make up a piece of software. In the context of the CRA, requiring an SBOM for digital products and services is akin to enforcing transparency in the software supply chain. This transparency is not just a boon for cybersecurity professionals; it empowers all stakeholders, including end-users, to better understand the provenance and composition of the software they rely on. By mandating SBOMs, the CRA ensures that vulnerabilities can be tracked and remediated more efficiently, significantly reducing the attack surface that cybercriminals can exploit.
An SBOM's critical role in enhancing software supply chain protection cannot be overstated. It provides a comprehensive inventory of all components, libraries, and modules that are in a software product, including open-source and third-party elements.
This transparency is not just a matter of good record-keeping; it's a foundational pillar for identifying, assessing, and mitigating vulnerabilities that could compromise the entire software supply chain. In essence, an SBOM enables organizations to have a clear understanding of their software's anatomy, paving the way for more informed security decisions and robust protection measures.
Regulatory bodies and industry standards are now recognizing the importance of SBOMs, integrating them into compliance requirements. In sum, SBOMs are indispensable tools in the arsenal for fortifying software supply chains against the evolving threat landscape.
Codenotary has an entry level, free offering for vulnerability scanning and SBOM manager with https://SBOM.sh , whereas our Trustcenter/Enterprise product (see more here) is geared towards our business customers who need comprehensive SBOM management:
- Creation
- Sharing
- Storing
- Recurring Vulnerability Scanning
- Integration with VEX (vulnerability and exploitability exchange)
An example might better explain how CRA plays requires an SBOM solution for compliance. Imagine an open-source web application developed using a variety of libraries and frameworks. The application utilizes the following components:
Frontend:
- React.js (v16.13.1) for the user interface
- Redux (v4.0.5) for state management
Backend:
- Node.js (v14.15.4) as the runtime environment
- Express (v4.17.1) for the web server framework
- MongoDB (v4.2.8) as the database
Third-party Services:
- Auth0 (v9.13.2) for authentication
- Stripe (v8.130.0) for payment processing
In this scenario, the SBOM for the web application would list each of these components, including their specific versions. This comprehensive inventory allows the development team and the application's users to understand the application's makeup precisely.
Should a vulnerability be discovered in, for example, in the version of Express being used, the SBOM makes it immediately clear that the application is potentially at risk. The team can then act swiftly to update the framework to a patched version, mitigating the vulnerability before it can be exploited.
Attestation of Supply Chain Security
Attestation in the CRA framework refers to the process by which a software development organization declares and provides evidence that their digital products meet the specified cybersecurity requirements. This process is critical because it places the responsibility on the creators to not only ensure their products are secure from the outset but also to maintain this security over time. Attestation makes the commitment to cybersecurity explicit, creating a culture of accountability and continuous improvement.
As an example let’s imagine a secure application deployment in a multinational bank, that is deploying a new online banking platform. This platform integrates various components, including a customer-facing web application, a backend processing system, and a mobile app. Each component is developed by different teams, using libraries and modules from multiple external sources.
Challenges
Ensuring the integrity and security of each component in the face of potential supply chain attacks. Complying with financial industry regulations that mandate strict cybersecurity measures and documentation.
Implementing Software Attestation
To mitigate these challenges, the bank implements a software attestation process with Trustcenter/Enterprise as part of its CI/CD pipeline.
By integrating Trustcenter/Enterprise with their Jenkins build server, developers use attested build environments to ensure that the software is compiled and packaged securely, without interference from malicious actors. This includes verifying the integrity of compilers and other build tools.
Each component (e.g., the web application, backend system, and mobile app) is signed using the bank’s private keys after successful build and test phases and is verified at each step by Trustcenter/Enterpise before allowing the next phase of the DevOps process to proceed.
Additionally, a Software Bill of Materials (SBOM) is generated for each component, listing all external dependencies and their versions. These SBOMs are also signed.
Verifying Attestation during Deployment: Before deployment, the platform's deployment mechanisms verify the digital signatures of each component and its SBOM to ensure they are intact and have not been tampered with since signing.
This verification process uses the corresponding public keys held securely by the deployment infrastructure.
Continuous Monitoring and Attestation: Post-deployment, the bank employs Trustcenter/Enterprise to continuously monitor the integrity of the platform and its components.
Any updates, including patches for vulnerabilities, must undergo the same attestation process before deployment.
Risk Scoring
The CRA introduces the concept of risk scoring, a methodology for evaluating and quantifying the cybersecurity risk associated with digital products and services. Risk scoring is vital for several reasons.
Firstly, it provides a standardized way to assess risk, making it easier for stakeholders to make informed decisions.
Secondly, it encourages manufacturers and developers to prioritize security measures based on the potential impact of vulnerabilities.
By integrating risk scoring into the development and deployment process, the CRA aims to foster a risk-aware culture, ensuring that resources are allocated efficiently to mitigate the most critical vulnerabilities.
As part of the Trustcenter/Enterprise offering the system will keep track of the continuous risk score of an application silo and inform stakeholders immediately when action is warranted.
Vulnerability Exploitability Exchange (VEX)
VEX is a mechanism for communicating the exploitability of known vulnerabilities in the context of specific products or services. It plays a crucial role in the CRA's strategy for enhancing cyber resilience.
VEX allows manufacturers and developers to inform users about vulnerabilities that are not applicable or pose no risk to their products, thereby reducing unnecessary panic and patching efforts.
This targeted approach to vulnerability management ensures that efforts are focused on mitigating risks that are truly relevant, enhancing the overall security posture without overburdening stakeholders.
Trustcenter/Enterprise has a world-class VEX implementation that allows organizations to keep track of those issues that need immediate action and those that can be resolved as a second priority.
As a case study let’s imagine a health care provider. In the healthcare sector, where data sensitivity and privacy are paramount, ensuring the security of software supply chains is crucial. For example, let’s take a fictitious MedTech Solutions, a company that offers a SaaS platform for healthcare providers. This platform integrates various third-party services, including electronic health records (EHR), telemedicine, and patient data analytics tools. Given the diversity of components and their origins, managing vulnerabilities effectively becomes a significant challenge.
Challenge: Efficient Vulnerability Management
MedTech Solutions must ensure that its platform and the integrated third-party services adhere to stringent healthcare regulations and standards, such as HIPAA in the United States. The company faces the challenge of identifying and mitigating vulnerabilities across its software supply chain without disrupting the availability or performance of its critical healthcare services.
Implementing Vulnerability Exploitability Exchange (VEX)
To address this challenge, MedTech Solutions adopts Trustcenter/Enterprise for its VEX strategy. VEX documents provide detailed information about whether a known vulnerability is exploitable in the context of a specific product or service. By integrating VEX into their vulnerability management processes, MedTech Solutions can achieve several key outcomes:
Targeted Remediation Efforts
When a new vulnerability is disclosed, Trustcenter/Enterprise will immediately notify MedTech Solutions’ team so it can quickly assess its impact on the platform and the integrated third-party services through VEX documents.
If a Trustcenter/Enterprise indicates that a vulnerability is not exploitable in the context of a specific component, MedTech Solutions can prioritize remediation efforts more effectively, focusing on vulnerabilities that pose a real threat.
Regulatory Compliance
By maintaining comprehensive VEX documentation, MedTech Solutions can demonstrate to regulators that it has a thorough understanding of its exposure to known vulnerabilities and is taking appropriate steps to address them. This documentation supports compliance with healthcare regulations by showing a proactive and informed approach to cybersecurity.
Strengthened Partner Relationships
MedTech Solutions requires its third-party service providers to supply VEX documents for their products. This requirement encourages a culture of transparency and cooperation among all parties involved in the supply chain. It ensures that all components integrated into the MedTech Solutions platform are monitored for vulnerabilities and that exploitable issues are addressed promptly.
Enhanced Trust with Healthcare Providers
By implementing a VEX-based approach with Trustcenter/Enterprise for vulnerability management, MedTech Solutions can provide assurances to healthcare providers that the platform is resilient against known vulnerabilities. This transparency enhances trust and confidence among the platform's users, which is crucial in the healthcare industry.
Conclusion
The new EU legislation requires companies to enable a trusted and secure software supply chain. The implementation of such a secure software supply chain requires tools such as SBOM, Risk scoring, VEX and attestation. Trustcenter/Enterprise is a proven platform to implement CRA in all its requirements and is used by many of the largest financial institutions today in the EU, and beyond.
