Techniques for identifying and verifying security control steps in software development pipeline

Abstract

Systems and methods for identifying security control steps in a software development pipeline. A method includes enumerating a plurality of steps in a software development infrastructure by analyzing software development pipeline data of the software development infrastructure, where each step includes a set of computer instructions for executing at least one task; identifying a plurality of step attributes for each of the plurality of steps in the step data of the steps; and classifying at least one of the plurality of steps as a security control step based on the plurality of step attributes identified for each of the plurality of steps, where each step classified as a security control step includes instructions for at least analyzing the code to determine whether at least one security requirement is met.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Non - Provisional Patent Application No. 17 / 664,315, filed on May 20, 2022, which is currently pending, and the content of which is incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to analyzing software development pipelines, and more particularly, to identifying and contextually analyzing steps that serve as security control steps in a software development pipeline. Background Art

[0004] As the business of digital transformation continues to develop, the software development life cycle has become a key component of many successful enterprises. Although the increasing number of software used is expected to greatly improve the way services are delivered, software development remains an ongoing challenge. In particular, due to the rapid growth of the development speed, software is created and deployed faster than ever, and software development infrastructure must often be rapidly scaled up to adapt. As more and more software is created, methods for identifying and resolving problems in the software development process, and more specifically, automated tools to assist in such remedies, are becoming increasingly popular.

[0005] In addition, due to the large amount of software being created and significant investment in DevOps - driven delivery automation, complex continuous integration / continuous delivery (CI / CD) pipelines using on - premise or cloud - native technologies to build, deploy, and control the entire application stack have been adopted. These pipelines can control everything from infrastructure to business logic, and the interactions between components in the software environment can no longer be effectively managed manually by human operators alone. Due to these issues, companies' security teams are seeing an increase in business risks and employee burnout. In addition, once security vulnerabilities are introduced via newly created defective software, companies face challenges in effectively reducing risks.

[0006] In a software development pipeline, various security measures can be implemented. Existing gatekeeping management solutions typically involve manually inserting audit, verification, or control steps in the pipeline based on recommended best practices. However, this process can be subject to human error. In particular, human operators often lack visibility into the software development pipeline, making it difficult to effectively evaluate where security measures are needed. Even if a human operator has some understanding of each pipeline, as different teams work on their respective pipelines, the components in different pipelines and the ways different pipelines interact can change rapidly, making it impractical to follow and understand pipeline definitions, even at the most optimistic assessment. Therefore, existing solutions often fail to install control steps, and such security measures can objectively improve the cybersecurity of the pipeline.

[0007] Therefore, it would be advantageous to provide a solution that overcomes the above challenges. SUMMARY OF THE DISCLOSURE

[0008] The following is an overview of several example embodiments of the present disclosure. This overview is provided to facilitate a basic understanding of these embodiments by the reader and does not fully define the scope of the present disclosure. This overview is not an extensive overview of all contemplated embodiments, nor is it intended to identify key or important elements of all embodiments or to describe the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description presented later. For convenience, the term "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or multiple embodiments of the present disclosure.

[0009] Certain embodiments disclosed herein include a method for identifying security control steps in a software development pipeline. The method includes: enumerating a plurality of steps in a software development infrastructure by analyzing software development pipeline data of the software development infrastructure, wherein each step includes a set of computer instructions for performing at least one task; identifying a plurality of step attributes for each of the plurality of steps in the step data of the steps; and classifying at least one of the plurality of steps as a security control step based on the plurality of step attributes identified for each of the plurality of steps, wherein each step classified as a security control step includes instructions for at least analyzing code to determine whether at least one security requirement is met.

[0010] Certain embodiments disclosed herein further include a non-transitory computer-readable medium having stored thereon a process that causes a processing circuit to perform a process that includes: enumerating a plurality of steps in a software development infrastructure by analyzing software development pipeline data of the software development infrastructure, wherein each step includes a set of computer instructions for performing at least one task; identifying a plurality of step attributes for each of the plurality of steps in the step data of the steps; and classifying at least one of the plurality of steps as a security control step based on the plurality of step attributes identified for each of the plurality of steps, wherein each step classified as a security control step includes instructions for at least analyzing code to determine whether at least one security requirement is met.

[0011] Certain embodiments disclosed herein also include a system for identifying security control steps in a software development pipeline. The system includes: a processing circuit; and a memory that contains instructions that, when executed by the processing circuit, configure the system to: enumerate a plurality of steps in a software development infrastructure by analyzing software development pipeline data of the software development infrastructure, where each step includes a set of computer instructions for performing at least one task; identify a plurality of step attributes for each of the plurality of steps in the step data; and classify at least one of the plurality of steps as a security control step based on the plurality of step attributes identified for each of the plurality of steps, where each step classified as a security control step includes instructions for at least analyzing code to determine whether at least one security requirement is met. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The subject matter disclosed herein is particularly pointed out and distinctly claimed in the claims at the end of the specification. The above and other objects, features, and advantages of the disclosed embodiments will be apparent from the following detailed description when taken in conjunction with the accompanying drawings.

[0013] Figure 1 is a network diagram for describing various disclosed embodiments.

[0014] Figure 2 is a flowchart showing a method for identifying security control steps in a software development pipeline according to an embodiment.

[0015] Figure 3 is a flowchart showing a method for classifying steps in a software development pipeline according to an embodiment.

[0016] Figure 4 is a flowchart showing a method for creating a knowledge base of semantic concepts and infrastructure values according to an embodiment.

[0017] Figure 5 is a schematic diagram of a security control step finder according to an embodiment. DETAILED DESCRIPTION

[0018] It is important to note that the embodiments disclosed herein are merely examples of many useful applications of the innovative teachings herein. In general, statements in the specification of this application do not necessarily limit any of the various claimed embodiments. Additionally, some statements may apply to some of the inventive features but not to others. In general, unless otherwise stated, without loss of generality, a singular element may be plural and vice versa. In the drawings, the same numbers refer to the same parts in several views.

[0019] In view of the above-described challenges of increasingly rapid and complex software development, it has been recognized that tools that allow for more visibility into the software development life cycle can be utilized to automatically identify security control steps in a software development pipeline. Specifically, in order to improve visibility into the status of security control steps, techniques for identifying, mapping, and validating security control steps (e.g., analyzing instruction sets that violate security requirements) are highly desirable. Additionally, techniques for automatically and accurately generating context insights regarding security control steps within a software development pipeline are also highly necessary. The disclosed embodiments provide various techniques for providing such visibility and vulnerability detection regarding security control steps in a software development pipeline.

