SBOM management method, non-transitory computer-readable medium, and SBOM management device

Abstract

To provide a Software Bill of Materials (SBOM) management method, an SBOM management apparatus, and a non-transitory computer readable medium.SOLUTION: In an SBOM management system, an SBOM proxy (SBOM management apparatus) includes a web proxy, a container executer, a container monitor, an SBOM generator, and an SBOM sender. The web proxy intercepts a container download request from machines. The container executor checks running condition of a container and executes it for a certain period of time. The container monitor monitors components that are executed or read during the operation. The SBOM generator accesses package managers of the container and estimates the packages of the monitored components. The SBOM sender sends active SBOM and potential SBOM to a manager.SELECTED DRAWING: Figure 2

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. An SBOM (Software Bill of Materials) is a machine-readable list of software packages and components. An SBOM can be used for fine-grained vulnerability management and communication between suppliers and consumers. Several forms of SBOM are available (e.g., SPDX®, Cyclone DX, etc.). As virtualization technology becomes more prevalent, managing the SBOM of virtual containers (e.g., Docker) becomes important. Ideally, suppliers should maintain and provide the SBOM. However, because suppliers do not always support SBOM, consumers still need to manage the software SBOM themselves. Generally, containers are built by stacking many pieces of software. Therefore, even if a component is listed in the SBOM, it may remain dormant while the software is running. From a risk analysis perspective, security operators should understand whether components in software are used or remain dormant during operation.

[0003] In a related art embodiment, there exists technology that monitors the execution and invocation of files within a machine, correlates them with the SBOM, and then identifies 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 the container to pass pre-checks before being installed on the machine. Even if the machine is capable of installing the 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 an agent already has a complete SBOM. After generating the SBOM for a container, an open source software (OSS) tool accesses a package manager within 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 in-machine agents, the monitoring logs can become very large, imposing potentially unacceptable overhead on the management system and network. Therefore, monitored components should be controlled by the management system. [Means for solving the problem]

[0007] Aspects of the present disclosure may involve a method, the method comprising: The present invention is realized by an SBOM management device including a processor, From the machine of Downloads the container associated with the container download request. death , execute the container's operating conditions for a certain period of time. death ,Monitor the components of the container that are executed or ,read during the execution of the operating conditions. death ,estimate the package of the monitored component death Generate active and potential software bills of materials (SBOMs) from execution death , Sends the active and potential SBOMs to the management server,An active SBOM is associated with a package of packages associated with a monitored component that was read or executed during the execution of the operating condition, and a potential SBOM is associated with the remaining packages of the monitored component that was read or executed during the execution of the operating condition. It is a package, may include:

[0008] Aspects of the present 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. and generating an active software bill of materials (SBOM) and a potential SBOM from the execution, where the active SBOM is associated with a package 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 package 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 present 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 external to the machine; means for executing an operating 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 operating 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 operating 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 present disclosure may involve an apparatus that may include a processor configured to: download a container associated with a container download request from a machine, the container being downloaded at a location external to the machine; execute operating conditions of the container for a period of time; monitor components of the container that are executed or read during execution of the operating conditions; estimate packages of the monitored components; generate an active software bill of materials (SBOM) and a potential SBOM from the execution, the active SBOM being associated with packages of 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; and send the active SBOM and the potential SBOM to a management server. [Brief explanation of the drawings]

[0011] [Figure 1]FIG. 1 illustrates an example of an SBOM architecture. [Figure 2] FIG. 1 illustrates an exemplary SBOM management system, according to an exemplary embodiment. [Figure 3] FIG. 10 illustrates a flow for a container executor, according to an example implementation. [Figure 4] FIG. 1 illustrates an example flow for an overview of an SBOM generator, according to an example embodiment. [Figure 5] FIG. 1 illustrates an exemplary flow for a package determiner of an SBOM generator, according to an exemplary embodiment. [Figure 6] FIG. 1 illustrates an example of a flow for an access controller, according to an exemplary implementation. [Figure 7] FIG. 1 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 computer device suitable for use in some exemplary implementations. DETAILED DESCRIPTION OF THE INVENTION

[0012] The following detailed description provides details of the figures and exemplary implementations of the present application. Reference numbers and descriptions of elements that are duplicated between figures are omitted for clarity. Terms used throughout the description are provided by way of example and are not intended to be limiting. For example, 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 those skilled in the art practicing the present application. Selections may be made by a user via a user interface or other input means, or may be implemented via a desired algorithm. The exemplary implementations as described herein may be used either alone or in combination, and the functionality of the exemplary implementations may be implemented via any means according to the desired embodiment. [Example]

[0013] 2 illustrates an exemplary SBOM management system, according to an exemplary embodiment. The exemplary embodiment described herein may involve 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 manager 220. Based on the response, manager 220 allows / denies the download.

