System and method for software verification

Abstract

To provide a system.SOLUTION: A system, method, and device for performing system verification are provided. According to an embodiment, the system may include a memory storage for storing a computer-executable instruction, and at least one processor connected to the memory storage in a communicative manner, where the at least one processor may be configured to execute an instruction to receive at least one software element from a user, to determine whether the received at least one software element passes a quality check, to add the received software element to a list based on the determination that the at least one received software element passes the quality check, and to perform first verification of the list, where each of the multiple software elements specified in the list includes one or more instructions indicating the type of quality check that each of the software elements in the list passes.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] Systems, methods, and computer programs consistent with example embodiments of the present disclosure relate to software security, and more particularly, to dynamic verification of software. [Background technology]

[0002] A software production line (SPL) refers to a software automation system that comprises a set of processes, automation, and orchestrated tools that enable its users (e.g., stakeholders and partners (OEMs and suppliers)) to continuously build, test, and deliver a software stack. For example, an SPL for vehicle software enables its users to build, test, and deliver a vehicle software stack for the electronic control units (ECUs) and microcontrollers (MCUs) in a vehicle. A software "production line," as the name suggests, is similar to a manufacturing production line, where physical parts from suppliers are provided to the production line and assembled into a final product as automatically as possible.

[0003] The basic building blocks in a software production line are software elements. A software element may point to a source code repository with a specific configuration. A software element may be defined via a configuration file specified by the software production line. A software element may be used to assemble a software development kit (SDK), which is a special type of software element that contains other software elements (similar to a physical assembly that contains other physical parts). Thus, software elements may have dependencies on each other and may be used in a vehicle and its variants through configuration, and software may be built (compiled) to target a vehicle and its variants.

[0004] SPL provides tools for building, testing, and packaging such software elements, as well as dependency management for such software elements. SPL can be used in vehicles, smartphones, IoT, and any entity that requires certain verifiable and provable assurances as part of its creation.

[0005] In fact, the SDK and software build for an ECU may be created from many different combinations of different software elements that must meet a wide variety of safety and security requirements, and each of the software elements that make up the SDK and software build must be tested both independently and as part of a 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] Exemplary embodiments of the present disclosure automatically and dynamically validate software based on the results of quality checks performed on the software elements that make up the software, thus enabling incremental updates and improvements to the software over time while ensuring that appropriate quality requirements are still met.

[0008] According to an embodiment, a system is provided that may include a memory storage that stores computer-executable instructions and at least one processor communicatively coupled to the memory storage, where the at least one processor may be configured to execute the instructions to: receive at least one software element from a user, where the received at least one software element is a newer version of at least one of a plurality of software elements specified in a list; determine 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, add the received software element to the list and perform a first validation of the list, where each of the plurality of software elements specified in the list includes one or more indications of types of quality checks that the respective software element of the plurality of software elements in the list passes.

[0009] According to an embodiment, a method is provided that may include receiving at least one software element from a user, where the received at least one software element is a newer version of at least one of a plurality of software elements specified in a list, determining whether the received at least one software element passes a quality check, and in response to determining that the received at least one software element passes the quality check, adding the received software element to a list and performing a first validation of the list, where each of the plurality of software elements specified in the list includes one or more indications of types of quality checks that the respective software element of the plurality of software elements in the list passes.

[0010] Additional aspects will be set forth in part in the description that follows, and in part will be obvious from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0011] The features, advantages, and importance of preferred embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals refer to like elements, and in which: [Figure 1] FIG. 1 illustrates a block diagram of an exemplary system configuration for software validation according to one or more embodiments. [Figure 2] FIG. 2 shows a block diagram of exemplary components of an SPL system according to one or more embodiments. [Figure 3] FIG. 3 illustrates a block diagram of an exemplary system configuration for software validation according to one or more embodiments. [Figure 4] FIG. 4 illustrates a flow diagram of an exemplary method for software validation according to one or more embodiments. [Figure 5] FIG. 5 illustrates a flow diagram of a first exemplary method for verifying software and software elements according to one or more embodiments. [Figure 6] FIG. 6 illustrates a flow diagram of a second exemplary method for verifying software and software elements according to one or more embodiments. [Figure 7] FIG. 7 illustrates a flow diagram of a third exemplary method for verifying software and software elements according to one or more embodiments. [Figure 8] FIG. 8 illustrates a diagram of an example environment in which the systems and / or methods described herein may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0012] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in different drawings may identify the same or similar elements.

[0013] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, or the order of one or more operations may be switched.

[0014] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual specialized control hardware or software code used to implement the systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0015] Although particular combinations of features are disclosed herein, such combinations are not intended to limit the disclosure of possible implementations, and in fact many of the features can be combined in ways not specifically disclosed herein.

[0016] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0017] Exemplary embodiments of the present disclosure provide systems, methods, devices, and the like for automatically and dynamically validating software based on the results of quality checks performed on software elements that make up the software.

[0018] According to an embodiment, the system may receive a new version of a software element that together with other software elements forms software, determine whether the received software element passes a quality check, and, in response to a determination that the received software element passes the quality check, add the received software element to a list and validate the list.

[0019] Finally, exemplary embodiments of the present disclosure automatically and dynamically validate software based on the results of quality checks performed on the software elements that make up the software, which allows for incremental updates and improvements to the software over time while ensuring that appropriate quality requirements are still met.

[0020] It is envisioned that the features, advantages, and importance of the exemplary embodiments described herein above are merely part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure.

[0021] Further description regarding the features, components, configuration, operation, and implementation aspects of the threshold adjustment system of the present disclosure, according to one or more embodiments, is provided below.

[0022] Exemplary System Architecture 1 illustrates a block diagram of an exemplary system configuration 100 for performing software validation, according to one or more embodiments. As shown in FIG. 1, the system configuration 100 may include a user 110 and a software production line (SPL) system 120.

[0023] Users 110 may include entities that participate in the production of software and provide at least one software element that forms the software, such as original product manufacturers, tier suppliers, etc. Users 110 may be communicatively connected to SPL system 120. In some implementations, users 110 may provide software elements to SPL system 120 and receive software builds, software bills of materials, etc. from SPL system 120.

[0024] SPL system 120 may include a system, platform, module, or the like that may be configured to perform one or more operations or actions that perform software validation. SPL system 120 may be a software automation system that comprises a set of processes, automation, and orchestrated tools that enable its users (e.g., stakeholders and partners (OEMs and suppliers)) to continuously build, test, and deliver vehicle software stacks to key electronic control units (ECUs) and microcontrollers (MCUs) in vehicles.

[0025] Exemplary operations that may be performed by SPL system 120 to perform software validation are described below with reference to Figures 4-7. Additionally, some exemplary components that may be included in SPL system 120, according to one or more embodiments, are described below with reference to Figures 2-3.