[0020] The disclosed embodiments include techniques for identifying and validating security control steps. Using software development pipeline data of one or more pipelines in a software development infrastructure, the steps of the pipeline are enumerated. Each step is a set of instructions that together define a process to be executed in the software development infrastructure. The enumerated steps are classified at least according to whether each step is a security control step. Each security control step performs a task related to protecting the software development infrastructure, specifically at least for analyzing code or configuration to determine whether security requirements are met or violated.

[0021] Based on the classification of the steps, the context of each security control step is determined. More specifically, the context is determined based on the deployment of each security control step relative to other components of the software development infrastructure and can also be determined based on the role of these other components within the software development infrastructure. The deployment of security control steps within each pipeline or within the software development infrastructure can be validated based on the context of each security control step and the type of security vulnerability that the security control step is intended to identify.

[0022] The various disclosed embodiments also include techniques for mitigating potential cybersecurity vulnerabilities associated with security control steps or the lack thereof. Potential vulnerabilities in the pipeline can be identified when a control step fails to be successfully validated (e.g., when the control step is deployed within the pipeline in a manner that prevents it from completing its intended task) or when a control step is absent at a location where security measures defined for the software development pipeline are required (e.g., a location in the pipeline map where security measures are known to be required). For example, potential vulnerabilities can be mitigated by sending a notification instructing a software developer to deploy a control step, by installing a control step, by changing the deployment of a control step relative to the software development pipeline, etc.

[0023] In various disclosed embodiments, a knowledge base can be utilized to enumerate and map steps, as well as retrieve information for classifying steps. The construction of the knowledge base includes an entity graph and a semantic concept dictionary. The knowledge base can be queried for entity identification values indicating entities in a software development infrastructure, semantic concepts identified in cybersecurity event data, or both, to identify the connection paths between event logic component entities and software component entities (e.g., policies that trigger cybersecurity events and software components).

[0024] A software component is a discrete logical component of a software development infrastructure and can include, but is not limited to, programs, functions, files, software containers, software layers, repositories, commits, binaries, pipelines, production assets, servers, workloads, databases, security tools (e.g., source code inspection tools, binary inspection tools, runtime environment observation tools, etc.), configuration definitions, scripts, modules, libraries, combinations thereof, or portions thereof, etc. Any software component can be contained within a discrete hardware component or can be a logical component stored on the same hardware component.

[0025] According to various disclosed embodiments, an entity can also include steps of a software development pipeline, particularly security control steps. Each step is a program that includes a set of instructions for performing a given task or a set of tasks. A security control step performs tasks related to cybersecurity or quality. Each step is a program that can access the pipeline computing environment. Such access can include integration with third-party systems or services. To this end, each step can use one or more functions or other code sets to perform its respective tasks.

[0026] In some implementations, an entity in the entity graph can also include a node representing a code owner (e.g., an engineer or programmer who wrote or is otherwise responsible for the code in any software component) based on predetermined information about the person responsible for each piece of code. Such a code owner node allows for the identification of the person responsible for a given part of the pipeline. This, in turn, allows for the accurate and automatic identification of the best person to receive reports related to the presence or absence of security control steps (including but not limited to a pipeline map showing where control steps are deployed within the pipeline, contextual insights for incorporating control steps into the pipeline, etc.). Alternatively or in combination, an entity in the entity graph can also include nodes representing other members of an infrastructure team, a devops team, or an operations team.

[0027] The disclosed embodiments provide visibility into the development operations (DevOps) pipeline of an organization's software development infrastructure and allow for the automatic or semi-automatic identification of security control steps, as well as the mitigation of potential cybersecurity vulnerabilities that may be due to the lack of security control steps at specific locations within the software development pipeline. Entity diagrams and semantic concepts can be defined relative to various entities and concepts of the software development life cycle (SDLC), such that the disclosed embodiments can be integrated across the SDLC to allow for the enforcement of policies throughout the SDLC. The disclosed embodiments can initially be used during software development to identify issues in real time when developing and promoting software.

[0028] More specifically, the disclosed embodiments allow steps of a software development infrastructure (e.g., steps within a software development pipeline) to be mapped relative to other components of the infrastructure, thereby allowing the relative position of the steps to the software development infrastructure to be defined. This, in turn, allows for the effective determination of whether control steps are misaligned or missing under normal use of such security steps, and whether the deployment of the control steps hinders their intended purpose. Accordingly, the disclosed embodiments allow for the generation of insights that help guide the manual correction of potential security vulnerabilities and / or the automatic remediation of such vulnerabilities.

[0029] The disclosed embodiments provide techniques for analyzing steps that include recursively enumerating the layers of a software development infrastructure, which in turn allows for an understanding of the relationships between components within each layer relative to the overall software development infrastructure, particularly the role that each step plays within the software development infrastructure. Locations within the software development infrastructure can be defined based on discrete portions of the infrastructure enumerated during the recursive enumeration. In this regard, it is worth noting that some existing solutions classify steps, but these solutions only utilize the name of the step and a description of the task that the step performs. However, relying solely on the name and description is often too general to accurately classify the task. Accordingly, compared to these existing solutions, the disclosed enumeration provides a process that allows for a more accurate classification of steps. The disclosed embodiments also include techniques for performing semantic analysis on steps (e.g., semantic analysis of the parameters, configuration files, portals, etc. used by the steps) to further improve the classification compared to these existing solutions.

[0030] In addition, the disclosed embodiments enable the automatic identification of control steps, thereby allowing the remediation effort to be scaled in ways that would not be feasible with a human operator alone. In this regard, it is worth noting that manually enumerating steps in a software development pipeline can take a significant amount of time for a human operator. Thus, using a human operator may not be sufficient to meet the number of remediation measures that may be required during a given development cycle. Further, as described herein, identifying and mapping control steps can improve visibility into the cybersecurity state of the pipeline, thereby detecting potential cybersecurity vulnerabilities associated with a lack of control steps with greater precision.

