Systems and methods for enhancing software bills of materials (SBOMS)

Abstract

A system and methods are described to manage, store, and enhance Software Bills of Materials (SBOMs) that accompany and describe the contents of a particular software product. The platform can import an initial SBOM as might be provided by a developer or vendor of a software product. The initial SBOM is analyzed to identify initial dependencies implicated within the software product. The platform will then schedule a mock software build including these identified dependencies. During this build process, further hidden dependencies are identified which were not apparent in the initial SBOM. The build process continues recursively until all dependencies have been identified, thus ensuring complete visibility of the components that make up the software product. Once all dependencies are identified, the system can produce an enhanced SBOM report that lists these dependencies and assesses their risks. An enhanced SBOM can be generated from the report.

Description

Systems and Methods for Enhancing Software Bills of Materials (SBOMs)FIELD OF THE INVENTION

[0001] The present invention relates generally to a system and method for managing and enhancing Software Bills of Materials (SBOMs) provided by software developers and vendors to their customers. This application incorporates by reference in its entirety, and claims priority to, U.S. Provisional Patent Application Serial No. 63 / 727,459, filed December 3, 2024.BACKGROUND

[0002] Recently the software industry has suffered numerous supply chain attacks that have resulted in malicious software being provided by software vendors to their clients. Attackers often corrupt the systems that build the software, or may inject malware into dependencies incorporated into software when it is being built.

[0003] A “dependency” is a certain software module that is needed for execution of the software product, which denotes a relationship between software components where one component relies on the other to work properly. For example, if a software product uses a library to query a database, the software depends on that library. If the library’ is unavailable or not working correctly, the software cannot make queries to the database and the software will not function as intended. Dependencies may be “on-line” and accessible to the software when it is executed (assuming the software has access to the Internet), or may be packaged with the software product to ensure its availability.

[0004] Dependencies are often open-source. As such, incorporating a dependency into a software product carries additional security risks because such dependencies are not under control of the software developer. As noted, dependencies may contain malware, or suffer from other problems that could impact the security of the software product into which they are incorporated.

[0005] One of the challenges when protecting against attacks that might be lurking in software is a lack of visibility concerning what components are included or implicated in a softw are product. To address this lack of visibility, the U.S. government’s National Telecommunications and Information Administration (NTIA) published a specification entitled “The Minimum Elements for a Software Bill of Materials (SBOM)” on July 12, 2021. iGenerally speaking, an SBOM is a record containing the details and supply chain relationships of various components used in building software. An SBOM therefore, among other details, ideally includes information concerning what dependencies are present in or implicated by the software. In theory, a software customer can review an SBOM to determine whether associated software and its components are safe, or whether they present a security risk.

[0006] Subsequent to the NTIA specification discussed above, government agencies and industry organizations began drafting rules requiring software vendors to provide SBOMs when delivering a software product. Consistent with such specifications, in various vertical industries, delivering SBOMs with supplied software is moving from being a mere recommendation to being a firm requirement. This is particularly true for software provided to U.S. government agencies as well as the medical device market. It is expected in coming years that a requirement to supply SBOMs with software will spread to financial services, and eventually to all mission-critical software.

[0007] The requirement to provide SBOMs with supplied softw are presents a challenge for both software developers, vendors, and customers, because the number of SBOMs to be supplied, reviewed, and managed will be very large and unwieldy. Furthermore, traditional SBOMs may7not always adequately7identify all components in a software product. Existing tools that create SBOMs typically do so by scanning manifest and lock files, which describe the dependencies required to build the software. However, a dependency may itself be dependent on a different software module. That is, a dependency may have a dependency, and so on. Software-vendor-supplied SBOMs produced by the software build system tend to only list direct or first-tier dependencies, but not those that may be nested farther downstream (i.e., dependencies of dependencies in second- and third-tiers, etc.). In short, typical SBOMs may not list all nested dependencies.

[0008] The platform described herein provides a means for both software customers, vendors, and developers to track, manage, and enhance the huge number SBOMs associated with software either deployed or produced in the entity’s environment.SUMMARY

[0009] In a first embodiment, a software platform is disclosed useable to enhance an initial Software Bill of Materials (SBOM) associated with a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network including one or more build services. The software platform may comprise: a proxy operable to capture communications issued by the one or more servicesconnected to the network; and a SBOM logic service connected to the network and configured to: (a) import and assess the initial SBOM to determine information indicative of initial dependencies of the software product referenced in the initial SBOM; (b) download the initial dependencies into a dependencies database; (c) cause one or more risk metrics to be determined for each downloaded initial dependency and store the one or more risk metrics in the dependencies database; (d) cause a mock software build to occur using the one or more build services, wherein the mock software build includes the initial dependencies; (e) use the proxy during the mock software build to determine further hidden dependencies of the software product; (f) download the hidden dependencies into the dependencies database; (g) cause one or more risk metrics to be determined for each downloaded hidden dependency and store the one or more risk metrics in the dependencies database; (h) repeat steps (d) through (g) by including the hidden dependencies in the mock software build until all hidden dependencies have been uncovered and assessed; and (i) generate a report, wherein the report includes information about the initial and hidden dependencies and their associated risk metrics.

[0010] In one example of this first embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this first embodiment, the dependencies database is associated with the SBOM logic. In one example of this first embodiment, the hidden dependencies are not referenced in the initial SBOM. In one example of this first embodiment, the initial and hidden dependencies are downloaded in steps (b) and (f) only if they are not already stored in the dependencies database. In one example of this first embodiment, the one or more risk metrics are determined for each initial and hidden dependencies only if the one or more risk metrics are not already stored in the dependencies database. In one example of this first embodiment, the one or more risk metrics are determined in a policy decision logic sendee connected to the network. In one example of this first embodiment, the policy decision logic service comprises one or more engines that provide the one or more risk metrics by assessing one or more risk databases and one or more PolicyPaks. In one example of this first embodiment, the PolicyPaks comprise a set of prepackaged policies to thw art one or more threats. In one example of this first embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this first embodiment, the report is generated via a graphical user interface (GUI) accessible by a portal connected to the network. In one example of this first embodiment, the GUI includes an option to export an enhanced SBOM using the information in the report. In one example of this first embodiment, the enhanced SBOM comprises information indicative of the initial dependencies and the hidden dependencies. In one example of this first embodiment, the GUI includes oneor more environmental inputs relevant to the environment within which the initial SBOM was generated. In one example of this first embodiment, the GUI includes an option to start a scan of the imported initial SBOM, which initiates steps (b)-(i). In one example of this first embodiment, the report displays a number of the initial dependencies and either (i) a number of the hidden dependencies, or (ii) a total number of the initial and hidden dependencies. In one example of this first embodiment, the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this first embodiment, the plurality of risk classifications comprise a high, medium, and low risk. In one example of this first embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In one example of this first embodiment, the one or risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this first embodiment, the SBOM logic senice is further configured to determine a risk score for the software product using the individual dependency risk scores for each initial and hidden dependency

[0011] In a second embodiment, a method is disclosed for enhancing an initial Software Bill of Materials (SBOM) associated with a software product usable with a software platform implemented as a plurality of network nodes each implementing one or more services connected to a network including one or more build services. The method may comprise: using a proxy to capture communications issued by the one or more services connected to the network; and using a SBOM logic service connected to the network to implement a process, the process comprising: (a) importing and assessing the initial SBOM to determine information indicative of initial dependencies of the software product referenced in the initial SBOM; (b) downloading the initial dependencies into a dependencies database; (c) causing one or more risk metrics to be determined for each downloaded initial dependency and storing the one or more risk metrics in the dependencies database; (d) causing a mock software build to occur using the one or more build services, wherein the mock software build includes the initial dependencies; (e) using the proxy during the mock software build to determine further hidden dependencies of the software product; (!) downloading the hidden dependencies into the dependencies database; (g) causing one or more risk metrics to be determined for each downloaded hidden dependency and store the one or more risk metrics in the dependencies database; (h) repeating steps (d) through (g) by including the hidden dependencies in the mock software build until all hidden dependencies have been uncovered and assessed; and (i)generating a report, wherein the report includes information about the initial and hidden dependencies and their associated risk metrics.

[0012] In one example of this second embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this second embodiment, the dependencies database is associated with the SBOM logic. In one example of this second embodiment, the hidden dependencies are not referenced in the initial SBOM. In one example of this second embodiment, the initial and hidden dependencies are downloaded in steps (b) and (f) only if they are not already stored in the dependencies database. In one example of this second embodiment, the one or more risk metrics are determined for each initial and hidden dependencies only if the one or more risk metrics are not already stored in the dependencies database. In one example of this second embodiment, the one or more risk metrics are determined in a policy decision logic service connected to the network. In one example of this second embodiment, the policy decision logic service comprises one or more engines that provide the one or more risk metrics by assessing one or more risk databases and one or more PolicyPaks. In one example of this second embodiment, the PolicyPaks comprise a set of prepackaged policies to thwart one or more threats. In one example of this second embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this second embodiment, the report is generated via a graphical user interface (GUI) accessible by a portal connected to the network. In one example of this second embodiment, the method further comprises using the GUI to export an enhanced SBOM using the information in the report. In one example of this second embodiment, the enhanced SBOM comprises information indicative of the initial dependencies and the hidden dependencies. In one example of this second embodiment, the GUI includes one or more environmental inputs relevant to the environment within which the initial SBOM was generated. In one example of this second embodiment, the method further comprises starting a scan of the imported initial SBOM using the GUI, which initiates steps (b)-(i). In one example of this second embodiment, the report displays a number of the initial dependencies and either (i) a number of the hidden dependencies, or (ii) a total number of the initial and hidden dependencies. In one example of this second embodiment, the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this second embodiment, the plurality of risk classifications comprise a high, medium, and low risk. In one example of this second embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In oneexample of this second embodiment, the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this second embodiment, the SBOM logic service further determines a risk score for the software product using the individual dependency risk scores for each initial and hidden dependency.

[0013] In a third embodiment, a software platform is disclosed useable by a developer of a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network. The software platform may comprises: a proxy operable to capture communications issued by the one or more services connected to the network; and a Software Bill of Materials (SBOM) exchange sendee connected to the network and configured to: receive an initial SBOM associated with the software product, wherein the initial SBOM comprises information indicative of initial dependencies of the software product; cause an SBOM logic service to generate an enhanced SBOM from the initial SBOM using the proxy, wherein the enhanced SBOM includes hidden dependencies of the software product in addition to the initial dependencies; receive information indicative of customers of the software product; and automatically provide to the customers access to the enhanced SBOM.

