{"id":4590,"date":"2022-05-18T11:26:56","date_gmt":"2022-05-18T11:26:56","guid":{"rendered":"https:\/\/solutionsreview.com\/enterprise-resource-planning\/?p=4590"},"modified":"2023-08-01T18:08:52","modified_gmt":"2023-08-01T18:08:52","slug":"how-sboms-reduce-software-procurement-risk-and-improve-enterprise-security","status":"publish","type":"post","link":"https:\/\/solutionsreview.com\/enterprise-resource-planning\/how-sboms-reduce-software-procurement-risk-and-improve-enterprise-security\/","title":{"rendered":"How SBOMs Reduce Software Procurement Risk and Improve Enterprise Security\u00a0"},"content":{"rendered":"

\"How<\/p>\n

As part of Solutions Review\u2019s\u00a0Contributed Content Series<\/a>\u2014a collection of articles written by industry thought leaders in maturing software categories\u2014Mike Dager, the Chief Executive Officer of GrammaTech<\/a>, shares some insights on the enterprise security benefits that software bill of materials (SBOMs) can offer to supply chain professionals.<\/strong><\/em><\/p>\n

Supply chain professionals should be familiar with a bill of materials (BOM), which is used to build quality products and support the procurement, inventory management, and resolution of problems involved in creating those products.<\/span> A BOM is also used to manage parts and maintenance supplies when buying products. However, software procurement is often more concerned with licensing terms, security requirements, pricing, maintenance, and support needs. While the BOM concept for software procurement is relatively new, it is now becoming an essential piece of managing the software supply chain.<\/span>\u00a0<\/span><\/p>\n

A Software BOM (SBOM for short), like a traditional BOM, is a list of third-party and open-source components that make up a software product. The SBOM is also responsible for listing the features that various subcomponents rely on and identifying licensing info, software versions, and vulnerabilities.<\/span><\/p>\n

In the past, software was assumed only to contain code and intellectual property developed by the product vendor. However, modern software is no longer developed entirely from scratch and almost always contains third-party and open-source software components. These components may include potential security vulnerabilities the buyer could be introducing into their environment.<\/span>\u00a0<\/span><\/p>\n

To put the problem in context, a study by <\/span>Osterman Research<\/span><\/a> found that 100-percent of widely used commercial software contained vulnerable open-source components. A worrying 85-percent of those analyzed applications had critical vulnerabilities which pose a significant security risk. <\/span>The most vulnerable applications are daily email and online meeting applications, which is a problem because enterprise organizations widely use these applications and these vulnerabilities present a severe cybersecurity risk.<\/span><\/p>\n

With many high-profile security breaches and attacks linked to purchased software, there’s now a heightened awareness of software supply chain security and the demand for SBOMs. The recent <\/span>Presidential Cybersecurity Executive Order<\/span><\/a> specifically identified the importance of improving the software supply chain. It spotlighted the critical need for SBOMs as a mandated prerequisite for software vendors doing business with the federal government. <\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

While RFPs, RFIs, and vendor questionnaires are part of the procurement due diligence process, the vendor fills these documents, and the procurement team has to trust them. Meanwhile, an SBOM is a document of \u201ctruth\u201d of what is actually in the software. Generally speaking, procurement departments are not expected to have technical knowledge of the software they purchase. However, it does help to understand what an SBOM should include so you can evaluate supplier SBOMs. At the very least, the components listed in an SBOM need to be well identified to have:<\/span>\u00a0<\/span><\/p>\n