Governance risk compliance platform and protection method for software supply chains

Abstract

A Governance. Risk, and Compliance (GRC) a security system useable by a software developer organization is disclosed. The system can comprise a proxy operable to capture communications on the network; and platform decision logic comprising: a configuration database comprising the plurality of requirements; an attest application configured to: determine for each of the plurality of requirements first evidence and / or second evidence that must be assessed to determine whether the developer organization has complied with that requirement; generate a Graphical User Interface (GUI) for the developer organization at a portal configured to receive the first evidence; an artifact collector configured to retrieve the second evidence using the proxy and comprises build artifacts originating from operation of the build controller service. The attest application is configured to assess each requirement and evidence relevant to that requirement to determine an individual compliance score for that requirement; and generate an attestation report.

Description

Governance Risk Compliance Platform and Protection Method for Software Supply ChainsFIELD OF THE INVENTION

[0001] The present invention relates generally to a governance risk compliance platform and protection method for software supply chains. This application incorporates by reference in its entirety’, and claims priority to, U.S. Provisional Patent Application Serial No. 63 / 727,459, filed December 3, 2024.BACKGROUND

[0002] Modem enterprises deploy large numbers of applications to conduct daily business. According to a recent Salesforce survey, enterprises deployed 1061 apps in 2023 representing a 25% increase from 843 apps in 2021. The deployment of these apps impacts the overall security’ risk to the business by potentially introducing cyber threat risk to the business. While an enterprise can control the processes and security posture for internally developed software by setting policies and requirements, they lack the control and visibility to enforce these policies daily. The advent of the open-source world with little standardization or process has left unsuspecting organizations potentially exposed. Today over 70% of enterprise software content originates in the wild west of the open-source world. Defects or deficiencies in these externally sourced components can lead to major security incidents placing the consuming enterprise at great risk. Unsuspecting software consumers have been victimized in the last few years as evidenced by7the SolarWinds, Kesaya, and Log4j attacks to name a few. At the same time the US Government has required businesses to disclose potential risk to investors as cyber-attacks can have material financial consequences.

[0003] Modem software development has moved to a Continuous Integration and Continuous Deployment (CI / CD) pipeline process 10, as shown in Figure 1. This pipeline 10 essentially automates the creation and deployment of software. Figure 10 shows a networked system 30 in which the pipeline 10 can be implemented. At the center of this networked system 30 is a network 50. Given the highly distributed nature of the (CI / CD) pipeline process 10, this network 50 may comprise the Internet, and Intranet, or combinations of these and other networks. A number of different network nodes, each providing some service, are shown connected to this network 50, which are explained further below.

[0004] As show n in Figure 1, the pipeline 10 typically starts with a development stage 10, where a software developer writes, incorporates, or make changes to, source code of a software product under development. The software developer is shown at a developer system 32 in Figure 10 that is connected to the netw ork 50. Such source code can be generated locally 14 (Fig. 1) as home-grown source code w ritten by the developer, which may be stored at a local source code repository 34 connected to the network 50 (Fig. 10). Although not shown in Figure 10, the local source code respiratory 34 could also comprise part of the developer system 32. Repository 34 may also reside in the cloud. For example, many companies today store their code using services such as GitHub or Amazon Web Services (AWS). Repository 34 may thus be local, remote, or external, as may also include mirrors on the developer’s desktop that may contain proprietary code. Developers may also incorporate open source code 16 (Fig. 1), which may be stored at an open source code repository 36 also connected to the network 50 (Fig. 10). Such incorporated open source code may be moved from the open source code repository 36 to the local source code repository 34, or the developer’s local source code may simply link to the incorporated open source code.

[0005] Regardless of how source code comes to be included in the developer’s software, the pipeline proceeds to a build stage 18 (Fig. 1). At this stage, the source code is converted to a binary' form directly executable by a dow nstream client’s computer system. The build stage 18 is typically implemented using a build controller 40 connected to the network 50. as shown in Figure 10. The build controller 40 comprises an automation server that controls the build pipeline scheduling one or more build runners to accomplish the build task, and examples include Jenkins, GitHub Actions, Team City', and AWS CodePipeline. The build controller 40 may support the use of one or more build containers 42a, 42b, etc. configured to run portions of the build in parallel to reduce build time. Although not shown in Figure 10, these build containers 42x can be separate from the build controller 40 and independently connected to the network 50.

[0006] Referring again to Figure 1, next in the pipeline 10, the resulting executable code is packaged at stage 22. Such packaging can involve the inclusion of certain dependencies 20 — i.e., certain software modules that are needed for execution of the software under development. A software dependency is a relationship between software components where one component relies on the other to work properly. For example, if the software uses a library to query a database, the software depends on that library. If the library is unavailable or not working correctly, the software cannot make queries to the database and the software will not function as intended.

[0007] As a result, it may be beneficial to package the library with the software as a dependency 20 at a packaging module 50. Such dependencies 20 can comprise local (internal) dependencies developed by the developer, or remote (external) dependencies procurable from other external sources. Figure 10 shows remote dependencies 20 as discrete from other components of the system 30, but dependencies may come from other system components, such as the open source code repository 36, or other third-party services 43. These third party services may comprise various external tools, such as developer security tools like SNYK, Jira, Docker, Veracode, JFrog, and others. The packaging module 50 can also occur at other places in the system, such as within the build controller 40 or the developer’s system 32. To summarize, the packaging stage 22 pulls together executables and necessary' dependencies and bundles them in an installation package. The installation package typically includes any installation scripts necessary to deploy on the target environment at the customer. Optionally, the software may also be packaged within a container which can be stored in a container library with all the necessary components to execute a container instance as required on the target deployment system.

[0008] Testing may also occur as part of pipeline 10, and in Figure 1 such testing 24 can — due to the distributed nature of the pipeline 5 — occur at different stages of the pipeline. Testing 24 can comprise running the software to ensure it is functioning properly and with suitable quality and reliability. Such testing can involve double checking that necessary dependencies 20 are present, and if not, downloading these. If testing of the software fails, the developer may be notified to allow for changes to be made at the development stage 12. Testing 24 can also include testing for viruses and other computer attack vectors.

[0009] More particular forms of testing 24 can be effectuated at a testing module 60 as shown in Figure 10. although the various testing services with module 60 may come from different sources. The testing module 60 may include a number of scanning containers 62, which are tasked with running specific scans to quantify the qualify and suitability of the built product. A number of different scanning containers are included, including a Static Application Security Testing (SAST) container 64, a Dynamic Application Security Testing (DAST) container 66, an Interactive Application Security Testing (IAST) container 68, a license scanner 70, and Software Composition Analysis (SCA) container 72. These scanners 64-72 are known to those skilled in the art, but are briefly explained.

[0010] The SAST container 64 typically runs scans on source code looking for problematic constructs, and generates reports highlighting potential issues. Typically such reports sort the findings by severity and may mark exceptions that will not be reported in thenext scan. SAST testing is iterative, and resources may need to be assigned to investigate reported issues and to fix actual defects, while marking false positives as exceptions.

[0011] The DAST container 66 typically runs checks relevant to deployment of the software under test, thus providing the ability to ‘‘black-box” test the software prior to distribution. The DAST container 66 will run requests that simulate request traffic coming from a user interface or an API client of a software customer. The parameters of these requests can be varied to ensure proper validation and to verify that correct error codes are returned. DAST tools exist to test the Open Worldwide Application Security Project (OWASP) top 10 as well as the OWASP API top 10. DAST container 66 will preferably make use of ZAP or other open-source security scanners.

