# Inventory

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.

### The Asset Graph <a href="#the_asset_graph" id="the_asset_graph"></a>

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.

### Asset Discovery

The inventory is compiled automatically by the [Xygeni Scanner](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-scanner-reference.md) (during runs of the `inventory` command) and the integration sensors.

The [Inventory Scan](/xygeni-products/application-security-posture-management-aspm/inventory-scanner.md) 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.

{% hint style="info" %}
For more information, see [Inventory Scanner](/xygeni-products/application-security-posture-management-aspm/inventory-scanner.md).
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.xygeni.io/xygeni-products/application-security-posture-management-aspm/inventory.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.