System and method for verifying software

Abstract

The invention provides a system and a method for verifying software. According to an embodiment, a system may include: a storage store storing computer executable instructions; and at least one processor communicatively coupled with the storage, the at least one processor may be configured to execute the instructions to: receive at least one software element from a user; determining whether the received at least one software element passes a quality check; and in response to a determination that the received at least one software element has passed the quality check, appending the received software element to the list, and performing a first verification of the list, each of the plurality of software elements specified in the list includes one or more indications of types of quality checks passed by each of the plurality of software elements within the list.

Description

Technical Field

[0001] The system, method, and computer program integrated with the exemplary embodiments of the present disclosure relate to software security, and more particularly, to dynamic verification of software. Background Art

[0002] A Software Production Line (SPL) is a software automation system that has a collection of processes, automation, and tuned tools that enable its users, such as stakeholders and partners (OEMs and suppliers), to continuously build, test, and deliver software stacks. For example, an SPL involving vehicle software enables its users to build, test, and deliver vehicle software stacks for the vehicle's electronic control units (ECUs) and microcontrollers (MCUs). As the name suggests, a software "production line" is similar to a manufacturing line that provides physical components from suppliers to the production line and assembles them into the final product as automatically as possible.

[0003] The basic building blocks of a software production line are software elements. A software element may refer to a source code repository having a specific structure. A software element may be determined via a configuration file specified by a software production line. Software elements may be used to assemble a software development kit (SDK), which is a special type of software element that includes other software elements (similar to a physical assembly that includes other physical components). Therefore, software elements may have dependencies on each other, may be constructed to be used in a vehicle and its variants, and software may be built (compiled) in a manner that takes the vehicle and its variants as objects.

[0004] SPL provides tools for building, testing, and packaging the software elements, as well as managing the dependencies of the software elements. SPL can be used in vehicles, smartphones, the Internet of Things (IoT), and any entity that requires specific verifiable and provable guarantees as part of its production.

[0005] In practice, SDKs and software builds for ECUs can be made from many different combinations of different software elements. The SDKs and software builds need to meet a wide variety of safety and security requirements, where each of the software elements that make up the SDK and software build needs to be tested both independently and as part of the combined package.

[0006] Therefore, there is a need to efficiently and effectively test each of the software elements that make up the SDK and software build, and to efficiently and easily identify any defects or errors in the software elements. Summary of the invention

[0007] The exemplary embodiments of the present disclosure automatically and dynamically perform software verification based on the results of quality checks on the software elements that form the software. Therefore, the exemplary embodiments of the present disclosure can progressively update and improve the software over time while ensuring that appropriate quality requirements are still met.

[0008] According to an embodiment, a system is provided. The system may include: a storage device storing computer executable instructions; at least one processor communicatively connected to the storage device, and the at least one processor may be configured to execute the instructions to perform the following processing: receiving at least one software element from a user, wherein the received at least one software element is a new version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element has passed a quality check; and in response to a determination that the received at least one software element has passed the quality check, appending the received software element to the list and performing a first verification of the list, wherein each of the plurality of software elements specified in the list includes: one or more indications of the type of quality check passed by each of the plurality of software elements in the list.

[0009] According to an embodiment, a method is provided. The method may include: receiving at least one software element from a user, wherein the received at least one software element is a new version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element has passed a quality check; and in response to a determination that the received at least one software element has passed the quality check, appending the received software element to a list and performing a first validation of the list, wherein each of the plurality of software elements specified in the list includes: one or more indications of a type of quality check that each of the plurality of software elements in the list has passed.

[0010] The additional aspects will be described in part in the following description and in part will be obvious from the description, or may be achieved by practice of the embodiments presented in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Hereinafter, features, advantages, and significance of preferred embodiments of the present disclosure will be described with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0012] Figure 1A block diagram illustrating an exemplary system configuration for performing software verification according to one or more embodiments.

[0013] Figure 2 A block diagram illustrating exemplary components of an SPL system according to one or more embodiments.

[0014] Figure 3 A block diagram illustrating an exemplary system configuration for performing software verification according to one or more embodiments.

[0015] Figure 4 A flow chart illustrating an exemplary method of performing software validation in accordance with one or more embodiments is shown.

[0016] Figure 5 A flow chart illustrating a first exemplary method of performing validation of software and software elements in accordance with one or more embodiments is shown.

[0017] Figure 6 A flow chart illustrating a second exemplary method of performing validation of software and software elements in accordance with one or more embodiments is shown.

[0018] Figure 7 A flow chart illustrating a third exemplary method of performing verification of software and software elements in accordance with one or more embodiments is shown.

[0019] Figure 8 A diagram is shown of an exemplary environment in which the systems and / or methods described herein may be implemented. DETAILED DESCRIPTION

[0020] The following detailed description of exemplary embodiments refers to the accompanying drawings. The same reference numerals in different drawings may identify the same elements or identical elements.

[0021] The above disclosure provides examples and illustrations, but is not intended to be exhaustive, nor is it intended to limit the implementation to the exact form disclosed. Modifications and variations may be made in view of the above disclosure, or may be learned from the implementation of the implementation. Moreover, one or more features or constituent elements of an embodiment may be combined with another embodiment (or one or more features of another embodiment), or may be combined therewith. Moreover, it is understood that in the description of the actions provided below, one or more actions may be omitted, one or more actions may be added, one or more actions may be performed (at least partially) simultaneously, and the order of one or more actions may be switched.

[0022] It is obvious that the system and / or method described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method does not limit the implementation. Therefore, the actions and behaviors of the system and / or method are recorded in this specification without reference to specific software codes. It is understood that software and hardware can be designed to implement the system and / or method based on the description of this specification.

[0023] Even if a particular combination of features is disclosed in this specification, this combination is not intended to limit the disclosure of possible implementations. In fact, many of the features can be combined in ways that are not specifically disclosed in this specification.

[0024] As long as there is no particularly clear record, the elements, behaviors or instructions used in this specification should not be interpreted as important or necessary. In addition, the articles "a" and "an" used in this specification are intended to include more than one matter and can be used interchangeably with "more than one". In the case of only one matter, a term such as "one" or the same term is used. In addition, the terms "has", "have", "having", "include", "including" or similar terms used in this specification are meant to be open-ended terms. Moreover, as long as there is no particularly clear record, phrases such as "based on..." are intended to mean "at least partially based on...". Moreover, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0025] The system, method, device and equivalent provided in the exemplary embodiments of the present disclosure automatically and dynamically perform software verification based on the results of quality checks performed on software elements forming the software.

[0026] According to an embodiment, the system can receive a new version of a software element that forms software together with other software elements, determine whether the received software element passes a quality check, append the received software element to a list in response to a determination that the received software element passes the quality check, and perform verification of the list.

[0027] Finally, the exemplary embodiments of the present disclosure automatically and dynamically perform software verification based on the results of quality checks on the software elements that form the software, so that the software can be progressively updated and improved over time while ensuring that appropriate quality requirements are still met.

[0028] It can be envisioned that the features, advantages, and significance of the exemplary embodiments described above in this specification are only part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0029] The following provides further descriptions of the features, components, configurations, operations, and implementations of the threshold adjustment system of the present disclosure in one or more embodiments.

[0030] Exemplary system architecture

[0031] Figure 1 A block diagram of an exemplary system configuration 100 for performing software verification according to one or more embodiments is shown. Figure 1 As shown, system configuration 100 may include a user 110 and a software production line (SPL) system 120 .

[0032] The user 110 may include an entity that provides at least one software element that participates in the production of software to form the software, such as an original product manufacturer, a tier supplier, etc. The user 110 may be communicatively connected to the SPL system 120. In a partial implementation, the user 110 may provide the software element to the SPL system 120 and receive a software build, a software bill of materials, etc. from the SPL system 120.

[0033] The SPL system 120 may include a system, platform, module, or equivalent that may be configured to perform one or more actions or behaviors of software validation. The SPL system 120 may be a software automation system that has a set of processes, automation, and coordinated tools that enable its users (e.g., stakeholders and partners (OEMs and suppliers)) to continuously build, test, and deliver vehicle software stacks for major electronic control units (ECUs) and microcontrollers (MCUs) in vehicles.

[0034] Below, refer to Figures 4 to 7 , describes exemplary actions that can be performed by the SPL system 120 for software verification. Figure 2-3 , describes several exemplary components that may be included in the SPL system 120 of more than one embodiment.