[0026] 2 shows a block diagram of exemplary components in an SPL system 200, according to one or more embodiments. SPL system 200 may correspond to SPL system 120 of FIG. 1, and therefore features associated with SPL system 120 and SPL system 200 may be equally applicable to one another unless expressly stated otherwise.

[0027] As shown in FIG. 2, 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, although it may be understood that SPL system 200 may include more or fewer components than those shown in FIG. 2 and / or may be arranged differently than those shown in FIG. 2 without departing from the scope of the present disclosure.

[0028] Communications interface 210 may include at least one transceiver-like component (e.g., a transceiver, separate receivers and transmitters, a bus, etc.) that enables components of SPL system 200 to communicate with each other and / or with one or more components external to SPL system 200, such as via wired connections, wireless connections, or a combination of wired and wireless connections.

[0029] For example, communication interface 210 may connect processor 220 to storage 240, thereby allowing them to communicate with and interoperate with each other in performing one or more operations. As another example, communication interface 210 may connect SPL system 200 (or one or more components included therein) to a device of user 110, allowing them to communicate with and interoperate with each other.

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

[0031] Input / output section 230 may include at least one component that enables SPL system 200 to receive information and / or provide output information. In some embodiments, input / output section 230 may include at least one input component (e.g., a touchscreen 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 (LEDs), etc.), each of which may be understood to be separate from one another.

[0032] Storage 240 may include one or more storage media suitable for storing data, information, and / or computer-executable instructions therein. According to an embodiment, storage 240 may include at least one memory storage, such as random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory), that stores information and / or instructions for use by processor 220. Additionally or alternatively, storage 240 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), compact disk (CD), digital versatile disk (DVD), floppy disk, cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0033] According to an embodiment, storage 240 may be configured to store information such as raw data, metadata, or the like. Additionally or alternatively, storage 240 may be configured to store one or more pieces of information associated with one or more actions performed by processor 220. For example, storage 240 may store information defining historical actions performed by processor 220 to perform software validation, one or more results of actions performed by processor 220, or the like. Furthermore, storage 240 may store data or information required in performing software validation.

[0034] In some implementations, storage 240 may include multiple storage media and may be configured to store duplicates or copies of at least some of the information on the multiple storage media to provide redundancy and to back up the information or associated data. Additionally, storage 240 may also store computer-readable or computer-executable instructions that, when executed by one or more processors (e.g., processor 220), cause the one or more processors to perform one or more acts / operations described herein.

[0035] Processor 220 may include at least one processor that is programmable or configurable to perform the functions or operations described herein. For example, processor 220 may be configured to execute computer-executable instructions stored in at least one storage medium or memory storage (e.g., storage 240, etc.) to thereby perform one or more acts or operations described herein.

[0036] According to an embodiment, processor 220 may be configured to receive one or more signals and / or one or more user inputs (e.g., via communications interface 210, input / output 230, etc.) that define one or more instructions to perform one or more operations. Furthermore, processor 220 may be implemented in hardware, firmware, or a combination of hardware and software. For example, processor 220 may include at least one of a central processing unit (CPU), a graphics 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 another type of processing or computational component.

[0037] According to an embodiment, the processor 220 may be configured to collect, extract, and / or receive one or more pieces of information (e.g., in the form of signals or data) from the user 110, process the received one or more pieces of information, and thereby perform software validation.

[0038] A description of some example operations that may be performed by processor 220 is provided below with reference to FIGS.

[0039] 3 illustrates a block diagram of an exemplary system configuration 300 for software validation, according to one or more embodiments. As shown in FIG. 3, system configuration 300 may include a user 310, a user storage 312, a public repository 314, and an SPL system 320.

[0040] SPL system 320 may correspond to SPL system 120 of Figure 1 and SPL system 200 of Figure 2, and therefore features associated with SPL system 120, SPL system 200, and SPL system 320 may be equally applicable to one another unless expressly stated otherwise. Similarly, user 310 may correspond to user 110 of Figure 1, and therefore features associated with user 110 and user 310 may be equally applicable to one another unless expressly stated otherwise.

[0041] 3, SPL system 320 may be configured to receive software components from users 310. SPL system 320 may also be configured to provide software builds and SBOMs to users 310 via user storage 312, and may also be configured to provide data such as public keys to public repository 314.

[0042] As further shown in FIG. 3, SPL system 320 may include at least one orchestrator 321, software quality gate 322, software repository 323, build system 324, SBOM generator 325, collaborative design system 326, verification store 327, trust and invalidation store 328, and data store 329, although it may be understood that SPL system 320 may include more or fewer components than those shown in FIG. 3 and / or may be arranged differently than those shown in FIG. 3 without departing from the scope of the present disclosure.

[0043] SPL system 320 may be configured to receive software components from user 310 and store the software components in software repository 323. Software repository 323 may be configured to store multiple software components needed to build multiple software programs.

[0044] Orchestrator 321 may be configured to request and monitor builds of software associated with received software elements from build system 324, request software bills of materials (SBOMs) from SBOM generator 325, store the SBOMs and data needed to perform validation (signatures, private keys, etc.) and timestamps in validation store 327, and store the results of the combination of software elements in data store 329. Orchestrator 321 may also keep aware of the state of all software elements, the quality checks performed on the software elements, and the results.

[0045] The build system 324 can be configured to retrieve any software elements required to build the software from the software repository 323, retrieve any quality checks stored and defined in the software quality gates 322 to perform quality checks on the software elements, and provide the software build, the status of the build, and the results of the quality checks to the orchestrator 321.

[0046] 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 validation of the SBOM and software elements. Trusted and revoked store 328 may be configured to store a database of trusted and untrusted signatures, private keys, etc. for validation.

[0047] Exemplary Operations for Performing Software Verification in the Present Disclosure Below, some exemplary operations that the SPL system of the present disclosure can perform are described with reference to FIGS.

[0048] 4 illustrates a flow diagram of an example method 400 for software validation according to one or more embodiments. One or more operations in method 400 may be performed by at least one processor (e.g., processor 220) of the SPL system.

[0049] As shown in FIG. 4 , at operation 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 component or individual element that together form software. For example, a software element may refer to one or a combination of source code, build files, data, binaries, tools, etc. that together form software. According to an embodiment, a portion of a software element may depend on another software element. For example, a software element may require input from another software element to operate, a software element may include another software element, output (e.g., performance) from one 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 a part of another software.

[0050] According to an embodiment, the software element received from the user in operation S410 may be a new version of one of the multiple software elements that make up the software. According to an embodiment, the multiple software elements that make up the software may be specified in a list, such as a software bill of materials (SBOM).