[0031] Figure 1 An example network diagram 100 for describing various disclosed embodiments is shown. The example network diagram 100 shows a cloud computing platform 110, a knowledge base 120, a security control step finder 130, and a knowledge base architect 140. The cloud computing platform 110 may be implemented via one or more networks, such as but not limited to wireless, cellular, or wired networks, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), the Internet, the World Wide Web (WWW), similar networks, and any combination thereof.

[0032] The cloud computing platform 110 includes a production server 112 and one or more scanners 115. The production server 112 may be configured to deploy and host web applications uploaded to the cloud computing platform 110 by one or more software developer devices (not shown). The scanners 115 are configured to scan the cloud computing platform 110, binary artifacts, code, combinations thereof, etc., and are configured to generate cybersecurity event data related to network activity, potential sources of cybersecurity events, intermediate representations of such potential sources, result artifacts of the software development process, combinations thereof, and so on. To this end, the scanners 115 may include, but are not limited to, cloud scanners, application security scanners, linting tools, combinations thereof, and any other security verification tools that may be configured to monitor network activity or potential sources of cybersecurity events.

[0033] Any cloud scanner among the scanners 115 is configured to monitor network activity and is configured to generate a source of cybersecurity event data. To this end, such a cloud scanner may be configured to monitor network activity and generate a log of such network activity, or may be configured to monitor for suspicious behavior and generate an alert when such suspicious behavior is identified. The alert may include information about the event, entity, or both that triggered the alert.

[0034] For example, cybersecurity events included in a cybersecurity event data source may be provided in the form of text data. Such text data may be analyzed using natural language processing and a semantic concept dictionary to identify entity identification values representing specific entities related to cybersecurity events in a software development infrastructure, semantic concepts indicating types, or other information about entities related to cybersecurity events, or both, etc.

[0035] According to various disclosed embodiments, the knowledge base 120 stores data for security control step identification and analysis. Such data includes, but is not limited to, an entity graph (EG) 121 and a semantic concept dictionary (SCD) 122. The entity graph 121 is a graph of linked nodes, where the nodes represent entity identification values of specific entities (such as, but not limited to, resource names, unique identifiers, etc.). The semantic concept dictionary 122 includes definitions of semantic concepts indicating semantic information about entities, such as, but not limited to, the type of the entity (e.g., Docker container, step, etc.).

[0036] The entity graph 121 provides an end-to-end view of all domains of a software development infrastructure, including the connections between components of these domains, thereby establishing potential connections between any two given components and their respective domains in the software development infrastructure. To this end, the entity graph 121 includes schematic data that links different domains and shows the links within each domain. These domains include domains representing the layers of the software development infrastructure, and domains representing event logic components related to cybersecurity events (e.g., policies, code defining business logic, queries, etc.). By drawing domains including parts of the software development infrastructure and event logic components related to cybersecurity events, the entity graph 121 can be queried to determine the node paths that connect entities to event logic components, thereby identifying the root cause of any given cybersecurity event as the entity connected to the event logic component related to the cybersecurity activity.

[0037] According to various disclosed embodiments, the components of the software development infrastructure in the entity graph 121 may include steps mapped relative to other components of the software development infrastructure as described herein. To this end, in an embodiment, the security control step finder 130 is configured to enumerate steps in the software development infrastructure (e.g., steps used by the production server 112) and classify these steps. The enumerated steps may be mapped based on the entity graph 121 and their respective classifications. The entity graph 121 may also include the classifications of the mapped steps and may thus indicate where the steps identified as security control steps are deployed relative to the software development infrastructure. The following refers to Figure 2 Further describes an example method for identifying and mapping steps. The following refers to Figure 5 Further describes an example schematic diagram of the security control step finder 130.

[0038] In an embodiment, the knowledge base architect 140 is configured to populate the knowledge base 120 with data used by the security control step finder 130, including but not limited to the entity graph 121 and the semantic concept dictionary 122. As described herein, the knowledge base architect 140 may include, but is not limited to, processing circuitry and a memory (not shown) containing instructions that, when executed by the processing circuitry, configure the knowledge base architect 40 to populate the knowledge base 120. An example method for creating a knowledge base that may be performed by the knowledge base architect 140 will be described further below with reference to Figure 4 an example method for creating a knowledge base that may be performed by the knowledge base architect 140.

[0039] It should be noted that Figure 1 the example network diagram depicted in is shown for illustrative purposes only of a particular arrangement of communication components for simplicity, but the disclosed embodiments are equally applicable to different cloud computing configurations. As a non-limiting example, without departing from the scope of the present disclosure, any one of the knowledge base 120, the security control step finder 130, and the knowledge base architect 140 may be deployed in the cloud computing platform 110. Additionally, the software being monitored may be deployed in an infrastructure other than the cloud computing infrastructure, such as but not limited to an on-premises infrastructure.

[0040] Figure 2 FIG. 200 is a flow chart showing a method for identifying security control steps in a software development pipeline according to an embodiment. In an embodiment, the method is performed by the Figure 1 security control step finder 130.

[0041] At S210, software development pipeline data is accessed or otherwise obtained. The software development pipeline data may be, for example, software development life cycle (SDLC) pipeline data (e.g., data from a continuous integration [CI] and continuous delivery [CD] pipeline). Such SDLC data may include but is not limited to pipeline configurations, pipeline definitions, build scripts, and other scripts used in the pipeline (e.g., deployment scripts, validation scripts, test scripts, etc.), source code, logs, manifests, metadata, combinations thereof, portions thereof, etc. In some embodiments, computing interface permissions provided by an operator of the software development pipeline (e.g., Figure 1 an operator of the cloud computing platform 110) may be used to access the software development pipeline data. The accessed software development pipeline may be but is not limited to data stored in source control, data retrieved via an API, data uploaded by a user for analysis, combinations thereof, and the like.

[0042] At S220, enumerate the pipeline execution steps of one or more software development pipelines. Each step is a program that includes a set of instructions (e.g., machine-readable computer instructions) for performing one or more corresponding tasks. In this regard, it is worth noting that a given software development pipeline includes one or more software components in a computing environment that can be accessed by a program. Thus, these steps are enumerated so that the programs for accessing different components of the software development infrastructure within the pipeline can be identified and analyzed.

