SBOM management method, non-transitory computer readable medium, and SBOM management apparatus
Patent Information
- Application Number
- JP2024116874
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-04
- Filing Date
- 2024-07-22
- Publication Date
- 2025-02-17
- Estimated Expiration
- 2044-07-22
Smart Images

Figure 2025023828000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates generally to Software Bill of Materials (SBOM) technology, and more particularly to an SBOM management method, a non-transitory computer-readable medium, and an SBOM management apparatus. [Background technology]
[0002] Figure 1 shows an example of an SBOM architecture. A Software Bill of Materials (SBOM) is a machine-readable list of software packages and components. SBOMs can be used for fine-grained vulnerability management and communication between suppliers and consumers. Several forms of SBOMs are available (e.g., SPDX®, Cyclone DX, etc.). As virtualization technology becomes more prevalent, it becomes important to manage the SBOM of virtual containers (e.g., Docker). Ideally, the supplier should maintain and provide the SBOM. However, because suppliers do not always support SBOMs, consumers still need to manage the SBOM of their software themselves. Generally, containers are built by stacking many pieces of software. Therefore, even if a component is enumerated in the SBOM, it may remain dormant while the software is running. From a risk analysis perspective, security operators should know whether a component in a software is used or remains dormant during operation.
[0003] In related art embodiments, techniques exist that monitor the execution and invocation of files within a machine, correlate them with the SBOM, and then identify associated vulnerabilities. Summary of the Invention [Problem to be solved by the invention]
[0004] Related art implementations require an agent program running on the machine, which may not be feasible for machines in manufacturing systems. Therefore, it is desirable for containers to pass pre-checks before being installed on a machine. Even if a machine is capable of installing an agent, it is still desirable to prevent high-risk vulnerable components from being activated on the machine in the first place.
[0005] Related art implementations assume that the agent already has a complete SBOM. When generating the SBOM for a container, an open source software (OSS) tool accesses a package manager in the container to extract the installed components and their packages. However, in reality, some packages are installed without a manager, making it difficult for the tool to track unmanaged packages.
[0006] Furthermore, even with the use of in-machine agents, the monitoring logs can become very large, imposing potentially insurmountable overhead on the management system and network. Therefore, the components being monitored should be controlled by the management system. [Means for solving the problem]
[0007] Aspects of the disclosure may involve a method that may include downloading a container associated with a container download request from a machine, where the container is downloaded at a location outside the machine; executing an operational condition of the container for a period of time; monitoring components of the container that are executed or read during execution of the operational condition; inferring packages of the monitored components; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, where the active SBOM is associated with packages of packages associated with the monitored components that were read or executed during execution of the operational condition, and the potential SBOM is the remaining packages of the packages; and transmitting the active SBOM and the potential SBOM to a management server.
[0008] Aspects of the disclosure may involve a computer program that may include computer instructions for downloading a container associated with a container download request from a machine, the container being downloaded at a location external to the machine; executing an operating condition of the container for a period of time; and monitoring components of the container that are executed or retrieved during execution of the operating condition. The method includes: estimating packages of the monitored components; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, where the active SBOM is associated with packages of the packages associated with the monitored components that were read or executed during the execution of the operating conditions, and the potential SBOM is the remaining packages of the packages; and transmitting the active SBOM and the potential SBOM to a management server. The computer program and instructions can be stored on a non-transitory computer readable medium and executed by one or more processors.
[0009] Aspects of the disclosure may involve a system that may include means for downloading a container associated with a container download request from a machine, where the container is downloaded at a location outside the machine; means for executing an operational condition of the container for a period of time; means for monitoring components of the container that are executed or read during execution of the operational condition; means for estimating packages of the monitored components; means for generating an active software bill of materials (SBOM) and a potential SBOM from the execution, where the active SBOM is associated with packages of packages associated with components of the monitored components that were read or executed during execution of the operational condition, and the potential SBOM is the remaining packages of the packages; and means for transmitting the active SBOM and the potential SBOM to a management server.
[0010] Aspects of the disclosure may involve an apparatus that may include a processor configured to: download a container associated with a container download request from a machine, where the container is downloaded at a location outside the machine; execute an operational condition of the container for a period of time; monitor components of the container that are executed or read during execution of the operational condition; infer packages of the monitored components; generate an active software bill of materials (SBOM) and a potential SBOM from the execution, where the active SBOM is associated with packages of packages associated with components of the monitored components that were read or executed during execution of the operational condition, and the potential SBOM is the remaining packages of the packages; and transmit the active SBOM and the potential SBOM to a management server. [Brief description of the drawings]
[0011] [Figure 1] FIG. 2 illustrates an example of an SBOM architecture. [Diagram 2] FIG. 1 illustrates an exemplary SBOM management system, according to an exemplary embodiment. [Diagram 3] FIG. 1 illustrates a flow for a container executor, according to an exemplary implementation. [Figure 4] FIG. 1 illustrates an example flow for an overview of an SBOM generator, according to an example embodiment. [Diagram 5] FIG. 2 illustrates an example flow for a package determiner of an SBOM generator, according to an example implementation. [Figure 6] FIG. 2 illustrates an example of a flow for an access controller, according to an exemplary implementation. [Figure 7] FIG. 2 illustrates an exemplary flow for a usage monitor, according to an exemplary implementation. [Figure 8] FIG. 1 illustrates an exemplary computing environment having an exemplary computing device suitable for use in some exemplary implementations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0012] The following detailed description provides details of the figures and exemplary implementations of the present application. Reference numbers and descriptions of elements that overlap between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may include fully automatic or semi-automatic implementations, including user or administrator control over certain aspects of the implementation, depending on the desired implementation of the person skilled in the art practicing the implementation of the present application. Selection may be performed by a user via a user interface or other input means, or may be performed via a desired algorithm. The exemplary implementations as described herein may be utilized either alone or in combination, and the functionality of the exemplary implementations may be implemented via any means according to the desired embodiment. EXAMPLES
[0013] 2 illustrates an exemplary SBOM management system, according to an exemplary embodiment. The exemplary embodiment described herein may involve a SBOM proxy 200 intercepting a container download request from a machine, downloading the container, running the container, generating two types of SBOMs (active SBOM and potential SBOM), and sending the SBOMs to a manager 220. Based on the response, the manager 220 allows / denies the download.
[0014] In particular, the SBOM proxy 200 may involve a web proxy 201 that intercepts container download requests from the machine 210. The container downloader 202 downloads the container for analysis. The container executor 203 checks the container's operating conditions and executes the container for a certain period of time (test run). The container monitor 204 monitors the components executed or read during the operation. The SBOM generator 205 accesses the container's package manager and infers the package of the monitored component. The SBOM sender 206 sends two types of components to the manager 220.
[0015] The active SBOM 222 is a list of packages of components that are loaded or executed during a test run. A container is considered to be at relatively high risk if any of its components listed in the active SBOM are vulnerable. The potential SBOM 223 includes packages that are installed in the container but are not listed in the active SBOM. The risk from vulnerable components that are only listed in the potential SBOM, while not negligible, is considered relatively low. Based on the access decision from the access controller 221, the web proxy 201 allows / denies the download.
[0016] The exemplary implementations described herein may also involve an access controller 221 receiving active SBOMs 222 and potential SBOMs 223 and determining the risk of the container by checking the SBOMs against a vulnerability database (DB) 224. If the risk is below a threshold, the download is allowed. These SBOMs are then stored in the database.
[0017] The exemplary implementation described herein involves a usage monitor 225 that shows the current SBOM, vulnerability DB, and monitoring status to an operator. Based on instructions from the operator, the usage monitor 225 determines which components / packages should be monitored. The direct log sender 211 then monitors the determined components / packages via the target DB 240. The usage monitor 225 receives monitoring logs 212 from the log sender 211 and shows them to the operator.
[0018] The exemplary embodiment involves a monitoring agent 213 that monitors the components being executed / called by the containers and software, and logs the usage of the components and associated packages in a monitoring log file.
[0019] The exemplary implementation involves a log sender 211 , which retrieves logs from the monitored log file 212 and sends them as directed by the usage monitor 225 .
[0020] 3 shows a flow for container executor 203 according to an example embodiment. At 300, the flow executes a container without options since there may be no information about what options are required to execute the container. At 301, a determination is made whether an error exists. If the execution failed due to an option error (Yes), at 302, the flow collects an error message; otherwise (No), the flow proceeds to 306.
[0021] At 303, the flow analyzes the cause of the error using NLP (Natural Language Processing) and then crafts a dummy option based on the analysis results. The flow then re-runs the container with the option at 304. If the run fails again at 305 (Yes), the flow returns to 302; otherwise (No), the flow proceeds to 306.
[0022] At 306, if no errors appear, execution continues until either no new components are observed in a particular time interval (eg, within a threshold) or the execution period reaches a timeout threshold.
[0023] 4 illustrates an example flow for an overview portion of the SBOM generator 205, according to an example implementation. First, the SBOM generator 205 accesses the container and retrieves the component / package information from the package manager (e.g., dpkg, apk). To facilitate such function, the SBOM generator 205 executes the flow as follows:
[0024] At 401, the flow accesses the image's file system. Then, at 402, the flow determines which package managers are installed, and then, at 403, retrieves packages from the package managers. Then, at 404, the flow gets components from each package.
[0025] The SBOM generator 205 then determines the packages of the components being monitored (e.g., executed or read). To facilitate such functionality, the SBOM generator 205 executes a flow as follows: At 405, a check is made as to whether there are any components being monitored but not checked. If there are not (No), the flow proceeds to 407 to begin generating active and potential SBOMs, and if there are (Yes), the flow proceeds to 406 to determine the packages of the components.
[0026] Finally, the SBOM generator 205 generates an active SBOM and a potential SBOM. To facilitate such functionality, the SBOM generator 205 executes a flow as follows: At 407, the flow classifies the components that are being monitored as active SBOMs. At 408, the remaining components that are included in the package manager but are not being monitored are classified as potential SBOMs.
[0027] FIG. 5 illustrates an exemplary flow for the package determination portion of the SBOM generator 205, according to an exemplary embodiment. This flow is an execution of the package determination component 406 of FIG. 4. First, at 501, the SBOM generator 205 checks whether the file path of the component is included in the package manager. If it is determined that the file path of the component is included in the package manager (Yes), the flow proceeds to return the package name at 506, otherwise (No), the flow proceeds to use a heuristic technique that uses the container metafile, the file path, and the directory. For example, the flow can check the container metafile at 502 to find the description in the package that it is supposed to point to. The flow can also check the file path of the component at 503 to see hints about the location of the package. In addition, the flow can check whether the file of the component is under a certain package-specific directory at 504.
[0028] Then, at 505, the flow determines the most feasible package based on heuristics and returns, at 506, the package name.
[0029] FIG. 6 illustrates an example of a flow for the access controller 221, according to an exemplary implementation.
[0030] At 600, the flow receives an active / potential SBOM from an SBOM sender. At 601, the flow retrieves vulnerability information for packages in the active / potential SBOM. The vulnerability information typically includes vulnerable packages and corresponding risk scores. The access controller 221 can thereby enumerate a set of risk scores for each component of the SBOM by matching each component with the vulnerability information stored in the access controller 221. If the component matches an entry in the vulnerability information, it imposes a risk on the container proportional to the corresponding risk score. On the other hand, if the component does not match the vulnerability information, it does not impose a risk on the container.
[0031] At 602, the flow calculates a risk score for each SBOM. This risk score can be the sum of the risks for the matched components, or more sophisticated mathematics can be applied, depending on the desired implementation. At 603, the flow adds the two risks together into an aggregate risk. The score can be a vector made up of the two scores, or a scalar, depending on the desired implementation.
[0032] At 604, a decision on access (allow / deny) is made based on the aggregate risk: if the combined score is above a threshold, access is denied; otherwise, access is allowed.
[0033] FIG. 7 illustrates an exemplary flow for the usage monitor 225, according to an exemplary implementation. First, at 700, the usage monitor 225 periodically updates vulnerability information by accessing vulnerability intelligence over the Internet. At 701, the usage monitor 225 matches that information against the SBOMs (both active and potential SBOMs) to identify vulnerable packages and high-risk assets. High-risk assets are identified by installed container images and vulnerable packages contained in the organization's asset DB. This process is important because SBOMs that were once determined to be non-vulnerable may become vulnerable if new vulnerabilities are found. The active / potential SBOMs then provide the current vulnerable packages and high-risk assets to the operator.
[0034] At 702, a security operator determines which packages should be monitored for each asset, and the usage monitor 225 receives the packages accordingly. This process can also be automated by defining rules, depending on the desired implementation.
[0035] In 703, the usage monitor 225 places a list of monitoring target packages (monitoring requests) in the target DB 240. The log sender 211 periodically accesses the DB, extracts the monitoring targets, and starts monitoring. The usage monitor 225 then instructs the log sender 211 to send usage information.
[0036] At 704, the usage monitor 225 receives the usage information from the log sender 211 and displays them to the security operator.
[0037] Through the exemplary embodiments described herein, the system can more accurately analyze the risk of installed containers by generating two types of SBOMs: an active SBOM for packages whose components are actually executed / read during test operations, and a latent SBOM for packages that are included in the container but whose components are not executed / read during test operations.
[0038] Further, through the exemplary implementations described herein, the system can identify packages that are not registered with the package manager by executing containers and monitoring the characteristics of the executed / loaded components.
[0039] Additionally, through the exemplary implementations described herein, the system can monitor the usage of generated SBOMs without imposing high overhead on the network and SBOM managers by limiting the packages monitored to those packages that are important to security operators.
[0040] Additionally, variations of the above exemplary implementations may also include desired implementations. For example, it may be beneficial to perform quick penetration testing during test operations on the SBOM proxy, as this may reveal additional packages that are used only if certain inputs are received. In this case, new functionality to perform penetration testing may be added to facilitate the desired implementation.
[0041] 8 illustrates an exemplary computing environment having an exemplary computing device suitable for use in some exemplary implementations, such as a management server or management computer in which manager 220 and access controller 221 are configured to perform functions as described in FIG. 2 to function as SBOM proxy 200 and / or to function as machine 210. Computing device 805 in computing environment 800 can include one or more processing units, cores, or processors 810, memory 815 (e.g., RAM, ROM, and / or the like), internal storage 820 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 825, any of which can be coupled over a communication mechanism or bus 830 for communicating information or can be incorporated into computing device 805. I / O interface 825 is further configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation.
[0042] The computing device 805 may be communicatively coupled to an input / user interface 835 and an output device / interface 840. Either one or both of the input / user interface 835 and the output device / interface 840 may be a wired or wireless interface and may be removable. The input / user interface 835 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch screen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, accelerometer, optical reader, and / or the like). The output device / interface 840 may include a display, television, monitor, printer, speaker, Braille, or the like. In some exemplary implementations, the input / user interface 835 and the output device / interface 840 may be incorporated with or physically coupled to the computing device 805. In other exemplary implementations, other computing devices may function as or provide the functionality of input / user interface 835 and output device / interface 840 for computing device 805 .
[0043] Examples of computing devices 805 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices mounted on vehicles and other machines, devices carried by people or animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded and / or televisions with one or more processors coupled thereto, radios, and the like).
[0044] Computing device 805 may be communicatively coupled (e.g., via I / O interface 825) to external storage 845 and a network 850 for communication with any number of networked components, devices, and systems, including one or more computing devices of the same or different configurations. Computing device 805 or any other connected computing device may function as, provide services to, or be referred to as a server, client, thin server, general purpose machine, special purpose machine, or otherwise.
[0045] I / O interface 825 may include, but is not limited to, wired and / or wireless interfaces using any communication or I / O protocol or convention (e.g., Ethernet, 802.11x, Universal System Bus, WiMax, modem, cellular network protocols, and the like) for communicating information to and / or from at least all connected components, devices, and networks in computing environment 800. Network 850 may be any network or combination of networks (e.g., the Internet, a local area network, a wide area network, a telephone network, a cellular network, a satellite network, and the like).
[0046] The computing device 805 can use and / or communicate using computer usable or computer readable media, including transitory and non-transitory media. Transitory media include transmission media (e.g., metallic cables, optical fibers), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray® disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.
[0047] The computing device 805 may be used to implement techniques, methods, applications, processes, or computer-executable instructions in some exemplary computing environments. The computer-executable instructions may be retrieved from a transitory medium and stored in and retrieved from a non-transitory medium. The executable instructions may be from one or more of any programming, scripting, and machine language (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, etc.).
[0048] The processor 810 can run under any operating system (OS) (not shown) in a native or virtual environment. One or more applications can be deployed, including a logic unit 860, an application programming interface (API) unit 865, an input unit 870, an output unit 875, and an inter-unit communication mechanism 895 for different units to communicate with each other, with the OS, and with other applications (not shown). The above-mentioned units and elements can differ in design, function, configuration, or implementation, and are not limited to the above description. The processor 810 can have the form of a hardware processor, such as a central processing unit (CPU), or can be a combination of hardware and software units.
[0049] In some exemplary implementations, when information or instructions for execution are received by API unit 865, it may be communicated to one or more other units (e.g., logic unit 860, input unit 870, output unit 875). In some examples, logic unit 860 may be configured to control information flow between units and direct services provided by API unit 865, input unit 870, output unit 875 in some exemplary implementations described above. For example, one or more processes or implementation flows may be controlled by logic unit 860 alone or in conjunction with API unit 865. Input unit 870 may be configured to obtain inputs for the calculations described in the exemplary implementations, and output unit 875 may be configured to provide outputs based on the calculations described in the exemplary implementations.
[0050] The processor 810 may be configured to execute a method or computer instructions involving downloading a container associated with a container download request from a machine, where the container is downloaded at a location outside the machine (e.g., by the SBOM proxy 200 by the container downloader 202); executing an operational condition of the container for a period of time (e.g., by the container executor 203); monitoring components of the container that are executed or retrieved during execution of the operational condition (e.g., by the container monitor 204); inferring packages of the monitored components (e.g., by the SBOM generator 205); generating an active software bill of materials (SBOM) and a potential SBOM from the execution (e.g., by the SBOM generator 205), where the active SBOM is associated with packages of the packages associated with the monitored components that were retrieved or executed during execution of the operational condition, and the potential SBOM is the remaining packages of the packages; and sending (e.g., by the SBOM sender 206) the active SBOM and the potential SBOM to a management server.
[0051] The processor 810 may be configured to execute a method or computer instructions as described above, further including denying or allowing the download of a container to a machine based on an access decision from the management server in response to the active and potential SBOMs (e.g., by the access controller 221 sending an access decision to the SBOM sender 206). In one exemplary implementation, the access decision may be based on matching the active SBOM with vulnerability information from a vulnerability database, as described with respect to FIG. 6.
[0052] The processor 810 may be configured to execute the method or instructions as described above, where estimating packages for the monitored components involves, for each of the monitored components, determining whether a file path for each of the monitored components is included in the package manager, and if the file path is determined to be included, including the package in the file path in the inferred package, as shown at 501 in FIG.
[0053] The processor 810 may be configured to execute methods or instructions as described above, where, as shown at 502 in FIG. 5 , estimating the packages of the monitored components involves checking the container metafile to obtain a description pointing to a package associated with each of the monitored components if it is determined that a file path is not included, and including the package associated with each of the monitored components found from the description.
[0054] The processor 810 may be configured to execute methods or instructions as described above, including, as shown at 503 in FIG. 5, estimating packages for monitored components involves checking within a directory of each of the monitored components for a package if a file path is determined not to be included, and including the package found in the directory in the inferred package.
[0055] The processor 810 may be configured to execute methods or instructions as described above, including, as shown at 504 in FIG. 5 , estimating packages for the monitored components involves, if a determination is made that the file paths are not included, checking the file paths of each of the monitored components to find a package associated with each of the monitored components and including the found package in the estimated package.
[0056] The processor 810 may be configured to execute the methods or instructions as described above, further involving determining an operating condition, where determining the operating condition involves running the container without the option (e.g., as shown at 300 in FIG. 3 ), and if running the container without the option does not have errors (e.g., as shown at 301 and 306 in FIG. 3 ), returning the operating condition when running the container without the option, and if running the container without the option fails due to an error, generating a dummy option for the container based on an analysis of the error, re-running the container with the dummy option, and repeating generating the dummy option and re-running the container with the dummy option until the container runs with the dummy option without errors, and returning the dummy option as the operating condition for the container, as shown at 303-306 in FIG. 3 .
[0057] The processor 810 may be configured to execute the methods or instructions as described above, with the methods being executed in response to intercepting a container download request from a machine, as indicated by a container request being intercepted by the web proxy 201, or in response to a request made from the machine 210.
[0058] Depending on the desired implementation, as shown in FIG. 6, in response to receiving the active SBOM and the potential SBOM (e.g., storing active SBOM 222 and potential SBOM 223 via access controller 221), the management server may be configured to retrieve vulnerability information for the packages in the active SBOM and the potential SBOM (e.g., via vulnerability DB 224), determine a risk based on a first risk assessment of the vulnerabilities of the active SBOM and a second risk assessment of the potential SBOM, and deny or allow the download of the container to the machine based on the determined risk.
[0059] Depending on the desired implementation, as shown in FIG. 7, the management server may be configured to obtain updated vulnerability information for packages in the active SBOM and the potential SBOM, select packages from the packages for monitoring based on the updated vulnerability information, and retrieve usage status of the monitored packages from logs in a target database for the selected components, where the logs in the target database are provided by the machine during execution of the container.
[0060] Depending on the desired implementation, machine 210 may perform an inference of the package of the running component. In one such exemplary implementation, monitoring agent 213 may have functionality similar to container monitor 204 and SBOM generator 205 to observe read / execute operations on files and identify the corresponding package.
[0061] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the substance of their innovations to others skilled in the art. An algorithm is a sequence of defined steps leading to a desired end state or result. In exemplary implementations, the steps performed require physical manipulations of tangible quantities to achieve a tangible result.
[0062] Unless otherwise noted, and as will be apparent from the description, throughout this specification, descriptions utilizing words such as "processing," "computing," "calculating," "determining," "displaying," or the like, are understood to include the actions and processes of a computer system or other information processing device that manipulates and converts data represented as physical (electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory or registers of the computer system or other information storage, transmission, or display devices.
[0063] Exemplary embodiments may further relate to an apparatus for performing the operations herein. The apparatus may be specially constructed for the desired purposes or may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored on a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. Computer-readable storage media may include tangible media, such as, but not limited to, optical disks, magnetic disks, read-only memory, random access memory, solid-state devices and drives, or any other type of tangible or non-transitory medium suitable for storing electronic information. Computer-readable signal media may include media such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. A computer program may include a purely software implementation that includes instructions for performing the operations of a desired implementation.
[0064] Various general-purpose systems may be used with the programs and modules according to the examples herein, or it may be convenient to construct specialized apparatus to perform the desired method steps. Additionally, the exemplary embodiments are not described with reference to any particular programming language. It will be understood that various programming languages may be used to implement the teachings of the exemplary embodiments as described herein. Instructions of the programming language may be executed by one or more processing devices, such as, for example, a central processing unit (CPU), a processor, or a controller.
[0065] As is known in the art, the operations described above may be performed by hardware, software, or any combination of software and hardware. Various aspects of the exemplary embodiments may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software) that, when executed by a processor, cause the processor to perform a method of performing an embodiment of the present application. Furthermore, some exemplary embodiments of the present application may be implemented solely in hardware, while other embodiments may be implemented solely in software. Furthermore, the various functions described may be performed in a single unit or may be distributed across multiple components in any number of ways. When implemented by software, the method may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions may be stored on the medium in compressed and / or encrypted format.
[0066] Moreover, other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings herein. Various aspects and / or components of the described exemplary implementations may be used alone or in any combination. It is intended that the specification and exemplary implementations be considered as examples only, with a true scope and spirit of the present application being indicated by the following claims. [Explanation of symbols]
[0067] 200 SBOM Proxy 201 Web Proxy 202 Container Downloader 203 Container Executor 204 Container Monitor 205 SBOM Generator 206 SBOM Sender 210 Machine 211 Log Sender 213 Monitoring Agent 220 Manager 221 Access Controller 224 Vulnerability DB 225 Usage Monitor 240 Target DB 805 Computer Devices 810 Processor 815 Memory 820 Internal Storage 825 I / O Interface 835 Input / User Interface 840 Output Device / Interface 845 External Storage 850 Network 860 Logical Units 865 API units 870 Input Unit 875 Output Unit
Claims
1. 1. A method for managing an SBOM, comprising: downloading a container associated with a container download request from a machine, the container being downloaded at a location external to the machine; implementing an operating condition for said container for a period of time; monitoring components of the container that are executed or invoked during execution of the operating condition; estimating a package of the monitored components; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, the active SBOM being associated with packages of the packages associated with components of the monitored components that were read or executed during execution of the operating condition, and the potential SBOM being the remaining packages of the packages; and transmitting the active SBOM and the potential SBOM to a management server.
2. and denying or allowing the download of the container to the machine based on an access decision from the management server in response to the active SBOM and the potential SBOM. The SBOM management method of claim 1 , further comprising:
3. estimating the package of the monitored component, For each of the monitored components, determining whether a file path of each of the monitored components is included in a package manager; if it is determined that the file path is included, including the package in the file path in the estimated package; The SBOM management method of claim 1 , comprising:
4. estimating the package of the monitored component, if it is determined that the file paths are not included, checking the container metafile to obtain a description pointing to the package associated with each of the monitored components, and including the package associated with each of the monitored components found in the description; The SBOM management method of claim 3 , comprising:
5. estimating the package of the monitored component, if a determination is made that the file path is not included, checking within a directory of each of the monitored components for the package and including the package found in the directory in the estimated package; The SBOM management method of claim 3 , comprising:
6. estimating the package of the monitored component, if a determination is made that the file path is not included, checking the file path of each of the monitored components to find a package associated with each of the monitored components; including the found packages in the estimated packages; The SBOM management method of claim 3 , comprising:
7. and determining the operating condition, the determining the operating condition comprising: running the container with no options; returning the operating conditions when running the container without the option if running the container without the option has no errors; If running the container without the option fails due to an error, generating a dummy option for the container based on an analysis of the error; and re-running the container with the dummy option; repeating the generating of the dummy option and the re-running of the container with the dummy option until the container executes the dummy option without error; returning the dummy option as the operating condition of the container; The SBOM management method of claim 1 , comprising:
8. 2. The SBOM management method of claim 1, wherein the method is performed in response to intercepting a request to download the container from the machine or in response to a request made from the machine.
9. The management server, in response to receiving the active SBOM and the potential SBOM, retrieving vulnerability information for the packages in the active SBOM and the potential SBOM; determining risk based on a first risk assessment of vulnerabilities of the active SBOM and a second risk assessment of the potential SBOM; denying or allowing the download of the container onto the machine based on the determined risk; The SBOM management method of claim 1 , configured to:
10. The management server, Obtaining updated vulnerability information for the packages in the active SBOM and the potential SBOM; selecting a package from the packages for monitoring based on the updated vulnerability information; retrieving a usage status of the monitored package from a log in a target database for the selected component, the log in the target database being provided by the machine during execution of the container; The SBOM management method of claim 1 , configured to:
11. The SBOM management method of claim 1 , wherein the machine performs an estimation of the package of the components that are operating.
12. A non-transitory computer readable medium storing instructions for carrying out a process, the instructions comprising: downloading a container associated with a container download request from a machine, the container being downloaded at a location external to the machine; implementing an operating condition for said container for a period of time; monitoring components of the container that are executed or invoked during execution of the operating condition; estimating a package of the monitored components; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, the active SBOM being associated with packages of the packages associated with components of the monitored components that were read or executed during execution of the operating condition, and the potential SBOM being the remaining packages of the packages; transmitting the active SBOM and the potential SBOM to a management server; A non-transitory computer readable medium comprising:
13. An SBOM management device, a processor, the processor comprising: downloading a container associated with a container download request from a machine, the container being downloaded at a location external to the machine; implementing an operating condition for said container for a period of time; monitoring components of the container that are executed or invoked during execution of the operating condition; estimating a package of the monitored components; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, the active SBOM being associated with packages of the packages associated with components of the monitored components that were read or executed during execution of the operating conditions, and the potential SBOM being the remaining packages of the packages; transmitting the active SBOM and the potential SBOM to a management server; An SBOM management device configured to perform the above.
Citation Information
Patent Citations
Dynamic application security verification
JP2016534460A
Vulnerability management system and program
JP2020021309A
Processing device and processing method
JP2023062394A
Method and apparatus for providing visibility of security into container images
US20210382997A1
Securing containerized applications
US20230131132A1
Cited By
Software parts bill generation device and software parts bill generation method
JP7799888B1
Information processing system, information processing method and program
JP7828691B1