[0051] According to embodiments, an SBOM may refer to metadata that includes a library or list of software elements that make up the software. Thus, an SBOM may be used to identify all of the components associated with a product's software for various purposes, such as, for example, to recreate the software, to identify software elements that were known to be faulty during production, etc.

[0052] According to an embodiment, users may refer to entities, such as OEMs and tier suppliers, that own the received software elements.

[0053] The method then proceeds to operation S420.

[0054] At operation S420, the at least one processor may be configured to determine whether the received software element passes a quality check.

[0055] According to an embodiment, a quality check may refer to a process of checking whether a software element satisfies an associated standard. For example, the quality check may include one or more of a security check, a safety check, a performance check, a power consumption check, a source code check, a privacy check, etc. These checks may be in accordance with one or more associated industry standards. For example, a safety check may be in accordance with the Automotive Safety Integrity Level (ASIL) standard according to ISO 26262, a security check may be in accordance with requirements set forth in the latest version of MISRA C++, a privacy check may be in accordance with standards according to ISO 2701, etc. According to an embodiment, performing a quality check may also include running a linter as part of the software build and invoking additional tools as needed.

[0056] Additional description regarding the process for determining whether a received software element passes a quality check is provided below with reference to FIGS.

[0057] It will be appreciated that the number of quality checks, the particular types of quality checks, and the particular standards regarding quality checks to be performed on particular software elements may be predetermined by the entities involved in the production of the software and / or standards established in the industry, based on the nature of the software and software elements.

[0058] The method then proceeds to operation S430.

[0059] In response to determining during operation S420 that the received software element passes the quality check, at operation S430, the at least one processor may be configured to add 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 that specifies, along with the received software element, the software elements specified in the previous version of the list.

[0060] The method then proceeds to operation S440.

[0061] At operation 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 the first verification of the list by digitally signing the list (e.g., the SBOM) as a whole. The list may be digitally signed directly (by encrypting the list directly with a private key) or by using a hash algorithm (i.e., by encrypting a hash of the list).

[0062] According to example embodiments, once a software element passes a certain type of quality check (e.g., security, safety, performance, power consumption, etc.), an entity responsible for performing that type of quality check may perform a validation (i.e., a second validation) of the software element. According to example embodiments, the entity may refer to a checking entity in the SPL system. For example, the entity may refer to a machine, software, module, etc. that is part of the SPL system and is designed to automatically perform a certain type of quality check on software elements. According to examples, the entity may refer to a human operating a machine, software, module, etc. that is part of the SPL system to manually perform a certain type of quality check on software elements. According to examples, the entity may refer to a checking entity external to the SPL system. For example, the entity may refer to an OEM, a tier supplier, a government agency, etc. that performs a certain type of quality check on software elements.

[0063] According to an example embodiment, performing a second verification of the software element may refer to cryptographically signing the software element by the checking entity. According to an example embodiment, performing a second verification may result in a cryptographic signature (or digital signature) being provided by the checking entity on a cryptographic hash of the software element (i.e., the software element is hashed and the resulting hash is encrypted using a private key). According to another example embodiment, the signature may be provided on the software element itself without hashing the software element.

[0064] It may be understood that each check entity may have a unique key, such as a private key (of a public-private key pair), to provide a cryptographic signature (i.e., perform a second verification). If a check entity is responsible for performing multiple types of quality checks, it may have multiple cryptographic private keys (where each key pair is associated with a respective type of quality check) to provide multiple cryptographic signatures, and different cryptographic signatures may be used when the check entity performs different types of quality checks. For example, a check entity may use a first private key to provide a first cryptographic signature when the check entity performs a security check on a software element and a second private key to provide a second cryptographic signature when the check entity performs a security check on the software element. Thus, a particular cryptographic signature may indicate a particular type of quality check performed on a software element and a particular check entity performing that particular type of quality check. Furthermore, because a software element is cryptographically signed (a second verification is performed) after it passes a certain type of quality check, the presence of the resulting cryptographic signature may indicate that the software element passes that type of quality check. In other words, the second verification verifies that the software element has passed that type of quality check. Furthermore, it is understood that the same or different hash algorithms may be used / associated for each type of quality check and / or each check entity.

[0065] In view of the above, it can be appreciated that each of the multiple software elements in the list (including software elements received from a user in operation S410 and added to the list in operation S430) may include one or more indications, such as a cryptographic signature, that indicate that the software element passes each quality check of a certain type.

[0066] In this regard, at operation S440, at least one processor may be configured to perform a first verification of the list to verify a second verification performed on all of the software elements specified in the list. According to an example embodiment, a supervising entity in the SPL system may perform the first verification of the list. For example, the supervising entity may refer to a machine, software, module, etc. that is part of the SPL system and is designed to automatically supervise the check entities and the build of the software. According to an example embodiment, the entity may refer to a human who operates a machine, software, module, etc. that is part of the SPL system to manually supervise the check entities and the build of the software.

[0067] According to an example embodiment, performing the first verification may result in a cryptographic signature being provided by the overseeing entity over the list (e.g., a private key encryption of a hash over the list or at least a predetermined portion of the list is generated using a predetermined hash algorithm). It may be appreciated that the overseeing entity, like the checking entity, may have a unique key, such as a cryptographic private key, for providing the cryptographic signature (i.e., performing the first verification). According to an example embodiment, the cryptographic signatures provided by the checking entity and the overseeing entity may also indicate the date and time the cryptographic signature is provided.

[0068] In this regard, a first verification may be performed on a list including multiple software elements that form the software, and the first verification may verify a second verification that is performed on all of the software elements specified in the list (which in turn verifies the software elements that pass the quality check), so that the first verification may verify the software as having software elements that adequately meet various standards regarding quality (e.g., security, safety, performance, power consumption, etc.).

[0069] Thus, a cryptographic signature may have the following characteristics: the data it is provided with, e.g., ECU software (source code or compiled binary), software elements, software builds, SBOMs, and other signatures (e.g., a signer may sign that another signer signed the data); a signer (e.g., a person or entity that produces the software, acts as a quality gate, or is responsible for verifying signatures) that uses their private key to perform the cryptographic signature; a verifier that verifies the signer (i.e., that the signer signed the data with their key); the date the signature was provided; an expiration date after which the signature is considered no longer valid (indicating that the software should not be used after that date); and revocation information (OSCP) that signals when the signature should be revoked. It can be understood that the verifier can be anyone or a list of specific public keys corresponding to the private keys of other parties. The verifier can be another supplier, an OEM, a public agency, or the general public. For example, a first entity may verify or attest that a second entity wrote a particular piece of software, or a supplier may verify or attest that a second entity ran particular tests on the supplier's software, or a first entity may verify or attest that a second entity verified a particular supplier's signature. Additionally, it may be understood that a date may be stored in a trusted store so that any entity can verify software when something was signed.