[0014] In particular, SBOM proxy 200 may involve web proxy 201, which intercepts container download requests from machine 210. Container downloader 202 downloads containers for analysis. Container executor 203 checks the container's operating conditions and executes the container for a specific period of time (test run). Container monitor 204 monitors components executed or loaded during operation. SBOM generator 205 accesses the container's package manager and infers the package of the monitored component. SBOM sender 206 sends two types of components to manager 220:

[0015] The active SBOM 222 is a list of component packages that are loaded or executed during a test run. A container is considered to be at a 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 to be relatively low. Based on the access decision from the access controller 221, the web proxy 201 allows or 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 comparing the SBOMs with 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 presents 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 presents them to the operator.

[0018] An exemplary implementation involves a monitoring agent 213 that monitors the components being executed / loaded by containers and software, and logs usage of the components and associated packages in a monitoring log file.

[0019] The exemplary implementation involves a log sender 211 , following instructions from a usage monitor 225 , retrieving logs from a monitored log file 212 and sending them.

[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 as to whether an error exists. If the execution failed due to an option error (Yes), the flow collects an error message at 302; otherwise (No), the flow continues 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 certain 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 functionality, 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 retrieves packages from the package managers at 403. 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., being 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; 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 monitored components as active SBOMs. At 408, the remaining components included in the package manager but not monitored are classified as potential SBOMs.

[0027] FIG. 5 shows an example flow for the package determiner of the SBOM generator 205, according to an example implementation. This flow is an execution of the package determiner 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; if not (No), the flow proceeds to use a heuristic that uses the container metafile, file path, and directory. For example, the flow can check the container metafile at 502 to find the description in the package that it likely points to. The flow can also check the file path of the component to confirm a hint about the package location at 503. In addition, the flow can check whether the component's file is under a specific package-specific directory at 504.

[0028] Then, at 505, the flow determines the most feasible package based on heuristics and returns the package name at 506.

[0029] FIG. 6 shows 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. This allows the access controller 221 to enumerate a set of risk scores for each component of the SBOM by matching each component of the SBOM with the vulnerability information stored in the access controller 221. If a component matches an entry in the vulnerability information, a risk proportional to the corresponding risk score is imposed on the container. On the other hand, if a component does not match the vulnerability information, no risk is imposed 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 combines the two risks 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 granted.

[0033] 7 shows an example flow for the usage monitor 225, according to an example 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 compares that information with 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 previously determined to be non-vulnerable may become vulnerable if new vulnerabilities are discovered. The active / potential SBOMs then provide the operator with the current vulnerable packages and high-risk assets.

[0034] At 702, a security operator determines which packages should be monitored at each asset, and 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 status 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 status monitor 225 then instructs the log sender 211 to send usage status 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] Additionally, 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 manager by limiting the packages monitored to those that are important to security operators.

[0040] Additionally, variations on the exemplary implementations described above 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 when specific inputs are received. In this case, new functionality for performing 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 configured to perform functions as described in FIG. 2 for manager 220 and access controller 221 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 can be further configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation.

[0042] Computing device 805 may be communicatively coupled to input / user interface 835 and output device / interface 840. Either or both of input / user interface 835 and output device / interface 840 may be wired or wireless interfaces and may be detachable. 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, touchscreen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, accelerometer, optical reader, and / or the like). Output device / interface 840 may include a display, television, monitor, printer, speaker, Braille, or the like. In some exemplary implementations, input / user interface 835 and output device / interface 840 may be incorporated with or physically coupled to 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 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, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tape), 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 can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some exemplary computing environments. The computer-executable instructions can be retrieved from transitory media and stored on and retrieved from non-transitory media. The executable instructions can 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 vary 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 the flow of information between units and, in some exemplary implementations described above, direct the services provided by API unit 865, input unit 870, and output unit 875. For example, the flow of one or more processes or implementations 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 external to the machine (e.g., by the SBOM proxy 200 by the container downloader 202); executing operational conditions of the container for a period of time (e.g., by the container executor 203); monitoring components of the container that are executed or read during execution of the operational conditions (e.g., by the container monitor 204); estimating packages of the monitored components (e.g., by the SBOM generator 205); generating an active software bill of materials (SBOM) and potential SBOMs from the execution (e.g., by the SBOM generator 205), where the active SBOM is associated with packages of packages associated with monitored components that were read or executed during execution of the operational conditions, and the potential SBOM is the remaining packages of packages; and sending the active SBOM and potential SBOMs to a management server (e.g., by the SBOM sender 206).

