> For the complete documentation index, see [llms.txt](https://docs.opsmx.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opsmx.com/code-to-cloud-security-and-scanners/code-security/sbom.md).

# SBOM

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of every component, open-source library, third-party dependency, and package that makes up a software application. It provides complete transparency into what your software is built from — enabling security teams to detect vulnerabilities, enforce license compliance, and respond rapidly when new threats emerge.

OpsMx Delivery Shield integrates with Syft — an easy-to-use open-source tool for generating and managing SBOMs for container images and filesystems — to gain visibility into dependencies, track OSS components, and streamline compliance and risk management. 

The platform allows users to scan code repositories, container images, and application artifacts and receive a full Software Bill of Materials (SBOM), prioritized vulnerability insights, and license risk assessments in under five minutes.

### **SBOM vs DBOM**

While an SBOM inventories what your software is made of, OpsMx goes further with the **Delivery Bill of Materials (DBOM)**:

A Software Bill of Materials (SBOM) is just a list of components that make up a software application, particularly keeping track of open-source and third-party components. However, OpsMx's Delivery Bill of Materials (DBOM) provides more granular information by capturing every step in the application's software delivery and deployment process in order to give you SDLC lifecycle visibility from code to deployment and ensure compliance. This includes results from code analysis and scanning, deployment security checks, approvals, policy enforcement, audits, and more. [OpsMX](https://www.opsmx.com/blog/how-devsecops-ci-cd-pipeline-secures-the-software-supply-chain/)

|            | SBOM                                 | DBOM                                                |
| ---------- | ------------------------------------ | --------------------------------------------------- |
| **Scope**  | What software is made of             | How software was built, tested, and deployed        |
| **Tracks** | Components, libraries, dependencies  | Code analysis, scans, approvals, policy enforcement |
| **Use**    | Vulnerability and license visibility | End-to-end SDLC compliance and audit trail          |
| **Output** | CycloneDX / SPDX / JSON              | Deployment record with full security posture        |

***

## Why Use SBOM in OpsMx

Malicious actors frequently take advantage of weaknesses found in both open-source programs and third-party software elements. Organizations that keep an SBOM will be able to swiftly detect known software vulnerabilities for timely remediation, which helps shrink their attack surface. Organizations holding an SBOM can instantly identify affected applications and start resolving them when security flaws like those in Log4j or OpenSSL emerge. Security risks increase when organizations cannot see their software dependencies clearly.

OpsMx uses SBOM generation in Delivery Shield to:

* Give engineering and security teams **complete real-time visibility** into every software component across all applications and environments
* **Automate supply chain risk detection** — identifying vulnerable or license-non-compliant dependencies before deployment
* **Feed vulnerability data** directly into the Delivery Shield Vulnerability Management and DBOM workflows
* **Enable rapid incident response** — when a zero-day is published, instantly know which applications are affected
* **Meet regulatory mandates** — including SEBI CSCRF, NIST 800-53, FedRAMP, PCI DSS, and HIPAA — with auto-generated, audit-ready SBOM exports

## How SBOM Works in OpsMx Delivery Shield

Delivery Shield generates SBOMs for build artifacts, analyzes and displays the vulnerabilities in the images getting deployed, and blocks deployments if they are likely to cause any breach to security. 

The SBOM lifecycle in Delivery Shield follows this flow:

1. **Connect** — Delivery Shield integrates with your CI/CD pipeline, container registries, and source repositories
2. **Generate** — Syft automatically generates SBOMs for container images and filesystems at the artifact level
3. **Enrich** — Each SBOM is enriched with CVE data, license information, and operational risk data from integrated vulnerability databases
4. **Monitor** — SBOMs are continuously updated as component versions change across environments
5. **Report** — Export SBOMs on demand in CycloneDX, SPDX, or JSON formats for audit and compliance use
6. **Act** — Vulnerability findings from SBOM analysis feed into the Vulnerability Management page, DBOM, and remediation workflows

## What Gets Scanned for SBOM Generation

| Source                              | Description                                                                                               |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Container Images**                | OS packages, application libraries, and layered dependencies across all image layers                      |
| **Git Repositories**                | Open-source and third-party dependencies in source code                                                   |
| **File Systems**                    | Build artifacts and file system components                                                                |
| **Third-Party / COTS Applications** | Vendor-delivered software packages scanned for hidden components and vulnerabilities                      |
| **AI-Generated Code**               | Dependencies introduced by AI code generation tools scanned for known vulnerabilities and unsafe patterns |
| **Public Repositories**             | Any public GitHub repo or Docker Hub image scanned on demand                                              |

## Compliance Frameworks Supported

| Framework                               | Requirement Addressed                                              |
| --------------------------------------- | ------------------------------------------------------------------ |
| **SEBI CSCRF**                          | SBOM generation and maintenance for all deployed applications      |
| **NIST 800-53**                         | Software supply chain risk management and component transparency   |
| **FedRAMP**                             | Continuous monitoring and audit trail of software components       |
| **PCI DSS**                             | Third-party component visibility and vulnerability management      |
| **HIPAA**                               | Software inventory and risk management for healthcare applications |
| **US Executive Order on Cybersecurity** | Machine-readable SBOM in CycloneDX or SPDX format                  |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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.opsmx.com/code-to-cloud-security-and-scanners/code-security/sbom.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.