[0043] In an embodiment, S220 includes analyzing the logs, manifests, and metadata of software development pipeline data. In another embodiment, S220 may include performing a recursive enumeration that starts from the top-level identifier of a service (e.g., the organizational identifier of an organization that owns or operates a service built using a software development pipeline). The recursive enumeration includes using data accessed through a computing interface to identify components within a service at each layer, where the data related to components in one layer is used to enumerate the components in the next layer. In other words, by enumerating the components in each layer of the software development infrastructure in each iteration, parts of the software development architecture are iteratively enumerated over multiple iterations. During this recursive enumeration process, the pipeline can be identified, and then the steps within the pipeline can be enumerated.

[0044] In this regard, it is worth noting that the software development infrastructure typically includes various logical components that encapsulate different aspects of the software development infrastructure at different granularities. In other words, some aspects include other aspects in a hierarchical manner. As a non-limiting example, the top-level software development server to be built (top layer / layer 1) may include projects and repositories (layer 2), where each project includes one or more pipelines (layer 3), each pipeline includes jobs (layer 4), and each job utilizes one or more steps (layer 5). The sub-components of each logical component are reflected in the logs, manifests, and metadata of the software development infrastructure (i.e., the software development pipeline data accessed at S210) so that these sub-components can be identified, thereby enumerating the components in each layer and ultimately the steps within one of the layers. Additionally, the relationships between these components and sub-components can be revealed through this recursive enumeration.

[0045] To this end, in another embodiment, S220 includes recursively enumerating all projects and repositories under the top-level identifier of a software development service using the computing interface of the pipeline (e.g., using the provided computer interface permissions). For each project enumerated in this way, the computing interface is used to enumerate all the pipelines of the project, then the jobs of each pipeline, and finally the steps taken during the execution of each job. This enables a complete enumeration of all the steps used for software development pipeline execution in the software development infrastructure.

[0046] In another embodiment, one or more steps can be forced to be identified by analyzing different types of objects in the software development infrastructure. This necessary analysis can be performed when the object types between layers are different, i.e., when different layers include different types of objects, so that the layers can be distinguished based on the object types they contain. Thus, in such an embodiment, the objects in the software development infrastructure can be enumerated without recursively enumerating the layers, and the relationships between components can be determined based on the types of components relative to each layer.

[0047] Alternatively or additionally, steps can be identified based on triggers between pipelines. More specifically, the connections between components of different pipelines can be identified based on the execution of a first pipeline that triggers the execution of a second pipeline. When there is a software dependency between the components built by the first pipeline and the components built by the second pipeline, i.e., when the components of the first pipeline call the components of the second pipeline, the execution of the first pipeline causes the execution of the second pipeline. In this case, the recursive analysis of the first pipeline can proceed to analyze the second pipeline, thus completing the analysis of the entire process starting from the first pipeline and leading to the execution of the second pipeline.

[0048] In S230, the enumerated steps are mapped relative to the components of the software development infrastructure to create a mapping including the relative positions of the respective steps within the software development pipeline. In various embodiments, these steps are mapped to each other at least within the pipeline.

[0049] The relative position of a given step relative to other components of the software development infrastructure is defined at least according to the connections between the components of the software development infrastructure, and can also be defined according to the processing order associated with these connections.

[0050] Connections can include passing parameters, passing outputs, etc. from one component to another (e.g., from one step to another step), or otherwise based on the use of the result of one component by another component. As a non-limiting example, a connection can be defined as an artifact built by one step being scanned by another step, or a parameter used by one step being passed to another step.

[0051] The order can be based on the data flow between connected steps. For example, the data output or processed by the first step in a given order can subsequently be passed to or processed by the second step, which is identified as a later step in the order. As a non-limiting example, the code created in one step can be analyzed by another step. As another non-limiting example, the code scanned in one step can be deployed in another step.

[0052] In at least some embodiments, these steps are mapped relative to an entity graph that indicates the entities and the connections between entities in the software development or SDLC pipeline. As will be described below with reference toFigure 4 As described, in additional embodiments, the entity graph can be part of a knowledge-based construction. Creating an entity graph and knowledge base for a software development pipeline is further described in U.S. Patent Application No. 17 / 507,180, assigned to a common assignee, the contents of which are incorporated herein by reference. The knowledge graph can also include step data associated with each mapping step, and the step data can indicate various attributes of the mapping step, and thus the step data can be queried.

[0053] In S240, the enumerated steps are classified. The classification is based on step attributes of each step, such as but not limited to provider, type, name, parameters, combinations thereof, and the like. In some embodiments, S240 also includes normalizing step data that can indicate such step attributes. Additionally, S240 can also include parsing and interpreting the text of the parameters to perform semantic analysis on the parameters used by these steps, thus improving the classification compared to solutions that classify steps based only on name and / or task description.

[0054] In an embodiment, as now regarding Figure 3 as described, the steps are classified. Figure 3 is a flowchart S240 showing a method for classifying steps in a software development pipeline according to an embodiment.

[0055] In S310, the steps to be classified are identified. The steps to be classified can include the enumerated steps (e.g., as discussed above regarding S220). Steps can also be identified relative to a mapping that includes a representation of the steps (e.g., as nodes in a mapping). Such a mapping can include an entity graph (e.g., Figure 1 the entity graph 121 in ), and S310 can also include identifying the entity graph and / or the mapping.

[0056] In S320, the step data of the identified steps is identified. For example, the step data can be retrieved from an entity graph (e.g., Figure 1 the entity graph 121 of ) or otherwise from a knowledge base that includes data associated with each step.

[0057] In an embodiment, S320 also includes normalizing the identified step data into a unified format so that step data from different CI / CD servers or from different data sources is normalized into the same format. The unified format can include fields and values, where each value is inserted into the corresponding field. As a non-limiting example, the text value "securityGatekeeper1" can correspond to the "name" field in the unified format. The appropriate field for each value can be determined by analyzing the value, the data structure of the data including the value in the original data (e.g., the text of the fields of the original data can be used to determine the appropriate field in the unified format), combinations thereof, and the like.

[0058] Normalizing the step data can further improve the mapping of steps. More specifically, the mapping of steps can be represented in an entity graph that includes the step data for each step represented therein. Subsequent queries of the entity graph with normalized step data are improved compared to non-normalized step data.

