Skip to main content

Sign Artifacts with Harness SCS

Last updated on

Protect your software supply chain by safeguarding your artifacts from being compromised. Attackers may attempt to inject malicious code into your artifacts, aiming to tamper with your software supply chain. One of the primary goals of attackers is to get you to deploy compromised (or "poisoned") artifacts into your environments. In the worst-case scenario, your deployments could become a distribution channel for these poisoned artifacts, putting your customers and users at risk.

As artifacts pass through multiple stages in the software lifecycle, ensuring they remain secure and untampered is critical. Artifact signing provides a reliable way to guarantee that the artifact built at one stage is the exact same artifact consumed or deployed at the next, with no chance of compromise. This process builds trust, ensures integrity, and strengthens the security of your software supply chain.

Artifact Signing in SCS​

For signing container images, the Artifact Signing step retrieves the artifact from the container registry, signs it using Cosign with a private key from a key pair, and generates a signature file .sig. Once the signature is successfully generated, it is pushed back to the same container registry alongside the artifact. This signature file is essential for verifying the artifact's integrity and authenticity. For more details on artifact verification, refer to the Artifact Verification documentation

Artifact Signing step configuration​

The Artifact Signing step allows you to sign your artifacts and optionally push the generated signature file .sig to the same artifact registry from which the artifact was retrieved.

Artifact Signing step supports both container as well as non-container images.

Container Images​

You can search for Artifact Signing and add it to either the Build , Deploy, or Security stage of a Harness pipeline

note

At present, Harness does not support artifact signing in the deployment stage, However this is part of our roadmap.

Follow the instructions below to configure the Artifact Signing step.

  • Name: Provide a name for the signing step.

  • Artifact Source: Select the source container registry (e.g., DockerHub, ACR, ECR, etc.).

  • Registry: Select the Harness Registry configured for the Harness Artifact Registry where your artifact is stored.

  • Image: Enter the name of your image with tag or digest, such as imagename:tag or imagename:digest.

Non-Container Images​

Artifacts aren't limited to container images. With the Artifact Signing step, you can also sign non-container images to ensure the integrity and authenticity. Each artifact is uniquely identified by its digest (SHA), which is later used during the verification step.

The following non-container artifact types are supported:

  • Helm Charts (.tgz)

  • YAML Manifests (.yaml)

  • Java Archives (.jar)

  • Web Application Archives (.war)

  • Artifacts that are not listed above will be considered as Unknown types.

Follow the instructions below to configure the Artifact Signing step for non-container images:

Name: Provide a name for the signing step.

Artifact Source: Select the Harness Local Stage as the source of the artifact.

Workspace Artifact Path: Provide the exact path to the artifact within the workspace. Ensure that you run a custom step to pull the artifact into the workspace directory.

Target Detection: Choose between Auto and Manual

Auto (default): Automatically sets the artifact name from the provided path.

Manual: Allows you to manually specify the artifact name and version.

Sign the Artifacts​

You can sign artifacts using Cosign with the following signing methods:

  • Keyless - Uses short-lived, automatically generated keys based on identity to sign artifacts without storing private keys.
  • Key-based - Uses a user-managed private and public key pair to sign artifacts, 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.

Keyless signing using Cosign lets you sign artifacts 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 provenance. The signing key is generated and used only in memory and is not persisted. This reduces the risk of key compromise while ensuring the provenance remains verifiable and trusted. The signed artifact is pushed to the container registry and associated with the image digest, typically referenced using the digest with a .sig extension.

To sign artifacts with Keyless signing using cosign, complete the following steps:

  1. Click the radio button beside Keyless under Sign with: to select Keyless signing.
  2. 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. 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. 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:

  1. Navigate to the Configuration page under the Manage section from the sidebar navigation of your SCS account. The General tab opens by default.
  2. Click Select Connector next to Connector for Keyless Signing to open the Create or Select an Existing Connector dialog.
  3. 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.
  4. Alternatively, click + New Connector to create a new OIDC connector for your preferred cloud provider. For more information, see Connectors for Cloud Providers.
  5. 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 artifact signing with a Non-Harness OIDC provider.

Attach Signature to Artifact Registry (Optional): By default, this option is unchecked which means the signature will not be uploaded to the artifact registry and checking this option will push the signature as a .sig file to the artifact registry.

note

This option is available only for signing container images.

View Signed Artifacts​

You can easily access the signed artifact details from the Artifacts Overview tab. This section shows the signature and who signed the artifact. Additionally, you can also find the artifact signing as an event in the Chain of Custody, where a new entry is logged every time you sign an artifact. This entry includes a link to the execution results and rekor log entry, allowing you to track the signing activity and cross-check the details.

note

Rekor logs are disabled by default. To enable them, click on Project Settings, navigate to Default Settings, and disable Airgap mode in Supply Chain Security.

info

You are allowed to re-sign the same image multiple times, with each new signing overwriting the previous one. The Artifacts Overview tab will always display the most up-to-date signing details, reflecting the latest signature information for the artifact.

Example Pipeline For Artifact Signing​

This example demonstrates how to implement artifact signing in the Build stage of the pipeline.

This example Build stage has two steps:

  • Build and Push an Image to Docker Registry: This step builds the cloned codebase and pushes the image to the container registry (DockerHub, ACR, etc.).

  • Artifact Signing: Pulls the artifact from the registry and signs it with a private key pair and pushes the .sig file back to the artifact registry.

To replicate the Artifact Signing step you can use the below sample pipeline YAML

Sample Pipeline YAML 
pipeline:
  name: Artifact Signing
  identifier: ArtifactSigning
  tags: {}
  projectIdentifier: Harness
  orgIdentifier: default
  properties:
    ci:
      codebase:
        connectorRef: Harnessgithub
        build: <+input>
  stages:
    - stage:
        name: Build
        identifier: Build
        description: ""
        type: CI
        spec:
          cloneCodebase: true
          caching:
            enabled: true
          buildIntelligence:
            enabled: true
          execution:
            steps:
              - step:
                  type: BuildAndPushDockerRegistry
                  name: BuildAndPushDockerRegistry_1
                  identifier: BuildAndPushDockerRegistry_1
                  spec:
                    connectorRef: lavakushDockerhub
                    repo: lavakush07/easy-buggy-app
                    tags:
                      - v5
                    caching: true
              - step:
                  type: SscaArtifactSigning
                  name: Artifact Signing_1
                  identifier: ArtifactSigning_1
                  spec:
                    source:
                      type: docker
                      spec:
                        connector: lavakushDockerhub
                        image: lavakush07/easy-buggy-app:v5
                    signing:
                      type: cosign
                      spec:
                        private_key: account.Cosign_Private_Key
                        password: account.Cosign_Password
                    uploadSignature:
                      upload: true
          infrastructure:
            type: KubernetesDirect
            spec:
              connectorRef: account.harness_kubernetes_connector
              namespace: artifact-signing
              automountServiceAccountToken: true
              nodeSelector: {}
              os: Linux
        variables:
          - name: LOG_LEVEL
            type: String
            description: ""
            required: false
            value: TRACE


Verify Artifact Signing​

You can verify the signed artifacts using the Artifact verification step. Refer to configure your pipeline to verify the artifact Signing