[0012] The IAST container 68 analyzes code for security vulnerabilities while the software is running, using sensor modules to track behavior and detect vulnerabilities. Vulnerabilities or suspect behavior can be detected by the sensors in real-time and alerts may be sent. Examples of issues found by IAST scanning may include clear text hardcoding of API keys, not sanitizing user inputs, or opening network connections without SSL encryption.

[0013] The license scanner 70 can examine all files incorporated in the source code with the intent of identifying and classifying licenses and license types used within the product. This may be important to allow customers to validate that the software it is developing complies with its corporate licensing policies, as well as to ensure that copyleft licenses will not (accidentally) affect a closed source commercial product in a manner that could inadvertently inject that product with open source characteristics. The license scanner 70 may also highlight licensing contribution, publication, or notice requirements, which again may be important to review for compliance with corporate licensing policies. An example of license scanner 70 includes the open-source NexB Scancode application.

[0014] The SCA scanner 72 can be used to assess dependencies 20 or open source software pulled in from external sources (e.g., 36), such as by comparing these structures against known vulnerabilities.

[0015] Referring again to Figure 1, once packaged 22 and tested 24, the software can be deployed at distribution stage 26. Typically, this involves publishes the installation package at a distribution module 80 (Fig. 10) where it may be purchased or otherwise downloaded by customer. This distribution module 80 may comprise some sort of host server of the developer, or any other number of softw are publishing platforms available for use on the network 50.

[0016] To date Governance, Risk, and Compliance (GRC) vendors have not been focused on software supply chain threats and as a result their risk management systems do notconsider these risks. Protecting the software build environment typically has fallen in the realm of security teams. Prior to this new class of threat, security solutions were more focused on ensuring code quality by scanning the software (SAST) looking for suspect constructs. This often resulted in large numbers of false positive alerts greatly reducing the scans value since software development organizations are not staffed to investigate all issues. As the use of open- source software grew SCA scanners evolved to look at dependencies pulled in from external sources and compare them against known vulnerabilities. While inciteful these tools often fail to recursively work through the dependencies of the dependencies leaving gaps in the analysis. The use of DAST tools added the ability to black-box test software focusing on finding defects or vulnerabilities prior to shipment. Additional configuration scanning tools were deployed to analyze configuration of the configuration build infrastructure itself. The configuration scanners while valuable fail to close the gap since the scanners only validate the pipeline configuration without the ability' to assess operational integrity.

[0017] Customers must deploy all the scanning technologies to protect the software supply chain with no guarantee of success. No solution currently exists to consolidate the results of the various scans to generate a composite risk score. This leaves potential threats invisible and unmanageable. Current scanning methods assume that the software build infrastructure is functioning correctly which is an incorrect assumption as bad actors have tainted and corrupted these environments leading to compromise. The shear number of technologies in the CI / CD pipeline (build tools, OS’s. Containers. Deployment Managers) and their interdependencies make it impossible to find all attack vectors looking at configuration below.

[0018] There is currently not a mechanism to validate the actual behavior of the build environment relative to security and governance policies. Furthermore, the audit process ty pically involves filling out questionnaires by hand which often evaluates the stated corporate development processes versus what is happening in practice. A new solution is needed to monitor and protect the entire software build pipeline against the evolving threat landscape. The solution should be able to access the risk of the environment providing the visibility and the prioritization necessary to manage the threats effectively. The solution should automate the Audit / Attestation process as much as possible providing evidence of the steps taken. Today no such solution exists.SUMMARY

[0019] In a first embodiment, A security system is disclosed useable by a developer organization that builds a software product using a continuous integration / continuous deployment system and in accordance with a standard comprising a plurality of requirements, wherein the system is implemented as a plurality of network nodes each implementing one or more services connected to a network including a build controller service. The system may comprise: a proxy operable to capture communications issued by the one or more services connected to the network; a platform decision logic service connected to the network comprising: a configuration database comprising the plurality of requirements; an attest application configured to determine for each of the plurality of requirements first evidence and / or second evidence that must be assessed to determine whether the developer organization has complied with that requirement when building the software product, and generate a Graphical User Interface (GUI) for the developer organization at a portal, wherein the GUI is configured to receive the first evidence; and an artifact collector connected to the network configured to retrieve the second evidence, wherein the second evidence is retrieved using the proxy and comprises build artifacts originating from operation of the build controller service; wherein the attest application is configured to assess each requirement and the first and / or second evidence relevant to that requirement to determine an individual compliance score for that requirement, and generate a report including an attestation indicating whether the software product is compliant with the standard.

[0020] In an example of the first embodiment, the platform decision logic sen ice further comprises an artifact database configured to store the first evidence and the second evidence. In an example of the first embodiment, the first evidence comprises one or more of: a software license; indicia that the developer organization has complied with security training requirements; or indicia of compliance with multifactor authentication requirements. In an example of the first embodiment, the report comprises a listing of the requirements. In an example of the first embodiment, the report further comprises an indication of the first and / or second evidence relevant to each of the requirements. In an example of the first embodiment, the report further comprises the individual compliance score for each of the requirements. In an example of the first embodiment, the attest application is configured to allow a representative of the developer organization to electronically sign the report using the GUI. In an example of the first embodiment, the platform decision logic is configured to automatically distribute the report to customers of the software product. In an example of the first embodiment, the platform decision logic is configured to electronically sign the first and second evidence to confirm its authenticity in the security system. In an example of the firstembodiment, the attest application is further configured to determine using the individual compliances scores whether the software product has passed or failed attestation of the standard. In an example of the first embodiment, the attest application is further configured to determine an overall compliance score for the software product, wherein the overall compliance score is used to determine whether the software product has passed or failed attestation of the standard. In an example of the first embodiment, the report comprises the overall compliance score for the software product. In an example of the first embodiment, the first evidence originates in the build controller service. In an example of the first embodiment, the artifact collector comprises a build blob agent. In an example of the first embodiment, the platform decision logic further comprises a scheduler, wherein the scheduler is configured to enable the attest application at various times. In an example of the first embodiment, the compliance score indicates a percentage of compliance. In an example of the first embodiment, the platform decision logic service comprises a risk rating engine, and wherein the attestation process determines the compliance score for each requirement using the risk rating engine. In an example of the first embodiment, the risk rating engine queries one or more compliance packs during the attestation process. In an example of the first embodiment, the risk rating engine queries an artificial intelligence model database.

[0021] In a second embodiment, a method useable by a developer organization in a security system is disclosed that builds a software product using a continuous integration / continuous deployment system and in accordance with a standard comprising a plurality of requirements, wherein the system is implemented as a plurality of network nodes each implementing one or more sendees connected to a network including a build controller sen ice. The method may comprise: using a proxy operable to capture communications issued by the one or more services connected to the network; using an attest application to determine for each of the plurality of requirements first evidence and / or second evidence that must be assessed to determine whether the developer organization has complied with that requirement when building the software product, and generate a Graphical User Interface (GUI) for the developer organization at a portal, wherein the GUI is configured to receive the first evidence; and using an artifact collector connected to the network configured to retrieve the second evidence, wherein the second evidence is retrieved using the proxy and comprises build artifacts originating from operation of the build controller service; further using attest application to assess each requirement and the first and / or second evidence relevant to that requirement to determine an individual compliance score for that requirement, and generate areport including an atestation indicating whether the software product is compliant with the standard.