[0014] In one example of this third embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this third embodiment, the SBOM exchange service is associated with the SBOM logic service. In one example of this third embodiment, the hidden dependencies are not included in the initial SBOM. In one example of this third embodiment, the SBOM exchange service is further configured to cause the SBOM logic sendee to generate an enhanced SBOM report. In one example of this third embodiment, the SBOM logic service is further configured to generate the enhanced SBOM from information in the enhanced SBOM report. In one example of this third embodiment, the enhanced SBOM report comprises one or more risk metrics for each initial and hidden dependency. In one example of this third embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this third embodiment, the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this third embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In one example of this third embodiment, the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this third embodiment, the SBOM exchange service is further configured to automatically provide to thecustomers access to the enhanced SBOM report. In one example of this third embodiment, the enhanced SBOM is viewable or downloadable via a portal connected to the network. In one example of this third embodiment, the SBOM exchange service is further configured to automatically provide to the customers access to the initial SBOM. In one example of this third embodiment, the SBOM exchange service is further configured to automatically update the enhanced SBOM when the initial SBOM is updated, and to automatically provide to the customers access to the updated enhanced SBOM. In one example of this third embodiment, the SBOM exchange sendee is configured to automatically receive information from the developer when the initial SBOM is updated. In one example of this third embodiment, the SBOM exchange service is further configured to send a notice to each of the customers of the software product that they have access to the enhanced SBOM. In one example of this third embodiment, the notice enables each customer to inform the SBOM exchange service of a manner in which they will receive the enhanced SBOM. In one example of this third embodiment, the notice invites each customer to create an account on the platform. In one example of this third embodiment, the SBOM exchange service is configured to automatically provide to the customers access to the enhanced SBOM by transmitting the enhanced SBOM to the customers.

[0015] In a fourth embodiment, a method is disclosed useable at a software platform by a developer of a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network. The method may comprises: using a proxy to capture communications issued by the one or more services connected to the network; and using a Software Bill of Materials (SBOM) exchange sendee connected to the network to implement a process, the process comprising: receiving an initial SBOM associated with the software product, wherein the initial SBOM comprises information indicative of initial dependencies of the software product; causing an SBOM logic service to generate an enhanced SBOM from the initial SBOM using the proxy, wherein the enhanced SBOM includes hidden dependencies of the software product in addition to the initial dependencies; receiving information indicative of customers of the software product; and automatically providing to the customers access to the enhanced SBOM.

[0016] In one example of this fourth embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this fourth embodiment, the SBOM exchange service is associated with the SBOM logic service. In one example of this fourth embodiment, the hidden dependencies are not included in the initial SBOM. In one example of this fourth embodiment, the SBOM logic service further generates an enhanced SBOMreport. In one example of this fourth embodiment, the SBOM logic service generates the enhanced SBOM from information in the enhanced SBOM report. In one example of this fourth embodiment, the enhanced SBOM report comprises one or more risk metrics for each initial and hidden dependency. In one example of this fourth embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this fourth embodiment, the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this fourth embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In one example of this fourth embodiment, the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this fourth embodiment, the SBOM exchange sendee automatically provides to the customers access to the enhanced SBOM report. In one example of this fourth embodiment, the enhanced SBOM is viewable or downloadable via a portal connected to the network. In one example of this fourth embodiment, the SBOM exchange automatically provides to the customers access to the initial SBOM. In one example of this fourth embodiment, the SBOM exchange service automatically update the enhanced SBOM when the initial SBOM is updated, and to automatically provides to the customers access to the updated enhanced SBOM. In one example of this fourth embodiment, the SBOM exchange service automatically receives information from the developer when the initial SBOM is updated. In one example of this fourth embodiment, the SBOM exchange service sends a notice to each of the customers of the software product that they have access to the enhanced SBOM. In one example of this fourth embodiment, the notice enables each customer to inform the SBOM exchange service of a manner in which they will receive the enhanced SBOM. In one example of this fourth embodiment, the notice invites each customer to create an account on the platform. In one example of this fourth embodiment, the SBOM exchange service automatically provides to the customers access to the enhanced SBOM by transmitting the enhanced SBOM to the customers.

[0017] In a fifth embodiment, a software platform is disclosed useable by a customer of software products, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network. The software platform may comprise: a proxy operable to capture communications issued by the one or more services connected to the network; and a Software Bill of Materials (SBOM) exchange sendee connected to the network and configured to: receive initial SBOMs each associated with oneof the software products, wherein the initial SBOMs each comprise information indicative of initial dependencies of the associated software product; cause an SBOM logic service to generate an enhanced SBOM report for an associated one of the initial SBOMs using the proxy, wherein each enhanced SBOM report includes information indicative of hidden dependencies of the associated software product in addition to the information indicative of I the initial dependencies, and one or more risk metrics for each initial and hidden dependency; and associate the customer with the initial SBOMs and with the enhanced SBOM reports to enable the customer to view or download the initial SBOMs and the enhanced SBOM reports at or from the SBOM exchange service.

[0018] In one example of this fifth embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this fifth embodiment, the SBOM exchange service is associated with the SBOM logic service. In one example of this fifth embodiment, the hidden dependencies for each enhanced SBOM report are not included in its associated initial SBOM. In one example of this fifth embodiment, the SBOM exchange service is further configured to cause the SBOM logic service to generate an enhanced SBOM for each of the initial SBOMs. In one example of this fifth embodiment, the SBOM logic service is further configured to generate the enhanced SBOM for each of the initial SBOMs from information in its associated enhanced SBOM report. In one example of this fifth embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this fifth embodiment, the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this fifth embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In one example of this fifth embodiment, the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this fifth embodiment, the SBOM exchange sen-ice is further configured to associate the customer with the enhanced SBOMs to enable the customer to view or download the enhanced SBOMs at or from the SBOM exchange service. In one example of this fifth embodiment, the initial SBOMs and the enhanced SBOM reports are viewable or downloadable via a portal connected to the network. In one example of this fifth embodiment, the SBOM exchange service is further configured to automatically update one of the enhanced SBOM reports when its associated initial SBOMs is updated, and to automatically enable the customer to view or download the updated enhanced SBOM report at or from the SBOM exchange sendee. In one example of this fifth embodiment, the SBOM exchangesen-ice is configured to automatically receive information from the customer when one or more of the initial SBOMs is updated. In one example of this fifth embodiment, the SBOM exchange service is configured to automatically receive information from one or more developers of the software products when one or more of the initial SBOMs is updated. In one example of this fifth embodiment, the SBOM exchange service is further configured to send a notice to the customer to view or download one or more of the initial SBOMs and the enhanced SBOM reports. In one example of this fifth embodiment, the SBOM exchange service is configured to transmit one or more of the initial SBOMs and the enhanced SBOM reports to the customer.

[0019] In a sixth embodiment, a method is disclosed useable at a software platform by a customer of software products, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network. The method may comprise: using a proxy to capture communications issued by the one or more services connected to the network; and using a Software Bill of Materials (SBOM) exchange sendee connected to the network to implement a process, the process comprising: receiving initial SBOMs each associated with one of the software products, wherein the initial SBOMs each comprise information indicative of initial dependencies of the associated software product; causing an SBOM logic service to generate an enhanced SBOM report for an associated one of the initial SBOMs using the proxy, wherein each enhanced SBOM report includes information indicative of hidden dependencies of the associated software product in addition to the information indicative of I the initial dependencies, and one or more risk metrics for each initial and hidden dependency; and associating the customer with the initial SBOMs and with the enhanced SBOM reports to enable the customer to view or download the initial SBOMs and the enhanced SBOM reports at or from the SBOM exchange service.

[0020] In one example of this sixth embodiment, the initial and hidden dependencies comprise open source dependencies. In one example of this sixth embodiment, the SBOM exchange service is associated with the SBOM logic service. In one example of this sixth embodiment, the hidden dependencies for each enhanced SBOM report are not included in its associated initial SBOM. In one example of this sixth embodiment, the SBOM exchange service causes the SBOM logic service to generate an enhanced SBOM for each of the initial SBOMs. In one example of this sixth embodiment, the SBOM logic service generates the enhanced SBOM for each of the initial SBOMs from information in its associated enhanced SBOM report. In one example of this sixth embodiment, the one or more risk metrics are determined by one or more dependency risk services connected to the network. In one example of this sixth embodiment, the one or more risk metrics comprise a risk breakdown for eachinitial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications. In one example of this sixth embodiment, the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk. In one example of this sixth embodiment, the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency. In one example of this sixth embodiment, the SBOM exchange service associates the customer with the enhanced SBOMs to enable the customer to view or download the enhanced SBOMs at or from the SBOM exchange service. In one example of this sixth embodiment, the initial SBOMs and the enhanced SBOM reports are viewable or downloadable via a portal connected to the network. In one example of this sixth embodiment, the SBOM exchange service automatically updates the one of the enhanced SBOM reports when its associated initial SBOM is updated, and automatically enables the customer to view or download the updated enhanced SBOM report at or from the SBOM exchange service. In one example of this sixth embodiment, the SBOM exchange service automatically receives information from the customer when one or more of the initial SBOMs is updated. In one example of this sixth embodiment, the SBOM exchange service automatically receives information from one or more developers of the softw are products when one or more of the initial SBOMs is updated. In one example of this sixth embodiment, the SBOM exchange service sends a notice to the customer to view' or download one or more of the initial SBOMs and the enhanced SBOM reports. In one example of this sixth embodiment, the SBOM exchange service transmits one or more of the initial SBOMs and the enhanced SBOM reports to the customer.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 shows an example of a platform for managing and enhancing Software Bills of Materials (SBOMs), deployed as a networked system.

[0022] Figure 2 shows an SBOM enhancement process that describes how an enhanced SBOM and report can be generated from an initial SBOM imported into the platform.

[0023] Figures 3A to 3D show a graphical user interface of an enhanced SBOM report generated by the SBOM enhancement process of Figure 2, which includes an assessment of risk of all identified dependencies in the software product, and the ability to export an enhanced SBOM.