[0059] In some embodiments, S320 may also include analyzing the scripts of one or more steps to obtain more data about the step type. More specifically, when the step is a custom type of step rather than a publicly available step (e.g., a step available in the public market), the script of the step can be extracted for further analysis.

[0060] In an embodiment, S320 also includes parsing and interpreting the parameters in the step data. Each parameter is a value passed to another program, step, or function when the step is executed. For example, a predefined definition database can be used to perform semantic analysis on each parameter including a text value by applying rules defined using the relative positions of words with respect to each other, etc. The semantic analysis can be used to identify the context of the words in each parameter, thereby obtaining more information that can be used to determine the attributes of the step or classify the step more accurately.

[0061] In additional embodiments, the parameters can be examined to extract the paths of the resources used by the parameters and analyze the extracted paths to identify the locations of these resources. The locations of the resources can be accessed to access the resources, and the resources can be analyzed. The analysis of the resources can similarly include but is not limited to performing semantic analysis on the text contained in the resources.

[0062] As a non-limiting example, where a parameter points to a configuration file in a code library from which a step reads its rules, the parameter is examined to extract the path and the extracted path is analyzed to identify the location of the configuration file. The configuration file is accessed at that location and the content of the configuration file is analyzed. The results of this analysis can be used to identify step attributes, classify the steps, or both.

[0063] In another embodiment, S320 may also include obtaining the remotely stored step data of one or more steps (e.g., data stored external to the software development infrastructure being analyzed). In such an embodiment, the key discovered during the analysis of the software infrastructure can be used to obtain the remotely stored step data. Alternatively or in combination, some or all of the remotely stored step data can be obtained through a third-party service (e.g., by sending a request to a service of a system that has been granted access to the method being executed) Figure 3 of the method).

[0064] As a non - limiting example, this step is a command - line input (CLI) command to obtain an API key (e.g., via a parameter, an environmental variable, or a configuration file), where the configuration data for this step is stored remotely. In such an example, the user can integrate the process of executing Figure 3 the method with a third - party service that can access the configuration data and can retrieve the configuration data through the third - party service.

[0065] In this regard, it is worth noting that the parameters may not fully contain all the semantic information required to accurately determine the role of the classification step. Analyzing the parameters and the paths represented in these parameters can provide additional context information about the step, thereby further improving the accuracy of the resulting step classification. Additionally, when at least a portion of the step data for a given step is not present locally, accessing such remote step data allows for obtaining additional information useful for improving step classification.

[0066] In S330, step attributes are identified within the step data. When the step data is normalized to a unified format, the step attributes can be identified as values within fields in the unified format representing the corresponding step attributes.

[0067] In S340, the step is classified based on the determined step attributes. In an embodiment, the step is classified as a security - control step or a non - security - control step. In another embodiment, the step can also be classified into process categories used in a pipeline. Alternatively, the step can be classified as a security - control step, a non - security - control step, or an unknown step. In some implementations, the classification can be implemented as the likelihood that the step falls into a given category (e.g., the likelihood that the step is a security - control step or the likelihood that the step falls into a particular type of security - control step).

[0068] In an embodiment, each security - control step is a step that performs one or more security - related tasks. Security - related tasks can include tasks that are part of a process that includes analyzing a portion of the pipeline (e.g., analyzing code) to identify potential security issues. In another embodiment, the steps classified as security - control steps only include steps that scan or otherwise analyze as part of one or more code - analysis tasks and exclude steps that do not perform code - analysis tasks. In such an embodiment, a security - control step can generally be a step that determines whether security requirements are met or otherwise analyzes code to check for potential vulnerabilities.

[0069] In another embodiment, the classification is at least partially based on an entity graph. More specifically, the steps can be mapped with respect to portions of the entity graph that represent pipeline portions associated with different categories of processes included in the pipeline. Thus, each step can be classified into the category of the portion of the entity graph to which the step is mapped. Such categories can include, but are not limited to, security, source code acquisition, artifact building, etc. In other words, the steps can be further classified according to their use in the pipeline.

[0070] In optional S350, the mapping can be updated based on the classification. As a non-limiting example, the entity graph can be updated to include the steps, or the entity graph including the steps can be updated to include the classification of each step, and thus as data associated with the step, for future reference (e.g., to generate insights for other steps for the steps in the mapping).

[0071] Referring again to Figure 2 , in S250, the context of each security control step within the pipeline is determined. In an embodiment, the context is determined based on the mapping between components of the software development infrastructure and the role of the security control step relative to other software components (especially other steps). The role of the security control step can be defined according to the type of component or specific component analyzed using the security control step instructions. As a non-limiting example, a security control step including instructions for scanning an artifact has the role of scanning the artifact, thus defining the relevant context of the security control step relative to other steps for building the artifact.

[0072] In additional embodiments, the context is determined based at least on the connections between components and the order between the connected components. As a non-limiting example, the context of a security control step designed to scan code can be determined based on the position of the step for deploying the code relative to the security control step for scanning the code.

[0073] In an embodiment, the context of the security control step is determined based on other components in the mapping (e.g., the mapping determined in S240 can be incorporated into the entity graph (e.g., Figure 1 entity graph 121)). To this end, in such an embodiment, S250 can include querying the entity graph representing the entity as a node in the graph that includes the mapped security control steps.

[0074] The query can be generated based on a predetermined query language. Such a query language can be designed to query the entity graph or relational database using logical inference rules in order to obtain relevant information on development, security, and operation in various areas of the software development infrastructure. Alternatively, the query can be generated using a general query language. In some implementations, the query language can be customized to allow queries to be customized for a specific environment (e.g., a cloud environment used by a specific company) in a way that can be extended to different stacks.

[0075] At S260, verification is performed based on the determined context to determine whether the security control steps are correctly deployed. Performing the verification may include, but is not limited to, confirming whether the security control steps are effectively deployed, determining whether any expected security control steps are missing at a given location relative to the software development pipeline, and the like. To this end, S260 may include applying verification rules that define the expected deployment of the security control steps, or otherwise define how the security control steps should be deployed.

[0076] More specifically, the verification rules may define requirements for the security control steps with respect to other components in the software development infrastructure, such that the verification is performed based on the relative position of the security control steps within the pipeline, the absence of security control steps at a particular location relative to the pipeline, or both. In addition, the categorization of other steps may be further verified so that the verification rules consider the relative position of the security control steps with respect to other steps based on the roles played by these other steps (e.g., source code acquisition, artifact construction, etc.). To this end, the verification rules may be further defined for the types of code that different security control steps are intended to protect, which may be determined by analyzing the step data as described above.