[0035] Figure 2 A block diagram showing exemplary components of an SPL system 200 according to one or more embodiments. The SPL system 200 may correspond to Figure 1 Therefore, unless otherwise expressly stated, features associated with the SPL system 120 and the SPL system 200 may be equally applicable to each other.

[0036] like Figure 2As shown, the SPL system 200 may include at least one communication interface 210, at least one processor 220, at least one input / output unit 230, and at least one storage 240, but it is understood that the SPL system 200 may include more than one embodiment without departing from the scope of the present disclosure. Figure 2 The components shown may be more or less than the components shown, and / or the SPL system 200 may be configured with Figure 2 The situation shown is different.

[0037] The communication interface 210 may include at least one component such as a transceiver (e.g., a transceiver, an independent receiver and transmitter, a bus, etc.), which enables the components of the SPL system 200 to communicate with each other via a wired connection, a wireless connection, or a combination of wired and wireless connections, and / or enables the components of the SPL system 200 to communicate with one or more components located outside the SPL system 200.

[0038] For example, the communication interface 210 connects the processor 220 to the storage 240, thereby enabling them to communicate and interact with each other when performing one or more actions. As another example, the communication interface 210 can connect the SPL system 200 (or one or more components included therein) with the device of the user 110 in a manner that enables them to communicate and interact with each other.

[0039] According to one or more embodiments, the communication interface 210 may include one or more application programming interfaces (APIs) that enable the SPL system 200 (or one or more components included therein) to communicate with one or more software applications.

[0040] The input / output unit 230 may include at least one component that enables the SPL system 200 to receive information and / or enables the SPL system 200 to provide output information. It can be understood that, in some embodiments, the input / output unit 230 may include at least one input component (e.g., a touch screen display, a button, a switch, a microphone, a sensor, etc.) and at least one output component (e.g., a display, a speaker, one or more light emitting diodes (LED: Light Emitting Diode)), etc.), which may also be separated from each other.

[0041] The storage 240 may include one or more storage media suitable for storing data, information and / or computer executable instructions internally. According to an embodiment, the storage 240 may include at least one storage storage such as a random access memory (RAM), a read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by the processor 220. In addition or in lieu thereof, the storage 240 may include: a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state hard disk), a compact disc (CD: Compact Disc), a digital versatile disc (DVD: Digital Versatile Disc), a floppy disk, a cartridge, a magnetic tape, and / or other types of non-temporary computer-readable media, and corresponding drives.

[0042] According to an embodiment, the storage 240 may be configured to store information such as raw data, metadata, or equivalents. Additionally or alternatively, the storage 240 may be configured to store one or more information associated with one or more actions performed by the processor 220. For example, the storage 240 may store information that specifies historical actions performed by the processor 220 for software verification, one or more results of actions performed by the processor 220, or equivalents. Furthermore, the storage 240 may store data or information required for software verification.

[0043] In some implementations, the storage 240 may include multiple storage media, and the storage 240 may be configured to store copies or replicas of at least a portion of the information in multiple storage media to provide redundancy and backup the information or associated data. In addition, the storage 240 may also store computer-readable instructions or computer-executable instructions, which, when executed by one or more processors (e.g., processor 220), cause one or more processors to perform one or more behaviors / actions described in this specification.

[0044] The processor 220 may include at least one processor that is programmable or configurable to perform functions or actions described in this specification. For example, the processor 220 may be configured to: execute computer executable instructions stored in at least one storage medium or storage storage (e.g., storage 240, etc.), thereby performing one or more behaviors or one or more actions described in this specification.

[0045] According to an embodiment, the processor 220 may be configured to receive (e.g., via the communication interface 210, the input / output unit 230, etc.) one or more signals and / or one or more user inputs that specify one or more instructions for performing one or more actions. Moreover, the processor 220 may be implemented by hardware, firmware, or a combination of hardware and software. For example, the processor 220 may include a central processing unit (CPU), an image processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and / or at least one of other types of processing components or computing components.

[0046] According to an embodiment, the processor 220 may be configured to collect, extract and / or receive one or more information (in the form of signals or data, etc.) from the user 110 and process the one or more received information, thereby performing software verification.

[0047] Below, refer to Figures 4 to 7 , provides an illustration of several exemplary actions that may be performed by processor 220.

[0048] Figure 3 A block diagram of an exemplary system configuration 300 for performing software verification according to one or more embodiments is shown. Figure 3 As shown, the system configuration 300 may include a user 310 , a user storage 312 , a public repository 314 , and an SPL system 320 .

[0049] The SPL system 320 may correspond to Figure 1 SPL system 120 and Figure 2 Therefore, unless otherwise specified, the features associated with SPL system 120, SPL system 200, and SPL system 320 may be equally applicable to each other. Similarly, user 310 may correspond to Figure 1 Unless otherwise specified, the features associated with user 110 and user 310 may be equally applicable to each other.

[0050] like Figure 3 As shown, the SPL system 320 may be configured to receive software elements from the user 310. The SPL system 320 may also be configured to provide the software build and software bill of material (SBOM) to the user 310 via the user storage 312, and may also be configured to provide data such as public keys to the public repository 314.

[0051] Moreover, if Figure 3 As shown, the SPL system 320 may include at least one orchestrator 321, a software quality gate 322, a software repository 323, a build system 324, an SBOM generator 325, a collaborative design system 326, a validation store 327, a trust and revocation store 328, and a data store 329, but it is understood that the SPL system 320 may include more than one embodiment without departing from the scope of the present disclosure. Figure 3 The components shown may be more or less than the components shown, and / or the SPL system 320 may be configured with Figure 3 The situation shown is different.

[0052] The SPL system 320 may be configured to receive software elements from the user 310 and store the software elements in the software repository 323. The software repository 323 may be configured to store a plurality of software elements required to build a plurality of software.

[0053] The orchestrator 321 may be configured to request and monitor the building of software associated with the received software elements from the build system 324, request a software bill of materials (SBOM) from the SBOM generator 325, store the SBOM and data (signature, private key, etc.) and timestamp required for verification in the verification storage 327, and store the result of the combination of the software elements in the data storage 329. The orchestrator 321 may also always identify the status of all software elements, the quality checks performed on the software elements, and the results.

[0054] The build system 324 may be configured to obtain any software elements required to build the above-mentioned software from the software repository 323, obtain any quality checks stored in the software quality gate 322 and specified in order to perform quality checks on the software elements, and provide the orchestrator 321 with the software build, build status, and quality check results.

[0055] SBOM generator 325 may be configured to generate an SBOM associated with the software and provide the SBOM to orchestrator 321. Co-design system 326 may be configured to provide a platform for verification of SBOM and software elements. Trust and revocation storage 328 may be configured to store a database of trusted and untrusted signatures, private keys, etc. for verification.

[0056] Exemplary actions of performing software verification disclosed herein

[0057] Below, refer to Figures 4 to 7 , which records several exemplary actions that the SPL system of the present disclosure can perform.

[0058] Figure 4 A flow chart of an exemplary method 400 for performing software validation according to one or more embodiments is shown. One or more actions in the method 400 may be performed by at least one processor (eg, processor 220) of the SPL system.

[0059] like Figure 4 As shown, in action S410, at least one processor may be configured to receive at least one software element from a user. According to an embodiment, a software element may refer to a constituent element or a separate element that together forms the software. For example, a software element may refer to one or a combination of source code, build files, data, binary files, tools, etc. that together form the software. According to an embodiment, a part of a software element may depend on another software element. For example, a software element may require input from another software element for action, a software element may include another software element, an output (e.g., performance) from a certain software element may affect the output of another software element, etc. According to an embodiment, a software element may also refer to software that is part of another software.

[0060] According to an embodiment, in action S410, the software element received from the user may be a new version of one of the plurality of software elements forming the software. According to an embodiment, the plurality of software elements forming the software may be specified in a list such as a software bill of materials (SBOM).

[0061] According to an embodiment, SBOM may refer to metadata including a library or list of software elements that form software. Therefore, SBOM may be used to identify all components related to the software of a product for various purposes, such as to re-produce the software, to identify software elements that are notified as defective during production, etc.

[0062] Depending on the implementation, the user may refer to entities such as OEMs and tier suppliers that own the received software elements.

[0063] Next, the method proceeds to action S420.

[0064] In act S420 , at least one processor may be configured to determine whether the received software element passes a quality check.