[0070] After performing operation S440, method 400 may end or terminate. Alternatively, method 400 may return to operation S410, such that the at least one processor may be configured to repeatedly receive (at operation S410), determine (at operation S420) that the software element passes a quality check, add (at operation S430) the software element to a list, and verify (at operation S440) the list for at least a predetermined amount of time. For example, the at least one processor may continuously (or periodically) receive newer versions of the same software element for the same software, newer versions of different software elements for the software, and newer versions of software elements for different software.

[0071] To this end, the system of the present disclosure may perform software validation.

[0072] Exemplary Operations for Validating Software and Software Elements in the Present Disclosure In the following, some exemplary operations that may be performed by at least one processor for validating software and software elements are described with reference to FIGS.

[0073] 5 illustrates a flow diagram of an example method 500 for verifying software and software elements according to one or more embodiments. One or more operations of method 500 may be part of operations S410, S420, S430, and / or S440 in method 400 and may be performed by at least one processor of the SPL system (e.g., processor 220).

[0074] 5, at operation 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 operation S410 in method 400, the received software element may be a new version of one of multiple software elements that form the software, and the user may refer to an entity, such as an OEM or tier supplier, that owns the received software element. The method then proceeds to operation S520.

[0075] At operation S520, the at least one processor may be configured to perform a quality check on the received software element. According to an embodiment, similar to that described in method 400, the quality check may refer to a process of checking whether the software element meets an associated standard, and may include one or more of a security check, a safety check, a performance check, a power consumption check, a source code check, etc. According to an embodiment, similar to that described in method 400, the quality check may be performed by a checking entity in the SPL system. The method then proceeds to operation S530.

[0076] At operation S530, the at least one processor may be configured to determine whether the received software element passes a quality check. According to an embodiment, the at least one processor may be configured to determine whether the received software element passes a quality check by determining whether a result of performing the quality check on the received software element satisfies a threshold. According to an embodiment, the threshold may be a quality gate.

[0077] According to embodiments, a quality gate may refer to a metric that defines a level of quality that a software element must meet. For example, after a quality check is performed on a software element to create resulting data, the resulting data may be processed to obtain a metric measurement that indicates the quality of the software element with respect to the type of quality check performed (e.g., security, safety, performance, power consumption, etc.). The metric may be compared against the quality gate to determine whether the quality of the software element meets an acceptable level. It may be understood that the quality gate may be predetermined based on the nature of the software and the software element, by the entities involved in the production of the software, and / or by standards established in the industry.

[0078] Thus, based on a determination that the received software element passes the quality check, the at least one processor may determine that the quality of the software element with respect to a particular type of quality check (e.g., security, safety, performance, power consumption, etc.) meets an acceptable level and proceed to operation S531. On the other hand, based on a determination that the received software element does not pass (fail) the quality check, the at least one processor may determine that the quality of the software element with respect to a particular type of quality check does not meet an acceptable level and proceed to operation S535.

[0079] According to an embodiment, if a software element is defined to be subject to multiple types of quality checks (e.g., by standards defined by entities involved in the production of the software and / or by the industry), at least one processor may proceed to operation S531 if the software element passes all of the defined types of quality checks, and may proceed to operation S535 if the software element fails any one of the defined types of quality checks.

[0080] At operation S531, the 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 passes. According to an embodiment, similar to that described above in connection 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, where a cryptographic signature (or digital signature) may be provided on a cryptographic hash of the received software element, and / or where a cryptographic signature (or digital signature) may be provided on the software element itself without hashing the software element.

[0081] For example, as described in connection with method 400, a check entity may have a unique key, such as a private key (of a public-private key pair), to provide a cryptographic signature, and may have multiple cryptographic private keys to provide multiple cryptographic signatures, with different cryptographic signatures used when the check entity performs different types of quality checks. Thus, for example, if check entity A uses private key A to provide cryptographic signature A when performing a safety check and private key B to provide cryptographic signature B when performing a security check, and if the software element passes the safety check performed by check entity A in operation S520, then check entity A may cryptographically sign the software element using private key A to provide cryptographic signature A (i.e., perform a second verification). As another example, check entity A may use private key C to provide cryptographic signature C when performing a safety check on a software element used in software for testing, and private key D to provide cryptographic signature D when performing a security check on a software element used in software for final products. Thus, when performing a security check on a software element used in software for testing, check entity A may use private key C to provide cryptographic signature C. The method then proceeds to operation S532.

[0082] At operation S532, the at least one processor may be configured to add the received software element to the software build. For example, because the received software element passed a quality check and underwent second verification during operations S520, S530, and S531, the at least one processor may determine that the received software element is of acceptable quality for inclusion in the software build. Thus, the at least one processor may be configured to add the received software element to the software build. The method then proceeds to operation S533.

[0083] At operation S533, the at least one processor may be configured to add the received software element to a list. According to an embodiment, the list may refer to an SBOM, similar to that described in connection with method 400. The method then proceeds to operation S534.

[0084] At operation S534, 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 the first verification of the list by cryptographically (or digitally) signing the list to provide a cryptographic signature by an overseeing entity, similar to that described in connection with method 400. The method then proceeds to operation S540.

[0085] At operation S535, the 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 fails. For example, if the received software element fails a security check, the at least one processor may be configured to provide a failure notification to a user indicating that the received software element fails the security check. According to an embodiment, the failure notification may include any additional information related to the failure, such as the checking entity that performed the quality check, the defined quality gates, the standard used for the quality check, etc. The method then proceeds to operation S536.

[0086] At operation S536, the at least one processor may be configured to add a previous version of the received software element to the software build. For example, between operations S520 and S530, the at least one processor may determine that the received software element is of unacceptable quality for inclusion in the software build because the received software element failed a quality check. Thus, the at least one processor may be configured to add a previous version of the received software element to the software build, which is assumed to have already passed the quality check. The method then proceeds to operation S540.

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

[0088] At operation S550, at least one processor may be configured to build the software. According to an embodiment, the at least one processor may be configured to build the software based on a plurality of software elements specified in the list, including new versions of the software elements added to the list and the build during operations S532 and S533. For example, if 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, and a new version of software element A version 1.0, software element A version 1.1, is received from a user, passes quality checks, and is added to the SBOM and the build during operations S510-S534, the at least one processor may be configured to build the software using software element A version 1.1, software element B version 1.0, and software element C version 1.0. The method then proceeds to operation S560.

[0089] At operation S560, the at least one processor may be configured to perform a third verification of the software build. According to an embodiment, similar to that described in connection with the first verification, the at least one processor may be configured to perform the third verification of the software build by cryptographically (or digitally) signing the software build to provide a cryptographic signature by an overseeing entity.