[0077] When the vulnerability rules include rules for identifying incorrect deployments of security control steps, the vulnerability rules may define the expected relationships between components in the pipeline with respect to their positions in the pipeline. More specifically, in an embodiment, each security control step is a program that includes a set of instructions for performing one or more security-related tasks. In another embodiment, each security control step includes instructions for scanning, comparing, or otherwise analyzing code or configurations in the software development infrastructure. In another embodiment, the security control steps may exclude security-related steps that do not involve analyzing code (e.g., steps for initializing code or other steps that may be required but do not actually involve analysis). In other words, in such an embodiment, the security control steps may be defined as including only steps that contain instructions for analyzing code in the software development infrastructure.

[0078] As a non-limiting example of a vulnerability rule defined for an incorrect deployment of a security control step, a vulnerability rule for a security control step intended to protect may define a vulnerability as occurring when a security control step in the artifact construction part of the software development infrastructure is deployed such that the pipeline containing the security control step constructs an artifact after applying the security control step (e.g., after analyzing the code as part of that step). A vulnerability may be detected when the security control step is deployed to create more artifacts in the same pipeline after applying the security control step.

[0079] When the vulnerability rule includes a rule for identifying the absence of an expected security control step, the vulnerability rule can define the location of the expected security control step within the pipeline. For example, these locations can be defined relative to other steps in the same pipeline as the security control step or other parts of the software development infrastructure. To this end, in such an embodiment, S260 can include identifying the absence of an expected security control step (e.g., the expectation for a given location relative to other components of the software development infrastructure) based on the context of each security control step, such as by determining whether the context of any security control step indicates that the step is deployed at the expected location.

[0080] As a non-limiting example of a vulnerability rule defined for the absence of a security control step, the vulnerability rule can define a vulnerability as occurring when a security control step is not deployed after one or more steps that result in the creation of a new artifact. A vulnerability may be detected when no security control step is deployed to analyze the artifact created by the artifact build step.

[0081] In S270, a security control step report is sent. The report can include, but is not limited to, data indicating the verification result, one or more context insights related to the security control steps or the lack of security control steps within the software development pipeline, a map of the software development infrastructure showing the relative location of the steps (especially the security control steps) relative to other components of the software development infrastructure or other visual representations of the organization, combinations thereof, and the like.

[0082] In optional S280, one or more potential vulnerabilities in the software pipeline are identified for the security control step or its absence. In an embodiment, the vulnerabilities can be identified based on the result of applying the vulnerability rule. More specifically, the vulnerabilities can include, but are not limited to, the absence of a security control step at the expected location, the presence of a security control step at a location that is inconsistent with the correct deployment of the security control step relative to a particular other component of the software development infrastructure (e.g., other steps with a particular classification), and the like.

[0083] In optional S290, one or more mitigation measures can be performed for the identified vulnerabilities. The mitigation measures can include, but are not limited to, changing the configuration of the software component, changing the software component code, installing or otherwise deploying the software component (e.g., installing a security control step), redeploying the security control step (e.g., deploying the security control step at a location different from the current location of the step), combinations thereof, and the like. When the mitigation measure includes installing a security control step or redeploying a security control step, such installation or deployment can be performed based on the mapping executed at S240.

[0084]

[0085] ​When the mitigation measure includes generating a notification, S290 may also include determining who the notification should be sent to. In an embodiment where the entity graph in the mapping step includes a node representing the code owner, the person to whom the notification should be sent can be an individual, team, business unit, etc. represented by a node linked to the step in the entity graph. Thus, the appropriate person to investigate or resolve the problem can be determined automatically and accurately.

[0086] Figure 4 FIG. 400 is a flowchart showing a method for creating a knowledge base of semantic concepts and entity identification values according to an embodiment. In an embodiment, the method is performed by Figure 1 the knowledge base architect 140 in

[0087] In S410, correlations between software components are derived by analyzing software development life cycle (SDLC) pipeline data (e.g., data from continuous integration [CI] and continuous delivery [CD] pipelines). Such SDLC data can include, but is not limited to, pipeline configurations, build scripts, source code, combinations thereof, portions thereof, etc. Correlations are identified based on references between software components indicated in these data, static analysis of software components, semantic analysis of text associated with software components, combinations thereof, etc.