[0065] According to an embodiment, quality check may refer to a process of checking whether software elements meet the standards for which associations have been established. For example, quality check may include one or more of security check, safety check, performance check, power consumption check, source code check, privacy check, etc. These checks may follow one or more industry standards for which associations have been established. For example, security check may follow the Automotive Safety Integrity Level (ASIL) standard specified by ISO26262, safety check may follow the requirements specified in the latest version of MISRA C++, privacy check may follow the standards specified by ISO2701, etc. According to an embodiment, performing quality check may also include: executing a linter (code checking tool) as part of the software build; and launching additional tools as needed.

[0066] Below, refer to Figure 5 to Figure 7 , provides additional description related to the process for determining whether a received software element passes quality inspection.

[0067] It will be appreciated that the number of quality checks, the specific types of quality checks, and the specific criteria associated with the quality checks that should be performed on specific software elements can be pre-defined based on the nature of the software and software elements, according to standards established by the entities and / or industries involved in the production of the software.

[0068] Next, the method proceeds to action S430.

[0069] In response to determining during act S420 that the received software element passes the quality check, in act S430, the at least one processor may be configured to append the received software element to a list. According to an embodiment, the list may refer to a software bill of materials (SBOM). According to an embodiment, the at least one processor may be configured to generate a new version of the list, the new version of the list specifying a plurality of software elements specified in a previous version of the list together with the received software element.

[0070] Next, the method proceeds to action S440.

[0071] In action S440, the at least one processor may be configured to perform a first verification of the list. According to an embodiment, the at least one processor may be configured to perform a first verification of the list by digitally signing the list (e.g., SBOM) in its entirety. The list may be digitally signed directly (encrypting the list directly using a private key) or by using a hash algorithm (i.e., by encrypting a hash of the list).

[0072] According to an exemplary embodiment, when a software element passes a certain type of quality check (e.g., safety, security, performance, power consumption, etc.), the entity that undertakes the task of performing the quality check of that type can perform verification of the software element (i.e., second verification). According to an exemplary embodiment, the entity may refer to an inspection entity in an SPL system. For example, the entity may refer to a machine, software, module, etc. that is part of an SPL system and is designed to automatically perform a specific type of quality check on a software element. According to an embodiment, the entity may refer to a person that is part of an SPL system, and the person causes the machine, software, module, etc. to act and manually performs a specific type of quality check on a software element. According to an embodiment, the entity may refer to an inspection entity that is located outside the SPL system. For example, the entity may refer to an OEM, a tier supplier, a government agency, etc. that performs a specific type of quality check on a software element.

[0073] According to an exemplary embodiment, performing the second verification of the software element may refer to cryptographically signing the software element by the checking entity. According to an exemplary embodiment, by performing the second verification, an encrypted signature (or digital signature) may be provided from the checking entity in association with an encrypted hash of the software element (i.e., the software element is hashed and the resulting hash is encrypted using a private key). According to other embodiments, the software element may not be hashed, but a signature may be provided in association with the software element itself.

[0074] It is understood that each of the inspection entities may have a unique key such as a private key (of a public key-private key pair) to provide an encrypted signature (i.e., perform a second verification). It is also understood that, in the case where the inspection entity undertakes the task of performing multiple types of quality inspections, the inspection entity may have multiple encrypted private keys to provide multiple encrypted signatures (here, each key pair is associated with a certain type of quality inspection), and different encrypted signatures are used when the inspection entity performs different types of quality inspections. For example, the inspection entity may use a first private key to provide a first encrypted signature when the inspection entity performs a security inspection on a software element, and the inspection entity may use a second key to provide a second encrypted signature when the inspection entity performs a security inspection on a software element. Therefore, a specific encrypted signature may represent a specific type of quality inspection performed on a software element and a specific inspection entity that performs the specific type of quality inspection. Moreover, after a software element passes a certain type of quality inspection, the software element is encrypted and signed (a second verification is performed), and therefore, the existence of the encrypted signature generated as a result may indicate that the software element has passed the quality inspection of that type. In other words, the second verification verifies the software element that has passed the quality inspection of that type. Furthermore, it is to be understood that the same hashing algorithm or different hashing algorithms may be used / associated with each type of quality inspection and / or each inspection entity.

[0075] Considering the above, it can be understood that each of the multiple software elements in the list (including the software elements received from the user in action S410 and appended to the list in action S430) can include one or more indications such as an encrypted signature indicating that the software element has passed a certain type of quality check.

[0076] In this regard, in action S440, at least one processor may be configured to perform a first verification of the list to verify a second verification of all software elements specified in the list. According to an exemplary embodiment, a supervisory entity in the SPL system may perform the first verification of the list. For example, the supervisory entity may refer to a machine, software, module, etc. that is part of the SPL system and is designed to automatically supervise the construction of the inspection entity and software. According to an exemplary embodiment, the entity may refer to a person who causes the machine, software, module, etc. that is part of the SPL system to act and manually supervises the construction of the inspection entity and software.

[0077] According to an exemplary embodiment, by performing the first verification, the supervisory entity can provide an encrypted signature related to the list (for example, a private key encryption of a hash related to the list or at least a predetermined portion of the list generated by a prescribed hash algorithm). It can be understood that, like the inspection entity, the supervisory entity can have a unique key such as an encryption private key to provide an encrypted signature (i.e., perform the first verification). According to an exemplary embodiment, the encrypted signature provided by the inspection entity and the supervisory entity can also indicate the date and time when the encrypted signature is provided.

[0078] In this regard, the first verification is performed on a list of multiple software elements that form the software. In the first verification, the second verification is performed on all the software elements specified in the list (next, the software elements that have passed the quality check will be verified in the second verification). Therefore, the first verification can verify the software as software that has software elements that appropriately meet various standards related to quality (for example, safety, security, performance, power consumption, etc.).

[0079] Thus, a cryptographic signature may have the following characteristics, namely: data that provides a cryptographic signature, such as ECU software (source code or compiled binary files), software elements, software builds, SBOMs, and other signatures (e.g., a signer may sign data that has already been signed by another signer); a signer that uses its own private key to perform the cryptographic signature (e.g., a person or entity that produces the software, is responsible for quality gates, or is responsible for verifying the signature); a verifier that verifies the signer (i.e., the signer signed the data using its own secret key); a date that provides the signature; an expiration date after which the signature will not be considered valid soon (indicating that the software should not be used beyond this date); and revocation information (OSCP: Online Certificate Status Protocol) that informs when the signature should be revoked. It is understood that the verifier may be anyone, or may be a list of specific public keys that correspond to the private keys of other parties. The verifier may be another supplier, OEM, public agency, or the public. For example, a first entity can verify or prove that a second entity wrote a particular piece of software, or a vendor can verify or prove that a second entity performed a particular test on the vendor's software, or a first entity can verify or prove that a second entity verified a particular vendor's signature. Furthermore, it will be appreciated that dates can be stored in some trusted storage location to enable any entity to verify the software when something was signed.

[0080] When performing act S440, method 400 may end or terminate. Alternatively, method 400 may return to act S410, with the result that at least one processor may be configured to repeat the following processes for at least a specified amount of time: (in act S410) receiving a software element; (in act S420) determining that the software element passes a quality check; (in act S430) appending the software element to a list; and (in act S440) performing validation of the list. For example, at least one processor may continuously (or periodically) receive updated versions of the same software element associated with the same software, updated versions of different software elements associated with software, and updated versions of software elements associated with different software.

[0081] For this purpose, the system of the present disclosure can perform verification of software.

[0082] Exemplary actions of performing verification of software and software elements of the present disclosure

[0083] Below, refer to Figure 5 to Figure 7 , describes several exemplary actions that can be performed by at least one processor for verifying software and software elements.

[0084] Figure 5 A flowchart of an exemplary method 500 for performing verification of software and software elements in accordance with one or more embodiments is shown. One or more actions of method 500 may be part of actions S410, S420, S430, and / or S440 in method 400, and may be performed by at least one processor (e.g., processor 220) of the SPL system.

[0085] like Figure 5 As shown, in action S510, at least one processor may be configured to receive at least one software element from a user. According to an exemplary embodiment, similar to action S410 in method 400, the received software element may be a new version of one of a plurality of software elements forming the software, and the user may refer to an entity such as an OEM and a tier supplier that owns the received software element. Next, the method proceeds to action S520.

