Software Transparency: A Key to Effective Risk Management
Software procured from third parties often poses a challenge for risk management programs due to the lack of visibility into the software components and their vulnerabilities. To address this challenge, the CISA, NSA and partners published a report: “Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption.” The report sets forth the best practices for using SBOMs, which are documents that list the software components and their attributes, such as versions, licenses and dependencies.
However, SBOMs are not an end in themselves, but a means to software transparency. Software consumers, such as government agencies, demand software transparency to make informed risk management decisions. The SBOM has been the focus of conversation as the means by which software producers share information with software consumers.
Therefore, to advance software transparency, both software consumers and producers need to adopt maturity models and targets that guide their practices and expectations. We recommend a four-phased maturity model for software transparency, which consists of the following stages:
Establishing expectations: Software consumers and producers need to agree on the level and frequency of software transparency, as well as the format and delivery of SBOMs. Software consumers should not request SBOMs only for one-time supply chain risk assessment, but for continuous monitoring and updating of software inventory and security.
To be on the right track, the following questions need to be answered:
— Where can I pick up your SBOM for each new software release?
— Is there a standard location where I can get it?
— What is the process by which I consume new information automatically? Do I need to build a process to consume new information?
— How will you share information about your own risk assessment of vulnerabilities?
— What level of transparency is expected and how complete of an SBOM is expected?
Making software transparency actionable: Software consumers need to maintain an accurate and up-to-date inventory of their software assets, and map them to the corresponding SBOMs. This enables them to identify the owners and locations of software applications, and implement corrective actions when needed. Software producers need to support software consumers in this process by providing timely and accurate SBOMs, and by notifying them of any changes or issues in software components.
Making risk assessment repeatable: In this phase, software consumers need to define trigger events for conducting risk assessment of software, such as new software releases, vulnerability disclosures, or configuration changes. Software consumers also need to standardize their risk assessment methods and criteria, and engage with software producers to verify and validate the impact and exploitability of vulnerabilities in software components. Software producers need to cooperate with software consumers in this process, by providing relevant and reliable information, and by offering remediation options and guidance.
It’s also important for risk management teams to ask themselves these questions:
What are the trigger events for risk assessment:
— When a new software release is issued?
— When a security score falls below a certain level?
— For known exploited vulnerabilities?
When do these triggers apply?
— Do I tier my suppliers and only engage with those above a certain tier?
— Does a risk reduction campaign impact all of my suppliers?
What are the most effective ways to engage with my suppliers?
— Do I expect my supplier to publish this information regularly or do I email them?
— Do we assess on a schedule?
The SBOM guidance document suggests that a scoring system be created to help scale risk assessment practices and make them more repeatable. These scoring systems could help normalize trigger events and engagement practices with suppliers. But before an output such as a score can be created, its inputs must be defined. Practicing risk assessment based on triggered events before a scoring system is put in place will help prioritize and define the inputs of a scoring system.
Governing the cost-effectiveness of software transparency: Software transparency is essential for both consumers and suppliers, but it also requires cost-effectiveness and that’s what the final phase of the maturity is all about.
Let’s say I trigger a risk assessment for a critical COTS application and find that the security score of the SBOM deployed in production has dropped below a threshold. I need to contact my vendor to fix it. They may suggest upgrading, correcting the score, or updating the application to address the risk. If a vendor has already made updates, they can be automated. If not, I have to rely on risk assessment and relationship management.
To reduce the cost of vendor engagement, I can use VEX (Vulnerability Exploitability eXchange), a tool that standardizes and streamlines vulnerability sharing and management across the software supply chain. However, maintaining VEX documents is expensive and demands transparency and commitment from both parties. Therefore, VEX automation depends on either setting clear expectations or lowering the cost of customer engagement. Until then, I have to follow the recommended practices that involve frequent communication and collaboration with vendors through emails or other customer-vendor collaboration applications.
Software transparency needs to be cost-effective for both consumers and suppliers in order to be successful. As more government programs seek to get visibility across their third- and first-party applications, recommended practices will evolve into a maturity model. Ultimately, software transparency is going to be battle-tested.
Jamie is a product manager building code governance solutions at Endor Labs.