[0022] In an example of the second embodiment, the method further comprises storing the first evidence and the second evidence in an artifact database connected to the network. In an example of the first embodiment, the first evidence comprises one or more of: a software license; indicia that the developer organization has complied with security training requirements; or indicia of compliance with multifactor authentication requirements. In an example of the first embodiment, the report comprises a listing of the requirements. In an example of the first embodiment, the report further comprises an indication of the first and / or second evidence relevant to each of the requirements. In an example of the first embodiment, the report further comprises the individual compliance score for each of the requirements. In an example of the first embodiment, the atest application further allows a representative of the developer organization to electronically sign the report using the GUI. In an example of the first embodiment, the method further comprises automatically distributing the report to customers of the software product. In an example of the first embodiment, the method further comprises electronically signing the first and second evidence to confirm its authenticity in the security system. In an example of the first embodiment, the attest application further determines using the individual compliances scores whether the software product has passed or failed attestation of the standard. In an example of the first embodiment, the attest application further determines an overall compliance score for the software product, wherein the overall compliance score is used to determine whether the software product has passed or failed attestation of the standard. In an example of the first embodiment, the report comprises the overall compliance score for the software product. In an example of the first embodiment, the first evidence originates in the build controller service. In an example of the first embodiment, the artifact collector comprises a build blob agent. In an example of the first embodiment, the method further comprises using a scheduler to enable the attest application at various times. In an example of the first embodiment, the compliance score indicates a percentage of compliance. In an example of the first embodiment, the system comprises a risk rating engine connected to the network, and wherein the atestation process determines the compliance score for each requirement using the risk rating engine. In an example of the first embodiment, the risk rating engine queries one or more compliance packs during the atestation process. In an example of the first embodiment, the risk rating engine queries an artificial intelligence model database.BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 shows an example of a software development pipeline process, more specifically a Continuous Integration and Continuous Deployment (CI / CD) pipeline process, in accordance with the prior art.

[0024] Figure 2: IR Attest Top Level Schema Diagram.

[0025] Figure 3: Connector Diagram.

[0026] Figure 4: Component Elements Example.

[0027] Figure 5: Product / Components.

[0028] Figure 6: Product Grouping.

[0029] Figure 7: Protect Build Artifacts.

[0030] Figure 8: Software Bill of Materials (SBOM) Diagram.

[0031] Figures 9 and 10: Governance Risk Compliance Protection Platform (GRCPP) Architecture.

[0032] Figure 11: Customer Build Environment.

[0033] Figure 12: Cloud Component Build Architecture.

[0034] Figure 13: Protect Build Record Diagram.

[0035] Figure 14: Component Build Environment.

[0036] Figure 15: Policy Engine Architecture.

[0037] Figure 16: Risk Rating Engine Architecture.DETAILED DESCRIPTION

[0038] The Governance Risk Compliance Protection Platform (GRCPP) has been designed to provide visibility' and active management of potential risk for both internally and externally sourced software products. GRCPP not only illuminates hidden risks within the software environment but also serves as a policy enforcement point to ensure corporate standards are being followed. The continuous visibility' and control provided by the GRCPP allows corporate executives to actively manage and communicate business risk avoiding costly litigation and enforcement actions.

[0039] The GRCPP deeply analyzes open-source dependencies, provides risk analysis across all code modules, blocks real-time attempts to infiltrate or corrupt the software CI / CD pipeline while providing automation to complete required attestations. The GRCPP allows enterprises to evaluate and monitor the risk profile of software deployed in the enterprise environment, while protecting the software build environment and enforcement of corporate policies ensuring compliance. The risks are rated and scored providing a means to prioritizerisks, run what if scenarios on potential remediation efforts and a method to measure the effectiveness of remediation efforts. The overall goal is to ensure the integrity of the build environment and the imported dependencies collecting the necessary artifacts to attest that corporate and industry standards have been met. The ability to monitor and enforce policy in real-time prevents flawed software from being shipped to end customers. The automated attestation support provides the assurance that the highest standards have been followed in producing the software. The system provides reporting that allows the risk score of the various software products and underlying components to be tracked as well as the attestations being tracked to completion. This provides real-time visibility to an organization’s risk profile, allowing the risk to be actively managed and the ability to export attestations and artifacts to certification bodies or end customers.

[0040] GRCPP Schema: The topmost schema element is the Enterprise object anchoring all items relating to a particular customer. One or more Products are configured under the appropriate enterprise. Note that the GRCPP will create a Turbo-Charged (enhanced) Software Bills of materials (SBOMs) that recursively traverse the dependency tree identify multi-level dependencies versus top level manifest scans, for all configured products as they are built. The SBOM will be fed to the GRCPP Core for archival in the Artifact Store and distribution through the SBOM Exchange if so configured. Note that the GRCPP Core will maintain ratings and risk scores for all components which will be shared with the local instance. This will allow an economy of scale when processing the components of a build since the components are global across all customers reducing the processing required to analyze a product. Note that the Build Blob will also be uploaded to the cloud by the Artifact Agent for archival in the artifact store via a separate API call if so configured. This arrangement allow s the artifacts to be securely stored in the GRCPP Core.

[0041] Connectors should be provisioned to automatically upload SBOM’s and the build artifacts upon software build completion. Connectors are provisioned for each enterprise enabling cloud-based API server instances for the enterprise. The Product Group schema element is used to group products together for reporting purposes or setting permissions for users. The sections that follow will describe each of the schema elements in greater detail.

[0042] Following the completion of the build artifact uploads the Attest application will run any configured attestations for the build. Build Group and Enterprise attestations may also be updated if necessary. The Artifact Exchange will publish any updated Attestations and the SBOM Exchange will publish updated SBOM's to the registered subscribers. The overall schema and the relationship of the various schema elements is shown below. See Fig. 2.

[0043] Enterprise: The Enterprise object is created after signing up on the GRCPP Core Portal. A single enterprise will be created for each customer business entity. Very large corporate customers may create separate Enterprise registrations for different divisions within a conglomerate. User accounts will be created and associated with the enterprise object and all configuration, reports, artifacts and connector credential entries will be assigned to a particular enterprise. Note that enterprises are distinct customer instances which are completely isolated from one another.

[0044] Connectors: Connector instances are associated with a particular enterprise object. The connector objects represent connections to external systems. Each connector instance will contain an URL entry where RESTful requests may be made to retrieve or post data as well as the credential information needed to complete the requests. The items retrieved may be externally generated SBOM’s, externally generated artifacts, reports, or score cards, etc. Connectors are used to import or export data from the Audit product. The connectors will ensure that imported content is scanned for malware, viruses or other embedded threats before ingesting or storing content. See Fig. 3.

[0045] Component: A component represents a piece of software pulled in during the build process of a product. Components are typically libraries aggregated to perform functions required by an application. Approximately 75% of all components in modem software originate in the open-source domain. When SBOM's are ingested, each of the software components will be identified and a build of the component will be scheduled if an entry does not already exist in the Component Store for the component. The build process will recursively work though all the dependencies for a particular component. This process will ultimately result in the identification of all components within a given product. As each dependent build is executed, component entries are created in the component store. The component store is globally scoped versus being scoped to a particular enterprise. During the component build process scans, score cards and ratings will be generated and associated with the corresponding component. See Fig. 4.