[0086] In action S520, at least one processor may be configured to perform a quality check on the received software element. According to an embodiment, similar to the content of method 400, the quality check may refer to a process of checking whether the software element meets the standards for establishing the association, and may include one or more of a safety check, a security check, a performance check, a power consumption check, a source code check, etc. According to an embodiment, similar to the content of method 400, the quality check is performed by a check entity in the SPL system. Next, the method proceeds to action S530.

[0087] In action S530, at least one processor may be configured to determine whether the received software element has passed the quality check. According to an embodiment, at least one processor may be configured to determine whether the result of performing the quality check on the received software element meets a threshold, thereby determining whether the received software element has passed the quality check. According to an embodiment, the threshold may be a quality gate.

[0088] Depending on the implementation, a quality gate may refer to an indicator that specifies the level of quality that a software element should meet. For example, when a quality check is performed on a software element and data generated as a result is produced, the data generated as a result may be processed in a manner to obtain an indicator measurement value representing the quality of the software element related to the type of quality check performed (e.g., safety, security, performance, power consumption, etc.). The indicator may be compared to a quality gate to determine whether the quality of the software element meets an acceptable level. It is understood that the quality gate may be pre-defined based on the nature of the software and software elements, according to standards specified in the entity and / or industry involved in the production of the software.

[0089] Therefore, based on the received determination that the software element passed the quality check, at least one processor may determine that the quality of the software element related to a particular type of quality check (e.g., safety, security, performance, power consumption, etc.) meets an acceptable level, and proceeds to action S531. On the other hand, based on the received determination that the software element did not pass the quality check (failed), at least one processor may determine that the quality of the software element related to the particular type of quality check does not meet an acceptable level, and proceeds to action S535.

[0090] According to an embodiment, when a software element is specified to be subject to multiple types of quality checks (for example, according to standards specified in entities and / or industries involved in the production of the software), at least one processor may proceed to action S531 if the software element passes all specified types of quality checks, and the at least one processor may proceed to action S535 if the software element fails any one of the specified types of quality checks.

[0091] In action S531, at least one processor may be configured to perform a second verification of the received software element based on the type of quality check that the received at least one software element has passed. According to an embodiment, similar to what is described above in association with method 400, performing a second verification of the received software element may refer to cryptographically signing the received software element by the checking entity, providing a cryptographic signature (or digital signature) in relation to a cryptographic hash of the received software element, and / or providing a cryptographic signature (or digital signature) in relation to the software element itself without hashing the software element.

[0092] For example, as described in connection with method 400, the inspection entity may have a unique key such as a private key (of a public key-private key pair) to provide an encrypted signature, and the inspection entity may have multiple encrypted private keys to provide multiple encrypted signatures. Different encrypted signatures are used when the inspection entity performs different types of quality checks. Therefore, for example, when the inspection entity A performs a security check, private key A is used to provide an encrypted signature A, and when the inspection entity A performs a security check, private key B is used to provide an encrypted signature B, and when the software element passes the security check performed by the inspection entity A in action S520, the inspection entity A can use key A to perform an encrypted signature on the software element (i.e., a second verification can be performed) to provide an encrypted signature A. As another example, sometimes, when the inspection entity A performs a security check on the software element used in the test software, private key C is used to provide an encrypted signature C, and when the inspection entity A performs a security check on the software element used in the final product software, private key D is used to provide an encrypted signature D. Therefore, when the security check is performed on the software element used in the test software, the inspection entity A can use key C to provide an encrypted signature C. Next, the method proceeds to action S532.

[0093] In action S532, at least one processor may be configured to append the received software element to the build of the software. For example, during actions S520, S530, and S531, the received software element passed the quality check and received the second verification, so at least one processor may determine that the received software element is of acceptable quality to be included in the build of the software. Therefore, at least one processor may be configured to append the received software element to the build of the software. Next, the method proceeds to action S533.

[0094] In action S533, at least one processor may be configured to append the received software element to the list. According to an embodiment, the list may refer to a SBOM, as described in connection with the method 400. Next, the method proceeds to action S534.

[0095] In action S534, at least one processor may be configured to perform a first verification of the list. According to an embodiment, similar to the content described in connection with method 400, at least one processor may be configured to cryptographically (or digitally) sign the list by providing a cryptographic signature through a supervisory entity, thereby performing a first verification of the list. Next, the method proceeds to action S540.

[0096] In action S535, at least one processor may be configured to provide a failure notification to a user. According to an embodiment, the failure notification may indicate the type of quality check for which the received software element failed. For example, in the case where the received software element fails in a security check, at least one processor may be configured to provide a failure notification to the user indicating that the received software element failed in the security check. According to an embodiment, the failure notification may include any additional information associated with the failure, such as the inspection entity that performed the quality check, the specified quality gate, the standard used for the quality check, etc. Next, the method proceeds to action S536.

[0097] In action S536, at least one processor may be configured to append a previous version of the received software element to the build of the software. For example, during actions S520 and S530, the received software element failed a quality check, and therefore, at least one processor may determine that the received software element is of unacceptable quality to be included in the build of the software. Therefore, at least one processor may be configured to append a previous version of the received software element that is assumed to have passed the quality check to the build of the software. Next, the method proceeds to action S540.

[0098] In action S540, at least one processor may be configured to determine whether there are other software elements received from the user. Therefore, based on the determination that there are still software elements received from the user, the method returns to action S520 to perform a quality check on the remaining software elements received from the user. On the other hand, based on the determination that there are no other software elements received from the user, the method proceeds to action S550.

[0099] In action S550, at least one processor may be configured to build the software. According to an embodiment, at least one processor may be configured to build the software based on a plurality of software elements specified in a list, wherein the software elements include new versions of the software elements appended to the list and built during actions S532 and S533. For example, the software is composed of software element A version 1.0, software element B version 1.0, and software element C version 1.0 specified in the SBOM. For software element A version 1.1, which is a new version of software element A version 1.0, the software element A version 1.1 is received from the user during actions S510 to S534, and the software element A version 1.1 passes the quality check and is appended to the SBOM and built. At least one processor may be configured to use software element A version 1.1, software element B version 1.0, and software element C version 1.0 to build the software. Next, the method proceeds to action S560.

[0100] In action S560, at least one processor may be configured to perform a third verification of the build of the software. According to an embodiment, similar to the content recorded in connection with the first verification, at least one processor may be configured to: cryptographically (or digitally) sign the build of the software by providing an encrypted signature through the supervisory entity, thereby performing a third verification of the build of the software.

[0101] When performing act S560, method 500 may end or terminate. Alternatively, method 500 may return to act S510, as a result of which at least one processor may be configured to repeat the following process for a specified amount of time: (in act S510) receiving a software element; (in act S520) performing a quality check; (in act S530) determining whether the software element passes the quality check; (in act S531) performing a second validation of the software element; (in act S532) appending the software element to the build; (in act S533) appending the software element to the list; (in act S534) performing a first validation of the list; (in act S535) providing a failure notification to the user; (in act S536) appending a previous version of the software element to the build; (in act S540) determining whether there are other software elements received from the user; (in act S550) building the software; and (in act S560) performing a third validation of the build. For example, at least one processor may continuously (or periodically) receive updated versions of the same software elements associated with the same software and updated versions of software elements associated with different software.

[0102] Figure 6A flowchart of an exemplary method 600 for performing verification of software and software elements in accordance with one or more embodiments is shown. One or more actions of method 600 may be part of actions S410, S420, S430, and / or S440 in method 400, and may be performed by at least one processor (e.g., processor 220) of the SPL system.

[0103] like Figure 6 As shown, in action S610, at least one processor may be configured to receive at least one software element from a user. According to an embodiment, similar to action S410 in method 400, the received software element may be a new version of one of a plurality of software elements forming the software, and the user may refer to an entity such as an OEM and a tier supplier that owns the received software element. Next, the method proceeds to action S620.

[0104] In action S620, the at least one processor may be configured to send the received software element to an inspection entity. According to an embodiment, as described in relation to the method 400, the inspection entity may refer to an inspection entity located outside the SPL system.

[0105] It is to be understood that, similar to the content described for the inspection entity in the SPL system described in association with method 500, the inspection entity located outside the SPL system can perform a quality check on the received software element, determine whether the received software element passes the quality check, and perform a second verification of the received software element based on the type of quality check passed by the received software element. Next, the method proceeds to action S630.