[0088] In an embodiment, the semantic analysis may include extracting semantic keywords from the text content included in network security event data related to the pipeline (e.g., event data generated by one or more scanners (e.g., Figure 1 scanner 115 in

[0089] In S420, based on the derived correlations, source code control is linked to binary files of one or more applications. In an embodiment, S420 includes extracting unique identification features of source code control artifacts and binary files from the analyzed data. In another embodiment, the linking is limited to pairs of binary files and source code control artifacts selected respectively from a limited set of binary files and source code control artifacts.

[0090] At S430, the log data (e.g., log files) is analyzed to find additional correlations. To this end, S430 can include identifying the actions taken by software components and the events that may be caused by these actions. These relationships can be identified based on circumstances such as but not limited to events that occur shortly after these actions, events that are logically determined to be caused by the actions, combinations thereof, etc. The identification at S430 can be based on probabilistic analysis (e.g., identifying correlations with a likelihood higher than a threshold).

[0091] As a non-limiting example, by analyzing the log files from an integration or deployment server, a link between code commits and binary hashes (and thus the corresponding entities involved) can be identified. As another non-limiting example, by analyzing files in a cloud environment, information identifying the entities used by an identification automation engine can be identified.

[0092] In this regard, it has been determined that correlations between log files can prove that a particular deployment has occurred previously, which in turn helps to provide visibility into the DevOps pipeline in cases where static analysis fails to meet the constraints, and can further help to discover hidden automation. As discussed above with respect to Figure 2 This in turn provides additional information about the relationships between software components and entity logical components, and this additional information can be used in some non-limiting examples to more accurately identify the root cause.

[0093] At S440, an entity graph is created based on the correlations identified at S410 to S430. The entity graph includes nodes and edges. The nodes represent different logical entities, such as but not limited to software components, event logical components, etc. The edges connect the entities based on the correlations identified at S410 to S430. Thus, the edges represent the relationships between entity pairs, which in turn form paths for navigating from a first entity to a second entity, from the second entity to a third entity, etc. Therefore, the paths along the edges between the nodes can be used to identify the connections between different entities (e.g., the connection between an event logical component and a software component), thereby automatically and objectively identifying the root cause of a cybersecurity event.

[0094] In some embodiments, S440 also includes incorporating a dataset of translated entity definitions into the entity graph. To this end, in such embodiments, S440 includes embedding the translated data into the entity graph, and S440 can also include performing such translations. The dataset of entity definitions provides a clear definition of the characteristics of the potential entities included in the entity graph. As a non-limiting example, such a dataset can be the schema of a DevOps tool (e.g., Terraform), which defines the functions performed by each part of the tool. Further combining such clearly defined characteristics allows for further increasing the granularity of the graph, thereby further improving the application of the graph in identifying the connections between cybersecurity event data and event logical components.

[0095] At S450, a semantic concept dictionary is created. The semantic concept dictionary can be populated with predetermined semantic concepts. Semantic concepts indicate potential characteristics of entities in the entity graph, such as but not limited to type (e.g., "Docker container"), potential identifiers (e.g., Internet protocol address), build automation, configuration, its parts, its combinations, etc. Such semantic concepts provide additional information about the entities, and this additional information can be used to improve the accuracy of root cause identification by providing additional identification data for queryable entities. These semantic concepts indicating potential characteristics of entities can be included as nodes in the entity graph or in the node data of the entity graph.

[0096] At S460, a knowledge base is established. The knowledge base includes the entity graph and the semantic concept dictionary.

[0097] Once constructed, the knowledge base can be queried as described herein (e.g., as discussed with respect to Figure 2 and Figure 3 ) to determine the connections between software components in the software development pipeline, and more specifically, to map the steps of the software development pipeline to other components reflected in the knowledge base.

[0098] It should be noted that Figure 4 the steps are described in a particular order, but the steps are not necessarily limited to the described order. As a non-limiting example, without departing from the scope of the present disclosure, the semantic concept dictionary can be created before or in parallel with any one of steps S410 to S440.

[0099] Figure 5 FIG. 21 is an exemplary schematic diagram of a security control step finder 130 according to an embodiment. The security control step finder 130 includes a processing circuit 510 coupled to a memory 520, a storage device 530, and a network interface 540. In an embodiment, the components of the security control step finder 130 can be communicatively connected via a bus 550.

[0100] The processing circuit 510 can be implemented as one or more hardware logic components and circuits. For example but not limited to, exemplary types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general purpose microprocessors, microcontrollers, digital signal processors (DSPs), etc., or any other hardware logic component that can perform computations or other information operations.

[0101] The memory 520 can be volatile (e.g., random access memory, etc.), non-volatile (e.g., read only memory, flash memory, etc.), or a combination thereof.

[0102] In one configuration, the software for implementing one or more embodiments disclosed herein may be stored in storage device 530. In another configuration, memory 520 is configured to store such software. Software should be construed broadly as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). When executed by processing circuitry 510, the instructions cause processing circuitry 510 to perform the various processes described herein.

[0103] Storage device 530 may be a magnetic storage device, an optical storage device, etc., and may be implemented as, for example, flash memory or other storage technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), or any other medium that can be used to store the required information.

[0104] Network interface 540 allows security control step finder 130 to communicate with, such as scanner 115, knowledge base 120, both, etc.

[0105] It should be understood that the embodiments described herein are not limited to Figure 5 the specific architecture shown, and other architectures may be equally used without departing from the scope of the disclosed embodiments.

[0106] The various embodiments disclosed herein may be implemented as hardware, firmware, software, or any combination thereof. Additionally, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer-readable medium consisting of components or a specific device and / or combination of devices. The application program may be uploaded to and executed by a machine including any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware, such as one or more central processing units (“CPUs”), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code, part of the application program, or any combination thereof, and may be executed by the CPU whether or not such a computer or processor is explicitly shown. Additionally, various other peripheral units, such as additional data storage units and printing units, may be connected to the computer platform. Further, a non-transitory computer-readable medium is any computer-readable medium other than a transitory propagated signal.

[0107] All of the examples and conditional language recited herein are intended for pedagogical purposes to assist the reader in understanding the principles of the disclosed embodiments and the concepts contributed by the inventor to further the art, and are to be construed as not being limited to the specific examples and conditions recited herein. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to cover both structural and functional equivalents thereof. Additionally, such equivalents include both currently known equivalents and equivalents developed in the future, i.e., any elements developed that perform the same function regardless of structure.

[0108] It should be understood that any reference in this document to an element using terms such as "first," "second," etc., generally does not limit the number or order of these elements. Instead, these terms are generally used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be used there, nor does it mean that the first element must precede the second element in some manner. Moreover, unless otherwise specified, a group of elements includes one or more elements.

[0109] As used herein, the phrase "at least one" followed by a list of items means that any one of the listed items can be used alone, or any combination of two or more of the listed items can be used. For example, if a system is described as including "at least one of A, B, and C," the system can include only A alone; B alone; C alone; 2A; 2B; 2C; 3A; a combination of A and B; a combination of B and C; a combination of A and C; a combination of A, B, and C; a combination of 2A and C; a combination of A, 3B, and 2C; and so on.

Claims

1. A method for identifying security control steps in a software development pipeline, comprising: enumerating a plurality of steps in the software development infrastructure by analyzing software development pipeline data of the software development infrastructure, wherein each step comprises a set of computer instructions for performing at least one task; identifying, in the step data for the step, a plurality of step attributes for each of the plurality of steps; and Based on the plurality of step attributes identified for each of the plurality of steps, at least one of the plurality of steps is classified as a safety control step, wherein each step classified as a safety control step includes instructions for at least analyzing code to determine whether at least one safety requirement is satisfied.

2. The method according to claim 1, wherein: The plurality of steps are enumerated by recursively enumerating portions of the software development infrastructure.

3. The method according to claim 2, wherein: The software development infrastructure includes a plurality of layers, wherein recursively enumerating the portion of the software development infrastructure includes iteratively enumerating components in a plurality of iterations, wherein at each iteration, components are enumerated within a layer of the plurality of layers.

