Inventory
Last updated
Last updated
The SDLC Inventory provides a comprehensive perspective on risk propagation throughout systems and highlights potential attack vectors that may impact other entities. It enables the identification of secure and vulnerable pipelines, and offers insights into the components involved in software build and deployment processes.
It is important to understand the different types of assets used within the SDLC Inventory and their relationships:
Repositories may contain children (modules), each with its own dependencies graph. Many repositories are single-module, anyway.
A module refers to a dependencies graph, and may produce one or more build artifacts (libraries, container images…), that could be published in component registries.
A repository is often built by a CI/CD product, using one or more build workflows. (a build workflow may build artifacts from multiple repositories and publish the artifacts in different registries, i.e. a real graph).
Sometimes the pipelines are files under version control along with the repository. Some SCM systems enforce this pattern within their CI/CD systems. As well as other external CI/CD tools like CircleCI also, but others like Jenkins do not.
The CI granularity also has various levels. For most CI/CD systems, a 'build pipeline' for a project has 'workflows', each workflow has multiple jobs, and 'jobs' (which can run in a given build machine or an "array" of them) is a sequence of 'steps' or 'commands'. The graph can fully represent this hierarchy or not (keep at a given level of granularity, like the workflow), but at the end the real build commands run are those little steps at the end.
On the contrary, a CD pipeline is built from IaC configuration files (a set of IaC template files under a given framework like Terraform, Azure ARM or Bicep, AWS CloudFormation…) which specify commands to sync the desired state represented by the IaC configuration with the existing assets in the cloud. So the CD pipeline may have multiple workflows based on jobs that run the tool’s CLI command (terraform, aws, az, ansible) to perform the sync or build the assets directly.
There are "contain" dependencies (a "parent" node can break down into "children") and "uses" dependencies ("builds", "runs", "publishes", "deploys"…) that could be represented by the directed graph.
The inventory is compiled automatically by the (during runs of the inventory command) and the integration sensors.
The processes configuration and source files to gather information about your pipelines and resolving the relationships between each asset. Including common assets like CI/CD systems and other shared tools.