[0106] In action S630, at least one processor may be configured to receive a result of quality checking the received software element from the inspection entity. According to an embodiment, in the case where the received software element passes the quality check, the result received from the inspection entity may indicate that the inspection entity has performed a second verification of the received software element based on the type of quality check passed by the received software element. For example, the result received from the inspection entity may include an encrypted signature obtained by the inspection entity that cryptographically signs the received software element, where the inclusion of the encrypted signature indicates that the inspection entity has cryptographically signed the received software element (i.e., performed a second verification of the received software element). According to an embodiment, in the case where the received software element fails in the quality check, the result received from the inspection entity may indicate that the received software element fails in the quality check. For example, the result received from the inspection entity may include a notification indicating that the received software element fails in the quality check. According to an embodiment, the result received from the inspection entity may include any additional information associated with the quality check, such as the inspection entity that performs the quality check, the specified quality gate, the standard used for the quality check, etc. Next, the method proceeds to action S640.

[0107] In action S640, the at least one processor may be configured to determine whether the received software element has passed the quality check. According to an embodiment, the at least one processor may be configured to determine whether the result received from the checking entity indicates that the checking entity has performed a second verification of the received software element, or indicates that the received software element has failed the quality check, thereby determining whether the received software element has passed the quality check.

[0108] Therefore, based on a determination that the received software element passes the quality check, the method proceeds to action S641. On the other hand, based on a determination that the received software element does not pass the quality check (failed), the method proceeds to action S644.

[0109] It is understandable that actions S641, S642, S643, S644, S645, S650, S660, and S670 in method 600 may be the same as actions S532, S533, S534, S535, S536, S540, S550, and S560 in method 500. Therefore, the description of this step is omitted.

[0110] Figure 7A flowchart of an exemplary method 700 for performing verification of software and software elements in accordance with one or more embodiments is shown. One or more actions of method 700 may be part of actions S410, S420, S430, and / or S440 in method 400, and may be performed by at least one processor (e.g., processor 220) of the SPL system.

[0111] like Figure 7 As shown, in action S710, at least one processor may be configured to receive at least one software element from a user. According to an embodiment, similar to action S410 in method 400, the received software element may be a new version of one of a plurality of software elements forming the software, and the user may refer to an entity such as an OEM and a tier supplier that owns the received software element. Next, the method proceeds to action S720.

[0112] In action S720, at least one processor may be configured to perform a quality check on the received software element. According to an embodiment, similar to the content of method 400, the quality check may refer to a process of checking whether the software element meets the standards for establishing the association, and may include one or more of a safety check, a security check, a performance check, a power consumption check, a source code check, etc. According to an embodiment, similar to the content of method 400, the quality check is performed by a check entity in the SPL system. Next, the method proceeds to action S730.

[0113] In action S730, at least one processor may be configured to determine whether the received software element has passed the quality check. According to an embodiment, similar to the content described in association with method 500, at least one processor may be configured to: determine whether the result of performing the quality check on the received software element meets a threshold, thereby determining whether the received software element has passed the quality check.

[0114] Therefore, based on the received determination that the software element passed the quality check, at least one processor may determine that the quality of the software element related to a particular type of quality check (e.g., safety, security, performance, power consumption, etc.) meets an acceptable level, and proceeds to action S731. On the other hand, based on the received determination that the software element did not pass the quality check (failed), at least one processor may determine that the quality of the software element related to the particular type of quality check does not meet an acceptable level, and proceeds to action S732.

[0115] In action S731, at least one processor may be configured to perform a second verification of the received software element based on the type of quality check that the received at least one software element has passed. According to an embodiment, as described above in association with method 400, performing a second verification of the received software element may refer to cryptographically signing the received software element by the checking entity, providing a cryptographic signature (or digital signature) in relation to a cryptographic hash of the received software element, and / or providing a cryptographic signature (or digital signature) in relation to the software element itself without hashing the software element. Next, the method proceeds to action S740.

[0116] In action S732, at least one processor may be configured to provide a failure notification to a user. According to an embodiment, the failure notification may indicate the type of quality check that the received software element failed, similar to what is described in connection with method 500. Next, the method proceeds to action S740.

[0117] In action S740, at least one processor may be configured to determine whether there are other quality checks to be performed on the received software element. According to an embodiment, in the case where the software element is specified to be subject to multiple types of quality checks (e.g., according to standards specified in an entity and / or industry involved in the production of the software), at least one processor may perform a check for each quality check separately during action S730, and may proceed to action S731 or action S732 for each quality check.

[0118] Therefore, based on the determination that there is still a quality check to be performed on the received software element, the method returns to action S730 to perform the additional quality check. On the other hand, based on the determination that there is no other quality check to be performed on the received software element, the method proceeds to action S750.

[0119] Considering the above process, for example, where a software element is specified to undergo a safety check, a security check, and a performance check, and where the software element passes the safety check, passes the security check, but fails the performance check, the software element includes two cryptographic signatures (obtained from the same checking entity or a different checking entity that cryptographically signed the software element) indicating that the software element passed the safety check and the security check during action S731. Furthermore, the SPL system provides a failure notification to the user during action S732 indicating that the software element failed the performance check. Next, the method proceeds to action S750.

[0120] In action S750, the at least one processor may be configured to append the received software element to the software build, similar to what was described in connection with method 500. Next, the method proceeds to action S760.

[0121] In action S760, at least one processor may be configured to determine whether the received software element passes all specified quality checks. Thus, based on a determination that the received software element passes all specified quality checks, the method proceeds to action S761. On the other hand, based on a determination that the received software element does not pass all specified quality checks, the method proceeds to action S770.

[0122] In action S770, the at least one processor may be configured to determine whether the received software element has at least one dependent software element that should be subject to a quality check. According to an embodiment, the at least one processor may be configured to determine whether the received software element has at least one dependent software element that should be subject to a quality check based on the type of quality check that the received software element failed.

[0123] According to an embodiment, a dependent software element may refer to a software element among a plurality of software elements specified in a list that form the software and is a software element that is dependent on another software element. According to an embodiment, the dependent software element may be specified according to a standard specified in an entity and / or industry involved in the production of the software so that, in the event that a software element on which the dependent software element depends fails in a specific quality check, the dependent software element is subjected to a specific quality check or all quality checks.

[0124] For example, software element B may sometimes be required to meet a performance check, and sometimes have previously been subject to and passed the performance check. However, the performance of software element B may be dependent on the performance of another software element A. In this regard, in the case where a new version of software element A is received from a user during action S710, and during actions S720 and S730, the new version of software element A fails the performance check, in the case where the new version of software element A is combined with the build and software element A is made in a way that software element B is dependent on the new version of software element A, software element B (which is dependent on software element A) sometimes no longer meets the performance check of software element B. Therefore, in the case where software element A fails in its performance check, software element B may be specified to undergo a performance check. Moreover, it is understood that in the case where software element A passes the performance check, software element B sometimes does not need to undergo a quality check even if software element A fails in another quality check (e.g., a security check).

[0125] According to an embodiment, at least one processor may be configured to determine whether the received software element has at least one dependent software element that should be subject to quality checks, as long as the received software element fails at least one of the specified quality checks. For example, the dependent software element may be specified according to a standard specified in an entity and / or industry involved in the production of the software as always subjecting the dependent software element to a specific quality check or all quality checks if the software element on which the dependent software element depends fails in any quality check. It is understood that in such a case, action S760 may be skipped.

[0126] Therefore, based on determining that the received software element has at least one dependent software element that should be subject to quality inspection, the method returns to action S720 to perform the quality inspection on the dependent software element. On the other hand, based on determining that the received software element does not have a dependent software element that should be subject to quality inspection, the method proceeds to action S763. It can be understood that in the case where the software element does not have any dependent software element, the method can proceed to action S763.

[0127] It is understandable that actions S761, S762, S763, S780, and S790 in method 700 may be the same as actions S533, S534, S540, S550, and S560 in method 500. Therefore, the description of this step is omitted.

[0128] Understandably, Figure 5 to Figure 7 The illustrated configurations are simplified for the purpose of illustration and are not intended to limit the scope of the present disclosure. Specifically, in practice, various solutions of the methods 500, 600, and 700 may be combined or interchanged with each other.

[0129] For example, a software element in the software can be checked by a check entity in the SPL as described in method 500, and another software element in the same software can be checked by a check entity located outside the SPL as described in the system of method 600. Similarly, a certain type of quality check related to the software can be performed by a check entity in the SPL as described in method 500, and other types of quality checks related to the same software element can be checked by a check entity located outside the SPL system as described in method 600.