[0090] After performing operation S560, method 500 may end or terminate. Alternatively, method 500 may return to operation S510, such that the at least one processor may be configured to repeatedly, for at least a predetermined amount of time, receive the software element (at operation S510), perform a quality check (at operation S520), determine whether the software element passes the quality check (at operation S530), perform a second verification of the software element (at operation S531), add the software element to a build (at operation S532), add the software element to a list (at operation S533), perform a first verification of the list (at operation S534), provide a failure notification to the user (at operation S535), add a previous version of the software element to the build (at operation S536), determine whether there are any more software elements received from the user (at operation S540), build the software (at operation S550), and perform a third verification of the build (at operation S560). For example, at least one processor may continuously (or periodically) receive newer versions of the same software element for the same software, and newer versions of the software element for different software.

[0091] 6 illustrates a flow diagram of an example method 600 for verifying software and software elements according to one or more embodiments. One or more operations of method 600 may be part of operations S410, S420, S430, and / or S440 in method 400 and may be performed by at least one processor of the SPL system (e.g., processor 220).

[0092] 6, at operation S610, at least one processor may be configured to receive at least one software element from a user. According to an embodiment, similar to operation S410 in method 400, the received software element may be a new version of one of multiple software elements that form the software, and the user may refer to an entity, such as an OEM or tier supplier, that owns the received software element. The method then proceeds to operation S620.

[0093] At operation S620, the at least one processor may be configured to send the received software element to a check entity. According to an embodiment, as described in connection with method 400, the check entity may refer to a check entity external to the SPL system.

[0094] It may be appreciated that a checking entity external to the SPL system may perform quality checks on the received software element, determine whether the received software element passes the quality checks, and perform a second verification of the received software element based on the type of quality checks the received software element passes, similar to what is described for the checking entity in the SPL system described in connection with method 500. The method then proceeds to operation S630.

[0095] At operation S630, the at least one processor may be configured to receive, from a check entity, results of performing a quality check on the received software element. According to an embodiment, if the received software element passes the quality check, the results received from the check entity may indicate that the check entity performed a second verification on the received software element based on the type of quality check the received software element passes. For example, the results received from the check entity may include a cryptographic signature attributable to the check entity cryptographically signing the received software element, where the inclusion of the cryptographic signature indicates that the check entity cryptographically signed the received software element (i.e., performed a second verification of the received software element). According to an embodiment, if the received software element fails the quality check, the results received from the check entity may indicate that the received software element failed the quality check. For example, the results received from the check entity may include a notification indicating that the received software element failed the quality check. According to an embodiment, the results received from the check entity may include any additional information related to the quality check, such as the check entity performing the quality check, the defined quality gates, the standard used for the quality check, etc. The method then proceeds to operation S640.

[0096] At operation S640, the at least one processor may be configured to determine whether the received software element passes the quality check. According to an embodiment, the at least one processor may be configured to determine whether the received software element passes the quality check by determining whether the result received from the checking entity indicates that the checking entity performed a second verification on the received software element or indicates that the received software element fails the quality check.

[0097] Thus, based on a determination that the received software element passes the quality check, the method proceeds to operation S641. On the other hand, based on a determination that the received software element does not pass (fails) the quality check, the method proceeds to operation S644.

[0098] It may be understood that operations S641, S642, S643, S644, S645, S650, S660, and S670 in method 600 may be similar to operations S532, S533, S534, S535, S536, S540, S550, and S560 in method 500. Therefore, a description of these steps will be omitted.

[0099] 7 illustrates a flow diagram of an example method 700 for verifying software and software elements according to one or more embodiments. One or more operations of method 700 may be part of operations S410, S420, S430, and / or S440 in method 400 and may be performed by at least one processor of the SPL system (e.g., processor 220).

[0100] 7, at operation S710, at least one processor may be configured to receive at least one software element from a user. According to an embodiment, similar to operation S410 in method 400, the received software element may be a new version of one of multiple software elements that form the software, and the user may refer to an entity, such as an OEM or tier supplier, that owns the received software element. The method then proceeds to operation S720.

[0101] At operation S720, the at least one processor may be configured to perform a quality check on the received software element. According to an embodiment, similar to that described in method 400, the quality check may refer to a process of checking whether the software element meets an associated standard, and may include one or more of a security check, a safety check, a performance check, a power consumption check, a source code check, etc. According to an embodiment, similar to that described in method 400, the quality check may be performed by a checking entity in the SPL system. The method then proceeds to operation S730.

[0102] At operation S730, the at least one processor may be configured to determine whether the received software element passes a quality check. According to an embodiment, similar to that described in connection with method 500, the at least one processor may be configured to determine whether the received software element passes a quality check by determining whether a result of performing a quality check on the received software element meets a threshold.

[0103] Thus, based on a determination that the received software element passes the quality check, the at least one processor may determine that the quality of the software element with respect to a particular type of quality check (e.g., security, safety, performance, power consumption, etc.) meets an acceptable level and proceed to operation S731. On the other hand, based on a determination that the received software element does not pass (fail) the quality check, the at least one processor may determine that the quality of the software element with respect to a particular type of quality check does not meet an acceptable level and proceed to operation S732.

[0104] At operation S731, the at least one processor may be configured to perform a second verification of the received software element based on the type of quality checks that the received at least one software element passes. According to an embodiment, similar to that described above in connection 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, where a cryptographic signature (or digital signature) may be provided on a cryptographic hash of the received software element and / or where a cryptographic signature (or digital signature) may be provided on the software element itself without hashing the software element. The method then proceeds to operation S740.

[0105] At operation S732, the at least one processor may be configured to provide a failure notification to the user. According to an embodiment, the failure notification may indicate the type of quality check that the received software element fails, similar to those described in connection with method 500. The method then proceeds to operation S740.

[0106] At operation S740, the at least one processor may be configured to determine whether there are more quality checks to perform on the received software element. According to an embodiment, if the software element is defined to be subject to multiple types of quality checks (e.g., by standards defined by entities involved in the production of the software and / or by the industry), the at least one processor may check each of the quality checks individually during operation S730 and proceed to operation S731 or operation S732 for each of the quality checks.

[0107] Thus, based on a determination that there are more quality checks to perform on the received software element, the method returns to operation S730 to perform the additional quality checks. On the other hand, based on a determination that there are no more quality checks to perform on the received software element, the method proceeds to operation S750.

[0108] Considering the above process, for example, if a software element is defined to be subject to security, safety, and performance checks, and if the software element passes the security check and the safety check, but fails the performance check, the software element will include two cryptographic signatures (attributed to the same checking entity or different checking entities that cryptographically sign the software element) during operation S731 indicating that the software element passes the security and safety checks. Additionally, the SPL system will provide a failure notification to the user during operation S732 indicating that the software element fails the performance check. The method then proceeds to operation S750.

