Ingest Software Bill of Materials (SBOM) data into SCS
Harness SCS offers flexible SBOM management. It can ingest SBOMs generated from Security Testing Orchestration (STO) scanner steps, like the Aqua Trivy STO step, provided the SBOM is in JSON format (SPDX or CycloneDX). This guide details configuring a pipeline to seamlessly ingest SBOMs generated by Trivy. Similarly, you can follow the same steps for the other STO scanners (Blackduck, Snyk).
Alternatively, you can leverage built-in tools in SCS for SBOM generation or ingest SBOMs from any external tool. Refer to our dedicated guides for these functionalities:
In the SBOM, dependency names may differ from their original source names, as SBOM tools sometimes list dependencies under a product or bundle name rather than the actual dependency name.
Configure the STO scan step to generate SBOM
Configure an STO scanner step, such as the Aqua Trivy STO step, and make sure you select Generate SBOM and the SBOM Format.
Get the SBOM file path
The Aqua Trivy STO step creates a JOB_ID output variable that you can use to reference the SBOM file path in the SBOM Orchestration step.
-
Replace
STAGE_IDandSTEP_IDin the following Harness expression with the stage ID and step ID for your Aqua Trivy STO step.<+pipeline.stages.STAGE_ID.spec.execution.steps.STEP_ID.output.outputVariables.JOB_ID> -
Use the expression in your SBOM file path. The exact path depends on where your scanner outputs SBOM files. For example, this filepath references an Aqua Trivy STO step with the ID
myaquatrivystepin a stage with the IDmybuildstage:/addon/results/<+pipeline.stages.mybuildstage.spec.execution.steps.myaquatrivystep.output.outputVariables.JOB_ID>.sbom
Alternately, you can get the output path and output variable expression from a previous run of the same pipeline. To do this, go to the execution details page, select the stage with the STO scanner step, and then select the STO scanner step. In the step's logs, you can find the output path, and you can get the output variable from the Output tab.

Configure the SBOM Orchestration step
Add an SBOM Orchestration step and configure to ingest the SBOM.
SBOM Orchestration step in deploy stage can only be used in the Containerized Step Groups
- Step Mode: Set the step mode to Ingestion.
- SBOM File Path: enter the SBOM file path that uses the
JOB_IDvalue, as detailed in Get the SBOM file path. - Source: Set the source, which can be DockerHub, ECR, GCR, ACR or Repository. Depending on your selection, a unique set of fields will appear, each specific to the source you've chosen. Address these fields as required, this is similar to configuring the source in SBOM Orchestration step. For more details of what each field entails, please refer to the documentation on SBOM Orchestration. If you are using DockerHub, you can follow along.
- Image:, Enter the name of your image with tag, such as
my-docker-org/repo-name:tag.
Attest the Ingested SBOM - Optional
SBOM signing is the process of cryptographically signing an ingested SBOM to ensure its authenticity and integrity. It ensures that externally sourced SBOMs have not been tampered with and can be trusted by downstream systems for analysis and compliance. To understand the signing and verification process, see attestation and verification concepts.
You can perform attestation using Cosign with the following signing methods:
- Keyless - Uses short-lived, automatically generated keys based on identity to sign ingested SBOMs without storing private keys.
- Key-based - Uses a user-managed private and public key pair to sign ingested SBOMs, requiring secure key storage and handling.
- Secret Manager - A secure service used to store, manage, and access sensitive data such as cryptographic keys without exposing them directly in pipelines.
Based on the attestation type you select, click the tab below and specify the configurations for the SBOM Orchestration step to perform the attestation.
- Keyless
- Key-based
- Secret Manager
Keyless signing using Cosign lets you sign ingested SBOMs without managing long-lived signing keys. Instead, Cosign uses your workload identity (via OIDC) to obtain a short-lived signing certificate during pipeline execution, which is then used to sign the SBOM. The signing key is generated and used only in memory and is not persisted. This reduces the risk of key compromise while ensuring externally sourced SBOMs remain verifiable and trusted.
To configure SBOM attestation for ingested SBOMs with Keyless signing using cosign, complete the following steps:
- Click the checkbox beside
Attest SBOMto enable SBOM attestation. The radio button besideKeylesswill be selected by default. - Select your preferred OIDC Provider from the dropdown under
OIDC Provider. The available options are:

Harness OIDC
Harness OIDC allows you to use the pipeline’s built-in identity for keyless signing of ingested SBOMs. In this approach, Harness acts as the OIDC provider and automatically supplies the identity required during pipeline execution, eliminating the need for external identity configuration.
Non-Harness OIDC
Non-Harness OIDC allows you to use an external identity provider for keyless signing of ingested SBOMs. In this approach, the OIDC token is retrieved from a configured connector (such as AWS, Azure, or GCP) during pipeline execution and used to obtain a signing certificate. This option is useful when you want to integrate with your organization’s existing identity and access management system instead of using Harness as the OIDC provider.
To use a Non-Harness OIDC provider, you need to configure the Connector for Keyless Signing. To configure the Connector:
- Navigate to the Configurations page under the Manage section from the sidebar navigation of your SCS account. The General tab opens by default.
- Click
Select Connectornext toConnector for Keyless Signingto open theCreate or Select an Existing Connectordialog. - Select your required connector from the list of existing connectors. You can search for your created connector or filter connectors by Project, Organization, and Account.
- Alternatively, click
+ New Connectorto create a new OIDC connector for your preferred cloud provider. For more information, see Connectors for Cloud Providers. - Click
Apply Selected. Once selected, you can view the Configuration Saved Successfully toaster message at the top, indicating that the connector has been selected or created successfully.

Once the connector configuration is done successfully, you can perform attestation using keyless signing with a Non-Harness OIDC provider.
To perform attestation with Cosign selected, you need a key pair. Follow the instructions below to generate the key pair. To perform the attestation process, you need to input the private key and password. Use Cosign to generate the keys in the ecdsa-p256 format. Here’s how to generate them:Generate key pairs using Cosign for SBOM attestation
cosign generate-key-pair to generate the key pairs..key file and a public key as a .pub file. To securely store these files, use Harness file secret.
- Private Key: Input your Private key from the Harness file secret.
- Password: Input your Password for the Private key from the Harness file secret.
In this mode, you can pass your Cosign keys using a Secret Manager. Currently, SCS supports only the HashiCorp Vault secret manager. You can connect your Vault with Harness using the Harness HashiCorp Vault connector. Here are the key points to consider when connecting your Vault:
- Enable the Transit Secrets Engine on your HashiCorp Vault. This is essential for key management and cryptographic operations.
- Configure your HashiCorp Vault connector using the following authentication methods AppRole, Token , JWT Auth or Vault Agent.
- Create a Cosign key pair of type
ecdsa-p256,rsa-2048, orrsa-4096in the Transit Secrets Engine. You can do this in two ways:- CLI: Run the command:
vault write -f <transit_name>/<key_name> type=ecdsa-p256 - Vault UI: Create the key pair directly from the Vault interface.
- CLI: Run the command:
- Ensure the Vault token generated has the required policy applied for Cosign to perform attestation operations.
Harness Vault Connector now supports fetching keys from Vault subfolder paths. This feature is behind the FF SSCA_COSIGN_USING_VAULT_V2. To enable it contact Harness Support, and also ensure to upgrade your Harness delegate version to 25.10.87000 or higher.
Configure the following fields in the step to perform the attestation
- Connector: Select the HashiCorp Vault connector.
- Key: Enter the path to the Transit Secrets Engine in your HashiCorp Vault where the keys are stored.
Harness Vault Connector is supported only for Kubernetes and VM infrastructure. Ensure your Harness delegate is on version 25.10.87000 or higher.