[0130] As another example, method 700 is recorded using action S720 for performing quality inspection on received software elements, but method 700 can be modified instead to send the received software elements to an external inspection entity and receive results from the external inspection entity, as described during actions S620 and S630 in method 600.

[0131] In addition, as described in connection with method 400, at least one processor can be configured to generate a new version of the list, which specifies multiple software elements specified in the previous version of the list together with the received software element. In this regard, methods 500, 600, and 700 record that the list can be generated continuously (where each of the new versions associated with each of the software elements is progressively appended to the list), but the list can also be generated in parallel (where each of the new versions associated with each of the software elements is individually appended to the list). Moreover, each of the new versions of the list can be signed and can be appended to another list signed in the same manner.

[0132] It is understood that when software and SBOM (e.g., list) are generated according to the processes in methods 500, 600, and 700, the software and SBOM can be provided to a user (e.g., OEM, tier supplier, etc.), as a result, the user can verify and utilize the software. Similarly, a product utilizing the software can also include the software itself and the SBOM, as a result, the seller and buyer of the product can verify and utilize the product.

[0133] Moreover, it will be appreciated that the public keys and cryptographic signatures for the inspection entity and the oversight entity may be provided to a public repository, with the result that end users (e.g., OEMs, tier suppliers, product sellers, product purchasers, etc.) can verify that the cryptographic signatures provided in association with the SBOM are valid.

[0134] It can be appreciated that, as described according to the processes in methods 500 , 600 , and 700 , the generated list (eg, SBOM) and software can provide software (supply) chain security and can have the following advantages.

[0135] All new versions of all software elements that pass quality checks are appended to the SBOM (and subsequently signed with a cryptographic signature), so the above method allows for incremental updates and improvements to the software over time while ensuring that appropriate quality requirements are still met.

[0136] In particular, for example, in the case where any of the software elements contains an error or is in a damaged state, or an attacker adds a malicious software element to the software to form the software (and a final product that subsequently uses the software), such a problem can be detected, and the SBOM of the software using such a damaged software element is sometimes not signed. Therefore, the end user (the seller of the product using the software, the purchaser of the product, etc.) can determine that the software using such a damaged software element is not suitable for use by checking that the corresponding SBOM is not signed (or there is no SBOM signed for the software). Therefore, the above process can detect a malicious problem or abnormal problem in the software, and the SBOM generated according to the above process provides a method (provable by the user) for making a specific certificate in a manner related to the quality, security, and compliance of the software in the centralized system with respect to any specific standard.

[0137] Furthermore, the SBOM generated according to the above process can indicate which software elements (and versions) have passed quality checks, what quality checks have been passed, and who is the entity that certified the pass, and thus, the SBOM can be used to identify responsibilities and obligations associated with inspection entities and supervisory entities.

[0138] Moreover, the SBOM generated according to the above process can indicate which version of the software element has passed the quality check and whether the quality check is provided to the test product or the final product. The SBOM can be used to identify whether the software is suitable for the product (for example, in the case where the product is a final product released to consumers, the quality check of the software element should be for the final product, not for testing).

[0139] Furthermore, the SBOM generated according to the above process can also perform: dynamic management of dependent software elements; dynamic management of quality gates required for production of SDKs; time-based progress of software component sources, dependencies, and quality gates; automatic real-time feedback related to the status of passing quality checks: obtaining past status related to the combination of software elements from a data store; items of manual checks related to the results are verified by humans; the SBOM functions as a monitorable unit for verifying files that are part of a release; use of cryptographic signatures for verifying the passing of quality checks and the overall quality of the software; use of a public repository for entities to verify signatures and the time when the release content was signed; vendors, external auditors, or other third parties build software with the same end result; classes of end users such as auditors verify the content and testing performed on a specific software package through a reproducible method; and software is automatically managed via signatures, whereby the SBOM can perform restrictions, revocations, or authorizations related to the use of the software.

[0140] Example Installation Environment

[0141] Figure 8 FIG. 8 is a diagram showing an exemplary environment 800 in which the systems and / or methods described herein may be implemented. Figure 8 As shown, environment 800 may include device 810, platform 820, and network 830. The devices of environment 800 may be connected to each other via wired connections, wireless connections, or a combination of wired and wireless connections. Figure 1 to Figure 7 Any of the functions and actions recorded can be Figure 8 The above-mentioned elements can be combined in any way.

[0142] According to an embodiment, the SPL system described in this specification may be stored, hosted or deployed in a cloud computing platform 820. In this regard, the device 810 may include a device, system, equipment or equivalent utilized by a user (e.g., a user of a marketing team, a user of a network planning team, etc.) to access the SPL system. In this case, the device 810 may include one or more devices capable of receiving, generating, storing, processing and / or providing information associated with the platform 820.

[0143] The platform 820 includes one or more devices that can receive, generate, store, process and / or provide information. In some implementations, the platform 820 may include a cloud server or a group of cloud servers. In some implementations, the platform 820 may be designed to be modular so that specific software components can be swapped in or out according to specific needs. Therefore, the platform 820 can be easily and / or quickly reconfigured for a variety of uses.

[0144] In some implementations, as shown, the platform 820 can be hosted in a cloud computing environment 822. In particular, in the implementations described in this specification, the platform 820 is described as being hosted in the cloud computing environment 822, but in some implementations, the platform 820 may not be cloud-based (i.e., may be implemented outside of the cloud computing environment), or may be partially cloud-based.

[0145] Cloud computing environment 822 includes an environment hosting platform 820. Cloud computing environment 822 can provide computing, software, data access, storage, etc. services that do not require knowledge by an end user (e.g., user device 810) regarding the physical location and configuration of the systems and / or devices hosting platform 820. As shown, cloud computing environment 822 can include a group of computing resources 824 (collectively referred to as "computing resources 824" or individually referred to as "computing resource 824").

[0146] The computing resources 824 include one or more personal computers, computing device clusters, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computing resources 824 can host the platform 820. Cloud resources may include computing instances executed in the computing resources 824, storage devices provided in the computing resources 824, data transmission devices provided by the computing resources 824, etc. In some implementations, the computing resources 824 can communicate with other computing resources 824 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0147] like Figure 8As further shown in , computing resources 824 include a group of cloud resources, such as one or more applications ("APPs") 824-1, one or more virtual machines ("VMs") 824-2, virtual storage ("VSs") 824-3, one or more hypervisors ("HYPs") 824-4, or equivalents. The exemplary embodiment refers to virtualized network functions, but it is understood that one or more other embodiments are not limited thereto, and they can be implemented in at least one of containers, cloud native services, one or more container platforms, etc. For example, in one or more other exemplary embodiments, any one of the above-mentioned components can be a software-based component deployed or hosted in a server cluster, such as a hybrid cloud server, a data center server, and the like. The software-based component can be containerized and can be deployed and controlled by one or more machines called "nodes", which start or execute containerized network elements and are addressable. In this regard, the server cluster may include at least one master node and multiple worker nodes, and the master node controls and manages a group of associated worker nodes.

[0148] Applications (APPs) 824-1 include one or more software applications that can be provided or accessed through the user device 810. Applications 824-1 can eliminate the need to install and execute software applications in the user device 810. For example, applications 824-1 can include software that can be provided via the cloud computing environment 822, associated with the platform 820, and / or any other software. In some implementations, an application 824-1 can send information to / receive information from one or more other applications 824-1 via a virtual machine 824-2.

[0149] Virtual machines (VMs) 824-2 include software implementations of machines (e.g., computers) that execute programs like physical machines. Depending on the use of the virtual machine 824-2 and the correspondence of the virtual machine 824-2 to any real machine, the virtual machine 824-2 can be either a system virtual machine or a process virtual machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system ("OS": operating system). A process virtual machine can execute a single program and can support a single process. In some implementations, the virtual machine 824-2 can execute on behalf of a user (e.g., a user device 810) and can manage the infrastructure of the cloud computing environment 822, such as data management, synchronization, or long-term data transfer.

[0150] Virtualized storage (VSs) 824-3 includes one or more storage systems and / or one or more devices using virtualization technology within the storage system or device of the computing resource 824. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage so that the storage system can be accessed independently of the physical storage or heterogeneous structure. Separation can make the administrator of the storage system flexible in terms of the way the administrator manages the storage for end users. File virtualization can eliminate the dependency between data accessed at the file level and the place where the file is physically stored. This can optimize storage usage, consolidate servers and / or perform non-disruptive file migration.