[0046] Product: The Product schema object represents a single application deployed in the enterprise environment. There will be a single product object instance for each application deployed in the enterprise environment. Upon creating the Product instance, it will be necessary to either associate an SBOM with the product object or point to the connector configuration that may be used to fetch the associated SBOM. The associated SBOM will be fetched and ingested to identify the individual components that make up the product. Note that Product objects are scoped to a single enterprise versus Component objects that are globallyscoped. The Product object will point to the component instances used within the product. The product object will perform a series of calculations using the component risk scores that make up the product to generate a composite risk score for the product. Note that the product object will store the composite risk score, the vulnerability list garnered from each component, as well as dependency lists obtained by scanning the components. The Product object should have all the information required to generated enhanced SBOM without having to perform additional queries. Note that when new vulnerabilities are discovered in an existing component, it will be necessary to regenerate the product object to formulate the increased risk and assign a new unique identifier to indicate the change for tracking / audit purposes. See Fig. 5.

[0047] Product Group: A product group is a construct used to group products for the purpose of reporting or permissions. For instance, a given enterprise might deploy an IBM InfoSphere Information Server and an Apache webserver to serve the front-end. Products would be configured for InfoSphere and the Apache webserver. A Product Group named “Front End” can be provisioned to associate these products together while a back-end group could be created to associate NodeJS and SQL Server together. This will allow for consolidated reporting and risk score across both products. The Product Group may also be used to grant permissions to edit or import / export artifacts, examine or generate reports related to a particular product group versus having to individually enable each individual product. As the number of products in a particular grouping increases the utility increases. The Product Group construct can be used to exclude access to reports to implement a least privileged model. For example, the front-end team doesn’t have access to the vulnerability reports of the back-end or vice versa. Giving access to elements in a product group will inherently give access to all products within the group. See Fig. 6.

[0048] Policies: The GRCPP allows for the creation of Enforcement and Compliance Policies. Enforcement Policies will be evaluated during the software build process while Compliance Policies will be evaluated when running attestations. The subsections that follow^ will describe each policy ty pe in greater detail.

[0049] Enforcement Policies: The GRCPP can serve as a policy enforcement point to protect the software build environment. The IR Proxy is positioned between the various pipeline components allowing it to inspect and apply policy to all traffic. The IR Proxy has been designed to be protocol aware for those protocols typically used in the build environment. The IR Proxy includes an Open Policy Agent implementation which is used to enforce policies written in Rego. Each transaction occurring in the build pipeline is evaluated by the policy agent to determine if the request should proceed, proceed but issue a warning, or block thetransaction. Blocking transactions in the build pipeline may be used to stop the build process. This functionality can be used to ensure that all published software conforms with the required policies.

[0050] Examples of uses of policy might include requiring that all external libraries come from a known repository. Another example might ensure that the softw are build system cannot retrieve fdes from blacklisted sites, or post data or secrets to external servers. The IR Proxy allows flexible rules to be written using layers two through seven to make the environment secure.

[0051] Policies can be assigned at the Enterprise, Product Group, or Product level. Policies are grouped into functional units known as PolicyPaks. PolicyPaks take advantage of the ability to import base level rule files into higher level rule files.

[0052] Compliance Policies: Compliance policies are applied during the attestation process. Like Enforcement policies, Compliance Policies will be bundled into Policy Paks. Compliance Policy Paks will ty pically be organized by a standard a group of standards or Audit / Attestation forms. Examples might include NIST SP-800-217 or the CISA Atestation form. Policies may also be developed for corporate standards. An example of a corporate standard might include requiring all software builds undergo SAST / DAST scanning. The Attest application will run the configured attestations following completion of the build using the build artifacts uploading during and following the build process. Policy violations will be reported as exceptions and serious violations may result in the failure of the attestation.

[0053] Artifacts: The GRCPP will extend the schema beyond the SBOM first defined by simply scanning manifests files. All build artifacts will be stored in the Artifact Store. The additional software build artifacts will include the Build Record, Build Blob, and the Attestation. Each time a product is built a new set of build artifacts will be created in addition to any component records created if the component had not been previously seen. Each object is described in greater detail in the subsections that follow. See Fig. 7.

[0054] Build Record: A Build Record will be produced for each software build attempted in the customers build environment. The record will uniquely identify the software build and provide linkage to the SBOM and Build Blob artifacts. The linkage will allow for a complete analysis of the build or a postmortem analysis for vulnerabilities found after the fact. The build record will minimally contain the following information: Product Name, Build Number, Version, Start Time, End Time, Status (Success, Fail, Warnings), Build Farm, SBOM UID, Build Blob UID. Build Composite Risk Score. Historical trending will be possible on the risk score, or the number and severity of know n vulnerabilities contained in the builds.

[0055] SBOM: An SBOM identifies the software components utilized in building a particular product instance. SBOM’s identify the entity building the product, the date the product was built, the names and versions of the software components used during the software build process. SBOM’s also establish the dependency relationship between upstream and downstream components. The SBOM includes the name of the entity authoring the SBOM as well as the timestamp of the SBOM assembly. SBOM’s will be produced in one of three standard formats: Software Package Data eChange (SPDX), CycloneDX, or Software Identification (SWID) tags. The GRCPP platform will be able to import or export SBOM’s in all three formats. In addition to minimally required SBOM fields, the Audit solution generated SBOMS will the following recommended fields for components: Hash of the Component, License Information, and the Lifecycle Phase. Note that all GRCPP generated SBOM’s will be signed to ensure integrity and authenticity. See Fig. 8.

[0056] Build Blob: The build blob will be created during the build process and stored as an artifact in the Artifact Store. The Build Blob will include all logs, scan reports, and other pieces of evidence for a particular build. Build Blob Contents may include: SBOM, Build Logs, SAST Logs, DAST Logs, IAST Logs, Packaging Logs, License Scan Logs. Note that actual Logs or reports included within a particular blob will be a function of what scanners are included in the pipeline. All build blobs w ill include an interim SBOM whether it was created by a 3rd party tool or the IR SBOM tool. The blob will be assembled by the Build Blob Agent. The Blob will be signed upon completion of the build process to ensure that the blob cannot be modified. The blob will be posted to the IR Portal by the Build Blob Agent over a secure connection. The build blobs will be disassembled and analyzed in the GRCPP Core resulting in an updated Supercharged SBOM and statistics used to populate reporting dashboards. The original unmodified blob will be retained in the Artifact store to support audits or postmortem analysis.

[0057] Forms / Documents: The GRCPP system may store forms and documents required for the various workflows or attestations. The SBOM exchange may require that all subscribers upload a signed NDA with the software producer before receiving the updated SBOM’s from the system. The attestation process may require writen statements or a signed affidavit indicating that the organization has complied with requirements. In both cases the documents are stored and labeled in the Artifact store. All items in the Artifact Store are encrypted and digitally signed to allow- verification of their authenticity.

[0058] Atestations: The GRCPP will allow one or more atestations to be provisioned for an enterprise. Typically, an atestation will correspond with a standard or policies that mustbe followed. As software builds complete the Attest application will determine if an updated attestation is required. If a new attestation is required an attestation j ob will be scheduled to run the attestation process. The attestation process will involve pulling artifacts from the Artifact Store and running the policies in the configured Policy Paks. The Attest application will generate a attestation object and any forms required to certify compliance which will be written to the Artifact Store. For example, the Attest application will auto-fill the CISA Attestation Form and attach any required evidence by retrieving artifacts from the artifact store. Once the Attestation form is complete the workflow will notify the person responsible for signing the attestation. Once signed, the Attestation Form will be published via the Artifact Exchange and all subscribers or regulatory bodies will be notified. The Portal will allow the attestations to be monitored reporting compliance and progress across the entire enterprise.