[0024] Figures 4A and 4B describe manners in which developers (Fig. 4A) and customers (Fig. 4B can use the SBOM exchange service of the platform to manage, store, update, and distribute SBOMs.DETAILED DESCRIPTION

[0025] The platform 100 described herein provides means and processes to manage and review SBOMs and, importantly, to produce enhanced SBOMs 409 from initial SBOMs 405 that may be lacking in detail. The platform is configured to receive initial SBOMs from software developers, vendors, or customers. Initial SBOMs for particular software products can be received at the platform in different manners, as explained further below, such as via a Graphical User Interface (GUI) 400 accessible through a portal 31. Received initial SBOMs will be analyzed to identify initial dependencies 434 implicated within the software product. The platform will then perform a mock software build including these identified initial dependencies. During this build process these dependencies are downloaded (if necessary), and the platform is configured to see if these dependencies call other hidden dependencies 436, with the platform capturing that information. This build process continues recursively until all dependencies have been identified and downloaded, thus ensuring complete visibility of the components that make up the software.

[0026] Once all implicated dependencies 434, 436 are identified for a software product associated with the initial SBOM, the platform 100 is configured to produce an enhanced SBOM report 401 that among other details lists these dependencies and assesses their risks. This enhanced SBOM report is reviewable in the GUI 400, and includes the ability to produce and export an enhanced SBOM 409 using at least some of the information in the enhanced SBOM report. This enhanced SBOM may be provided to downstream customers of the software to which the enhanced SBOM pertains so that the customer can review' the software’s contents. The enhanced SBOM report, or the enhanced SBOM itself, may also be reviewed by a licensed developer of the software, thus allowing the developer to possibly make changes in its software to lower its risks. For example, if a particular open-source dependency carries a high risk, the software developer may no longer include that dependency in the software, or may preclude the software from incorporating that dependency.

[0027] The enhanced SBOM report 401 lists all identified dependencies and determines an individual dependency risk scores 424 for each, as well as a risk breakdown 428 classifying the risks by severity. Importantly, critical vulnerabilities 426 are identified. The enhanced SBOM report further includes an overall risk score 420 for the software product associated with the SBOM, which overall risk score is based on the individual dependency risk scores 424. In addition to determining a risk score for a software product, the platform can determine and quantify risk for individual packages or components within the software; the softwareproduct itself; groups of related software products (e.g., that an enterprise might be using); or even all software products (e.g., used in the enterprise).

[0028] Software developers may use the disclosed platform 100 in two distinct ways. First, they may receive initial SBOMs 405 created by their build systems and enhance them to create enhanced SBOMs 409. This allows the software developer, upon review of an enhanced SBOM, to possibly make changes to the software under development: for example, the developer may decide to use dependencies presenting less security risk. Second, software developers may also publish initial SBOMs or (more preferably) enhanced SBOMs for the software products they ship to customers, for the customers’ use or review. This is beneficial because, as discussed above, it is often a requirement that an SBOM be supplied to a customer with software, and the disclosed platform can provide enhanced SBOMs that are more detailed and thus reveal more potential risks.

[0029] Software customers may also use the disclosed platform 100. For example, if a customer has an initial SBOM 405 for a software product supplied by a software developer or vendor — either because the customer is considering purchasing, or has already purchased, the software product — the customer may use the platform to generate an enhanced SBOM 409 to enable the customer to better assess risk of the software product. When a customer has access to the platform, enhanced SBOM management and analysis can largely be offloaded from the software developer or vendor. A customer may use the platform to generate an enhanced SBOM regardless whether the software developer used the platform 100 to develop the software in question. The customer may further use the platform as a means for storing, organizing, and managing SBOMs for the software products used in their enterprise.

[0030] The platform 100 may only be accessible to valid subscribers (e.g., developers, vendors, or customers) of the platform, for example, those that have signed NDAs. Such subscribers may access the platform via a portal 31 for example.

[0031] To summarize, the disclosed platform 100 and methods solve several pressing problems. The platform provides a means to manage and analyze large numbers of SBOMs. The platform can enhance developer or vendor supplied SBOMs to provide greater visibility and to beter identify and quantify known vulnerabilities and other quality issues contained in the software product or in the dependencies that comprise the software. The platform may be configured to automatically receive and analyze all new initial SBOMs as they become available (e.g., as their associated software products are revised) and the platform may be utilized by software developers and vendors to manage distribution of enhanced SBOMs to end customers. The platform provides reporting capabilities to allow software customers anddevelopers to manage risks present in their environments. The platform can continuously monitor and update various databases and other risk metrics discussed further herein as an ongoing service. When new vulnerabilities are found, the customer or developer can be automatically notified by the platform, and have their enhanced SBOMs and / or enhanced SBOM reports adjusted accordingly.

[0032] Platform 100 is shown in Figure 1. While the platform 100 here is used to track, manage, and enhance SBOMs, it can also be used for other purposes as well. For example, platform 100 can be used as a Continuous Integration and Continuous Deployment (CI / CD) pipeline to build software. That use case is described in U.S. Provisional Patent Application Serial No. 63 / 727,448, filed December 3, 2024, and in its non-provisional PCT (Int'l) application [attorney docket no. 166-0002WO] which is filed concurrently with this present application. This provisional application and PCT application are both incorporated herein by reference in their entireties.

[0033] Some aspects of platform 100 usable by a developer to build software are briefly described first. Other build aspects usable in the platform 100 but not necessary’ to SBOM enhancement and management are omitted, although these other aspects are described in the above-incorporated applications. The build aspects disclosed here are important to understanding the generation of an enhanced SBOM report 401, which can involve implementing a mock software build in the platform 100. As explained further below, this mock software build includes recursively downloading open source dependencies that the platform 100 identifies.

[0034] Platform 100 is formed around a network 50 that may comprise the Internet, an Intranet, or combinations of these and other networks. A number of different network nodes, each providing some service, are shown connected to this network 50, which are explained further below. Conventional aspects of the network 100 in Figure 1 are shown in thinner lines, while new aspects developed for the platform 100 are shown in thicker lines.

[0035] A software developer, or a vendor of softw are supplied by the developer, are shown at systems 32 and 29 respectively in Figure 1. Developers may incorporate open source code which may be stored at an open source code repository 36 also connected to the network 50. As noted above, open source dependencies may also be referenced by and incorporated in a developer’s source code. These dependencies may be downloaded from the network 50 from many different sources 20a, 20b, etc., where all such dependencies repositories are represented singularly as 20 in Figure 1.

[0036] Element 43 may comprise any other generic service connected to the network 50, and although shown as a singular node may comprise a number of different sendees each hosted at their own addresses.

[0037] Source code once included in the developer’s software can be built at a build controller 40. The build controller 40 converts the source code to a form, binary or other, that is directly executable by a downstream client's computer system. The build controller 40 may support the use of one or more build containers 42a, 42b, etc. configured to run portions of the build in parallel to reduce build time. Importantly to SBOM enhancement and management, the build controller 40 can downloaded various open source dependencies during the mock software build, as explained further below. The build controller 40 can include a steering container 140. As explained in the above-incorporated patent applications, the steering container 140 can be used to serially steer all communications to and from the proxy 102. Proxy 102 is described in detail further below. As explained in the above-incorporate patent applications, the resulting executable code output from the build controller 40 can be packaged and distributed, although packaging and distribution are not necessary when performing the mock software build described below to generate an enhanced SBOM report 401.

[0038] Testing of software built using platform 100 (including the below-described mock software build) may also occur, which can be affected by a number of scanning containers 62. These scanning containers 62 are tasked with running specific scans to quantify the quality and suitability of the built product. A number of different scanning containers are included, including a Static Application Security Testing (SAST) container 64, a Dynamic Application Security Testing (DAST) container 66, an Interactive Application Security’ Testing (IAST) container 68, a license scanner 70, and Software Composition Analysis (SCA) container 72. As most relevant here, the scanning containers can assess the various open source dependencies identified and downloaded by the platform. These scanners 64-72 are known to those skilled in the art, and described in further detail in the above-incorporated patent applications.

[0039] Platform 100 further includes a proxy 102 through which all network 50 communications flow. Proxy 102 serves as the policy enforcement point within the platform by receiving and forwarding all messages issued by any of the services connected to the network 50. These messages can comprise requests 200 made from one sendee (source) to another (destination), or responses 201 to such messages.

[0040] Because proxy 102 receives all requests 200 and responses 201 issued by any sen ice in the platform 100, complete visibility of all transactions in the environment is ensured. Importantly here, this includes transactions relevant to downloading and evaluating variousopen source dependencies during the mock software build process. This can occur as follows. All requests 200 and responses 201 relating to dependencies are decoded (e.g., parsed) by a handler 103 and sent to a policy engine 122 within the policy decision logic 110. The handler 103 determines parsed information 202 useable by the policy engine 122 by analyzing the type of request 200 or response 201, the protocol or format of the request or response, the source and destination of the request or response including ports to or from which the request or response is issued or destined, or the higher level elements of the application protocols contained within the messages.

[0041] The policy engine 122 retrieves PolicyPaks 212 (sometimes known as policy bundles) from a policy storage 124. A PolicyPak 212 is a set of prepackaged policies that protect the platform 10 from known threats, and which can be constantly updated in the platform 100 as new threats emerge. Such PolicyPaks 212 can comprise one or more security rulesets that may allow- or disallow certain processes to occur in the system 100. The policy engine 122 may also consult a risk rating engine 118 that will assess the risk of the request 200 or response 201, and will provide one or more risk scores 215 to the policy engine 122.

[0042] The risk rating engine 118 may further provide risk scores 215 in accordance with information pulled from one or more risk databases 119 within the policy decision logic 110. These risk database(s) 119 are discussed further in the above-incorporated patent applications, and thus are only briefly mentioned here. Briefly, risk database(s) 119 can comprise one or more of an IP address reputation databases that checks the IP addresses of sources or destinations of the requests 200 and responses 201 intercepted by the proxy 102 in response to downloading the dependency; a vulnerability' database that assesses a risk of a dependency identifying known vulnerabilities in that dependencies; an exploited vulnerability database which includes dependencies that are known to have been a tool to exploit software in which it is incorporated; a repository history that rates transaction risk based on past behavior; and an Al model that may be trained to recognize suspect transactions thereby avoiding corruption of the build environment and ultimately the shipped product.

[0043] Significantly here, the risk rating engine 118 can determine the risk of particular dependencies incorporated in a software product under investigation, as well as for the softw are product as a whole. That is, the risk rating engine 1 18 can determine various risks scores 420, 424, 426, 428 (Fig. 3B) for the dependencies and the software based on an initial SBOM under analysis, as explained further below.

[0044] Upon receiving the PolicyPak 212 (if any) and risk scores 215 (again, if any), the policy engine 122 takes action with respect to the request 200 or response 201 , such as allow ingthe message to pass unmodified 205, forwarding the message to an alternate location 206, redirecting the message to a decoy environment 207, or blocking 208 the request or response, or issuing warnings 209 or alerts 210. Note that a default response of the policy engine 122 can be to forward the request 200 or response 201 if no policies within the system 100 are applicable. The default response may also block requests 200 or responses 201 with when no policies are applicable, which essentially requires policies to exist for all traffic. As particularly relevant here, the policy engine 122 may prevent the download of dependencies into a software build that are deemed to be too risky.

[0045] All transactions within the policy decision logic 110 will be recorded in a log 125, which is preferably a standalone entity with its own dedicated databases. A capture file 126 will capture all unmodified requests 200 and responses 201 that are passed by the proxy 102 to the policy decision logic 110. The capture file 126 may be used to replay requests 200 and responses 201 to debug issues in the system, to develop reproducible test cases, or to test new policies that may be implanted in policy decision logic 110.

[0046] Proxy 102 is preferably configured with the relevant certificates to allow decryption of system communications to allow full visibility into message contents. While the proxy 102 is shown as within network 50, it may additionally simply be connected to the network 50. Further, the proxy 102 is not necessarily singularly placed in the system 100, but may be distributed throughout.

[0047] SBOM management and enhancement in the platform 100 is discussed next. When using the platform 100 in this manner, the software developer (32), vendor (29), or customer (33) can access the system via a portal 31 (Fig. 1). This portal 31 allows the user to access SBOM functionality in the system, and to execute the SBOM enhancement process 300 described shortly with respect to Figure 2. The portal 31 provides a Graphical User Interface (GUI) 400 to the user, which is shown in one example in Figures 3A-3D. Portal 31 may be accessible as a w ebsite hosted by the provider of platform 100 that the user can access via their respective systems 32, 29, or 33. Note that a software developer who has used the platform 100 to develop the software product in question may not need to use the portal 31 specifically to develop an enhanced SBOM for their product. This is because enhanced SBOM generation may occur automatically in the platform as the softw are is produced, as explained in the aboveincorporated patent applications.

[0048] Also shown in Figure 1 is SBOM logic 130 which is coupled to the network 50. The SBOM logic 130 implements the SBOM enhancement process 300 (Fig. 2) in the platform 100, and can further store information relevant to SBOM analysis and management.

[0049] First, the SBOM logic 130 includes an SBOM exchange 135, which is an application that allows software developers, vendors and customers to publish and store initial and enhanced SBOMs for a given software product, as explained further below. A software customer can use the SBOM exchange 135 as a place to store all SBOMs (whether enhanced or not) for its enterprise, thus providing a convenient and singular location for these documents. The SBOM exchange 135 can also be used to publish enhanced SBOMs 409 (Fig. 3D) and / or enhanced SBOM reports 401 (Figs. 3A-3D) that the platform 100 generates, as explained further below. Such publishing capability is beneficial because it provides a convenient and automated means to allow the developer or vendor the ability to supply SBOMs to customers.

[0050] The SBOM exchange 135 can further ensure that all necessary contracts and agreements (e.g.. ND As) are in place prior to allowing a user to publish or download SBOMs on the platform 100. In other words, only validly subscribed users may be able to access the SBOM exchange 135. As new versions of a software product are generated over time, so to can the SBOMs stored at the exchange 135 be automatically re-assessed and updated using the SBOM logic 130 in the platform 100. Updated SBOMs created by the platform may automatically be published to subscribed customers as necessary. The SBOM exchange 135, and manner in which both developers and customers can use it, is described further below with reference to Figures 4A and 4B.

[0051] Second, the SBOM logic 130 includes a dependencies database 138. This database 138 stores information about dependencies that the platform 100 has uncovered as it executes the SBOM enhancement process 300 (Fig. 2) for different clients. This information can include the dependency’s file name, its source (i.e., location from which it was downloaded), its IP address, version number, and the like. The dependencies database 138 store further information about the dependencies as well, including a number risk metrics (424, 426. 428) for each, which are discussed further below. Database 138 may also store the code of the dependency itself.

[0052] The SBOM enhancement process 300 of Figure 2 enhances an initial SBOM 405 that is input into the platform 100. During this process, the platform 100 will analyze the initial SBOM 405 and ultimately provide an enhanced SBOM report 401 that is much richer in detail and that allows risks associated with an associated software product to be better assessed. This enhanced SBOM report 401 is shown in GUI 400 in Figures 3A-3D. A user can also export an enhanced SBOM 409 from this report, as explained further below.

[0053] As an initial step not shown in Figure 2, a user will create an enterprise account on the platform 100 that will serve as the anchor point for reporting on the software product associatedwith the initial SBOM 405 being analyzed. At step 310, the user imports the initial SBOM 405 for the software product using the portal 31. An initial SBOM 405 may also be imported from the SBOM Exchange 135 as discussed earlier, or from some other service 43 (Fig. 1).

[0054] Figure 3 A shows an example of how the initial SBOM 405 can be imported into the GUI 400, and included in enhanced SBOM report 401 that the process 300 ultimately generates (see Fig. 2, 350). Here, the initial SBOM 405 corresponds to a particular software product called "wizbo.” as shown at input 402. Input 402 can also allow wizbo to be manually entered, or to be selected from a particular service (e.g., 43) connected to the network 50 (such as github as shown). The initial SBOM 405 describing wizbo’s contents (wizbosbomjson) is imported at input 404. In this example, it is assumed that the initial SBOM 405 has been encoded in a *.json format, but file type selector 406 allows the user to select other input formats for the initial SBOM 405. The initial SBOM 405 may also automatically be sent to the platform 100 via Webhook or an API, or may be pulled into the platform if an API or website is available to download SBOMs associated with (purchased) software.

[0055] Environmental inputs 407 comprise one or more variables relevant to the environment within which the initial SBOM 405 was generated. For example, and as shown, the ecosystem used (e.g., Java, Javascript, Python, etc.) may be specified. Any manifest accompanying or referenced in the initial SBOM 405 can be entered, which may be indicative of the ecosystem for initial SBOM 405. Still other environmental inputs can be specified relevant to build configuration, such as the type of family of processor (e.g., ARM. x86) used to generate the initial SBOM 405. Such environmental input(s), if known, are useful to identify and enter at 407 because they can affect the resulting initial SBOM 405 under analysis. For example, an initial SBOM 405 formed in a Windows environment might differ from an initial SBOM formed in a MacOS environment, even for the same software product, with the result that the enhanced SBOM report 401 and enhanced SBOM 409 would differ slightly. Further, these environmental inputs may dictate that different dependencies are incorporated into the software product — for example a Linux version of a dependency or a Windows version of that same dependency. By taking these environment inputs into account, the process 300 arrives at a more uniform SBOM enhancement, and can exclude from such enhancement details that are solely related to environment and thus not relevant to security or risk. That being said, it is not strictly required that the environment inputs be entered (407) at step 310 when importing the initial SBOM 405. If such environmental inputs are not entered, the process 300 can assume default inputs, or try to identify such inputs based on an analysis of the initial SBOM 405 without additional user input.

[0056] Referring again to Figure 2, at a next step 315, the initial SBOM 405 is assessed to identify initial dependencies 434 used to make up the software product. Such initial dependencies 434 are typically simply listed in the initial SBOM 405, which after all includes a bill of materials included within the corresponding software product (wizbo). Preferably, the initial dependencies 434 comprise only open-source dependencies. Any closed-source or proprietary dependencies reflected in the initial SBOM 405 may, by contrast, be ignored and may receive no analysis in process 300. That process 300 limits identification to open-source dependencies is reasonable, because 75% or more of modem software is composed of open- source dependencies, and because such open-source dependencies due to their public nature tend to be riskier than closed-source or proprietary dependencies. As such, identifying and analyzing the risk of only open-source initial dependencies 434 provides a meaningful assessment of the security risks inherent in the software product (wizbo) as a whole.

[0057] Initial dependencies 434 determined at step 315 are represented in the enhanced SBOM report 401 in various ways. Figure 3A shows at an output 412 how many initial dependencies were found (35), while Figure 3B shows a listing of these dependencies (Depl- Dep35) further down in the report 401.

[0058] At step 320, the initial dependencies are reviewed to see if information concerning them is present in the dependencies database 138. As noted above, dependencies database 138 includes information about dependencies that the platform 100 has already encountered, including various risk metrics (424, 426, 428) that may have been determined for these dependencies earlier, and which are discussed further below. By logging this information for dependencies the platform 100 has encountered, future clients of platform 100 are benefitted, because the platform will not need to download or assess these dependencies again. If at step 320 a particular initial dependency 434 is not reflected in the database 138. and if there are no risk metrics for it, that dependency is downloaded and stored there. The initial dependencies 434 can be downloaded from various dependency sources 20 (Fig. 1).

[0059] At step 325, the risk of each the dow nloaded initial dependencies 434 is determined. As just explained, an initial dependency 434 known to the platform 100 and thus not downloaded at step 320 already has its risk reflected by metric in the dependency dataset 138, and thus the risk of this dependency does not need to be reassessed. Initial dependencies 434 downloaded at step 320 though are new, and risk metrics (e.g., 424, 426, 428) must be determined for that dependency.

[0060] The risk metrics for a new initial dependency 434 can be determined in different ways at step 325. First, risk metrics can be looked up by consulting one or more dependency risksen-ices 113 accessible via the network 50. A dependency risk service 113 essentially comprises an on-line database that publishes risk for various dependencies, which may be operated independently of the platform. The Cloud Security Alliance (CSA) (https: / / cl oudsecurity alliance, org), the National Institute of Standards and Technology (NIST) (https: / / www. nist. gov), and the National Cyber Security Center (https: / / www. ncsc. gov. uk) are examples of dependency risk services 113. In some examples, the risk metrics (424, 426. 428) may come directly from one or more dependency risk service 113, while in other examples the SBOM logic 130 may determine the risk metrics from information the service(s) 113 provide.

[0061] Second, the risk metrics shown for each of the dow nloaded initial dependencies 434 can also be calculated at step 325 by the process 300. This can involve use of the policy decision logic 110. For example, the SBOM logic 130 can make a request 200 to the policy decision logic to determine risk metrics for a given initial dependency 434. The policy engine 122 can request (216) the risk rating engine 118 to consult a number of different databases 119 to determine one or more risk scores 215. As explained further below, these risk score(s) 215 can comprise a risk breakdown 428 and individual dependency risk scores 424, as discussed shortly in conjunction with Figure 3B. Alternatively, these risk metric(s) can be computed by the SBOM logic 130 from the risk score(s) 215. In short, the SBOM logic 130 implementing process 300 can call the policy decision logic 110 as necessary to procure the necessary risk metric(s) for an initial dependency 434 under analysis at step 325. In any event, once the risk metrics (424, 426, 428) are determined at step 325, they are stored with their associated dependency in the dependency database 138.

[0062] Although process 300 has not yet generated the enhanced SBOM report 401 of Figures 3A-3D, this report preferably and eventually displays the initial dependencies and their risk metrics, as shown in Figure 3B. These display risk metrics may be calculated or may be pulled from the dependencies database 138 if determined earlier, as just described.

[0063] Many different risk metrics can be determined for the initial dependencies 434, and Figure 3B shows an example involving a risk breakdown 428. This breakdown 428 splits risks into four severities: critical vulnerabilities (CV), high risk (H), medium risk (M) and low risk (L). Further, for each severity, a number of such identified risks is determined and displayed. Several risks (six in total) have been identified for the first listed dependencies (Depl). Specifically, three critical vulnerabilities have been identified. These critical vulnerabilities are significant enough that they are separately highlighted at output 426 (Fig. 3B). For this first dependency, three further risks are deemed to be a high risk (H); and no medium (M) orlow (L) risks have been identified. Notice in this regard that a particular dependency can present several different risks, with some of these risks being more severe than others. Furthermore, for each risk severity, there may be more than one risk. This is because a dependency can be risky within the software product (wizbo) in more than one way. The total number of all critical vulnerabilities for all of the initial dependencies 434 summed together may be highlighted at output 414 in Figure 3 A to provide a user an indication of how many critical vulnerabilities are present in the software product (wizbo) as a whole prior to the SBOM enhancement analysis that follows.

[0064] From the risk breakdown 428, an individual dependency risk score 424 (Fig. 3B) can be determined by the SBOM logic 130 and process 300 a step 325. For the first dependency Depl, this risk score is high: 5. 1 out of 10, where a higher risk score indicates more risk. This individual dependency risk score 424 for dependencies Depl is high because this dependency has been determined to comprise three critical vulnerabilities and three high risks. By contrast, Dep3, which has only two low risks, has a much better (lower) individual dependency risk score 324 (1.2). While the process 300 can determine the individual dependency risk scores 424 from the risk breakdowns 428 in different ways, some amount of weighting is preferably used. Again, these risk metrics (424, 426, 428) can be stored along with the dependencies in dependencies database 138 at step 325, and later pulled from the database 138 when displaying a report 401 on the GUI 400 (step 350).

[0065] Although the SBOM enhancement process 300 as shown in Figure 2 determines risks of the initial dependencies 434 reflected in the initial SBOM 405 as soon as those dependencies are known (step 325), note that this is not strictly necessary. Instead, as process 300 runs and once all further hidden dependencies 436 are determined, the process may instead determine the risks of all identified dependencies (434. 436) at that time (e.g., at step 345). Furthermore, while the process 300 preferably determines more than one risk metric for each identified dependency, the process may instead only identify one risk metric for each. Process 300 may also determine risk metrics for each that are different from those show n.

[0066] Now that the initial dependencies 434 have been determined, and possibly downloaded, and (optionally) risk assessed, the process 300 continues by instigating a mock software build which includes these initial dependencies 434. Because other source code beyond these initial dependencies 434 is lacking, this mock software build does not seek to regenerate or reverse-engineer the software product (wizbo) to which the initial SBOM 405 under analysis pertains. Instead, the point of the mock software build is to determine other hidden dependencies 436 implicated by these initial dependencies 434.

[0067] This mock software build at step 330 can employ use of the build controller 40 (Fig. 1) described earlier, and possibly other modules (e.g., the packaging module 50) provided in the platform 100 and relevant to its use as a software product builder. As this mock software build occurs, the initial dependencies 434 are themselves built, meaning that hidden dependencies 436 referenced by them are determined (step 335). These dependencies are referred to as “hidden” in the sense that they were not apparent upon review of the initial SBOM 405 (i.e., at step 315).

[0068] Steps 340 and 345 taken with respect to the hidden dependencies 436 are similar to steps 320 and 325 taken with respect to the initial dependencies 434. Thus, at step 340, the process 300 determines whether the hidden dependencies 346 exist in the dependencies database 138. If a particular hidden dependency 436 is not, then it is downloaded. Step 345 determines the risk metrics for (new) downloaded hidden dependencies 436, a step which is unnecessary for hidden dependencies 436 already known to the platform 100 and whose risks are already populated in the dependency database 138. Determining the risk metrics (e.g., 424, 426, 428) for the downloaded hidden dependencies 436 occurs similarly to what occurred earlier for the initial dependencies 434. That is, the risk metnc(s) can be pulled from a dependency risk service 113, or computed using the policy decision logic 110 via control of the SBOM logic 130.

[0069] Hidden dependencies 436 are identified during the mock software build process by operation of the proxy 102. Specifically, the proxy 102 analyzes the communications coming from the build controller 40 (or other build-related modules in the platform), which will include calls for dependencies referenced in the initial dependencies 434. As new hidden dependencies 436 are referenced and / or downloaded during the mock software build, the proxy 102 communicates information concerning these newly-discovered hidden dependencies 436 to the SBOM logic 130 executing the SBOM enhancement process 300.

[0070] The proxy 102 will additionally discover further hidden dependencies 436 referenced by the original hidden dependencies as they are referenced or downloaded during the mock software build. This occurs because the proxy 102 direct request 200 and responses 201 to the policy decision logic 110, which are indicative of dependencies that have been downloaded (steps 320, 340). In turn, the policy decision logic 110 can provide this information to the SBOM logic 130 executing process 300.

[0071] As shown in Figure 2, process 300 can iterate (see steps 345 to step 330) until all hidden dependencies 436 have been uncovered and assessed. This is. the hidden dependencies 436 can be included in the mock software build (330), which may in turn reference lower-tierhidden dependencies 436 (335), which can be downloaded if not known (340), and whose risk can be assessed (435), and so on. This iteration can continue until all hidden dependencies 346 have been determined and their risk assessed.

[0072] Step 350 generates the enhanced SBOM report 401 shown in the example of Figures 3A-3D. Hidden dependencies 436 can be reflected in the enhanced SBOM report 401 similarly to the manner in which the initial dependencies 434 were reflected. As before, these hidden dependencies 436 can be listed (Fig. 3B), and their risk metrics displayed (424, 426, 428).

[0073] Furthermore, the enhanced SBOM report 401 can further summarize the number and risks of dependencies noticed before and after analysis of the imported initial SBOM 405. For example, the report 401 can show (Fig. 3A) a number of initial dependencies 434 detected 412 as well as the number of critical vulnerabilities of those dependencies 414 prior to analysis, as already mentioned. The report 401 can then further show a total number of dependencies detected after analysis 416 (including newly-discovered hidden dependencies 436), and well as the number of the critical vulnerabilities of those dependencies 418. Comparing the values for outputs 412 / 414 with 416 / 418 thus shows the user the difference when the platform 100 and the SBOM enhancement process 300 are used. This is useful because this comparison typically shows many more dependencies and (possibly) more vulnerabilities after the process 300 has run, which vindicates the process 300 as a superior and more-comprehensive tool for assessing the risks and security inherent in the software product (wizbo). 416 / 418 could also just show the number of hidden dependencies 436 located by the process 300 for comparison to the initial dependencies 434, as well as the critical vulnerabilities for each.

[0074] A user can interface with GUI 400 to glean further information about the located dependencies 434 and 436 and their risk metrics as displayed in the enhanced SBOM report 401. Such further information can be shown in different ways, but in Figure 3B. a user can click (e.g., right click) on various fields using a pointing device such as a computer mouse. For example, the user can click on a particular dependency (e.g., Dep35) to reveal further information about that dependency (431), such as its file name, its source (i.e., a location from which it was downloaded), its IP address, version number, and the like. Similarly, a user can click a particular risk metric to understand further details underlying that metric (432). For example, clicking a particular risk such as the medium risk highlighted for dependency Dep37 allows a description of both of the medium risks to be explained in detail. As shown at 432, these risks are violative of two different policies (A and B) established in the platform 100. Details explaining these risks can accompany the identification of those policies violations. These explanations can come from the external dependency risk services 113 that haveanalyzed these dependencies, or from the policy decision logic 110, as reflected in one or more of the Policy Paks 212 and / or in one or more risk scores 215 provided by the risk rating engine 1 18.

[0075] The enhanced SBOM report 401 can provide other information as well. For example, in Figure 3C, relationships between the various identified dependencies in the software product can be shown in a dependency map 452. This dependency map 452 may be generated and included in the report 401 upon selection of dependency mapping option 450. Dependency map 452 shows which dependencies were referenced by a particular dependency, and these may be displayed in tiers. For example, first-tier dependencies are shown in the left column, and correspond to the initial dependencies 434 (e.g., Depl-Dep35). Further hidden dependencies 436 for each of these are shown in subsequent columns. For example, Depl references further second-tier dependencies Dep36, Dep37, and Dep38 uncovered as hidden dependencies 436 by the process 300. Initial dependency 434 Dep2 has no further dependents, whereas Dep3 has three second-tier hidden dependencies (Dep54, Dep71, and Dep72). These second-tier dependencies can have third-tier dependencies, and so on. For example, second- tier dependency Dep36 has third-tier dependencies Dep61, Dep62, and Dep63. Third-tier dependency Dep96 has two fourth-tier dependencies Dep 124, and Dep 125, and so on.

[0076] As explained earlier, the items shown in dependency map 452 may be selectable to provide further information. For example, (right) clicking on the dependencies shown in the map 452 can display other information akin to 431 described earlier (Fig. 3B).

[0077] Figure 3D provides a selectable option 460 to display a nodal map 462 of the dependencies incorporated as components into the software product (wizbo), regardless whether these dependencies are initial 434 or hidden 436. This map 462 show s the locations where one or more of the dependencies are hosted. Certain dependencies may be hosted from the same location. For example, map 462 shows that dependencies Depl and Dep42 ae hosted at node www.citel, and that dependencies Dep2 and Dep3 are hosted at node www.cite2. IP addresses denoting the location of these dependencies could also be displayed.

[0078] Further, additional information can also be revealed in the map 462. For example, policy violations and / or anomalies can be shown for each dependency. For example, dependency Depl is shown in the map to have three clear policy violations. The user can for example (right) click to see further details of these violations, as described earlier (432). The policy violations may for example correspond to the critical vulnerabilities or high risks. Anomalies for each dependency may also be shown, which may correspond to lesser risks (e.g. medium or low' risks), and again these can be selected to allow' the user to see further details.In this example, Dep4, downloaded from www.cite3 has no policy violations of anomalies, and thus would presumably have a low risk score (424, Fig. 3B).

[0079] Returning to process 300 and Figure 2, step 355 involves generating and exporting an enhanced SBOM 409 from the information contained in the enhanced SBOM report 401, as show n at the bottom of Figure 3D. An enhanced SBOM 409 so generated may be stored in the SBOM exchange 135 or at some other location of the user's choosing. Just as the initial SBOM 405 can be imported in a number of different formats (406, Fig. 3A), so too can the enhanced SBOM 409 be exported in a number of different formats using file type selector 410. The enhanced SBOM 409 as exported may not include all information shown in the enhanced SBOM report 401. For example, the enhanced SBOM 409 may only include information about the located dependencies (434, 436). while omitting information concerning risk of those dependencies (e.g., 424-428, Fig. 3B), or while omitting information concerning the risk of the software product as a whole (420, Fig. 3A).

[0080] Although not shown, the file ty pe selector 410 can allow a user to expert information in the form of a Vulnerability Exploitability exchange (VEX) report, which is a standard format for reporting software product risk.

[0081] At step 360, the user can be notified of the generation of the enhanced SBOM report 401 and / or the enhanced SBOM 409, which user can comprise a developer or customer. As explained shortly with reference to Figure 4A and 4B, these parties can interact with the platform 100, and in particular the SBOM exchange 135, in different manners and for different reasons, but both will benefit from understanding the issuance of these enhanced SBOM materials, and whether they have been updated. Such notification may come in the form of an emailed link for example, and may include providing a copy of the report 401 and enhanced SBOM 409.

[0082] As concerns the issue of updating, the platform 100 preferably continually operates to periodically reassess the risks of dependencies it has identified, i.e., dependencies populated to date in the dependencies database 138. This is beneficial because the nature of certain dependency risks may not be fully understood when they are encountered initially, and thus may be deemed more or less risky over time. For example, dependency risk services 113 may eventually change risk ratings it provides for various dependencies. The policy decision logic 110 may also change over time in terms of how it assigns risk. The risk rating engine 118 may change, as may entries in risk databases 119 it consults. PolicyPaks 212 may also be newly entered or updated in the policy storage 124 that assign new risk priorities, thus changing the manner in which the policy decision logic 110 would quantify such dependency risks asreflected for example in risk metrics 424, 426, and 428. Still further, dependencies that at first seemed to present no risk may later be understood to present significant risks. For example, dependencies may be later found to have a defect of some sort that was not understood initially. In short, for these and other reasons, the risk profiles for the dependencies can change over time.

[0083] Because these risks may change over time, step 365 preferably updates the risks for the dependencies from time to time. Preferably this is done automatically for all dependencies in the dependencies database 138, which cumulates all encountered dependencies for all platform 100 users. For example, the SBOM logic 130 can automatically determine when factors affecting risk have changed, such as new updates to risk databases 119, or entry or updating of a PolicyPak 212. When such changes occur, the SBOM logic 130 can adjust the risk metrics 424, 426, and 428 of affected dependencies in database 138 at those times. Alternatively, the SBOM logic 130 may update the risks on a set periodic schedule, such as every 10 minutes.

[0084] At step 370. process 300 inquires whether any of the updated dependencies (whether initial 434 or hidden 436) have been updated for the particular user (developer, customer) of process 300. If so, the process can revert back to step 350 to generate an updated enhanced SBOM report 401 for that user, and possibly an updated enhanced SBOM 409 (355). The user can then be notified about the update to these materials at step 360, as summarized earlier.

[0085] Figures 4A and 4B explain further details of the SBOM exchange 135 and how it can be used in the platform 100 to manage, store, generate, update, and distribute SBOMs. More specifically, these figures respectively show a developer process 500 (Fig. 4A) and a customer process (Fig. 4B) describing how a software developer and customer might each differently use the platform 100 and interact with the SBOM exchange 135. Processes 500 and 550 can involve the use of the portal 31, which may present a GUI to the developer or customer to interact with the SBOM exchange 135 and the platform 100 more generally, although this detail isn't shown.

[0086] Starting with the developer process 500 in Figure 4A, it is assumed that the developer of a software product generates an initial SBOM 405 in step 505. This initial SBOM 405 doesn’t have to have been generated using the platform 100; it could be generated by the developer by other means or tools.

[0087] At step 510, the developer creates an account on the platform 100 if it hasn't done so already. This account can come with a particular subscription, and may be accompanied by various subscriber agreements and licenses, as discussed above. This subscription may allow,for example, the developer post or host initial SBOMs 405 for its developed software products at the SBOM exchange 135, thus providing a convenient way to publish or distribute initial SBOMs 405 for those products to its customers. A subscription preferably also allows the developer to use the platform 100 to generate enhanced SBOM reports 401 and enhanced SBOMs 409 using process 300, thus allowing enhanced SBOMs 409 to be distributed. Enhanced SBOM 409 generation is shown as an optional step 515 because, as just mentioned, the developer’s subscription may not include the ability to generate enhanced SBOMs 409 for its initial SBOMs 405. Although not shown, step 515 may also include the generation of an enhanced SBOM report 401 (from which the enhanced SBOM 409 can preferably determined). This enhanced SBOM report 401 may be of use to the developer because it allows the developer to review risk metrics (424. 426. 428) in addition to a listing of enhanced listing of dependencies.

[0088] At step 510, the developer also provides access to the initial SBOM for its software product. This access can involve uploading the initial SBOM 405 to the SBOM exchange 135. Providing access can also involve providing a location / site under control of the developer where initial SBOMs 405 for their software products are stored and updated. Such updating of the initial SBOM 405 may be required because the software developer may update the associated software product from time to time. By providing a location or site where the developer’s initial SBOMs 405 are located, the process 500 can automatically process such updates as they occur in the future (see step 535).

[0089] Ultimately, it is important that SBOMs hosted by the SBOM exchange 135 (whether initial 405 or enhanced 409) be delivered to, or be made accessible to, the developer’s customers. Thus, at step 520, the developer specifies the various customers for its software product(s) so that they may automatically receive SBOMs. Also at step 520, the developer may specify whether customers are to receive the initial SBOMs 405 or the enhanced SBOMs 409 (or possibly both). Step 520 may require the developer from time to time to access the platform 100 via portal 31 to enter information for its customers. That being said, it is preferred that customers are input into the platform automatically. This can occur by providing the platform 100 customer information automatically whenever a copy of the software product is sold (downloaded). Alternatively, the developer may host and update a customer list for the software product which the exchange 135 reads automatically.

[0090] Figure 4A shows a representation of the information populated in the SBOM exchange 135 as a result of these proceeding steps. Software developer 1 has two software products ‘a’ and ‘b’ registered with the system, and has uploaded (or provided access to) initial SBOMs405a and 405b for them. As noted earlier, these initial SBOMs 405a and 405b may be updated from time to time if and when software productsca’ andcb’ are updated (see step 535). The developer has also denoted customers 1 and 2 as customers for product ‘a’ (or has automatically provided to the exchange 135 access to that information). Further, the developer has specified that these customers are to receive enhanced SBOM 409a for this product (as opposed to just the initial SBOM 405a), and the exchange 135 has further used process 300 to generate this enhanced SBOM 409a (step 515). Notice that this developer 1 has another software product ‘b’; has designated its customers 1 and 3 for this product; and has denoted that they are to receive an enhanced SBOM 409b for this product. Of course, a particular developer could host and generate SBOMs for many such software products on the exchange 135. A further developer 2 may likewise host and generate SBOMs for its software products (e.g. ‘c’), and again the exchange 135 could support a large number of developers.

[0091] Next at step 525, the exchange 135 can send designated customers of the software product a notice (e g., link, email, etc.) informing them that they will be receiving SBOMs for that software product from the platform 100. The SBOM the customer will receive can depend upon the SBOM that the developer chooses to send at step 520 (either the initial 405 or enhanced 409). This notice at step 525 can invite the customers to create an account on platform 100, which may be preferred because an account may also require these customers to acknowledge various agreements or restrictive licenses (e.g., obligating them to not disclose the SBOMs they receive to others). This being said, binding customers via agreements can occur in other manners short of requiring them to create accounts. In any event, the notice provided to the customer at step 525 preferably allows the customer to specify how it wishes to receive SBOMs. For example, the customer may desire to have them automatically attached to emails sent to the customer; or have a link sent to them by which they can access the SBOM (e.g., as stored on the exchange 135) when they desire to do so; etc.

[0092] At step 530, the exchange 135 sends or posts the SBOM (again whether initial 405 or enhanced 409) to the customer in any of the various forms just mentioned when it is made available. At step 535, the process 500 considers whether the initial SBOM 405 has been updated, for example because a new build has been generated for the software product. As noted earlier, receiving an updated SBOM 405 at the platform 100 preferably occurs automatically when generated by the developer. If an initial SBOM 405 has been updated, it is preferable processed (300) to create an enhanced SBOM 409 at step 540, with the process then reverting to step 530 to send or post a relevant updated SBOM (either initial 405 or enhanced 409) to the customer.

[0093] Although not shown, process 500 can also inquire as to whether the risk profiles for the dependencies have changed. See steps 365 and 370 of Figure 2. This too can cause the enhanced SBOM report 401 and the enhanced SBOM 409 to be updated at this step, so that these updated materials can be sent or posted for customers (e.g., at step 530).

[0094] Notice the manner in which developer process 500 and the SBOM exchange 135 organizes and simplifies SBOM distribution for the developer’s software products. By making SBOMs available to its customers on the platform 100, the developer is potentially offloaded of the responsibility to individually provide SBOMs to its customers. The developer may further enhance these SBOMs on the platform 100. Still further, customers are convenienced because they can receive SBOMs from the developer in manners they have chosen and that are most convenient for them. Significantly, the SBOM exchange can fully automate these steps, conveniencing both the developer and the customer. For example, as discussed above, if the initial SBOM 405 has been updated (535), the process 500 ensures that the specified SBOM will automatically be sent or posted to specified customers.

[0095] Customer process 550 is shown in Figure 4B. In this process 550, the SBOM exchange 135 is used by the customer as a means to store and enhance SBOMs associated with a software products owned by the customer. This process 550 is beneficial because it organizes the customer’s SBOM-related materials in a central repository that the customer can access at any time. Because a customer may use thousands of software products in its enterprise, providing the ability to manage and organize SBOM-related materials at the exchange 135 provides obvious convenience by allowing a central location where the customer can assess risks inherent in those products. Further, initial SBOMs 405 for the customer’s various software products can be enhanced per process 300, providing the customer with improved visibility into their software products’ contents and risks.

[0096] In step 555, a customer wishing to upload and enhance an initial SBOM 405 for one of its enterprise’s software products creates an account on the platform 100. At next step 560, the customer providing the initial SBOM 405 to the SBOM exchange 135. How this occurs can differ whether the initial SBOM 405 is under the control or possession of the customer or the developer of that software product. If the customer has the initial SBOM 405, the customer can provide access to it, similar to how this occurs in step 510 of the developer process 500. If the developer has the initial SBOM 405, the customer can grant permission to the developer to post it to the exchange 135, or otherwise indicate to the exchange 135 how and where this initial SBOM 405 can be accessed at or from the developer.

[0097] In next step 565, the process 550 inquires whether the initial SBOM 405 in question has already been populated at the SBOM exchange 135. This is possible, because a previous customer of the associated software product may have already provided the initial SBOM 405 to the SBOM exchange 135 under their account. If this occurred, the present customer (like the previous one) will be associated with this initial SBOM 405 and its other enhancements (401, 409) in step 575, which is discussed further below.

[0098] If the initial SBOM 405 is not already known to the SBOM exchange at step 565, it is stored there at step 570. Then, the SBOM enhancement process 300 described earlier is performed at step 571, thereby generating an enhanced SBOM report 401 and an enhanced SBOM 409. The customer is then notified that these enhancements have occurred, thus allowing the customer the opportunity to review them (see step 580). Afterward, at step 575, the customer is associated with the initial SBOM 405, the report 401 and the enhanced SBOM 409. This association allows the customer to view and download initial SBOMs 405, enhanced SBOM reports 401, and / or enhanced SBOMs 409 with which it is associated at step 580.

[0099] Figure 4B shows a representation of the information populated in the SBOM exchange 135 as a result of these proceeding steps. As shown (and consistently with the example of Figure 4A), an initial SBOM 405a from developer 1 for software product ‘a’ is stored in the exchange 135, along with the generated enhanced SBOM report 401 a and the enhanced SBOM 409a (step 570). Further, customers 1 and 2 have been associated (step 575) with these SBOM materials (405a, 401a, 409a) and can view or download them (step 580, e.g., from portal 31). Similarly, customers 1 and 3 can view or download SBOM materials 405b, 401b, and 409b for software product ‘b’ from developer 1. And, customers 2 and 4 can view or download SBOM materials 405c, 401c, and 409c for software product ‘c’ from developer 2.

[0100] The process 550 preferably repeats these steps as necessary if and when the initial SBOM 405 is updated at step 585. As noted before, an initial SBOM 405 could from time to time be updated because the customer’s associated softw are product has been updated. If no updating occurs, the process reverts back to step 580 to allow the customer to continue to view and download SBOM materials with which they have been associated.

[0101] Whether an update occurs at step 585 can be determined differently if the initial SBOM 405 is under the control or possession of the customer or the developer of that software product. The customer may indicate that the initial SBOM 405 has been updated by affirmatively telling the system so, or by providing the updated initial SBOM 405 to the exchange 135 (step 590). The customer can set up its own systems to automatically provide any updated initial SBOMs 405 to the exchange 135. The customer or developer can likewisecause the developer to automatically provide any updated initial SBOMs 405 to the exchange 135 as soon as they are distributed by the developer.

[0102] Although not shown, process 550 can also inquire as to whether the risk profiles for the dependencies have changed. See steps 365 and 370 of Figure 2. This too can cause the enhanced SBOM report 401 and the enhanced SBOM 409 to be updated at this step, so that these updated materials can be sent or posted for the customer (e.g., at step 572).

[0103] Once an updated initial SBOM has been received (step 590), the system can revert to step 570 where it is stored in the exchange 135. Further at this step, process 300 can again be used to create updated versions of the enhanced SBOM report 401 and the enhanced SBOM 409 (571), and the customer can be notified of this change (572). Again at step 575, the customer can (continue) to be associated with the (updated) SBOM materials (405, 401, 409), and review them at step 580.

[0104] Although particular embodiments of the present invention have been shown and described, it should be understood that the above discussion is not intended to limit the present invention to these embodiments. It will be obvious to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the present invention. Thus, the present invention is intended to cover alternatives, modifications, and equivalents that may fall within the spirit and scope of the present invention as defined by the claims.

Claims

WHAT IS CLAIMED IS;1 . A software platform useable to enhance an initial Software Bill of Materials (SBOM) associated with a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network including one or more build services, the software platform comprising: a proxy operable to capture communications issued by the one or more services connected to the network; and a SBOM logic service connected to the network and configured to:(a) import and assess the initial SBOM to determine information indicative of initial dependencies of the software product referenced in the initial SBOM;(b) download the initial dependencies into a dependencies database;(c) cause one or more risk metrics to be determined for each down loaded initial dependency and store the one or more risk metrics in the dependencies database;(d) cause a mock software build to occur using the one or more build services, wherein the mock software build includes the initial dependencies;(e) use the proxy during the mock software build to determine further hidden dependencies of the software product;(f) download the hidden dependencies into the dependencies database;(g) cause one or more risk metrics to be determined for each downloaded hidden dependency and store the one or more risk metrics in the dependencies database;(h) repeat steps (d) through (g) by including the hidden dependencies in the mock software build until all hidden dependencies have been uncovered and assessed; and(i) generate a report, wherein the report includes information about the initial and hidden dependencies and their associated risk metrics.

2. The softw are platform of claim 1, wherein the initial and hidden dependencies comprise open source dependencies.

3. The software platform of claim 1, wherein the dependencies database is associated with the SBOM logic.

4. The software platform of claim 1, wherein the hidden dependencies are not referenced in the initial SBOM.

5. The software platform of claim 1, wherein the initial and hidden dependencies are downloaded in steps (b) and (f) only if they are not already stored in the dependencies database.

6. The software platform of claim 6, wherein the one or more risk metrics are determined for each initial and hidden dependencies only if the one or more risk metrics are not already stored in the dependencies database.

7. The software platform of claim 1, wherein the one or more risk metrics are determined in a policy decision logic service connected to the network.

8. The software platform of claim 7, wherein the policy decision logic sen ice comprises one or more engines that provide the one or more risk metrics by assessing one or more risk databases and one or more PolicyPaks.

9. The software platform of claim 8, wherein the PolicyPaks comprise a set of prepackaged policies to thwart one or more threats.

10. The software platform of claim 1, wherein the one or more risk metrics are determined by one or more dependency risk services connected to the network.

11. The software platform of claim 1, wherein the report is generated via a graphical user interface (GUI) accessible by a portal connected to the network.

12. The software platform of claim 11, wherein the GUI includes an option to export an enhanced SBOM using the information in the report.

13. The software platform of claim 12, wherein the enhanced SBOM comprises information indicative of the initial dependencies and the hidden dependencies.

14. The software platform of claim 11, wherein the GUI includes one or more environmental inputs relevant to the environment within which the initial SBOM was generated.

15. The software platform of claim 11 , wherein the GUI includes an option to start a scan of the imported initial SBOM, which initiates steps (b)-(i).

16. The software platform of claim 11, wherein the report displays a number of the initial dependencies and either (i) a number of the hidden dependencies, or (ii) a total number of the initial and hidden dependencies.

17. The software platform of claim 11, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications.

18. The software platform of claim 17, wherein the plurality of risk classifications comprise a high, medium, and low risk.

19. The software platform of claim 17, wherein the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk.

20. The software platform of claim 11 , wherein the one or risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

21. The software platform of claim 20, wherein the SBOM logic service is further configured to determine a risk score for the software product using the individual dependency risk scores for each initial and hidden dependency.

22. A method for enhancing an initial Software Bill of Materials (SBOM) associated with a software product usable with a software platform implemented as a plurality of networknodes each implementing one or more services connected to a network including one or more build services, the method comprising: using a proxy to capture communications issued by the one or more services connected to the network; and using a SBOM logic service connected to the network to implement a process, the process comprising:(a) importing and assessing the initial SBOM to determine information indicative of initial dependencies of the software product referenced in the initial SBOM;(b) downloading the initial dependencies into a dependencies database;(c) causing one or more risk metrics to be determined for each downloaded initial dependency and storing the one or more risk metrics in the dependencies database;(d) causing a mock software build to occur using the one or more build services, wherein the mock software build includes the initial dependencies;(e) using the proxy during the mock software build to determine further hidden dependencies of the software product;(f) downloading the hidden dependencies into the dependencies database;(g) causing one or more risk metrics to be determined for each downloaded hidden dependency and store the one or more risk metrics in the dependencies database;(h) repeating steps (d) through (g) by including the hidden dependencies in the mock software build until all hidden dependencies have been uncovered and assessed; and(i) generating a report, wherein the report includes information about the initial and hidden dependencies and their associated risk metrics.

23. The method of claim 22, wherein the initial and hidden dependencies comprise open source dependencies.

24. The method of claim 22, wherein the dependencies database is associated with the SBOM logic.

25. The method of claim 22, wherein the hidden dependencies are not referenced in the initial SBOM.

26. The method of claim 22, wherein the initial and hidden dependencies are downloaded in steps (b) and (f) only if they are not already stored in the dependencies database.

27. The method of claim 26, wherein the one or more risk metrics are determined for each initial and hidden dependencies only if the one or more risk metrics are not already stored in the dependencies database.

28. The method of claim 22, wherein the one or more risk metrics are determined in a policy decision logic service connected to the network.

29. The method of claim 28, wherein the policy decision logic service comprises one or more engines that provide the one or more risk metrics by assessing one or more risk databases and one or more PohcyPaks.

30. The method of claim 29, wherein the PohcyPaks comprise a set of prepackaged policies to thwart one or more threats.31 . The method of claim 22, wherein the one or more risk metrics are determined by one or more dependency risk sendees connected to the network.

32. The method of claim 22, wherein the report is generated via a graphical user interface (GUI) accessible by a portal connected to the network.

33. The method of claim 32, further comprising using the GUI to export an enhanced SBOM using the information in the report.

34. The method of claim 33, wherein the enhanced SBOM comprises information indicative of the initial dependencies and the hidden dependencies.

35. The method of claim 32, wherein the GUI includes one or more environmental inputs relevant to the environment within which the initial SBOM was generated.

36. The method of claim 32, further comprising starting a scan of the imported initial SBOM using the GUI, which initiates steps (b)-(i).

37. The method of claim 32, wherein the report displays a number of the initial dependencies and either (i) a number of the hidden dependencies, or (ii) a total number of the initial and hidden dependencies.

38. The method of claim 32, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality’ of risk classifications.

39. The method of claim 38, wherein the plurality of risk classifications comprise a high, medium, and low risk.

40. The method of claim 38, wherein the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk.

41. The method of claim 32, wherein the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

42. The method of claim 41, wherein the SBOM logic service further determines a risk score for the software product using the individual dependency risk scores for each initial and hidden dependency.

43. A software platform useable by a developer of a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network, the software platform comprising: a proxy operable to capture communications issued by the one or more services connected to the network; and a Software Bill of Materials (SBOM) exchange service connected to the network and configured to:receive an initial SBOM associated with the software product, wherein the initial SBOM comprises information indicative of initial dependencies of the software product; cause an SBOM logic service to generate an enhanced SBOM from the initial SBOM using the proxy, wherein the enhanced SBOM includes hidden dependencies of the software product in addition to the initial dependencies; receive information indicative of customers of the software product; and automatically provide to the customers access to the enhanced SBOM.

44. The software platform of claim 43, wherein the initial and hidden dependencies comprise open source dependencies.

45. The software platform of claim 43, wherein the SBOM exchange service is associated with the SBOM logic service.

46. The software platform of claim 43, wherein the hidden dependencies are not included in the initial SBOM.

47. The software platform of claim 43, wherein the SBOM exchange sen ice is further configured to cause the SBOM logic service to generate an enhanced SBOM report.

48. The software platform of claim 47, wherein the SBOM logic service is further configured to generate the enhanced SBOM from information in the enhanced SBOM report.

49. The software platform of claim 47, wherein the enhanced SBOM report comprises one or more risk metrics for each initial and hidden dependency.

50. The software platform of claim 49, wherein the one or more risk metrics are determined by one or more dependency risk services connected to the network.

51. The software platform of claim 49, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications.

52. The software platform of claim 51, wherein the plurality’ of risk classifications comprise a critical vulnerability and at least one other lesser risk.

53. The software platform of claim 49, wherein the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

54. The software platform of claim 47, wherein the SBOM exchange service is further configured to automatically provide to the customers access to the enhanced SBOM report.

55. The software platform of claim 43, wherein the enhanced SBOM is viewable or downloadable via a portal connected to the network.

56. The software platform of claim 43, wherein the SBOM exchange service is further configured to automatically provide to the customers access to the initial SBOM.

57. The software platform of claim 43, wherein the SBOM exchange service is further configured to automatically update the enhanced SBOM when the initial SBOM is updated, and to automatically provide to the customers access to the updated enhanced SBOM.

58. The software platform of claim 57, wherein the SBOM exchange service is configured to automatically receive information from the developer when the initial SBOM is updated.

59. The software platform of claim 43, wherein the SBOM exchange service is further configured to send a notice to each of the customers of the software product that they have access to the enhanced SBOM.

60. The software platform of claim 59, wherein the notice enables each customer to inform the SBOM exchange service of a manner in which they will receive the enhanced SBOM.

61. The software platform of claim 59, wherein the notice invites each customer to create an account on the platform.

62. The software platform of claim 43, wherein the SBOM exchange service is configured to automatically provide to the customers access to the enhanced SBOM bytransmitting the enhanced SBOM to the customers.

63. A method useable at a software platform by a developer of a software product, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network, the method comprising: using a proxy to capture communications issued by the one or more services connected to the network; and using a Software Bill of Materials (SBOM) exchange service connected to the network to implement a process, the process comprising: receiving an initial SBOM associated with the software product, wherein the initial SBOM comprises information indicative of initial dependencies of the software product; causing an SBOM logic service to generate an enhanced SBOM from the initial SBOM using the proxy, wherein the enhanced SBOM includes hidden dependencies of the software product in addition to the initial dependencies; receiving information indicative of customers of the software product; and automatically providing to the customers access to the enhanced SBOM.

64. The method of claim 63 wherein the initial and hidden dependencies comprise open source dependencies.

65. The method of claim 63 wherein the SBOM exchange service is associated with the SBOM logic sendee.

66. The method of claim 63 wherein the hidden dependencies are not included in the initial SBOM.

67. The method of claim 63 wherein the SBOM logic service further generates an enhanced SBOM report.

68. The method of claim 67, wherein the SBOM logic service generates the enhanced SBOM from information in the enhanced SBOM report.

69. The method of claim 67, wherein the enhanced SBOM report comprises one or more risk metrics for each initial and hidden dependency.

70. The method of claim 69, wherein the one or more risk metrics are determined by one or more dependency risk services connected to the network.

71. The method of claim 69, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications.

72. The method of claim 71, wherein the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk.

73. The method of claim 69, wherein the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

74. The method of claim 67. wherein the SBOM exchange service automatically provides to the customers access to the enhanced SBOM report.

75. The method of claim 63, wherein the enhanced SBOM is viewable or dow nloadable via a portal connected to the network.

76. The method of claim 63, wherein the SBOM exchange automatically provides to the customers access to the initial SBOM.

77. The method of claim 63, wherein the SBOM exchange service automatically update the enhanced SBOM when the initial SBOM is updated, and to automatically provides to the customers access to the updated enhanced SBOM.

78. The method of claim 77, wherein the SBOM exchange service automatically receives information from the developer when the initial SBOM is updated.

79. The method of claim 63, wherein the SBOM exchange service sends a notice to each of the customers of the software product that they have access to the enhanced SBOM.

80. The method of claim 79, wherein the notice enables each customer to inform the SBOM exchange service of a manner in which they will receive the enhanced SBOM.

81. The method of claim 79, wherein the notice invites each customer to create an account on the platform.

82. The method of claim 63, wherein the SBOM exchange service automatically provides to the customers access to the enhanced SBOM by transmitting the enhanced SBOM to the customers.

83. A software platform useable by a customer of software products, wherein the platform is implemented as a plurality of network nodes each implementing one or more services connected to a network, the software platform comprising: a proxy operable to capture communications issued by the one or more services connected to the network; and a Software Bill of Materials (SBOM) exchange service connected to the network and configured to: receive initial SBOMs each associated with one of the software products, wherein the initial SBOMs each comprise information indicative of initial dependencies of the associated software product; cause an SBOM logic service to generate an enhanced SBOM report for an associated one of the initial SBOMs using the proxy, wherein each enhanced SBOM report includes information indicative of hidden dependencies of the associated software product in addition to the information indicative of I the initial dependencies, and one or more risk metrics for each initial and hidden dependency; and associate the customer with the initial SBOMs and with the enhanced SBOM reports to enable the customer to view or download the initialSBOMs and the enhanced SBOM reports at or from the SBOM exchange service.

84. The software platform of claim 83, wherein the initial and hidden dependencies comprise open source dependencies.

85. The software platform of claim 83, wherein the SBOM exchange service is associated with the SBOM logic service.

86. The software platform of claim 83, wherein the hidden dependencies for each enhanced SBOM report are not included in its associated initial SBOM.

87. The software platform of claim 83, wherein the SBOM exchange service is further configured to cause the SBOM logic service to generate an enhanced SBOM for each of the initial SBOMs.

88. The software platform of claim 87, wherein the SBOM logic service is further configured to generate the enhanced SBOM for each of the initial SBOMs from information in its associated enhanced SBOM report.

89. The software platform of claim 83, wherein the one or more risk metrics are determined by one or more dependency risk services connected to the network.

90. The software platform of claim 83, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications.

91. The software platform of claim 90, wherein the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk.

92. The software platform of claim 83, wherein the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

93. The software platform of claim 87, wherein the SBOM exchange service is further configured to associate the customer with the enhanced SBOMs to enable the customer to view or download the enhanced SBOMs at or from the SBOM exchange service.

94. The software platform of claim 83, wherein the initial SBOMs and the enhanced SBOM reports are viewable or downloadable via a portal connected to the network.

95. The software platform of claim 83, wherein the SBOM exchange service is further configured to automatically update one of the enhanced SBOM reports when its associated initial SBOMs is updated, and to automatically enable the customer to view or download the updated enhanced SBOM report at or from the SBOM exchange service.

96. The software platform of claim 95, wherein the SBOM exchange service is configured to automatically receive information from the customer when one or more of the initial SBOMs is updated.

97. The software platform of claim 95, wherein the SBOM exchange service is configured to automatically receive information from one or more developers of the softw are products when one or more of the initial SBOMs is updated.

98. The software platform of claim 83, wherein the SBOM exchange service is further configured to send a notice to the customer to view or download one or more of the initial SBOMs and the enhanced SBOM reports.

99. The software platform of claim 83, wherein the SBOM exchange service is configured to transmit one or more of the initial SBOMs and the enhanced SBOM reports to the customer.

100. A method useable at a software platform by a customer of software products, wherein the platform is implemented as a plurality of netw ork nodes each implementing one or more services connected to a network, the method comprising: using a proxy to capture communications issued by the one or more services connected to the network; andusing a Software Bill of Materials (SBOM) exchange service connected to the network to implement a process, the process comprising: receiving initial SBOMs each associated with one of the software products, wherein the initial SBOMs each comprise information indicative of initial dependencies of the associated software product; causing an SBOM logic service to generate an enhanced SBOM report for an associated one of the initial SBOMs using the proxy, wherein each enhanced SBOM report includes information indicative of hidden dependencies of the associated software product in addition to the information indicative of I the initial dependencies, and one or more risk metrics for each initial and hidden dependency; and associating the customer with the initial SBOMs and with the enhanced SBOM reports to enable the customer to view or download the initial SBOMs and the enhanced SBOM reports at or from the SBOM exchange sendee.

101. The method of claim 100, wherein the initial and hidden dependencies comprise open source dependencies.

102. The method of claim 100, wherein the SBOM exchange service is associated with the SBOM logic sen ice.

103. The method of claim 100, wherein the hidden dependencies for each enhanced SBOM report are not included in its associated initial SBOM.

104. The method of claim 100, wherein the SBOM exchange service causes the SBOM logic service to generate an enhanced SBOM for each of the initial SBOMs.

105. The method of claim 104, wherein the SBOM logic service generates the enhanced SBOM for each of the initial SBOMs from information in its associated enhanced SBOM report.

106. The method of claim 100, wherein the one or more risk metrics are determined by one or more dependency risk services connected to the network.

107. The method of claim 100, wherein the one or more risk metrics comprise a risk breakdown for each initial and hidden dependency, wherein the risk breakdown quantifies a risk of each initial or hidden dependency into a plurality of risk classifications.

108. The method of claim 107, wherein the plurality of risk classifications comprise a critical vulnerability and at least one other lesser risk.

109. The method of claim 100, wherein the one or more risk metrics comprise an individual dependency risk score for each initial and hidden dependency.

110. The method of claim 104, wherein the SBOM exchange service associates the customer with the enhanced SBOMs to enable the customer to view or download the enhanced SBOMs at or from the SBOM exchange service.

111. The method of claim 100, wherein the initial SBOMs and the enhanced SBOM reports are viewable or downloadable via a portal connected to the network.1 12. The method of claim 100, wherein the SBOM exchange service automatically updates the one of the enhanced SBOM reports when its associated initial SBOM is updated, and automatically enables the customer to view or dow nload the updated enhanced SBOM report at or from the SBOM exchange service.

113. The method of claim 112, wherein the SBOM exchange service automatically receives information from the customer when one or more of the initial SBOMs is updated.

114. The method of claim 112, wherein the SBOM exchange service automatically receives information from one or more developers of the software products when one or more of the initial SBOMs is updated.

115. The method of claim 100, wherein the SBOM exchange service sends a notice to the customer to view or download one or more of the initial SBOMs and the enhanced SBOM reports.

116. The method of claim 100, wherein the SBOM exchange service transmits one or more of the initial SBOMs and the enhanced SBOM reports to the customer.

Images