> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/software-supply-chain-assurance/use-scs/open-source-management/sbom-gitlab-ci-cd/ingest-sbom.md).

# Ingest and Attest SBOM with Harness GitLab CI/CD

Organizations often receive Software Bills of Materials (SBOMs) from third-party vendors, external development teams, or existing build systems. Without a centralized way to store and analyze these SBOMs, it becomes difficult to gain visibility into software dependencies, identify security risks, review license information, and maintain governance across the software supply chain.

Harness Supply Chain Security (SCS) integrates with [GitLab CI/CD](https://gitlab.com/explore/catalog/harness-scs/gitlab-plugins?tab=components) to automate software supply chain security tasks within your CI/CD workflow. It enables you to ingest existing SBOMs generated by external tools or build processes during pipeline execution. The ingested SBOM is uploaded to the SCS module, which provides a centralized inventory of software components to improve software supply chain visibility and support vulnerability management, license compliance, and governance throughout the software development lifecycle.

***

### What will you learn in this topic? <a href="#what-will-you-learn-in-this-topic" id="what-will-you-learn-in-this-topic"></a>

By the end of this topic, you will be able to:

* Set up Harness GitLab CI/CD integration from your SCS project.
* Configure SBOM ingestion in your GitLab workflow using the **SBOM Ingestion** component.
* Configure optional SBOM attestation using keyless, key-based, or Secret Manager signing methods.
* Ingest an existing SBOM into the SCS module and review its software components.

***

### Before you begin <a href="#before-you-begin" id="before-you-begin"></a>

Make a note of the following before you proceed with ingesting an SBOM using GitLab CI/CD:

* Understand how to create Harness API keys using Personal API Keys or Service Account API Keys. Go to [Manage API Keys](/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys.md) and [Service Account API Keys](/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys.md#create-service-account-api-keys-and-tokens) to create either key type.
* If you are using key-based or Secret Manager signing or verification, create or configure a Cosign key pair before configuring the pipeline. Go to [Quickstart Signing and Verifying with Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/#quickstart-signing-and-verifying-with-cosign) to generate a local key pair or create one using a supported KMS provider. The key should be generated using Cosign of type `ecdsa-P256`. You do not need to install Cosign on your GitLab runner. The `harness/ssca-plugin` container image used by the Harness GitLab CI/CD components includes Cosign, so no additional installation is required.
* If you plan to use Secret Manager attestation, store your signing key in a supported secret manager. Currently, Harness supports HashiCorp Vault. For GitLab CI/CD, you point the component at the key through pipeline variables such as `KMS_KEY` (and `VAULT_ADDR` when the key is stored in HashiCorp Vault), so you do not need to configure a Harness Secret Manager connector. Go to [Add a HashiCorp Vault secret manager](/harness-ai/use-harness-platform/secrets/secrets-management/add-hashicorp-vault.md) to configure HashiCorp Vault.
* Ensure that your GitLab runners support Docker-in-Docker (DinD). The component runs using the `docker:24-dind` service. Go to [Use Docker-in-Docker](https://docs.gitlab.com/ci/docker/docker_in_docker/) to configure Docker-in-Docker support.

***

### Understand SBOM ingestion with Harness GitLab CI/CD <a href="#understand-sbom-ingestion-with-harness-gitlab-cicd" id="understand-sbom-ingestion-with-harness-gitlab-cicd"></a>

Harness SCS integrates with GitLab CI/CD through reusable GitLab CI/CD components. These components enable you to automate software supply chain security tasks in your GitLab pipelines, helping you build, verify, and govern software artifacts without adding custom implementation to your CI/CD workflow.

The **SBOM Ingestion** capability enables you to upload an existing Software Bill of Materials (SBOM) generated by external tools or build systems to the SCS module during pipeline execution. Instead of generating a new SBOM, the component imports an existing SBOM and makes it available in SCS for further analysis.

Once the SBOM is ingested, you can review the software components included in your application from a centralized location. This helps you identify software dependencies, investigate vulnerabilities, review license information, and maintain visibility into your software supply chain. By consolidating SBOMs generated across different tools and environments, you can standardize software inventory management and strengthen governance throughout the software development lifecycle.

| **Why use it?**                                                           | **When to use it?**                                                                   | **How can you leverage it?**                                                                                                                                                  |
| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Import an existing SBOM into the SCS module without generating a new one. | When your SBOM is already generated by an external tool or an existing build process. | Use the ingested SBOM to gain visibility into software dependencies, identify vulnerabilities, review license information, and support governance and compliance initiatives. |

***

### Set up Harness GitLab CI/CD <a href="#set-up-harness-gitlab-cicd" id="set-up-harness-gitlab-cicd"></a>

Before configuring SBOM ingestion in your GitLab pipeline, set up Harness GitLab CI/CD from your SCS project. The setup guides you through creating or selecting a Harness API key and generates a project-specific YAML configuration with your Harness account ID, organization ID, project ID, and account URL already populated. You can copy this configuration into your GitLab workflow and update the remaining inputs as needed.

Complete the following steps to set up Harness GitLab CI/CD:

1. Navigate to the **Integrations** page under the **Manage** section from the sidebar navigation of your SCS account.
2. Click the `Add Integration` button to go to the **Configure Integration** page.\
   Alternatively, you can access this page by clicking **Get Started > Get Started** from the sidebar navigation of your SCS account.
3. Scroll down to the GitLab collapsible and click it to expand.
4. Click the `Configure` button under **Configure GitLab CI/CD in your pipeline to generate SBOM and SLSA, and sign artifacts** to open the **Configure Integration** page, where the Artifact Security feature cards are displayed.
5. Click the **Ingest SBOM** card to open the **SBOM Ingestion** sidepanel.
6. Click the `Go to Key Generation` button to create the Harness API key required to configure Harness GitLab CI/CD.
   * Select **Using Service Account** from the dropdown to create the API key using a service account. Go to [Service Account API Keys](/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys.md#create-service-account-api-keys-and-tokens) to create the key.
   * Select **Using Personal Account** from the dropdown to create a personal API key. Personal API keys are created at the account level and inherit the permissions assigned to your user account. Go to [Manage API Keys](/harness-ai/use-harness-platform/automation/api/add-and-manage-api-keys.md) to create a personal API key.
7. Click **Copy** in the upper-right corner of the code block to copy the generated GitLab CI/CD configuration, and then paste it into your GitLab workflow file.

<figure><img src="/files/cfErK1loHGZDlwZYyUBR" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

***

### Configure SBOM ingestion in GitLab CI/CD <a href="#configure-sbom-ingestion-in-gitlab-cicd" id="configure-sbom-ingestion-in-gitlab-cicd"></a>

After setting up Harness GitLab CI/CD, configure the SBOM Ingestion component in your GitLab workflow file. Add the required GitLab CI/CD variables to your GitLab project, configure the component inputs, the attestation settings, and run the pipeline. During pipeline execution, the component ingests an SBOM for the specified artifact and uploads it to the SCS module. Go to the CI/CD Catalog at [SCS GitLab Plugins](https://gitlab.com/explore/catalog/harness-scs/gitlab-plugins?tab=components#sbom-ingestion) to review the authoritative list of component inputs and defaults.

{% hint style="info" %}
If you are using **GitLab Self-Managed**, mirror the required Harness GitLab CI/CD components to your GitLab instance before configuring your pipeline. After mirroring the components, update the `component` reference in your workflow file to use the mirrored component. Go to [Use a GitLab.com component on GitLab Self-Managed](https://docs.gitlab.com/ci/components/#use-a-gitlabcom-component-on-gitlab-self-managed) to mirror the components.
{% endhint %}

Complete the following steps to configure SBOM ingestion:

1. [Add the required GitLab CI/CD variables](#step-1---add-the-required-gitlab-cicd-variables)
2. [Include the SBOM Ingestion component](#step-2---include-the-sbom-ingestion-component)
3. [Configure SBOM attestation in the workflow (optional)](#step-3---configure-sbom-attestation-optional)
4. [Review the workflow](#step-4---review-the-workflow)
5. [Run the pipeline](#step-5---run-the-pipeline)

#### Step 1 - Add the required GitLab CI/CD variables <a href="#step-1-add-the-required-gitlab-cicd-variables" id="step-1-add-the-required-gitlab-cicd-variables"></a>

Before configuring the SBOM Ingestion component, add the following variables to your GitLab project. Go to [Define a CI/CD Variable for a project](https://docs.gitlab.com/ci/variables/#for-a-project) to add project variables.

| **Variable**          | **Description**                                                                        | **Required** | **Example**                  | **Masked?** |
| --------------------- | -------------------------------------------------------------------------------------- | ------------ | ---------------------------- | ----------- |
| `HARNESS_API_KEY`     | Harness Personal API Key or Service Account API Key used to authenticate with Harness. | Yes          | `pat.xxxxxxxxxxxxxxxxxxxx`   | Yes         |
| `HARNESS_ACCOUNT_ID`  | Harness account identifier.                                                            | Yes          | `AbCdEf123456`               | No          |
| `HARNESS_ORG_ID`      | Harness organization identifier.                                                       | Yes          | `SCS_Org`                    | No          |
| `HARNESS_PROJECT_ID`  | Harness project identifier.                                                            | Yes          | `SCS`                        | No          |
| `HARNESS_ACCOUNT_URL` | Harness account URL.                                                                   | Yes          | `https://example.harness.io` | No          |

{% hint style="info" %}
Masked GitLab CI/CD variables cannot be passed through component inputs. For this reason, the Harness scope variables (`HARNESS_ACCOUNT_ID`, `HARNESS_ORG_ID`, `HARNESS_PROJECT_ID`, and `HARNESS_ACCOUNT_URL`) must remain unmasked so that they can be wired through the component `inputs`. `HARNESS_API_KEY` remains masked and is consumed directly from the job environment, not passed as a component input. These values are included in the generated YAML provided during the [Set up Harness GitLab CI/CD](#set-up-harness-gitlab-cicd) workflow.
{% endhint %}

#### Step 2 - Include the SBOM Ingestion component <a href="#step-2-include-the-sbom-ingestion-component" id="step-2-include-the-sbom-ingestion-component"></a>

Add an `scs` stage to your GitLab workflow file, or set the `stage` input on the component to an existing stage. Then, include the Harness **SBOM Ingestion** component in your GitLab workflow file.

The following code snippet demonstrates how to add the `scs` stage and include the SBOM Ingestion component in your GitLab workflow file. The snippet includes the minimum required component inputs because the component requires the Harness scope variables and the target artifact to run.

```yaml
stages: [scs]

include:
  - component: gitlab.com/harness-scs/gitlab-plugins/sbom-ingestion@1.0.0
    inputs:
      HARNESS_ACCOUNT_ID: $HARNESS_ACCOUNT_ID
      HARNESS_ORG_ID: $HARNESS_ORG_ID
      HARNESS_PROJECT_ID: $HARNESS_PROJECT_ID
      HARNESS_ACCOUNT_URL: $HARNESS_ACCOUNT_URL
      TARGET: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      SBOM_FILE_PATH: $CI_PROJECT_DIR/sbom.json
```

Configure the component using the GitLab CI/CD variables created in the previous step and the following component inputs.

| **Input**             | **Description**                                                                                         | **Required** | **Default**             | **Example**                         |
| --------------------- | ------------------------------------------------------------------------------------------------------- | ------------ | ----------------------- | ----------------------------------- |
| `HARNESS_ACCOUNT_ID`  | Harness account ID. Pass a non-masked CI/CD variable reference.                                         | Yes          | N/A                     | `$HARNESS_ACCOUNT_ID`               |
| `HARNESS_ORG_ID`      | Harness organization ID. Pass a non-masked CI/CD variable reference.                                    | Yes          | N/A                     | `$HARNESS_ORG_ID`                   |
| `HARNESS_PROJECT_ID`  | Harness project ID. Pass a non-masked CI/CD variable reference.                                         | Yes          | N/A                     | `$HARNESS_PROJECT_ID`               |
| `HARNESS_ACCOUNT_URL` | Harness base URL with scheme. Pass a non-masked CI/CD variable reference.                               | Yes          | N/A                     | `$HARNESS_ACCOUNT_URL`              |
| `TARGET`              | Container image reference when `SOURCE` is `container`, or artifact file path when `SOURCE` is `local`. | Yes          | N/A                     | `$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA` |
| `SBOM_FILE_PATH`      | Path to the SBOM file to ingest.                                                                        | Yes          | N/A                     | `$CI_PROJECT_DIR/sbom.json`         |
| `FORMAT`              | SBOM output format. Supported values are `spdx-json` and `cyclonedx-json`.                              | No           | `spdx-json`             | `cyclonedx-json`                    |
| `SOURCE`              | Artifact source. Supported values are `container` and `local`.                                          | No           | `container`             | `local`                             |
| `ATTEST`              | Enables SBOM attestation for the ingested SBOM.                                                         | No           | `false`                 | `true`                              |
| `ARTIFACT_NAME`       | Display name for a local artifact. Applicable when `SOURCE=local`.                                      | No           | File name from `TARGET` | `payment-service`                   |
| `ARTIFACT_VERSION`    | Artifact version. Applicable when `SOURCE=local`.                                                       | No           | N/A                     | `$CI_COMMIT_SHORT_SHA`              |
| `stage`               | GitLab pipeline stage in which the component runs.                                                      | No           | `scs`                   | `security`                          |
| `job-name`            | Name of the GitLab job created by the component.                                                        | No           | `scs-sbom-ingestion`    | `ingest-sbom`                       |

{% hint style="info" %}
By default, the component ingests an existing SBOM for a container image. To ingest an SBOM for a local artifact, set `SOURCE` to `local`. When using a local artifact, specify the artifact path in `TARGET` and provide an `ARTIFACT_VERSION`.
{% endhint %}

To attest the ingested SBOM, configure the attestation inputs (`ATTEST_WITH`, `OIDC_PROVIDER`, `FULCIO_URL`, `KMS_KEY`, and `VAULT_ADDR`) as described in [Step 3 - Configure SBOM attestation](#step-3---configure-sbom-attestation-optional).

**Override the generated job**

Standard GitLab job keywords, such as `needs`, `before_script`, `script`, `after_script`, `allow_failure`, and `tags`, are not component inputs. To set them, redeclare the generated job (default name `scs-sbom-ingestion`, or the value of `job-name`) in your workflow file. GitLab merges your keys into the generated job.

```yaml
scs-sbom-ingestion:
  needs: [generate-sbom]
  tags: [docker, linux]
  before_script:
    - echo "Starting SBOM ingestion"
  after_script:
    - echo "SBOM ingestion complete"
```

{% hint style="info" %}
If you are ingesting an SBOM for an image in a private registry that is not the GitLab container registry, provide the registry credentials as masked GitLab CI/CD variables so that the component can access the image.
{% endhint %}

#### Step 3 - Configure SBOM attestation (optional) <a href="#step-3-configure-sbom-attestation-optional" id="step-3-configure-sbom-attestation-optional"></a>

Harness supports the following attestation methods:

* **Keyless attestation** – Uses OpenID Connect (OIDC) identities to sign the generated SBOM without managing long-lived signing keys.
* **Key-based attestation** – Uses a cryptographic key managed through your organization's key management solution.
* **Secret Manager** – Uses signing keys stored in a supported secret manager.

{% hint style="info" %}
SBOM attestation is disabled by default (`ATTEST: false`). The component ingests and uploads the SBOM without signing it. If you plan to verify the SBOM attestation during [SBOM policy enforcement](/software-supply-chain-assurance/use-scs/open-source-management/sbom-gitlab-ci-cd/enforce-sbom-policies.md) (with `VERIFY: true`), set `ATTEST: true` to generate a signed attestation.
{% endhint %}

Configure the appropriate attestation inputs based on the attestation method you want to use.

{% tabs %}
{% tab title="Configure keyless attestation" %}
If you enable SBOM attestation, you can configure **keyless attestation** to sign the ingested SBOM using an OpenID Connect (OIDC) identity. For GitLab CI/CD, set `OIDC_PROVIDER` to `non-harness`. The `harness` OIDC provider is not supported as of now. Keyless attestation requires **GitLab 15.7** or later, because it depends on GitLab `id_tokens`. Configure the following inputs.

| Input           | Description                                                                                                                   | Required |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------- | -------- |
| `ATTEST_WITH`   | Specifies the attestation method. Set the value to `keyless`.                                                                 | Yes      |
| `OIDC_PROVIDER` | OIDC provider used to obtain the signing identity. For GitLab CI/CD, set the value to `non-harness`.                          | Yes      |
| `FULCIO_URL`    | Fulcio certificate authority endpoint. Used when `OIDC_PROVIDER` is `non-harness`. Defaults to `https://fulcio.sigstore.dev`. | No       |

Provide the OIDC token to the generated job using `id_tokens`. The component reads the token from `PLUGIN_NON_HARNESS_OIDC_TOKEN`.

```yaml
stages: [scs]
 
include:
  - component: gitlab.com/harness-scs/gitlab-plugins/sbom-ingestion@1.0.0
    inputs:
      HARNESS_ACCOUNT_ID: $HARNESS_ACCOUNT_ID
      HARNESS_ORG_ID: $HARNESS_ORG_ID
      HARNESS_PROJECT_ID: $HARNESS_PROJECT_ID
      HARNESS_ACCOUNT_URL: $HARNESS_ACCOUNT_URL
      TARGET: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      SBOM_FILE_PATH: $CI_PROJECT_DIR/sbom.json
      ATTEST: true
      ATTEST_WITH: keyless
      OIDC_PROVIDER: non-harness
 
scs-sbom-ingestion:
  id_tokens:
    PLUGIN_NON_HARNESS_OIDC_TOKEN:
      aud: sigstore
```

{% endtab %}

{% tab title="Configure key-based attestation" %}
To sign the ingested SBOM using a cryptographic key, set `ATTEST_WITH` to `keybased` and provide the Cosign key material as [masked GitLab CI/CD variables](https://docs.gitlab.com/ci/variables/#for-a-project) on the job. `KMS_KEY` is not used for key-based attestation. It applies only to Secret Manager attestation.

| Input         | Description                                                    | Required |
| ------------- | -------------------------------------------------------------- | -------- |
| `ATTEST_WITH` | Specifies the attestation method. Set the value to `keybased`. | Yes      |

Provide the following masked GitLab CI/CD variables on the job:

| Variable                                | Description                                           | Required |
| --------------------------------------- | ----------------------------------------------------- | -------- |
| `SSCA_ORCHESTRATION_COSIGN_PRIVATE_KEY` | Cosign private key used to sign the SBOM attestation. | Yes      |
| `SSCA_ORCHESTRATION_COSIGN_PASSWORD`    | Password for the Cosign private key.                  | Yes      |
| {% endtab %}                            |                                                       |          |

{% tab title="Configure Secret Manager attestation" %}
To use a signing key stored in a supported secret manager, configure the following inputs.

| Input         | Description                                                            | Required    |
| ------------- | ---------------------------------------------------------------------- | ----------- |
| `ATTEST_WITH` | Specifies the attestation method. Set the value to `secret-manager`.   | Yes         |
| `KMS_KEY`     | KMS or Vault key URI for the signing key stored in the secret manager. | Yes         |
| `VAULT_ADDR`  | HashiCorp Vault address. Required when `KMS_KEY` uses a Vault URI.     | Conditional |
| {% endtab %}  |                                                                        |             |
| {% endtabs %} |                                                                        |             |

#### Step 4 - Review the workflow <a href="#step-4-review-the-workflow" id="step-4-review-the-workflow"></a>

After configuring the required GitLab CI/CD variables and component inputs, your GitLab workflow file should resemble the following example. This example ingests an existing SBOM for a container image into Harness SCS and optionally attests the ingested SBOM using Cosign with a key stored in HashiCorp Vault. The Harness scope variables are wired through `inputs`, `HARNESS_API_KEY` remains a masked GitLab CI/CD variable, and the Vault variables (`KMS_KEY` and `VAULT_ADDR`) are provided because attestation is enabled.

```yaml
include:
  - component: gitlab.com/harness-scs/gitlab-plugins/sbom-ingestion@1.0.0
    inputs:
      HARNESS_ACCOUNT_ID: $HARNESS_ACCOUNT_ID
      HARNESS_ORG_ID: $HARNESS_ORG_ID
      HARNESS_PROJECT_ID: $HARNESS_PROJECT_ID
      HARNESS_ACCOUNT_URL: $HARNESS_ACCOUNT_URL
      TARGET: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      SBOM_FILE_PATH: $CI_PROJECT_DIR/sbom.json
      ATTEST: true
      ATTEST_WITH: secret-manager
      KMS_KEY: hashivault://cosign
      VAULT_ADDR: $VAULT_ADDR
```

#### Step 5 - Run the pipeline <a href="#step-5-run-the-pipeline" id="step-5-run-the-pipeline"></a>

Commit your changes and run the GitLab pipeline. During pipeline execution, the SBOM Ingestion component uploads the specified SBOM file to the SCS module and associates it with the configured target. If SBOM attestation is enabled, the component also generates and signs an SBOM attestation using the configured attestation method. Go to [Tutorial: Create and run your first GitLab CI/CD pipeline](https://docs.gitlab.com/ci/quick_start/) to run a GitLab pipeline.

After the pipeline completes, open the job execution logs and click the **Harness Artifact Details** link to view the generated artifact in SCS. Go to [View the status of your pipeline and jobs](https://docs.gitlab.com/ci/quick_start/#view-the-status-of-your-pipeline-and-jobs) to review the job status and pipeline details.

<figure><img src="/files/oWAgEgELG0bh6cAkBpLK" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

The Artifact Details page displays the ingested SBOM and its associated security results. The SBOM is also automatically recorded in the [Chain of Custody](/software-supply-chain-assurance/use-scs/artifact-security/overview.md#chain-of-custody), providing an immutable audit trail of the artifact lifecycle and the associated GitLab CI/CD pipeline execution. Go to [Artifact Overview](/software-supply-chain-assurance/use-scs/artifact-security/overview.md) to navigate through artifacts.

<figure><img src="/files/cLMJd8NB2B4mN2FB3fFY" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

***

### Example SBOM ingestion workflow <a href="#example-sbom-ingestion-workflow" id="example-sbom-ingestion-workflow"></a>

<details>

<summary>Example SBOM ingestion workflow for a container image</summary>

The following example demonstrates how to configure the SBOM Ingestion component in a GitLab workflow to upload an existing SBOM for a container image to Harness SCS. The example also shows how to optionally attest the ingested SBOM using Cosign with a key stored in HashiCorp Vault.

The `generate-sbom` job produces the SBOM with **Syft** and publishes it as an artifact. It sets `needs: [build-image]` so that **Syft** runs only after the image has been built and pushed, and the ingestion job uses `needs` so that the SBOM file exists before ingestion runs.

```yaml
stages:
  - build
  - scs
 
build-image:
  stage: build
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
 
generate-sbom:
  stage: build
  image: ghcr.io/anchore/syft:latest
  needs: [build-image]
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o spdx-json=sbom.json
  artifacts:
    paths:
      - sbom.json
 
scs-sbom-ingestion:
  needs: [generate-sbom]
 
include:
  - component: gitlab.com/harness-scs/gitlab-plugins/sbom-ingestion@1.0.0
    inputs:
      stage: scs
      job-name: ingest-sbom
      HARNESS_ACCOUNT_ID: $HARNESS_ACCOUNT_ID
      HARNESS_ORG_ID: $HARNESS_ORG_ID
      HARNESS_PROJECT_ID: $HARNESS_PROJECT_ID
      HARNESS_ACCOUNT_URL: $HARNESS_ACCOUNT_URL
 
      TARGET: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
      SBOM_FILE_PATH: $CI_PROJECT_DIR/sbom.json
      FORMAT: spdx-json
 
      ATTEST: true
      ATTEST_WITH: secret-manager
      KMS_KEY: hashivault://cosign
      VAULT_ADDR: $VAULT_ADDR
```

</details>

<details>

<summary>Example SBOM ingestion workflow for a local artifact</summary>

The following example ingests an SBOM for a local artifact. It builds the artifact in an earlier job, produces the SBOM file, passes both forward with `artifacts`, and uses `needs` so the ingestion job runs after they are available. When `SOURCE` is `local`, `TARGET` is the artifact file path and `ARTIFACT_VERSION` is required.

```yaml
stages:
  - build
  - scs
 
build-artifact:
  stage: build
  script:
    - ./build.sh -o $CI_PROJECT_DIR/target/myapp.jar
    - syft $CI_PROJECT_DIR/target/myapp.jar -o spdx-json=sbom.json
  artifacts:
    paths:
      - target/myapp.jar
      - sbom.json
 
scs-sbom-ingestion:
  needs: [build-artifact]
 
include:
  - component: gitlab.com/harness-scs/gitlab-plugins/sbom-ingestion@1.0.0
    inputs:
      HARNESS_ACCOUNT_ID: $HARNESS_ACCOUNT_ID
      HARNESS_ORG_ID: $HARNESS_ORG_ID
      HARNESS_PROJECT_ID: $HARNESS_PROJECT_ID
      HARNESS_ACCOUNT_URL: $HARNESS_ACCOUNT_URL
 
      SOURCE: local
      TARGET: $CI_PROJECT_DIR/target/myapp.jar
      SBOM_FILE_PATH: $CI_PROJECT_DIR/sbom.json
      ARTIFACT_VERSION: $CI_COMMIT_SHORT_SHA
```

</details>

***

### Next steps <a href="#next-steps" id="next-steps"></a>

* [Generate SBOM with GitLab CI/CD](/software-supply-chain-assurance/use-scs/open-source-management/sbom-gitlab-ci-cd/generate-sbom.md): Learn how to generate, attest, and upload SBOMs to Harness SCS during pipeline execution.
* [Enforce SBOM Policies with GitLab CI/CD](/software-supply-chain-assurance/use-scs/open-source-management/sbom-gitlab-ci-cd/enforce-sbom-policies.md): Learn how to verify SBOM attestations and enforce software supply chain policies during pipeline execution.