Skip to main content

Harness SSCA key concepts

This topic covers basic terminology and concepts related to the Harness Software Supply Chain Assurance (SSCA) module.

Software supply chain security​

A software supply chain comprises almost anything involved in developing, building, and publishing software artifacts. This can include components, libraries, tools, processes, and more. Software supply chain security includes the measures and processes required to secure these elements.

Supply-chain Levels for Software Artifacts (SLSA) provides industry-wide standards and frameworks for software supply chain security. The Harness SSCA module helps you meet these standards and otherwise secure your software supply chain.

It is a best practice in software supply chain security to produce declarations about your supply chain inventory or security, including:

  • Software Bill of Materials (SBOM): An inventory of components used in producing an artifact.
  • SLSA Provenance: A description of how an artifact was produced.
  • Attestation: A digitally signed SBOM or SLSA Provenance that can be verified for authenticity.

For a detailed explanation of software supply chain security concepts and terms, go to the SLSA terminology documentation.

SBOM generation and management​

A Software Bill of Materials (SBOM) is essential for understanding the components and dependencies within an application, which in turn enables organizations to manage open-source component risks effectively.

The Harness SSCA module provides comprehensive capabilities for generating, managing, and analyzing SBOM for software artifacts.

Integration with other Harness modules and third-party tools​

The SSCA module integrates with the CI and CD stages of Harness pipelines, ensuring that an SBOM is generated for every build of your software artifacts and, optionally, before deployment, as well. This helps you maintain up-to-date information about the components used in your applications at all times. Additionally, you have the flexibility to use your preferred SBOM generation tool.

The SSCA module can also integrate with third-party SBOM generation tools, such as Syft. In the SSCA module, this is referred to as orchestrating with a tool, and it allows you to use your preferred SBOM generation tools or tools standardized and approved by security and governance teams.

SBOM formats​

SSCA can generate SBOM in popular standard formats, such as CycloneDX and SPDX.

Because there are multiple SBOM formats and standards, the SSCA module normalizes your SBOM to extract the relevant information, such as component name, version, supplier, and licensing data. This normalization process ensures that your SBOM data is consistent, easy to manage, and can be used for policy enforcement and further analysis.

Attest and store​

When an SBOM is generated, the SSCA module generates and signs the attestation, ensuring that the information is accurate and trustworthy. The attestations are then securely stored in your artifact repository, where you can access and analyze them as needed. SBOM are also stored in the Harness Platform so that you can download, analyze, and share them as needed.

Attestations are stored as .att files in the artifact repository, specified in your build or deploy stage, along with the image. You can also find the SBOM on the Execution details page in Harness. For more information, go to view pipeline execution results.

info

While Harness is capable of generating SBOMs for both Container Images and Code Repositories, it is important to note that SBOM attestation is supported only for Container Images.

Policy management and enforcement​

With the Harness SSCA module, you can define and enforce policies governing the use of open-source components within your software artifacts. This policy management and enforcement capability helps you ensure compliance with your security, legal, and operational requirements.

Policy definitions​

You can create custom policies to define rules for open-source component usage based on criteria such as component name, version, license, PURL, and supplier.

Policy types​

The SSCA module supports these policy types:

  • Deny list policies: Define components, or combinations of component attributes, that are not allowed. If an artifact includes a component that is part of the deny list, the artifact's policy evaluation fails.
  • Allow list policies: Define components or combinations of component attributes that are allowed. If an artifact includes a component that is not part of the allow list, the artifact's policy evaluation fails.
  • Deny list and Allow list policies: Policies with with both deny list and allow list.

Policy enforcement​

The SSCA module enforces policies in the CI and CD stages of the software delivery lifecycle, ensuring that you build and deploy only compliant software artifacts. When an artifact moves through the CI and CD stages of your pipelines, the SSCA module checks the artifact and its associated SBOM against your defined policies. You can review any detected policy violations on the Supply Chain tab in Execution details page of a pipeline. For more information, go to view pipeline execution results.

SLSA compliance​

With the Harness SSCA module, you can achieve SLSA Build Level 1, Level 2, Level 3. Refer to SLSA Overview

SLSA Provenance attestations are stored as .att files in the artifact repository along with the image. You can also find the SLSA Provenance on the Supply Chain tab in Execution details page of a pipeline.

Harness Platform components​

The Harness SSCA module integrates with other Harness modules and uses components that are common to the Harness Platform. For more information about Harness Platform terminology and concepts, go to Harness' key concepts.

Pipelines​

You add SSCA steps to your CI (build), CD (deploy) and STO (security) stages in your Harness pipelines.

A pipeline is an end-to-end workflow that, for example, pulls code from a codebase, builds an artifact, runs tests or other actions on the artifact or code, and then uploads or deploys the artifact to storage or a container registry.

To learn more about CI and CD pipelines go to:

Pipelines are comprised of stages and steps.

  • Stages: A stage is a subset of a pipeline that contains one major segment of the workflow. For example, a CI (build) stage includes steps for building, pushing, and testing your code.
  • Steps: A stage contains one or more steps. Each step is a series of commands that perform a task. For example, you can use an SBOM Orchestration step to generate SBOM.

Connectors​

Connectors contain the information necessary to integrate and work with third-party tools, such as Git providers and artifact repos. For example, a GitHub connector authenticates with a GitHub account and/or repo and fetches files as part of a deploy stage. Harness uses connectors at pipeline runtime to authenticate and run operations in external tools.

Connectors require different permissions depending on your build environment and the tasks your pipeline performs. For example, if your pipeline builds and pushes an image to Docker Hub, you need a connector that can connect to your Docker Hub repo and push images.

Delegates​

The Harness Delegate is a software service you install in an environment, such as a Kubernetes cluster, that connects to the Harness Manager and performs tasks using your container orchestration platforms, artifact repositories, monitoring systems, and so on.

The delegate uses the credentials set up in the connectors used by the pipeline to perform deployment tasks. Additionally, the delegate needs permissions in the target environment to execute build tasks. These permissions are granted in the delegate config file or the environment account you use when installing the delegate.

For more information, go to the Harness Platform documentation on delegates.

Variables and expressions​

You can add and reference built-in and custom variables and expressions in pipelines and stages. They're available across the pipeline. You can propagate and override their values in later stages.