[0051] The processor 810 may be configured to execute the method or computer instructions as described above, further including denying or allowing the download of the container to the machine based on the access decision from the management server in response to the active and potential SBOMs (e.g., by the access controller 221 sending the 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, wherein estimating packages for monitored components involves, for each monitored component, determining whether a file path for each monitored component is included in the package manager, as shown at 501 in FIG. 5 , and if the file path is determined to be included, including the package in the file path in the estimated package.

[0053] The processor 810 may be configured to execute the method or instructions as described above, and as shown at 502 in FIG. 5, if it is determined that the file paths are not included, estimating the packages of the monitored components involves 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 from the description.

[0054] The processor 810 may be configured to execute the method or instructions as described above, and as shown at 503 in FIG. 5, estimating the package of the monitored components involves checking within the directory of each of the monitored components for the package if a determination is made that the file path is not included, and including the package found in the directory in the estimated 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 monitored components involves, if a determination is made that the file paths are not included, checking the file paths of each monitored component to find a package associated with each monitored component, 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 including 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, as shown at 303-306 in FIG. 3 , 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.

[0057] The processor 810 may be configured to execute the method or instructions as described above, where the method is 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, the management server may be configured to, in response to receiving the active SBOM and the potential SBOM (e.g., via access controller 221, storing active SBOM 222 and potential SBOM 223), 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 in 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 package inference of the running components. 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 packages.

[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 series of defined steps leading to a desired end state or result. In exemplary implementations, the performed steps require physical manipulations of tangible quantities to achieve a tangible result.

[0062] Unless otherwise specified, and as will be apparent from the description, throughout this specification, descriptions utilizing words such as "processing," "calculating," "computing," "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 apparatuses for performing the operations herein. This 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 containing 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 eventually be convenient to construct specialized apparatus to perform the desired method steps. Additionally, the example embodiments are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the teachings of the example 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), processor, or controller.

[0065] As is known in the art, the operations described above may be performed by hardware, software, or some 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 methods that implement the embodiments 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 methods 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] Additionally, 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 embodiments may be used singly or in any combination. It is intended that the specification and exemplary embodiments be considered as examples only, with the 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 Devices / Interfaces 845 External Storage 850 Network 860 logical units 865 API units 870 Input Unit 875 output unit

Claims

1. 1. A method for managing SBOM, comprising: The SBOM management device includes a processor, The processor: Downloads the container associated with the container download request from the machine, Execute the operating conditions of the container for a certain 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 component; generating an active software bill of materials (SBOM) and a potential SBOM from said execution; sending the active SBOM and the potential SBOM to a management server; The active SBOM is associated with a package of the packages associated with a component of the monitored components that was called or executed during execution of the operating condition, and the potential SBOM is a remaining package of the packages.

1. A method for managing SBOM, comprising:

2. The processor, The SBOM management method of claim 1 , further comprising: denying or allowing the download of the container based on an access decision from the management server in response to the active SBOM and the potential SBOM.

3. The processor, In 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 of the container; The SBOM management method according to claim 1 , wherein if it is determined that the file path is included, a package in the file path is estimated to be a package of the component.

4. The processor, In estimating the package of the monitored component, 4. The SBOM management method of claim 3, wherein if it is determined that the file path is not included, the metafile of the container is checked to obtain a description pointing to the package associated with each of the monitored components, and the package associated with each of the monitored components found from the description is included and estimated as the package of the component.

5. The processor, In estimating the package of the monitored component, 4. The SBOM management method of claim 3, wherein if it is determined that the file path is not included, the package is searched for in the directory of each of the monitored components, and the package found in the directory is included and inferred as the package of the component.

6. The processor: In estimating the package of the monitored component, if it is determined 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; The SBOM management method of claim 3 , further comprising including the found package in the estimated package.

7. The processor: Further, determining the operating condition, wherein the determining of the operating condition includes: Run the container without any options: If running the container without options has no errors, returning the operating conditions when running the container without options; If running the container without any options fails due to an error, generating a dummy option for the container based on the analysis of the error; re-running the container with the dummy option; repeating the generating of the dummy option and the re-execution 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 includes a processor; The processor included in 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 in the active SBOM and a second risk assessment of vulnerabilities in the potential SBOM; The method of claim 1 , further comprising denying or allowing the download of the container to the machine based on the determined risk.

10. the management server includes a processor; The processor included in the management server obtaining updated vulnerability information for the packages in the active SBOM and the potential SBOM; selecting a package from the packages to monitor based on the updated vulnerability information; Retrieving the monitored package usage status from a log in a target database for the selected component; The SBOM management method of claim 1 , wherein the logs in the target database are provided by the machine while the container is running.

11. the machine performs an estimation of the package of the component in operation; The SBOM management method according to claim 1 .

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 component; generating an active software bill of materials (SBOM) and a potential SBOM from the execution, wherein the active SBOM is 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 is the remaining packages of the packages; transmitting the active SBOM and the potential SBOM to a management server; 1. 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. To do, estimating a package of the monitored component; 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.

Images