4. The method according to claim 1, further comprising: Step data for each of a plurality of steps of the enumeration is normalized to a uniform format, wherein each enumeration step is classified based on the normalized step data for the step.

5. The method according to claim 1, wherein: Each enumerated step is also categorized based on a mapping of the software development infrastructure.

6. The method according to claim 1, further comprising: The context of each security control step is determined relative to other components of the software development infrastructure.

7. The method according to claim 6, wherein: The context of each safety control step is determined based on the type of component analyzed using the instructions of the safety control step.

8. The method according to claim 6, further comprising: Determining whether each security control step is correctly deployed, wherein each security control step is correctly deployed when the context of the security control step indicates that the security control step is deployed at a location of the software development infrastructure that matches an expected location of a component of the software development infrastructure.

9. The method according to claim 6, further comprising: Based on the context determined for each security control step, a lack of expected security control steps within the software development infrastructure is identified.

10. The method according to claim 1, further comprising: detecting at least one vulnerability in the software development infrastructure based on the context determined for each security control step; as well as At least one mitigation measure is performed for at least one detected vulnerability.

11. The method according to claim 1, further comprising: A map of the software development infrastructure is created, wherein the map includes connections between components of the software development infrastructure, wherein the components of the software development infrastructure include the enumerated plurality of steps.

12. The method according to claim 11, wherein: Creating the mapping further includes: An entity graph having a plurality of nodes representing respective ones of a plurality of entities is updated, wherein each of the plurality of entities corresponds to one of the components of the software development infrastructure, wherein the entity graph is updated to include nodes representing respective ones of the enumerated plurality of steps.

13. The method according to claim 12, further comprising: creating a semantic concept dictionary, wherein the semantic concept dictionary defines a plurality of semantic concepts describing potential characteristics of components of the software development infrastructure; creating the entity graph based on a plurality of relationships identified between entities of the plurality of entities; and A knowledge base is constructed using the semantic concept dictionary and the entity graph, wherein at least a portion of the step data is retrieved from the knowledge base.

14. The method according to claim 1, further comprising: A security control step report is sent to indicate at least one of: results of validating the deployment of security control steps within the software development infrastructure, at least one contextual insight of the security control measures within the software development infrastructure, and a representation of the organization of the software development infrastructure including the enumerated multiple steps.

15. A non-transitory computer readable medium having stored thereon instructions for causing a processing circuit to perform a process, the process comprising: By analyzing software development pipeline data of the software development infrastructure, a plurality of steps in the software development infrastructure are enumerated, wherein each step includes a set of computer instructions for performing at least one task; identifying, in the step data for the step, a plurality of step attributes for each of the plurality of steps; and Based on the plurality of step attributes identified for each of the plurality of steps, at least one of the plurality of steps is classified as a safety control step, wherein each step classified as a safety control step includes instructions for at least analyzing code to determine whether at least one safety requirement is satisfied.

16. A system for identifying security control steps in a software development pipeline, comprising: Processing circuit; as well as a memory comprising instructions that, when executed by the processing circuit, configure the system to: By analyzing software development pipeline data of the software development infrastructure, a plurality of steps in the software development infrastructure are enumerated, wherein each step includes a set of computer instructions for performing at least one task; identifying, in the step data for the step, a plurality of step attributes for each of the plurality of steps; and Based on the plurality of step attributes identified for each of the plurality of steps, at least one of the plurality of steps is classified as a safety control step, wherein each step classified as a safety control step includes instructions for at least analyzing code to determine whether at least one safety requirement is satisfied.

17. The system of claim 16, wherein: The plurality of steps are enumerated by recursively enumerating portions of the software development infrastructure.

18. The system of claim 17, wherein: The software development infrastructure includes a plurality of layers, wherein recursively enumerating the portion of the software development infrastructure includes iteratively enumerating components in a plurality of iterations, wherein at each iteration, components are enumerated within a layer of the plurality of layers.

19. The system of claim 16, wherein: The system is also configured to: The step data for each of the enumerated plurality of steps is normalized to a uniform format, wherein each enumerated step is classified based on the normalized step data for the step.

20. The system of claim 16, wherein: Each enumerated step is also categorized based on a mapping of the software development infrastructure.

21. The system of claim 16, wherein: The system is also configured to: Determine the context of each security control step relative to other components of the software development infrastructure.

22. The system of claim 21, wherein: The context of each safety control step is determined based on the type of component analyzed using the instructions of the safety control step.

23. The system of claim 21, wherein: The system is also configured to: Determine whether each security control step is correctly deployed, wherein each security control step is correctly deployed when the context of the security control step indicates that the security control step is deployed at a location of the software development infrastructure that matches an expected location of a component of the software development infrastructure.

24. The system of claim 21, wherein: The system is also configured to: Based on the context determined for each security control step, missing security control steps within the software development infrastructure are identified.

25. The system of claim 16, wherein: The system is also configured to: detecting at least one vulnerability in the software development infrastructure based on the context determined for each security control step; and At least one mitigation measure is performed for at least one detected vulnerability.

26. The system of claim 16, wherein: The system is also configured to: A map of the software development infrastructure is created, wherein the map includes connections between components of the software development infrastructure, wherein the components of the software development infrastructure include the enumerated plurality of steps.

27. The system of claim 26, wherein: The system is also configured to: An entity graph having a plurality of nodes representing respective ones of a plurality of entities is updated, wherein each of the plurality of entities corresponds to one of the components of the software development infrastructure, wherein the entity graph is updated to include nodes representing respective ones of the enumerated plurality of steps.

28. The system of claim 27, wherein: The system is also configured to: creating a semantic concept dictionary, wherein the semantic concept dictionary defines a plurality of semantic concepts describing potential characteristics of components of the software development infrastructure; creating the entity graph based on a plurality of relationships identified between entities of the plurality of entities; and A knowledge base is constructed using the semantic concept dictionary and the entity graph, wherein at least a portion of the step data is retrieved from the knowledge base.

29. The system of claim 16, wherein: The system is also configured to: A security control step report is sent to indicate at least one of: results of validating the deployment of security control steps within the software development infrastructure, at least one contextual insight of the security control steps within the software development infrastructure, and a representation of the organization of the software development infrastructure including the listed plurality of steps.

Images