[0059] GRCPP Architecture: The GRCPP contains a set of architectural elements to implement the required functionality and features. The outward facing components of the architecture include the User Portal, SBOM Exchange, Artifact Exchange, Build Blob Agent, SBOM Creator, and IR Proxy. The internal Core components include the Configuration Store, Component Store, Scheduler, Artifact Store, Risk Rating Engine, Exploited Vulnerability database, Vulnerability Database, Repository History database, Al Models and Policy Engine. The sub sections that follow will describe each one of the architectural elements in greater detail. A diagram of the architecture is shown below for reference. See Figs. 9 and 10.

[0060] Attest Application: The Attest application is the master controller for the entire GRCPP environment. It will be responsible for spinning up the other GRCPP components at startup. Upon start up the Attest application will read the configuration store and spin up the other components in the GRCPP environment. When all components have acknowledged they have started successfully the User Portal will be enabled allowing management of the system through the portal. The final phase of the startup process will involve scheduling periodic jobs and enabling the API’s allowing the connection of the IR Proxy, Build Blob Agent, and IR SBOM Creator.

[0061] The Attest Application will serve the IR Portal for configuration and reporting requests. The Attest Application will be notified when new SBOM’s are uploaded, Build Blobs are uploaded, or new documents are uploaded to the Artifact Store. Jobs will then be scheduled to process the uploaded data. Processing will involve performing tasks to process the uploaded data and updating the appropriate stores and databases. Note that the stores and databases may be used to generate reports, Turbo-Charge SBOM’s or generate Attestation documents. The SBOM Exchange or Artifact exchange will be responsible for delivering updated artifacts ornotifying an end-user that new artifacts are available. The SBOM Exchange will be limited to only SBOM’s while the Artifact Exchange will be responsible for distributing all artifacts other than SBOM’s. This separation is intentional since it is envisioned that there will be many subscribers for product SBOM’s potentially requiring significant resource to manage. The separation of exchanges will also assist in securing the environment since product end-users should not have access to any software build artifacts, or defect lists beyond the SBOM.

[0062] The Attest Application will also be responsible for GRCPP Platform management including system maintenance processes, system shutdown, system backup and restore tasks, as well as failure recovery or disaster recovery.

[0063] User Portal: The user portal will be responsible for managing all external user interactions. The user portal will generate the user interface needed to run the entire system. If shall enforce permissions to ensure that only authorized users are able to view or modify the configuration of the system or the artifacts generated or reported by the system. Note that the user portal will limit access to system resources to a single Enterprise. This will ensure separation between organizations and ensure that data leaks do not occur. The portal will also be used to examine the reports created by the system.

[0064] Build Environment: The GRCPP product architecture contains an internal build environment as well as a remote build environment. The remote build environment will usually be deployed within the customer environment. The IR Proxy, IR SBOM Creator, and the Build Bloc agent will run within containers in the customer build environment. The software will initially be deployed in docker containers although other options may be made available. Additional containers may optionally be deployed to perform SAST, DAST, IAST and license scans if the customer does not already have a comparable solution deployed. The subsections that follow will provide more detail on the containers. See Fig. 11.

[0065] IR Proxy: The IR Proxy must be deployed centrally in the software build environment to provide complete visibility. The proxy will capture and examine all traffic passing through. The policy engine will inspect the traffic and apply policy as configured. This may result in the generation of alerts, blocking traffic, or no action at all. The policies will be packaged in predefined Policy Paks for the most popular build system configurations. It will be possible to customize or extend the policies as required.

[0066] IR SBOM Creator: The IR SBOM Creator is a tool that may generate Turbo- Charged SBOM's during the build process. Alternately if an alternate 3rd party tools is used to generate the SBOM, the SBOM Creator will read the SBOM as input and output a Turbo- Charged SBOM. The IR SBOM Creator will generate a Turbo-Charged SBOM in cases whereno other existing SBOM tool exists. The tool will inspect manifest files and other build logs as well as evaluate the output of the IR Proxy to generate the Turbo-Charged SBOM. The IR SBOM Creator will transfer the standard SBOM to the GRCPP Core for additional processing and storage in the Artifact Store.

[0067] IR Build Blob Agent: The IR Build Blob Agent is responsible for capturing build artifacts related to a particular build. The artifacts may include build logs, scanner logs (SAST,DAST, IAST, and license), OS Error Logs, and any other security or code quality tools. The Build Blob will be compressed and encrypted prior to sending it via a secure channel to the GRCPP Core. Upon reception, a copy of the Blob will be unpacked for processing. Processing may examine one or more of the artifacts to detect build errors or updating the build risk score based on the security scan output contained in the blob. The original Blob will be archived in the Artifact Store in its original compressed and encrypted form. In the event of communication failures transmitting blobs to the IR Cloud, blobs will be queued and retransmitted when the channel comes up again. The IR Build Blob Agent will be responsible for establishing and maintaining the communication channel.

[0068] SAST: Static Application Security Testing tools typically run scans on source code looking for not problematic constructs. These tools will usually generate reports that point to potential issues. The tools can be problematic as they tend to identify a high number of false positives. Usually controls exist to sort the findings by severity and it is usually possible mark exceptions that will not be reported in the next scan. The process is usually iterative where resources need to be assigned to investigate reported issues and actual defects are fixed and false positives are marked as exceptions. The secret to successfully using SAST tools is to place them in the development pipeline from the creation of the software. Unfortunately, SAST testing is usually added after the fact creating a monstrous backlog of issues leading to a continuous effort to reduce issues potentially creating new issues in the process. If a SAST scanner has been deployed in the pipeline the Build Blob Agent will capture the logs / reports and add it to the Build Blob.

[0069] DAST: Dynamic Application Security Testing tools typically run tests against actual deployment of the software under test. API requests on a running server instance. The DAST scanner will run requests meant to simulate request traffic coming from a user interface or an API client. The parameters can be varied to ensure that the input is properly validated by the server under test and the correct error codes are returned. DAST tools exist to test the OWASP top 10 as well as the OWASP API top 10. InvisiRisk will make use of ZAP or other open-source tools to perform DAST testing in the cloud on open-source builds. The DASTcontainer may also be deployed in customer environments if the customer has not deployed a commercial 3rd party solution. Either way if a DAST scanner has been deployed in the pipeline the Build Blob Agent will capture the logs / reports and add it to the Build Blob.

[0070] IAST: Interactive Application Security Testing tools instrumented and a set of tests are then run. The code under test is instrumented by a set of sensor libraries included in the application code. The sensor modules will track application behavior while interactive tests are running. Vulnerabilities or suspect behavior can be detected by the sensors in real-time and alerts may be sent. Examples of issues found by IAST may include clear text hardcoding of API keys, not sanitizing user inputs, or opening network connections without SSL encryption. If an IAST tool has been deployed in the customer pipeline the Build Blob Agent will capture the logs / reports and add it to the Build Blob.

[0071] License Scanner: The license scanner will examine all files in the various repositories with the intent of identifying and classifying the license types used within the product. The license scan results may be used in policies to ensure that the product being built complies to corporate licensing policies. This is meant to ensure that copyleft licenses are not accidentally inserted into a closed source commercial product rendering the consuming product as open source. Licenses may also have contribution and publication requirements that may conflict with corporate policy. If the customer environment has an existing tool the license report may be harvested from the environment. If the customer does not have a license scanner deployed the InvisiRisk scanner may be deployed. Initially InvisiRisk will use the open-source NexB Scancode application although this may change over time. Reports and warnings will be available for each product build as well as being sent to the Artifact Store in a Build Blob.

