SSDF

The Secure Software Development Framework (SSDF) v1.1, published by NIST, offers a structured approach to embedding secure-by-design principles throughout the software development life cycle (SDLC) and emphasizes the organizational policies, roles, and processes needed to make these practices effective. Its ultimate goal is to reduce software vulnerabilities and limit the impact of potential exploitation. Originally released as voluntary guidance in 2020, SSDF has since become a foundational part of U.S. federal software security requirements, with growing emphasis on measurable compliance.

Chainloop’s current implementation offers an overall SSDF self-assessment checklist, extended with more granular manual evidence and automated policies specifically for the Respond to Vulnerabilities (RV) activities (details in our reference guide).

You should consider SSDF compliance tracking in projects that:

• Include an SBOM as part of the attestation for a generated artifact.
• Periodically run an SCA vulnerability scan on officially supported, released versions of the product.

While these actions could happen in the same workflow, they usually don’t:

• The SBOM is typically generated when the artifact is first created.
• Scanners are often run later, and repeatedly, on already-built artifacts.

A typical Chainloop project managing build, test, release, and post-release workflows with SSDF compliance tracking will resemble the following:

You can enable SSDF compliance tracking on existing projects and workflows as long as they meet these requirements:

• You have a Chainloop project with at least one version. We will refer to this project as production-project.
• Within this project there is a workflow associated with a CI process that sends an SBOM in the attestation. We’ll refer to this as release-workflow.
• Within the same project, you have a workflow associated with the CI process that sends SCA scan reports in the attestation. We’ll refer to this as vuln-scan-workflow.

When a project is set up and workflows are in place, only three steps are needed to track compliance with SSDF:

• Step 1: Attach the SSDF framework to the project
• Step 2: Update or create contracts to gather SBOM, vulnerability report and run policies.
• Step 3: Attach those contracts to workflows (only when previously using default-contract)

Next, we’ll go over SSDF compliance tracking setup in two different cases:

• An existing project that already meets the workflow requirements described above.
• A new project and workflows, where we’ll demonstrate the process manually by uploading attestations. This helps illustrate the mechanics of SSDF compliance tracking. You can later automate this via your CI pipeline.

​

Step 1. Attach the SSDF Framework to the Project

For existing projects, simply follow the framework attachment instructions selecting SSDF from the frameworks list.

If you are starting from scratch, create a new project with the name production-project and add the SSDF framework during the project creation.

​

Step 2. Update or Create Contracts

If you’re reusing existing workflows and those workflows already have contracts (other than the default one), update those contracts to include:

• Correct material types (if you already had contracts, you probably already had the material needed, keep your existing name for each type so you don’t need to update your CI pipeline).
• Required policy groups: sbom-quality for the release-workflow and vulnerability-management for the vuln-scan-workflow.

Go to your contracts list, identify the contract and edit it. For reference, see the release-contract and vuln-scan-contract examples.

If you are starting fresh or using the default (empty) contract, you will need to create new contracts:

#release-contract
schemaVersion: v1
materials:
  # SBOMs will be uploaded to your artifact registry and referenced by digest in the attestation
  # Both SBOM_CYCLONEDX_JSON and SBOM_SPDX_JSON are supported
  - type: SBOM_CYCLONEDX_JSON
    name: sbom
policyGroups:
  - ref: sbom-quality

#vuln-scan-contract
schemaVersion: v1
materials:
  # SCA scans will be uploaded to your artifact registry and referenced by digest in the attestation
  # BLACKDUCK_SCA_JSON, SARIF, TWISTCLI_SCAN_JSON, GHAS_DEPENDENCY_SCAN
  # are supported
  - type: SARIF
    name: vuln-scan
policyGroups:
  - ref: vulnerability-management

#release-contract
schemaVersion: v1
materials:
  # SBOMs will be uploaded to your artifact registry and referenced by digest in the attestation
  # Both SBOM_CYCLONEDX_JSON and SBOM_SPDX_JSON are supported
  - type: SBOM_CYCLONEDX_JSON
    name: sbom
policyGroups:
  - ref: sbom-quality

#vuln-scan-contract
schemaVersion: v1
materials:
  # SCA scans will be uploaded to your artifact registry and referenced by digest in the attestation
  # BLACKDUCK_SCA_JSON, SARIF, TWISTCLI_SCAN_JSON, GHAS_DEPENDENCY_SCAN
  # are supported
  - type: SARIF
    name: vuln-scan
policyGroups:
  - ref: vulnerability-management

# Create release-contract
chainloop workflow contract create --name release-contract -f https://raw.githubusercontent.com/chainloop-dev/chainloop/main/docs/examples/contracts/sbom/sbom-quality.yaml

# Create vulnerability-management-contract
chainloop workflow contract create --name vuln-scan-contract -f https://raw.githubusercontent.com/chainloop-dev/chainloop/main/docs/examples/contracts/vulnerabilities/vulnerability-management.yaml

​

Step 3. Attach Contracts to Workflows

If you’re using existing workflows that were attached to the default contract, update them to use the new contracts:

# Assign release-contract to release-worfklow
chainloop workflow update --name release-workflow --project production-project --contract release-contract

# Assign vuln-scan-contract to vuln-scan-worfklow
chainloop workflow update --name vuln-scan-workflow --project production-project --contract vuln-scan-contract

If you are not reusing any existing workflows, create new ones:

• Create a workflow with the release-workflow name and associate it with the production-project and the release-contract that you created in the previous step.
• Create a workflow with the vuln-scan-workflow name and associate it with the production-project and the vuln-scan-contract that you created in the previous step.

​

Step 4. Send Attestation and Create a Project Version

This step is only necessary if you don’t already have your CI pipeline configured to send attestations.

Assuming you have the Chainloop CLI installed (see installation docs if not), run:

# send sbom attestation
chainloop att init --workflow release-workflow --project production-project --version 1.0 --release
chainloop att add --name sbom --value https://raw.githubusercontent.com/chainloop-dev/chainloop/refs/heads/main/docs/examples/quickstart/sbom.json
chainloop att push

#send vulnerability scan attestation
chainloop att init --workflow vuln-scan-workflow --project production-project --version 1.0 --release
chainloop att add --name vuln-scan --value https://raw.githubusercontent.com/chainloop-dev/chainloop/refs/heads/main/docs/examples/quickstart/vulnerability-report.json
chainloop att push

​

Tracking SSDF Compliance

Once you’ve completed the steps above, your project should now be configured according to the structure shown in the diagram at the beginning of this guide and your SSDF compliance status will appear in the Project Overview for each version.

The compliance status is updated whenever:

• Attestations are submitted through a workflow.
• Manual evidence is provided.
• A policy is due for evaluation (based on time-based rules or SLAs).

Click “See details” to view all SSDF requirements, associated policies, and manual evidence.

As you complete the manual evidence and submit valid attestations through your CI workflows, compliance indicators will turn green.