[0151] Hypervisors (HYPs) 824-4 may provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host computer such as computing resource 824. Hypervisors 824-4 may provide a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0152] The network 830 may include more than one wired and / or wireless network. For example, the network 830 may include: a cellular network (e.g., a 5G (fifth generation mobile communication technology) network, a long-term evolution (LTE: long-term evolution) network, a 3G (third generation mobile communication technology) network, a code division multiple access (CDMA: Code Division Multiple Access) network, etc.), a public land mobile network (PLMN: Public Land Mobile Network), a local area network (LAN: Local Area Network), a wide area network (WAN: Wide Area Network), a metropolitan area network (MAN: Metropolitan Area Network), a telephone network (e.g., a public switched telephone network (PSTN: Public Switched Telephone Network)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network or an equivalent and / or a combination of these types or other types of networks.

[0153] supply Figure 8 The number and configuration of devices and networks shown are examples. Figure 8 There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently configured devices and / or networks than those shown. Figure 8 Two or more of the devices shown may be implemented in a single device, or Figure 8 The single device shown may be implemented as multiple discrete devices. Additionally or alternatively, one set of devices (eg, more than one device) of environment 800 may perform one or more functions that are documented as being performed by another set of devices of environment 800.

[0154] Various options for implementation

[0155] The above disclosure provides examples and illustrations, but is not intended to be exhaustive, nor is it intended to limit the implementations to the precise forms disclosed. Modifications and variations may be made in light of the present disclosure or may be learned from practicing the implementations.

[0156] Some embodiments may involve systems, methods and / or computer-readable media at any possible level of technical detail of the integration. Moreover, one or more of the above-mentioned constituent elements may be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium(s)) having computer-readable program instructions that cause the processor to perform actions.

[0157] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above devices, but is not limited to these. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely: portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), portable compact disc read-only memories (CD-ROM), digital versatile discs (DVD), memory sticks, floppy disks, punched cards with instructions recorded or mechanically encoded devices such as raised structures in grooves, and any suitable combination of the above. The computer-readable storage medium used in this specification should not be interpreted as a temporary signal itself such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (for example, a light pulse through an optical cable), or an electrical signal sent through a wire.

[0158] The computer-readable program instructions recorded in this specification can be downloaded from a computer-readable storage medium to a respective computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can have copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to be stored in a computer-readable storage medium in the respective computing / processing device.

[0159] The computer readable program code / instructions for performing the actions may be source code or object code written in assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++ or similar languages, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, may be executed partially on the user's computer, may be executed as a stand-alone software package, may be executed partially on the user's computer and partially on a remote computer, or may be executed entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer may be made (e.g., using an Internet service provider and thereby via the Internet). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may utilize state information of computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions to perform a scheme or action.

[0160] The computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device in order to generate a machine, with the result that the instructions executed by the processor of the computer or other programmable data processing device generate a component that implements the function / behavior specified in the functional block or functional blocks (multiple) of the flowchart and / or block diagram. The computer-readable program instructions may also be stored in a computer-readable storage medium, wherein the computer-readable storage medium may instruct a computer, a programmable data processing device, and / or other equipment to function in a specific manner, with the result that the computer-readable storage medium having the instructions stored therein has a product, which includes instructions for implementing the scheme of the function / behavior specified in the functional block or functional blocks (multiple) of the flowchart and / or block diagram.

[0161] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, and perform a series of action steps on the computer, other programmable apparatus, or other device to generate a computer-implemented process, as a result of which the instructions executed on the computer, other programmable apparatus, or other device implement the functions / behaviors specified in the functional box or functional boxes (multiple) in the flowchart and / or block diagram.

[0162] The flowcharts and block diagrams in the figure show the architecture, functions and actions of possible implementations of the systems, methods and computer-readable media of various embodiments. In this regard, each functional block in the flowchart or block diagram may represent a part of a microservice module, segment or instruction with one or more executable instructions that implement the specified logical function. The method, computer system and computer-readable medium may include additional functional blocks, fewer functional blocks, different functional blocks or functional blocks of different configurations compared to those depicted in the accompanying drawings. In a partially replaced implementation, the functions recorded in the functional blocks may be generated independently of the order recorded in the figure. For example, two functional blocks shown in succession may be executed in fact or substantially at the same time, or the functional blocks may be executed in reverse order according to the associated functions. It should be noted that each functional block of the block diagram and / or flowchart, and the combination of functional blocks of the block diagram and / or flowchart can be implemented by a dedicated hardware-based system, wherein the system performs a specified function or behavior, or executes a combination of dedicated hardware and computer instructions.

[0163] It is apparent that the systems and / or methods described in this specification may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method is not limited to more than one implementation. Therefore, it is understood that the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and the software and hardware may be designed to implement the system and / or method based on the description of this specification.

[0164] Various further aspects and features of the embodiments of the present disclosure can be specified by the following items.

[0165] Item [1]: A system may include: a storage device storing computer executable instructions; and at least one processor communicatively connected to the storage device, wherein the at least one processor may be configured to execute the instructions to perform the following processing: receiving at least one software element from a user, wherein the received at least one software element is a new version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element has passed a quality check; and in response to a determination that the received at least one software element has passed the quality check, appending the received software element to the list and performing a first verification of the list, wherein each of the plurality of software elements specified in the list includes: one or more indications of the type of quality check passed by each of the plurality of software elements in the list.

[0166] Item [2]: In the system according to Item [1], the quality check may include one or more of a safety check, a security check, a performance check, and a power consumption check.

[0167] Item [3]: According to the system described in any one of items [1] to [2], the one or more instructions may include an encrypted signature obtained by encrypting each of the multiple software elements specified in the list, and the encrypted signature may represent the entity responsible for performing the quality check of the type passed by each of the multiple software elements in the list.

[0168] Item [4]: ​​According to the system described in any one of Items [1] to [3], the at least one processor can also be configured to execute the instructions to perform the following processing: perform the quality check on the at least one received software element, and based on the type of the quality check passed by the at least one received software element, perform a second verification of the at least one received software element. The at least one processor can be configured to execute the instructions to perform the following processing: determine whether the result of the quality check on the at least one received software element meets a threshold, thereby determining whether the at least one received software element has passed the quality check.

[0169] Item [5]: In the system of Item [4], the threshold may include a quality gate, which may specify a level of quality that the received at least one software element should meet.

[0170] Item [6]: According to the system described in any one of Items [1] to [5], the at least one processor can also be configured to execute the instructions to perform the following processing: sending the received at least one software element to an inspection entity, and receiving the result of the quality check of the received at least one software element from the inspection entity, and the at least one processor can be configured to execute the instructions to perform the following processing: based on the type of the quality check passed by the received at least one software element from the inspection entity, determining whether the received result indicates that the inspection entity has performed a second verification of the received at least one software element, thereby determining whether the received at least one software element has passed the quality check.

[0171] Item [7]: In the system described in any one of Items [1] to [6], the list may include a software bill of materials (SBOM).

[0172] Item [8]: According to the system described in any one of Items [1] to [7], the at least one processor can also be configured to execute the instructions to perform the following processing: in response to a determination that the at least one received software element fails the quality check, provide a failure notification to the user, and the failure notification can indicate the type of the quality check in which the at least one received software element fails.

[0173] Item [9]: According to the system described in any one of Items [1] to [8], the at least one processor can also be configured to execute the instructions to perform the following processing: in response to a determination that the at least one received software element fails the quality check, based on the type of the quality check in which the at least one received software element fails, determine whether the at least one received software element has at least one dependent software element that should be subject to the quality check, wherein the at least one dependent software element may be at least one software element among the multiple software elements that depend on the at least one received software element; and in response to a determination that the at least one received software element has at least one dependent software element that should be subject to the quality check, perform the quality check on the at least one dependent software element.

[0174] Item

[10] : According to the system described in any one of items [1] to [9], the at least one processor can be configured to execute the instructions to perform the following processing: perform the first verification of the list by cryptographically signing the list.

[0175] Item

[11] : A method may include: receiving at least one software element from a user, wherein the received at least one software element is a new version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element has passed a quality check; and in response to a determination that the received at least one software element has passed the quality check, appending the received software element to the list and performing a first verification of the list, wherein each of the plurality of software elements specified in the list includes: one or more indications of the type of quality check passed by each of the plurality of software elements in the list.