[0109] At operation S750, the at least one processor may be configured to add the received software element to a build of the software, similar to that described in connection with method 500. The method then proceeds to operation S760.

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

[0111] At operation 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 undergo 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 undergo a quality check based on a type of quality check that the received software element fails.

[0112] According to embodiments, a dependent software element may refer to a software element in a plurality of software elements that is specified in a list forming the software and that depends on another software element. According to embodiments, a dependent software element may be defined by standards established by entities involved in the production of the software and / or by an industry, such that the dependent software element is subject to certain quality checks or all quality checks if the software element on which it depends fails a certain quality check.

[0113] For example, software element B may be required to satisfy a performance check and may have previously undergone and passed that performance check. However, the performance of software element B may depend on the performance of another software element A. In this regard, if a new version of software element A is received from a user during operation S710 and fails a performance check during operations S720 and S730, software element B (which depends on software element A) may no longer satisfy software element B's performance check when the new version of software element A is incorporated into the build and software element B is made dependent thereon. Thus, software element B may be defined to undergo a performance check if software element A fails its performance check. Furthermore, it may be understood that if software element A passes a performance check, software element B may not need to undergo a quality check even if software element A fails another quality check (e.g., a safety check).

[0114] 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 undergo a quality check unless the received software element fails at least one of the defined quality checks. For example, the dependent software element may be defined by a standard defined by an entity involved in the production of software and / or an industry such that the dependent software element always undergoes a specific quality check or all quality checks if the software element on which the dependent software element depends fails any quality check. In such a case, it may be understood that operation S760 may be skipped.

[0115] Therefore, based on a determination that the received software element has at least one dependent software element that should undergo a quality check, the method returns to operation S720 to perform the quality check on the dependent software element. On the other hand, based on a determination that the received software element does not have any dependent software elements that should undergo a quality check, the method proceeds to operation S763. It may also be understood that if the software element does not have any dependent software elements, the method may proceed to S763.

[0116] It may be understood that operations S761, S762, S763, S780, and S790 in method 700 may be similar to operations S533, S534, S540, S550, and S560 in method 500. Therefore, descriptions regarding these steps will be omitted.

[0117] 5-7 are simplified for illustrative purposes and are not intended to limit the scope of the present disclosure in any way. In particular, in practice, various aspects of methods 500, 600, and 700 may be combined or interchangeable with one another.

[0118] For example, one software element in the software may be checked by a checking entity in the SPL as described in method 500, and another software element in the same software may be checked by a checking entity external to the SPL as described in the system of method 600. Similarly, one type of quality check on the software may be performed by a checking entity in the SPL as described in method 500, and another type of quality check on the same software element may be checked by a checking entity external to the SPL system as described in method 600.

[0119] As another example, although method 700 is described with operation S720 for performing a quality check on the received software element, method 700 may instead be modified to send the received software element to an external check entity and receive results from the external check entity, similar to that described between operations S620 and S630 in method 600.

[0120] Additionally, as described in connection with method 400, at least one processor may be configured to generate, along with the received software elements, a new version of the list that specifies the software elements specified in the previous version of the list. In this regard, although methods 500, 600, and 700 describe that the list may be generated serially (where each new version of each of the software elements is added incrementally to the list), the list may also be generated in parallel (where each new version of each of the software elements is added separately to the list). Additionally, each new version of the list may be signed and added together to another list that is similarly signed.

[0121] It can be appreciated that once the software and SBOM (e.g., a listing) are generated according to the processes in methods 500, 600, and 700, the software and SBOM can be provided to users (e.g., OEMs, tier suppliers, etc.) so that the users can verify and use the software. Similarly, products that utilize the software can also include the software itself along with an SBOM so that sellers and purchasers of the product can verify and use the product.

[0122] Additionally, it may be appreciated that the public keys and cryptographic signatures for the checking entities and oversight entities may be provided to a public repository so that end users (e.g., OEMs, tier suppliers, product sellers, product purchasers, etc.) can verify that the cryptographic signatures provided in connection with the SBOM are valid.

[0123] It can be appreciated that the lists (e.g., SBOMs) and software generated as described according to the processes in methods 500, 600, and 700 can provide software (supply) chain security and can have the following advantages:

[0124] Because every new version of every software element that passes the quality check is added to the SBOM (and then signed with a cryptographic signature), the above method allows for incremental updates and improvements to the software over time while ensuring that appropriate quality requirements are still met.

[0125] In particular, for example, if any of the software elements becomes erroneous or corrupted, or if an attacker adds a malicious software element to the software in order to configure the software (and subsequently, a final product that uses the software), such a problem may be detected, and the SBOM of the software that uses such a corrupted software element may not be signed. Thus, an end user (such as a seller of a product that uses the software, a purchaser of the product, etc.) can determine that the software that uses such a corrupted software element is not suitable for use by checking that the corresponding SBOM is not signed (or that a signed SBOM does not exist for the software). Thus, the above process enables the detection of malicious or abnormal problems in software, and the SBOM generated according to the above process provides a way to create specific attestations (which can be attested by a user) regarding the quality, safety, and compliance of the software in a centralized system with any specific standard.

[0126] Furthermore, because the SBOM generated according to the above process can indicate which software elements (and versions) have passed quality checks, which quality checks they have passed, and who authorized them, the SBOM can be used to identify responsibilities and responsibilities for checking and oversight entities.

[0127] Additionally, the SBOM generated according to the above process may indicate which versions of software elements passed quality checks and whether the quality checks are applied to a test product or a final product, so that the SBOM can be used to identify whether the software is appropriate for the product (e.g., if the product is a final product that will be released to consumers, then the quality checks performed on the software elements should be for the final product, not for testing).

[0128] Furthermore, the SBOM generated according to the above process may also enable dynamic management of dependent software elements, dynamic management of quality gates required for production of the SDK, the evolution of software component sources, dependencies, and quality gates over time, automatic real-time feedback on passing quality checks, historical states of combinations of software elements being retrieved from a data store, an option for manual checking of results to be verified by humans, the SBOM serving as an auditable means of verifying files that are part of a release, the use of cryptographic signatures to verify passing of quality checks and the overall quality of the software, the use of public repositories where entities may verify the signatures and the time the release was signed, suppliers, external auditors, or other third parties building software with the same end result, a class of end users such as auditors verifying the content and testing performed on a particular software package in a reproducible manner, and software being automatically managed via signatures, and may enable restrictions, overrides, or consents on use of the software accordingly.