[0072] Core Infrastructure: The GRCPP Core houses a software build environment used to build open-source components. The GRCPP Core build environment is similar to what is deployed within the customer environment. The GRCPP build environment may be used to build updated components thereby pre-seeding the component store. The difference is that the software being built in the GRCPP Core is always open-source components while the customer environment may also build proprietary code. The GRCPP Core component build environment also deploys code scanners to detect flawed code as well as potential vulnerabilities. The scanner results and build logs will be analyzed following each build. A component record will be created to memorialize the analysis and its findings which will be stored in a component record within the component store. When new' SBOM’s are uploaded, the component store will be consulted to see if the component has already been seen. If not, a component build will be scheduled and analyzed upon completion. Note that the scope of the component store isglobal across all customers. This will greatly reduce the number of component builds required over time. In addition to SBOM triggered builds, a periodic scan may be performed to build updated versions of component libraries essentially pre-populating the Component Store. The component store will initially be seeded by building the top 200 included open-source components as identified in the “Census II of Free and Open Source Software-Application Libraries” report (https: / / www.linuxfoundation.org / hubfs / Research%20Reports / lfr_harvard_censusll_ mar2022_042824b.pdf?hsLang=en). See Fig. 12.

[0073] Configuration Store: The configuration is used to house the various configuration elements. The Enterprise objects, Enterprise User objects, Product objects, Product Group objects, Policy / Policy Paks and Connector objects will be stored in the Configuration Store. The Enterprise object is the master object from which all other configuration objects emanate.

[0074] Artifact Store: The Artifact Store will house records ingested by the system or created during the software build process. The Artifact Store will house ingested SBOM’s, enhanced SBOM’s, Build Records, and Build Blobs. Objects in the Artifact Store are scoped to the product and software build.

[0075] Scheduler: The scheduler is the architectural component responsible for initiating scheduled activities. This will typically involve an API call to schedule a one-shot execution of a job task or a periodic reoccurring job task. An example of a one-shot task might be to build a newly identified component, while a reoccurring task might be periodically scanning the vulnerabilities list for new vulnerabilities. The scheduler will ensure that all tasks are executed in a timely fashion and the system will monitor task execution to add or remove resources as needed to ensure timely execution of tasks. All scheduled tasks will generate audit log entries indicating the start / end time, all outcomes (error or success), as well as periodic performance metrics.

[0076] SBOM Exchange: The SBOM Exchange is an application that allows vendors to publish SBOM’s that will be imported by the GRCPP platform for processing and enrichment. The analysis process will systematically analysis the components of the software product calculating risk scores for each component and the overall product. Each component will also be evaluated against a list of known vulnerabilities providing a complete list for each product. When the process is complete an updated SBOM will be generated which can be distributed to parties subscribing to the updates, The SBOM exchange will ensure that all necessary contracts and agreements are in place prior to accepting vendor data or publishingupdated data. The subsections that follow will describe the Publish and Subscribe functionality.

[0077] Publish: The Publish feature will be used by software vendors to publish their SBOM’s to software customers. An enterprise must be created and the Publish feature must be licensed to enable this functionality. The software vendor will be able to provision the products that SBOM’s will be published. The vendor will also provision the connector to the vendor site allowing updated SBOM’s to be retrieved when new builds are available. Software vendors may opt to only purchase the GRCPP Publish feature which will allow customers approved by the vendor to subscribe to SBOM updates. Essentially allowing the GRCPP to manage the process of distributing SBOM’s and ensuring that all required paperwork (NDA’s, Licenses, etc.) is on file before distributing the SBOM’s. If the software vendor purchases the full GRCPP feature set they will have access to the Turbo-Charged SBOM and the vendor may choose to publish either the retrieved SBOM or the Turbo-Charged version.

[0078] Subscribe: The Subscribe feature will be used by software consumers to receive updated SBOMS’s when vendors release new builds of software. An enterprise must be created and the Subscribe feature must be licensed to enable this functionality. The administrator will provision the products to be monitored and provide the path and credentials provided by the software vendor to retrieve SBOM’s updates. The credentials and retrieval path are provisioned by creating a connector to the vendor site. The GRCPP Platform will monitor the vendor site for updated SBOM’s. When an updated SBOM is detected, the configured contacts will be notified and a REST PUT may be performed to deliver the updated SBOM. Software consumers may have been directed to use the GRCPP Platform by the software vendor (In cases where the vendor has outsourced SBOM delivery to GRCPP) to receive SBOM updates. The software consumer may opt to purchase the GRCPP full feature set which will analyze the SBOM supplied by the vendor and enrich the data performing a full risk analysis. The full product will provide reports allowing software the consumer to monitor the risk of software being deployed. The full product will also provide a comparison report showing a comparison against the Original and enhanced SBOM.

[0079] Artifact Exchange: The Artifact Exchange is an application built to store into and distribute artifacts from the Artifact Store. The Artifact Store provides the home for the various items created and ingested by all parts of the system. Artifacts could include uploaded agreements, signed exception documents for attestations, affidavits for compliance / attestations, Build Blobs (build logs, scan reports, etc. see Build Blob in Schema for more details) and attestation forms and the associated evidence. The Artifact Exchange isresponsible for enforcing access to all artifacts as well as securing artifacts to ensure that they cannot be modified or altered once created. The artifact exchange will produce an audit log recording when artifacts are stored and retrieved. The audit log will provide a means to audit the chain of custody for all stored artifacts.