[0176] Item

[12] : According to the method described in Item

[11] , the quality check may include one or more of a safety check, a security check, a performance check, and a power consumption check.

[0177] Item

[13] : According to the method described in any one of items

[11] to

[12] , the one or more indications may include an encrypted signature obtained by encrypting each of the multiple software elements specified in the list, and the encrypted signature may represent the entity responsible for the type of quality check passed by each of the multiple software elements in the list.

[0178] Item

[14] : The method according to any one of items

[11] to

[13] may also include: performing the quality check on the at least one received software element; and performing a second verification of the at least one received software element based on the type of the quality check passed by the at least one received software element, and the determination related to whether the at least one received software element has passed the quality check may include: determining whether the result of the quality check on the at least one received software element meets a threshold.

[0179] Item

[15] : According to the method described in Item

[14] , the threshold may include a quality gate, which may specify a level of quality that the at least one received software element should meet.

[0180] Item

[16] : The method according to any one of items

[11] to

[15] may also include: sending the at least one received software element to an inspection entity; and receiving the result of the quality check on the at least one received software element from the inspection entity, and the determination related to whether the at least one received software element has passed the quality check includes: determining whether the received result indicates that the inspection entity has performed a second verification of the at least one received software element based on the type of the quality check passed by the at least one received software element from the inspection entity.

[0181] Item

[17] : According to the method described in any one of items

[11] to

[16] , the list may include a software bill of materials (SBOM).

[0182] Item

[18] : The method according to any one of Items

[11] to

[17] may also include: in response to determining that at least one received software element has failed the quality check, providing a failure notification to the user, wherein the failure notification may indicate the type of the quality check in which the at least one received software element has failed.

[0183] Item

[19] : The method according to any one of Items

[11] to

[18] may also include: in response to a determination that the at least one received software element fails the quality check, based on the type of the quality check in which the at least one received software element fails, determining whether the at least one received software element has at least one dependent software element that should be subject to the quality check, wherein the at least one dependent software element may be at least one software element among the multiple software elements that depend on the at least one received software element; and in response to a determination that the at least one received software element has at least one dependent software element that should be subject to the quality check, performing the quality check on the at least one dependent software element.

[0184] Item

[20] : According to the method described in any one of items

[11] to

[19] , performing the first verification of the list may include: cryptographically signing the list.

[0185] It is understandable that many modifications and variations of the present disclosure can be made in light of the above teachings. It is obvious that within the scope of the appended clauses, the present disclosure can be implemented in a manner different from that specifically described in this specification.

Claims

1. A system for verifying software, comprising: a storage memory storing computer executable instructions; and at least one processor communicatively connected to the storage memory, The at least one processor is configured to execute the instructions to perform the following processing: receiving at least one software element from a user, wherein: The received at least one software element is a new version of at least one of the plurality of software elements specified in the list; determining whether the received at least one software element passes a quality check; as well as In response to a determination that the received at least one software element passes the quality check, appending the received software element to the list and performing a first validation of the list, Each of the plurality of software elements specified in the list includes one or more indications of a type of the quality check passed by each of the plurality of software elements in the list.

2. The system for performing software verification according to claim 1, wherein: The quality inspection includes at least one of a safety inspection, a security inspection, a performance inspection, and a power consumption inspection.

3. The system for performing software verification according to claim 1 or 2, wherein: The one or more instructions include an encrypted signature obtained by cryptographically signing each of the plurality of software elements specified in the list, The cryptographic signature indicates an entity tasked with performing the quality check of the type passed by each of the plurality of software elements in the list.

4. The system for verifying software according to any one of claims 1 to 3, wherein: The at least one processor is further configured to execute the instructions to perform the following processing: performing said quality check on said received at least one software element, and performing a second verification of the at least one received software element based on the type of the quality check passed by the at least one received software element, The at least one processor is configured to execute the instructions to perform the following processing: determine whether a result of performing the quality check on the at least one received software element meets a threshold, thereby determining whether the at least one received software element passes the quality check.

5. The system for performing software verification according to claim 4, wherein: The threshold has a quality gate, The quality gate specifies a level of quality that the received at least one software element should meet.

6. The system for performing software verification according to any one of claims 1 to 5, wherein: The at least one processor is further configured to execute the instructions to perform the following processing: sending said received at least one software element to an inspection entity, and receiving from the checking entity a result of performing the quality check on the received at least one software element, The at least one processor is configured to execute the instructions to perform the following processing: based on the type of the quality check passed by the at least one received software element from the inspection entity, determine whether the received result indicates that the inspection entity performed a second verification of the at least one received software element, thereby determining whether the at least one received software element passed the quality check.

7. The system for verifying software according to any one of claims 1 to 6, wherein: The list has a software bill of materials SBOM.

8. The system for performing software verification according to any one of claims 1 to 7, wherein: The at least one processor is further configured to execute the instructions to perform the following processing: in response to a determination that the at least one received software element fails the quality check, provide a failure notification to the user, the failure notification indicating a type of the quality check that the at least one received software element fails.

9. The system for verifying software according to any one of claims 1 to 8, wherein: The at least one processor is further configured to execute the instructions to perform the following processing: In response to a determination that the at least one received software element fails the quality check, determining whether the at least one received software element has at least one dependent software element that should be subject to the quality check based on a type of the quality check that the at least one received software element fails, wherein the at least one dependent software element is at least one software element of the plurality of software elements that is dependent on the at least one received software element; and In response to a determination that the received at least one software element has at least one dependent software element that should be subject to the quality check, the quality check is performed on the at least one dependent software element.

10. The system for verifying software according to any one of claims 1 to 9, wherein: The at least one processor is configured to execute the instructions to perform the following processing: performing the first verification of the list by cryptographically signing the list.

11. A method for verifying software, comprising: receiving at least one software element from a user, wherein the received at least one software element is a new version of at least one of the plurality of software elements specified in the list; determining whether the received at least one software element passes a quality check; and In response to a determination that the received at least one software element passes the quality check, appending the received software element to the list and performing a first validation of the list, Each of the plurality of software elements specified in the list includes one or more indications of a type of the quality check passed by each of the plurality of software elements in the list.

12. The method for verifying software according to claim 11, wherein: The quality inspection includes at least one of a safety inspection, a security inspection, a performance inspection, and a power consumption inspection.

13. The method for verifying software according to claim 11 or 12, wherein: The one or more instructions include an encrypted signature obtained by cryptographically signing each of the plurality of software elements specified in the list, The cryptographic signature indicates an entity tasked with performing the quality check of the type passed by each of the plurality of software elements in the list.

14. The method for verifying software according to any one of claims 11 to 13, further comprising: Performing the quality check on the received at least one software element; as well as performing a second verification of the at least one received software element based on the type of the quality check passed by the at least one received software element, Determining whether the received at least one software element passes the quality check includes determining whether a result of performing the quality check on the received at least one software element satisfies a threshold.

15. The method for verifying software according to claim 14, wherein: The threshold has a quality gate, The quality gate specifies a level of quality that the received at least one software element should meet.

16. The method for verifying software according to any one of claims 11 to 15, further comprising: sending said received at least one software element to an inspection entity; as well as receiving from the checking entity a result of performing the quality check on the received at least one software element, Determining whether the at least one received software element has passed the quality check includes: based on the type of the quality check passed by the at least one received software element from the inspection entity, determining whether the received result indicates that the inspection entity has performed a second verification of the at least one received software element.

17. The method for verifying software according to any one of claims 11 to 16, wherein: The list has a software bill of materials SBOM.

18. The method for verifying software according to any one of claims 11 to 17, further comprising: In response to a determination that the at least one received software element fails the quality check, a failure notification is provided to the user, the failure notification indicating a type of the quality check that the at least one received software element fails.

19. The method for verifying software according to any one of claims 11 to 18, wherein: Also includes: In response to a determination that the at least one received software element fails the quality check, determining whether the at least one received software element has at least one dependent software element that should be subject to the quality check based on a type of the quality check that the at least one received software element fails, wherein the at least one dependent software element is at least one software element of the plurality of software elements that is dependent on the at least one received software element; as well as In response to a determination that the received at least one software element has at least one dependent software element that should be subject to the quality check, the quality check is performed on the at least one dependent software element.

20. The method for verifying software according to any one of claims 11 to 19, wherein: Performing the first verification of the list includes cryptographically signing the list.

Images