[0129] Example Implementation 8 illustrates a diagram of an example environment 800 in which the systems and / or methods described herein may be implemented. As shown in FIG. 8, environment 800 may include a device 810, a platform 820, and a network 830. The devices of environment 800 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In some embodiments, any of the functions and operations described with reference to FIGS. 1-7 above may be performed by any combination of elements shown in FIG. 8.

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

[0131] Platform 820 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 820 may include a cloud server or a group of cloud servers. In some implementations, platform 820 may be designed to be modular such that particular software components can be swapped in or out depending on particular needs. Thus, platform 820 may be easily and / or quickly reconfigured for different uses.

[0132] In some implementations, as shown, platform 820 may be hosted in a cloud computing environment 822. Notably, although implementations described herein describe platform 820 as being hosted in a cloud computing environment 822, in some implementations platform 820 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0133] Cloud computing environment 822 includes an environment that hosts platform 820. Cloud computing environment 822 may provide services such as computing, software, data access, storage, etc., without requiring end-user (e.g., user device 810) knowledge of the physical location and configuration of the systems and / or devices that host platform 820. As shown, cloud computing environment 822 may include a group of computing resources 824 (collectively referred to as “computing resources 824” and individually referred to as “computing resource 824”).

[0134] The computational resources 824 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, the computational resources 824 may host the platform 820. Cloud resources may include compute instances running on the computational resources 824, storage devices provided on the computational resources 824, data transfer devices provided by the computational resources 824, etc. In some implementations, the computational resources 824 may communicate with other computational resources 824 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0135] As further shown in FIG. 8 , the 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, virtualized storage (“VSs”) 824-3, one or more hypervisors (“HYPs”) 824-4, or the like. While the exemplary embodiment refers to virtualized network functions, it is understood that one or more other embodiments may be implemented in at least one of, but not limited to, containers, cloud-native services, one or more container platforms, and the like. For example, in one or more other exemplary embodiments, any of the above-described components may be software-based components deployed or hosted in a server cluster, such as, for example, a hybrid cloud server, a data center server, and the like. The software-based components may be containerized and deployed and controlled by one or more machines, referred to as “nodes,” that launch or run and are addressable for the containerized network elements. In this regard, a server cluster may include at least one master node and multiple worker nodes, where the master node controls and manages a set of associated worker nodes.

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

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

[0138] Virtualized storages (VSs) 824-3 include one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of the computing resources 824. In some implementations, within the context of storage systems, 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 such that the storage system may be accessed without regard to the physical storage or heterogeneity. The separation may allow administrators of storage systems to be flexible in how they manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and where the file is physically stored. This may enable optimization of storage usage, server consolidation, and / or the performance of non-disruptive file movements.

[0139] Hypervisors (HYPs) 824-4 may provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer, such as the computing resource 824. The hypervisor 824-4 may provide a virtual operating platform for 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.

[0140] Network 830 may include one or more wired and / or wireless networks. For example, network 830 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, or the like, and / or a combination of these or other types of networks.

[0141] The number and arrangement of devices and networks shown in Figure 8 are provided as an example. In fact, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or different arrangements of devices and / or networks compared to those shown in Figure 8. Furthermore, two or more devices shown in Figure 8 may be implemented within a single device, or a single device shown in Figure 8 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment 800 may perform one or more functions that are described as being performed by another set of devices of environment 800.

[0142] Various aspects of the embodiments The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations.

[0143] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium(s) having computer-readable program instructions that cause a processor to perform operations.

[0144] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0145] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or may be 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 may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0146] The computer-readable program code / instructions for performing operations may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, 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, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0147] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0148] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0149] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a microservice module, segment, or portion of instructions, comprising one or more executable instructions that implement the specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0150] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement the systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0151] Further aspects and features of various respective embodiments of the present disclosure may be defined by the following clauses. Item [1]: A system may include a memory storage that stores computer-executable instructions and at least one processor communicatively connected to the memory storage, wherein the at least one processor is configured to execute the instructions to: receive at least one software element from a user, where the received at least one software element is a newer version of at least one of a plurality of software elements specified in a list; determine 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, add the received software element to the list and perform 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 that the respective software element of the plurality of software elements in the list passes. Item [2]: The system described in Item [1], wherein the quality check may include one or more of a security check, a safety check, a performance check, and a power consumption check. Item [3]: The system described in any one of items [1] to [2], wherein the one or more instructions may include a cryptographic signature resulting from cryptographically signing each software element of the plurality of software elements specified in the list, and the cryptographic signature may indicate an entity responsible for performing the quality check of the type passed by each software element of the plurality of software elements in the list. Item [4]: ​​The at least one processor may be further configured to execute the instructions to perform the quality check on the received at least one software element and perform a second verification of the received at least one software element based on the type of the quality check that the received at least one software element passes, and the at least one processor may be configured to execute the instructions to determine whether the received at least one software element passes the quality check by determining whether the result of performing the quality check on the received at least one software element satisfies a threshold. The system described in any one of Items [1] to [3]. Item [5]: The system described in Item [4], wherein the threshold may include a quality gate, and the quality gate may define a level of quality that the received at least one software element must meet. Item [6]: The at least one processor may be further configured to execute the instructions to send the received at least one software element to a check entity and receive from the check entity the results of the quality check performed on the received at least one software element, and the at least one processor may be configured to execute the instructions to determine whether the received at least one software element passes the quality check by determining, based on the type of the quality check passed by the received at least one software element from the check entity, whether the received results indicate that the check entity has performed a second verification of the received at least one software element. The system described in any one of Items [1] to [5]. Item [7]: The system according to any one of items [1] to [6], wherein the list may include a software bill of materials (SBOM). Item [8]: The system described in any one of items [1] to [7], wherein the at least one processor may be further configured to execute the instructions to provide a failure notification to the user in response to a determination that the received at least one software element fails the quality check, and the failure notification may indicate the type of quality check that the received at least one software element fails. Item [9]: The at least one processor may further be configured to execute the instructions to: in response to a determination that the received at least one software element fails the quality check, determine whether the received at least one software element has at least one dependent software element that should undergo the quality check based on the type of the quality check that the received at least one software element fails, where the at least one dependent software element may be at least one software element in the plurality of software elements that depends on the received at least one 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 undergo the quality check, perform the quality check on the at least one dependent software element. Item

[10] : The system described in any one of items [1] to [9], wherein the at least one processor may be configured to execute the instructions to perform the first verification of the list by cryptographically signing the list. Item

[11] : A method may include receiving at least one software element from a user, the received at least one software element being a newer version of at least one of a plurality of software elements specified in a 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, adding 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 that the respective software element of the plurality of software elements in the list passes. Item

[12] : The method described in Item

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

[13] : A method according to any one of items

[11] to

