​
Data Gathering Primitives

​
Material

In Chainloop, a material is any piece of evidence (metadata) generated as part of the software development lifecycle (SDLC), or in more general terms, in any activity from the company compliance process. Examples of materials are:
  • A container image built in a CI pipeline, referenced by its OCI URL (oci://my-registry/my-repo@mytag)
  • A software bill of materials (SBOM)
  • A test or code coverage report
  • A vulnerability scan result
  • An infrastructure scan, and more
Materials can be attached to an attestation during the attestation process. Read the docs

​
Attestation

An attestation is a unit of data sent to Chainloop. Users and CI systems use the Chainloop CLI to “craft” attestations, add pieces of evidence (materials) to them, and “push” them to Chainloop service (the evidence store). Attestations are performed with the Chainloop CLI and its lifecycle looks like this 
# initialize the attestation. Downloading the contract
> chainloop att init --workflow workflow-name --project project-name

# add materials to the attestation
> chainloop att add --value ghcr.io/chainloop-dev/chainloop/control-plane:latest
> chainloop att add --value reports/cyclonedx.json --kind SBOM_CYCLONEDX_JSON

# generate, sign and push the attestation to chainloop
> chainloop att push
Read the docs

​
Workflow

A workflow represents a source of data to be sent to Chainloop. It usually corresponds to a CI pipeline, but it doesn’t necessarily need to match. For example, users might send data from other sources, like a custom integration from Jira. Workflows are just an umbrella term for all data ingestions from the same source. Read the docs

​
Workflow Run

A workflow run represents an execution of a workflow. A successful workflow run will be associated with an attestation. Read the docs

​
Contract

info A contract is the interface between development pipelines and the Chainloop service. It defines the materials that are expected to be sent to Chainloop and some additional constraints, like the type of source (Github, Dagger …, etc.) and the policies that must be evaluated. A contract can also be seen as the interface between the developers who must instrument their CI/CD pipelines and the other teams. Read the docs

​
Compliance Primitives

Compliance Primitives

​
Policy

Policies are rules evaluated against materials and/or the whole attestation document. They represent acceptance criteria for the system to ingest those materials. Even in failure cases (when there are policy violations), attestations are still sent to Chainloop but clearly marked as “not compliant.” This way, Chainloop keeps track of everything that is happening in the system, even if it’s not acceptable. Policies are written in Rego language. Read the docs

​
Policy Groups

Policy groups are a way to group policies together. They are used to be able to attach a set of policies to a workflow contract. Read the docs

​
Frameworks

Frameworks represent high-level regulatory standards or good practices. They are usually promoted by governments and required for companies to fulfill, such as SDDF, SOC2, CRA, etc. Frameworks can also represent internal, custom checklists and normative for release management, security compliance, etc. In any case, Chainloop will help automate those by giving tools to manage and automate frameworks and requirements in terms of policies and data ingestions. Read the docs

​
Requirements

Requirements are a high-level representation of Compliance criteria that the project must meet. They are not necessarily technical but written in high-level natural language by Compliance teams. It’s the responsibility of SecOps teams to map high-level requirements into low-level policies. Requirements are grouped in a framework. Read the docs

​
Exceptions

Sometimes, it’s acceptable for some organizations to release software without fulfilling all internal requirements. In these cases, Chainloop provides a way to register “exceptions” to those requirements, marking them as exempt and thus not counting against compliance criteria. Exceptions and their authors are recorded in the system for future auditing. Read the docs

​
Organizational Primitives

​
Organization

Organizations represent the tenant entity in Chainloop. All users belong to one or more organizations and might have different role levels.
You can select or create an organization in the top left corner of the Chainloop Web UI.Web UI

​
Project and Versions

Projects and versions can be used to model software products. By associating workflows to projects, you can get an aggregated overview of the compliance status of the software product. Read the docs

​
Products

This feature is only available on Chainloop’s platform paid plans.
Products can be seen as a collection of projects (components) to enable product management capabilities and become an entry point to manage compliance, alerting, and user access configuration at scale. Read the docs