[0080] Publish: The Publish feature will be used by software vendors to publish their Attestations or other artifacts for Products, Product Groups, or the Enterprise to software customers or Government Agencies. An enterprise must be created and the Publish feature must be licensed to enable this functionality. The software vendor will be able to provision the Artifacts that w ll be published for a particular subscriber or governmental agency. Essentially allowing InvisiRisk to manage the process of distributing Attestations and supporting evidence with the assurance that the proper paperwork (NDA's, Licenses, etc.) has been filed before distribution.

[0081] Subscribe: The Subscribe feature will be used by software consumers or governmental agencies to receive updated Attestation and evidence when vendors release new builds of software. An enterprise must be created for the subscribing organization and the software vendor must be licensed for this feature. The vendor administrator will provision the products to be published and provide the path and credentials required by the subscriber to retrieve the Attestations or Artifacts. The credentials and retrieval path are provisioned by creating a connector identifying the publishing endpoint. When an updated Artifact is detected, the configured contacts will be notified to retrieve the Artifacts by logging into the GRCPP User Portal. Alternately a subscriber delivery endpoint may be provisioned and the content can be delivered via a REST PUT request.

[0082] Build Record Store: The Build Records will be stored in the Artifact Store. Build summary’ records will be written for all Product builds performed by the system. Each time a build is initiated for a product a new’ build summary record will be generated. It will include a reference to the product being built, build number and version, as w ell as a pointer to the Build Blob corresponding to a particular build instance. Note that the build record w ill also point to the SBOM generated for a particular build instance which is stored in the artifact store. See Fig. 13.

[0083] Component Store: The Component Store will house records created when an SBOM is ingested by the system. The component store will contain information regarding the provenance of the component. Minimally each component entry will contain the following information: unique identifier, author, date created, source / project path, license type, version, know n vulnerabilities, dependencies, hash / checksum, and creation language. The informationshould be sufficient to uniquely identify any component. The Component Store is a system- wide resource and is therefore not scoped to any one enterprise. As SBOM’s are ingested by the system, a search will be performed to determine if a component entry already exists and new entries will only be created if no existing entry is found. The existing entry will be used in the case of a match. Periodically the entire component list will be compared against recently- discovered vulnerabilities and entry will be updated if necessary.

[0084] Component Build Environment: The component build environment resides in the GRCPP Core. It is used to build and analyze the components identified from the imported SBOM’s. The micro-service architecture allows new analyzers to be added to further enrich the SBOM data over time. Note that scheduled component builds will result in the Component Stores entries being updated. After all builds and analysis for all components within the SBOM have been completed the SBOM will be enriched with the newly discovered data. The updated enriched SBOM will then be placed in the Artifact Store and a notification will sent to the SBOM exchange to notify any subscribers monitoring the associated product.

[0085] The IR Proxy is positioned between all build system components and the outside world. The proxy will see all traffic related to building the component including all package downloads from the various repositories as well as all http post in or out of the build environment. The proxy will be able to log all transactions and apply policy to limit or warn of adverse transactions. The IR Proxy will ensure that the dependencies list is complete ensuring that all known vulnerabilities are identified. Scans may also be run against the components and the results will be used to calculate the component risk score. See Fig. 14.

[0086] Policy Engine: The policy engine is based on the Open Policy Agent(OPA). The policies may be categorized as static or dynamic. Static policies can be evaluated without the need to converse with external systems. An example of a static policy might be whitelisting or blacklisting an IP address. Dynamic policies allow external data sources to be queried to make a policy decision. The proxy will forward requests for each transaction to the policy engine for evaluation. The static policies will first be applied if applicable followed by evaluation of dynamic policies.

[0087] Before evaluation the policy engine will establish the transactional context. The context will include information like the source and destination of the request as well as the protocol, ports, and any information parsed by the IR Proxy. Additional context will be gathered as necessary to evaluate the static policies and additional context may be added as necessary to evaluate the dynamic policies. The goal will be to minimize policy evaluation time caching results where applicable to further speed up the process.

[0088] The policy engine may also contact a risk rating engine which will access the transaction risk based on analytical or Al models. A policy may choose different resultant actions based on transactional risk. For instance, a commit transaction may be blocked if the risk engine determines the risk is too high based. See Fig. 15.

[0089] The execution of the policy engine will result in an action to be taken by the IR Proxy for the request or the response. The action may be one of the following: Block, Forward, or Redirect. Note that the default response will be configured to Forward the traffic if no policies are applicable. The default response may also be changed to block requests with no applicable policies essentially requiring policies exist for all traffic.

[0090] Risk Rating Engine: The Risk Rating Engine will compute risk scores when requested to do so by the Policy Engine. The rating request will include the transactional context forwarded by the IR Proxy as well as any enrichments performed by the Policy Engine itself. The Risk Rating Engine may consult external sources to gather additional information to compute the risk score. The risk score may be used by the policy engine to determine the action to be taken by the requests. The Risk Rating Architecture is shown below. See Fig. 16.

[0091] The risk score will be a number zero (0) to one hundred (100) where 0 represents no risk and 100 represents certain risk. Over time new Al models and additional external sources may be added to extend the Risk Rating Engines capabilities and accuracy.

[0092] IP Address Reputation Databases: The Risk Rating engine may consult an IP Address Reputation Database to the source or destination address of the requests and responses intercepted by the proxy. The reputation databases will allow suspect domains of addresses to be identified as adding risk to any interaction. One or more such databases may be consulted by the risk engine and the resultant decision will be cached for future transactions. A job will be scheduled to periodically update the local copies of the databases if they are stored locally.

[0093] Vulnerability Databases: The Risk Rating engine may consult one or more known vulnerability databases to assess the risk of an included dependency or package. The vulnerabilities databases will identify known vulnerabilities present in external dependencies. Vulnerabilities in dependencies increase the risk of the resultant product that includes them. One or more such databases may be consulted by the risk engine and the resultant decision will be cached for future transactions. A job will be scheduled to periodically update the local copies of the databases if they are stored locally.

[0094] Exploited Vulnerability Database: The Risk Rating engine may consult one or more known exploited vulnerability databases to assess the risk of an included dependency or package. The exploited vulnerabilities can be used to further qualify’ the risk associated withvulnerabilities found within a product. While many vulnerabilities existing in a product are never exploited vulnerabilities on the exploited list have documented cases of exploitation. Exploited vulnerabilities represent a much greater risk resulting in a higher risk score. One or more such databases may be consulted by the risk engine and the resultant decision will be cached for future transactions. A job will be scheduled to periodically update the local copies of the databases if they are stored locally.

[0095] Repository History: The Risk Rating engine may consult the repository history when the transaction being rated involves a modification of a code repository. The repository history can be used to rate the transaction risk based on past behavior. For instance, if commit is made by a senior engineering executive who has no history with the code base it is likely fraudulent. Bad actors will often spear phish senior team members identities knowing they most often have access to all the infrastructure. Performing a risk assessment using repository histor ■ can ensure such attacks are thwarted. A job will be scheduled to periodically update the local copies of the databases if they are stored locally.

[0096] Al Models: The Risk Rating engine may consult one or more Al models to rate the request or response captured by the proxy. The models may be trained to recognize suspect transactions thereby avoiding corruption of the build environment and ultimately the shipped product. The rating engine can consult the Al models to assess transactional risk or use an Al model to calculate composite risk across the multiple dependencies that make up the product being built.

[0097] GRCPP Use Cases:• Allows ingestion of vendor supplied Software Build of Materials (SBOM’s) in multiple formats.• Supports ingestion via deployment of the IR PAF Proxy in the build environment.• Identifies and analyzes all components within a software product.• Catalogues components data allowing for historical or what if analysis.• Provides a risk score for each identified component.• Evaluates component licensing versus policy.• Identifies deficiencies or omissions in vendor supplied SBOM’s.• Identifies known component vulnerabilities.• Supports integration with 3rdparty scanners & code evaluation platforms.• Generates composite product risk score.• Flags affected software when new vulnerabilities are identified.• Provides risk / vulnerability monitoring reports.• SBOM Exchange: Manages documentation and agreements (NDA’s, Licenses, etc.); Catalogues ingested SBOM's in the Artifact Store for historical studies; Allows for continual update of vendor SBOM’s with risk monitoring; Allows the export of SBOM’s in the SPDX, CycloneDX, or SWID formats; Allows signing of exported SBOM’s to ensure integrity.• Identifies system build components.• Monitors build infrastructure and versions.• Protocol aware inspection of protocols used by build tools.• Monitors IP traffic within build environment enforcing policy.• Allows halting build or distribution for severe policy violations.• Enforces access / protects build system components from tampering or modification.• Deployable in cloud or premise build environment.• Out of the box integration with IR supplied SCA, SAST, DAST, and IAST tool set.• Interfaces with customer’s existing 3rdparty SAST, DAST, and IAST tools.• Calculates OpenSSF scorecard for products and components.• Provides complete audit capability for all components on every product build.• Al generated build composite risk score for product builds.• Ability to stop distribution if product build exceeds risk threshold.• Al driven risk analysis of applications recommending risk reduction scenarios.• Supports the following types of policies out of the box:- Block / Notify downloads from domains, IP addresses, or subnets.- Block / Notify writes or uploads to file systems, repositories, domains, IP addresses, or subnets.- Redirect writes or uploads to file systems, repositories, domains, IP addresses, or subnets to a decoy honey pot or security trap.- Compute and validate hashes of downloaded dependencies.- Validate versions of downloaded dependencies.- Block / Notify file writes to sensitive directories or repositories independent of ID (Zero trust).- Redirect file writes to sensitive directories or repositories independent of ID (Zero trust) to a decoy honey pot or security7trap.- Blocks exfiltration of secrets (Key. passwords, credentials, etc).- Prevents accidental or intentional insider breaches.- Blocks malicious or intentional insider threat modifications of sensitive files.- Block / Stop / Notify if risk score of included dependency exceeds threshold.- Stop / Notify if package download is attempted from a blocked source.- Stop / Notify if blocked mime types are detected in request / response.- Stop / Notify if package download is attempted from an unapproved source.- Stop / Notify if vulnerability with risk score xx or higher is detected.- Stop / Notify if secrets are passed in build calls.- Stop / Notify if recent change in package ownership is detected.- Stop / Notify if file downloads of size greater than xx bytes is detected.- Stop / Notify if unapproved package managers are used.- Stop build if critical code vulnerability is detected.- Stop build if sensitive data is detected in code.- Stop build if CI instructions are misconfigured or insecure.- top build if laC instructions are misconfigured or insecure.• Supports the creation of custom policies.• SBOM / Artifact Exchange: Manages documentation and agreements (NDA’s, Licenses, etc.); Catalogues all ingested artifacts in the Artifact Store for historical studies; Allow s for continual update of vendor tools with risk monitoring; Captures and archives build artifacts; Allows signing of exported artifacts to ensure integrity.• Allows the creation of Governance Policies and monitors for compliance.• Provides detailed reports on compliance violations dow n to product build.• Provides Al enabled automation to populate and certify attestation documents.• Supports CISA and NIST-SP-800-218 attestation with others to follow.• Attestation available at the Enterprise, Product Group, or Product level.• Artifacts used in attestation packaged as evidence.• Extends Artifact Exchange to allow publication of Attestations and evidence.• Provides attestation dashboard allowing compliance to be continuously monitored.• Al based recommendations to improve security and compliance.

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

Claims

WHAT IS CLAIMED IS;1. A security system useable by a developer organization that builds a software product using a continuous integration / continuous deployment system and in accordance with a standard comprising a plurality of requirements, wherein the system is implemented as a plurality of network nodes each implementing one or more services connected to a network including a build controller service, the system comprising: a proxy operable to capture communications issued by the one or more services connected to the network; a platform decision logic service connected to the network comprising: a configuration database comprising the lurality of requirements; an attest application configured to determine for each of the plurality of requirements first evidence and / or second evidence that must be assessed to determine whether the developer organization has complied with that requirement when building the software product, and generate a Graphical User Interface (GUI) for the developer organization at a portal, wherein the GUI is configured to receive the first evidence; and an artifact collector connected to the network configured to retrieve the second evidence, wherein the second evidence is retrieved using the proxy and comprises build artifacts originating from operation of the build controller service; wherein the attest application is configured to assess each requirement and the first and / or second evidence relevant to that requirement to determine an individual compliance score for that requirement, and generate a report including an attestation indicating whether the software product is compliant with the standard.

2. The system of claim 1, wherein the platform decision logic service further comprises an artifact database configured to store the first evidence and the second evidence.

3. The system of claim 1, wherein the first evidence comprises one or more of: a software license; indicia that the developer organization has complied with security training requirements; or indicia of compliance with multifactor authentication requirements.

4. The system of claim 1, wherein the report comprises a listing of the requirements.

5. The system of claim 4. wherein the report further comprises an indication of the first and / or second evidence relevant to each of the requirements.

6. The system of claim 4, wherein the report further comprises the individual compliance score for each of the requirements.

7. The system of claim 1, wherein the attest application is configured to allow a representative of the developer organization to electronically sign the report using the GUI.

8. The system of claim 7, wherein the platform decision logic is configured to automatically distribute the report to customers of the software product.

9. The system of claim 8, wherein the platform decision logic is configured to electronically sign the first and second evidence to confirm its authenticity in the security system.

10. The system of claim 1, wherein the attest application is further configured to determine using the individual compliances scores whether the software product has passed or failed attestation of the standard.

11. The system of claim 10, wherein the attest application is further configured to determine an overall compliance score for the software product, wherein the overall compliance score is used to determine whether the software product has passed or failed attestation of the standard.

12. The system of claim 11, wherein the report comprises the overall compliance score for the software product.

13. The system of claim 1, wherein the first evidence originates in the build controller service.

14. The system of claim 1, wherein the artifact collector comprises a build blob agent.

15. The system of claim 1, wherein the platform decision logic further comprises a scheduler, wherein the scheduler is configured to enable the attest application at various times.

16. The system of claim 1, wherein the compliance score indicates a percentage of compliance.

17. The system of claim 1, wherein the platform decision logic service comprises a risk rating engine, and wherein the attestation process determines the compliance score for each requirement using the risk rating engine.

18. The system of claim 17, wherein the risk rating engine queries one or more compliance packs during the attestation process.

19. The system of claim 17, wherein the risk rating engine queries an artificial intelligence model database.

20. A method useable by a developer organization in a security system that builds a software product using a continuous integration / continuous deployment system and in accordance with a standard comprising a plurality of requirements, wherein the system is implemented as a plurality of network nodes each implementing one or more services connected to a network including a build controller service, the method comprising: using a proxy operable to capture communications issued by the one or more services connected to the network; using an attest application to determine for each of the plurality of requirements first evidence and / or second evidence that must be assessed to determine whether the developer organization has complied with that requirement when building the software product, andgenerate a Graphical User Interface (GUI) for the developer organization at a portal, wherein the GUI is configured to receive the first evidence; and using an artifact collector connected to the network configured to retrieve the second evidence, wherein the second evidence is retrieved using the proxy and comprises build artifacts originating from operation of the build controller service; further using attest application to assess each requirement and the first and / or second evidence relevant to that requirement to determine an individual compliance score for that requirement, and generate a report including an attestation indicating whether the software product is compliant with the standard.

21. The method of claim 20, further comprising storing the first evidence and the second evidence in an artifact database connected to the network.22 The method of claim 20, wherein the first evidence comprises one or more of: a software license; indicia that the developer organization has complied with security training requirements; or indicia of compliance with multifactor authentication requirements.

23. The method of claim 20, wherein the report comprises a listing of the requirements.

24. The method of claim 23, wherein the report further comprises an indication of the first and / or second evidence relevant to each of the requirements.

25. The method of claim 23, wherein the report further comprises the individual compliance score for each of the requirements.

26. The method of claim 20, wherein the attest application further allows a representative of the developer organization to electronically sign the report using the GUI.

27. The method of claim 26, further comprising automatically distributing the report to customers of the software product.

28. The method of claim 27, further comprising electronically signing the first and second evidence to confirm its authenticity in the security system.

29. The method of claim 20, wherein the attest application further determines using the individual compliances scores whether the software product has passed or failed attestation of the standard.

30. The method of claim 29, wherein the attest application further determines an overall compliance score for the software product, wherein the overall compliance score is used to determine whether the software product has passed or failed attestation of the standard.

31. The method of claim 30, wherein the report comprises the overall compliance score for the software product.

32. The method of claim 20, wherein the first evidence originates in the build controller service.

33. The method of claim 20, wherein the artifact collector comprises a build blob agent.

34. The method of claim 20, further comprising using a scheduler to enable the attest application at various times.

35. The method of claim 20, wherein the compliance score indicates a percentage of compliance.

36. The method of claim 20, wherein the system comprises a risk rating engine connected to the network, and wherein the attestation process determines the compliance score for each requirement using the risk rating engine.

37. The method of claim 36, wherein the risk rating engine queries one or more compliance packs during the attestation process.

38. The method of claim 36, wherein the risk rating engine queries an artificial intelligence model database.

Images