Inventory

Assets in SDLC build and deploy infrastructure

Modern software is complex, and the build and deployment infrastructure is accordingly complex.

Software is typically built and deployed into production environments using pipelines of commands. A build/deploy pipeline is based on a set of automated processes and tools, involving source control, build tools, continuous integration, testing automation (unit, integration and regression testing), validation, reporting, and distribution.

The assets involved in build/deploy pipeline are named SDLC assets, and in the Xygeni platform an inventory of SDLC assets, for the pipelines used in an organization, is discovered automatically.

Security issues and unusual activity events, as captured by the Xygeni platform, are then mapped to the target SDLC assets.

An SDLC Asset may present misconfigurations, leaked secrets, vulnerabilities and other security issues, and could be abused in software supply chain attacks. Common assets are code repositories, dependencies graphs, package managers, build files, security tools, CI/CD workflows, or IaC templates and provisioning scripts, along with the infrastructure, tools and extensions (like "plugins") used in the build / deploy pipelines.

Security issues and unusual activity events, as captured by the Xygeni platform, are mapped to the target SDLC assets. The Inventory allows to reveal unknown, misconfigured and vulnerable SDLC systems and infrastructure, and perform impact analysis: dependencies between assets may be exploited by attackers to propagate the attack payloads.

The SDLC inventory allows:

• To know which elements are involved during software build & deploy operations.

• To understand which pipelines are secure and which are vulnerable or flawed.

• To have an insight of how risk propagates across systems, and how an attack might break through systems to affect other parties.

The Asset Graph

In the SDLC inventory there are relations between assets, so it is important to understand the different kind of assets 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 with its own CI/CD tool enforce this pattern, and other external CI/CD tools like CircleCI also do, but others like Jenkins do not.

• The CI granularity has also 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 could present fully 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.

• A CD pipeline, on the contrary, is built from IaC configuration (a set of IaC template files under a given framework like Terraform, Azure ARM or Bicep, AWS CloudFormation…​) which launches 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, in the end, 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.

Assets discovery

The inventory is compiled automatically by the Xygeni scanner (during runs of the inventory command) and the integration sensors.

The inventory scan processes configuration and source files for gathering information about the pipeline and resolving the relationship between the assets, including common assets like CI/CD systems and other shared tools.

For more information, see Inventory Scanner.