El software adquirido de terceros a menudo plantea un desaf\u00edo para los programas de gesti\u00f3n de riesgos debido a la falta de visibilidad de los componentes del software y sus vulnerabilidades. Para abordar este desaf\u00edo, CISA, NSA y sus socios publicaron un informe: ” Seguridad de la cadena de suministro de software: pr\u00e1cticas recomendadas para el consumo de la lista de materiales de software “. El informe establece las mejores pr\u00e1cticas para el uso de SBOM, que son documentos que enumeran los componentes de software y sus atributos, como versiones, licencias y dependencias.<\/p>\n
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: \u201cSecuring the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption<\/a>.\u201d 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.<\/p>\n 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.<\/p>\n 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:<\/p>\n Establishing expectations<\/b>: 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.<\/p>\n To be on the right track, the following questions need to be answered:<\/p>\n \u2014 Where can I pick up your SBOM for each new software release?<\/p>\n \u2014 Is there a standard location where I can get it?<\/p>\n \u2014 What is the process by which I consume new information automatically? Do I need to build a process to consume new information?<\/p>\n \u2014 How will you share information about your own risk assessment of vulnerabilities?<\/p>\n \u2014 What level of transparency is expected and how complete of an SBOM is expected?<\/p>\n Making software transparency actionable<\/b>: 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.<\/p>\n Making risk assessment repeatable<\/b>: 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.<\/p>\n It\u2019s also important for risk management teams to ask themselves these questions:<\/p>\n What are the trigger events for risk assessment:<\/b><\/i><\/p>\n \u2014 When a new software release is issued?<\/p>\n \u2014 When a security score falls below a certain level?<\/p>\n \u2014 For known exploited vulnerabilities?<\/p>\n When do these triggers apply?<\/b><\/i><\/p>\n \u2014 Do I tier my suppliers and only engage with those above a certain tier?<\/p>\n \u2014 Does a risk reduction campaign impact all of my suppliers?<\/p>\n What are the most effective ways to engage with my suppliers?<\/b><\/i><\/p>\n \u2014 Do I expect my supplier to publish this information regularly or do I email them?<\/p>\n \u2014 Do we assess on a schedule?<\/p>\n 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\u00a0<\/b>before a scoring system is put in place\u00a0will help prioritize and define the inputs of a scoring system.<\/p>\n Governing the cost-effectiveness of software transparency<\/b>: Software transparency is essential for both consumers and suppliers, but it also requires cost-effectiveness and that\u2019s what the final phase of the maturity is all about.<\/p>\n Let\u2019s 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.<\/p>\n