[12] , wherein the one or more instructions may include a cryptographic signature resulting from cryptographically signing each software element of the plurality of software elements specified in the list, and the cryptographic signature may indicate an entity responsible for performing the quality check of the type passed by each software element of the plurality of software elements in the list. Item

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

[11] to

[13] , which may further include performing the quality check on the received at least one software element and performing a second verification of the received at least one software element based on the type of the quality check passed by the received at least one software element, and wherein the determination as to whether the received at least one software element passes the quality check may include determining whether the result of performing the quality check on the received at least one software element satisfies a threshold. Item

[15] : The method according to Item

[14] , wherein the threshold may include a quality gate, and the quality gate may define a level of quality that the received at least one software element should meet. Item

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

[11] to

[15] , which may further include sending the received at least one software element to a check entity and receiving from the check entity results of the quality check performed on the received at least one software element, and wherein the determination as to whether the received at least one software element passes the quality check may include determining whether the received results indicate that the check entity has performed a second verification of the received at least one software element based on the type of quality check passed by the received at least one software element from the check entity. Item

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

[11] to

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

[18] : A method according to any one of items

[11] to

[17] , which may further include providing a failure notification to the user in response to determining that the received at least one software element fails the quality check, and the failure notification may indicate the type of quality check that the received at least one software element fails. Item

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

[11] to

[18] , which may further include: in response to a determination that the received at least one software element fails the quality check, determining whether the received at least one software element has at least one dependent software element that should undergo the quality check based on the type of quality check that the received at least one software element fails, where the at least one dependent software element may be at least one software element in the plurality of software elements that depends on the received at least one 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 undergo the quality check, performing the quality check on the at least one dependent software element. Item

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

[11] to

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

[0152] It will be appreciated that many modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that, within the scope of the appended sections, the present disclosure may be practiced otherwise than as specifically described herein.

Claims

1. memory storage for storing computer-executable instructions; at least one processor communicatively connected to the memory storage; wherein the at least one processor executes the instructions to receiving at least one software element from a user, the received at least one software element being a newer version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element passes a quality check; In response to determining that the received at least one software element passes the quality check, adding the received software element to the list; and performing a first verification of said list; and wherein each of the plurality of software elements specified in the list includes one or more indications of the type of quality checks that each software element of the plurality of software elements in the list passes.

2. The system of claim 1 , wherein the quality check comprises one or more of a security check, a safety check, a performance check, and a power consumption check.

3. the one or more instructions comprising a cryptographic signature resulting from cryptographically signing each software element of the plurality of software elements specified in the list; The system of claim 1 or 2, wherein the cryptographic signature indicates an entity responsible for performing the quality checks of the type passed by each software element of the plurality of software elements in the list.

4. The at least one processor further executes the instructions to: performing the quality check on the received at least one software element; and performing a second validation of the received at least one software element based on the type of quality check that the received at least one software element passes; 3. The system of claim 1, wherein the at least one processor is configured to execute the instructions to determine whether the received at least one software element passes the quality check by determining whether a result of performing the quality check on the received at least one software element meets a threshold.

5. the threshold comprises a quality gate; The system of claim 4 , wherein the quality gate defines a level of quality that the received at least one software element must meet.

6. The at least one processor further executes the instructions to: sending the received at least one software element to a checking entity; configured to receive from the checking entity a result of performing the quality check on the received at least one software element; 3. The system of claim 1, wherein the at least one processor is configured to execute the instructions to determine whether the received at least one software element passes the quality check by determining, based on the type of the quality check passed by the received at least one software element from the check entity, whether the received result indicates that the check entity has performed a second verification of the received at least one software element.

7. The system of claim 1 or 2, wherein the list comprises a software bill of materials (SBOM).

8. 3. The system of claim 1, wherein the at least one processor is further configured to execute the instructions to provide a failure notification to the user in response to a determination that the received at least one software element fails the quality check, the failure notification indicating the type of the quality check that the received at least one software element fails.

9. The at least one processor further executes the instructions to: in response to determining 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 subjected to the quality check based on the 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 in the plurality of software elements that depends on the at least one received software element; responsive to determining that the received at least one software element has at least one dependent software element that should be subjected to the quality check, performing the quality check on the at least one dependent software element; 3. The system of claim 1, configured to:

10. The system of claim 1 or 2, wherein the at least one processor is configured to execute the instructions to perform the first verification of the list by cryptographically signing the list.

11. A method performed by a processor, comprising: receiving at least one software element from a user, the received at least one software element being a newer version of at least one of a plurality of software elements specified in a list; determining whether the received at least one software element passes a quality check; In response to determining that the received at least one software element passes the quality check, adding the received software element to the list; and performing a first verification of said list; Including, The method of claim 1, wherein each of the plurality of software elements specified in the list includes one or more indications of the types of quality checks that each software element of the plurality of software elements in the list passes.

12. The method of claim 11 , wherein the quality check comprises one or more of a security check, a safety check, a performance check, and a power consumption check.

13. the one or more instructions comprising a cryptographic signature resulting from cryptographically signing each software element of the plurality of software elements specified in the list; 13. The method of claim 11 or 12, wherein the cryptographic signature indicates an entity responsible for performing the quality checks of the type passed by each software element of the plurality of software elements in the list.

14. performing said quality check on said received at least one software element; performing a second validation of the received at least one software element based on the type of quality check that the received at least one software element passes; Further comprising:

13. The method of claim 11 or 12, wherein determining whether the received at least one software element passes the quality check comprises determining whether a result of performing the quality check on the received at least one software element meets a threshold.

15. the threshold comprises a quality gate; The method of claim 14 , wherein the quality gate defines a level of quality that the received at least one software element must meet.

16. transmitting said received at least one software element to a checking entity; receiving from the checking entity a result of performing the quality check on the received at least one software element; Further comprising:

13. The method of claim 11 or 12, wherein determining whether the received at least one software element passes the quality check comprises determining, based on the type of quality check passed by the received at least one software element from the checking entity, whether the received result indicates that the checking entity has performed a second verification of the received at least one software element.

17. The method of claim 11 or 12, wherein the list comprises a software bill of materials (SBOM).

18. 13. The method of claim 11 or 12, further comprising providing a failure notification to the user in response to determining that the received at least one software element fails the quality check, the failure notification indicating the type of the quality check that the received at least one software element fails.

19. in response to determining 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 subjected to the quality check based on the 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 in the plurality of software elements that depends on the at least one received software element; responsive to determining that the received at least one software element has at least one dependent software element that should be subjected to the quality check, performing the quality check on the at least one dependent software element; 13. The method of claim 11 or 12, further comprising:

20. The method of claim 11 or 12, wherein performing the first verification of the list comprises cryptographically signing the list.

Images