Artifact integrity is crucial in maintaining software security and trustworthiness. High-profile breaches like SolarWinds, CodeCov, 3CX, and JumpCloud have shown how altering artifact contents can lead to significant security vulnerabilities, enabling attackers to infiltrate and compromise software supply chains.

This is the first in a series of blog posts about the importance of artifact integrity, the emergence of frameworks like Supply-chain Levels for Software Artifacts (SLSA) and Sigstore, and how Cycode is addressing these issues by developing secure infrastructure and tooling for organizations.

Sigstore + SLSA = WIN

SLSA has been gaining traction and adoption. With the upcoming release of SLSA 1.1 and additional tracks like the source track, the framework is expanding its scope and effectiveness.

Sigstore is a collection of open-source tools and infrastructure to help developers securely sign, verify, and protect their software artifacts. It aims to make cryptographic signing easy and accessible by using short-lived certificates and a transparency log to ensure integrity and accountability. Sigstore’s main components are Fulcio for certificate issuance and Rekor for immutable logging.

In addition, Sigstore hosts and maintains public instances of Fulcio and Rekor, allowing open-source maintainers to easily sign their artifacts using the infrastructure. Some of the ecosystems that either already integrate with, or plan to integrate with, Sigstore ecosystems are NPM, PyPI, Maven, GitHub, brew, Kubernetes, and more to come. This expanding list demonstrates Sigstore’s significant role in enhancing the security of the software supply chain across various platforms in the open-source ecosystem.

Like Sigstore, For Organizations

Sigstore’s transparency and public verification are significant benefits, though they pose challenges for large enterprises concerned about exposing sensitive data like user information, commits, and repository metadata. Furthermore, Sigstore’s end-user tools primarily focus on GitHub, leaving enterprises using other CI systems, such as Azure Pipelines and Jenkins, without appropriate tools for artifact integrity.

Cimon, Cycode’s offering for build hardening and integrity, has long enabled the attesting and verification of artifacts across various Continuous Integration (CI) systems using diverse signature and verification methods. Our public documentation, provides detailed instructions on these capabilities.

Based on the Sigstore team’s amazing work, our research and engineering teams conducted extensive threat modeling and created our own keyless infrastructure. The infrastructure enables signing artifacts with keyless signing, improving their SLSA rank while ensuring the integrity of the artifact!

From Key Management to … Keyless?

Organizations may create thousands of artifacts per day, including Docker images, JavaScript libraries, JAR files, executables for end-users, and more. Traditionally, these artifacts are signed with code-signing certificates, which must be carefully managed and protected.

Sigstore and keyless methods revolutionize code signing with the following tooling:

• Fulcio: A certificate authority for short-lived signing certificates issued based on an OpenID Connect identity provider
• Rekor: A transparency log that records every signature in a non-modifiable way

These tools are complementary – Fulcio receives signed OIDC tokens representing machine identities created and signed by the Continuous Integration/Continuous Deployment (CI/CD) service provider. Based on this token, it generates a short-lived signed certificate that can be used to sign the desired artifact. Rekor, an immutable ledger, saves this signature along with the certificate, ensuring that the certificate was valid at the time the signature was created. This process provides a verifiable and tamper-proof record for the artifact signature.

This blog introduces several complex terms, such as SLSA, provenance, keyless signing, in-toto attestations, and short-lived certificates. Don’t worry – we’ll cover these concepts in detail in upcoming blogs, explaining the technical aspects and emphasizing the importance of security in this design.

How Cimon Can Help

From a business use case perspective, the Cimon ecosystem addresses the challenges organizations face by offering an end-to-end solution to enhance artifact integrity. We’ll guide you through the entire process, from creating and signing artifacts to managing attestations and verifying them.

Generating SLSA Attestations

As explained in this Cimon getting started guide, generating attestations involves several lines of code in your CI/CD. 

For example, in GitHub Actions:

- name: Cimon Attest
  uses: cycodelabs/cimon-action/attest@v0
  with:
    subjects: |
      dist/artifact1
      dist/artifact2

If you’re using a different CI system, don’t worry. The Cimon command line interface (CLI) handles everything seamlessly behind the scenes. The following command will achieve the same results:

cimon attest generate-and-sign \
 --subjects "dist/artifact1 dist/artifact2"

Cimon uses its own SLSA attestor to create provenance documents that can be signed, attached to artifacts, and cryptographically verified. We create attestations based on intimate knowledge of the runner environment and carefully collect them into structured SLSA and in-toto attestation format. The documentation provides examples of provenance documents Cimon creates.

Signing the Attestations

According to the SLSA v1.0 standard, generating provenance without signing it can only achieve SLSA level 1. Signing is essential to enhance integrity.

With standard key management, you can sign attestations using a provided key:

cimon attest generate-and-sign \
 --subjects "dist/artifact1 dist/artifact2" --key private-key.pem

The attestation could then be verified later by using the matching public key or providing a certificate – and even a certificate chain –  that proves possession of that public key. This is similar to how SSL/TLS connections today are verified.

An upgrade to the execution flow and the use of the new keyless approach only requires the addition of a single flag:

cimon attest generate-and-sign \
 --subjects "dist/artifact1 dist/artifact2" --keyless

Cimon will use the CI provider’s OIDC token to create a short-lived certificate with Sigstore’s public infrastructure, signing the artifact without any provided keys. 

When using keyless signing, users have the option to choose between the public Sigstore infrastructure – which is ideal for open-source projects – and Cycode-managed infrastructure, which is better suited for organizations prioritizing privacy. In our next blog, we will delve into the details of this process, including the specifics of implementing our private infrastructure.

Artifact Storage

One of the challenges in the Sigstore ecosystem is attestation storage. While cosign, another tooling in the Sigstore umbrella offers a solution for container images by storing attestations in the OCI registry, other artifacts like executables, JAR files, and Python packages still face challenges.

To solve that, Cimon securely uploads attestations to the Cycode platform, where they can be fetched and verified at any time.

It’s also important to remember that while SLSA attestation is one focus, it isn’t the only one. The same method can be used for uploading SBOMs, container vulnerabilities, and other types of attestations. Our inspiration came from GUAC, an emerging open-source tool that allows digesting different kinds of attestations and correlating them with one another.

In that term, Cycode’s strength lies within the capability to correlate the attestation with other pieces of data discovered from the SDLC, such as vulnerabilities, code repositories, developers, code owners, branch protections, and much more. The correlation enriches the data and allows better risk prioritization, as explained in the following section.

Verifying Compliance Posture

The Cycode platform correlates attestation data through the Risk Intelligence Graph (RIG), which supports compliance queries to identify gaps. We will show several example queries for such use cases:

• Showing all release images (according to the image tag standard) that weren’t attested properly:

• Showing all images running in production without valid attestation:

• Showing all attested images that were not created in secure CI/CD settings with branch protections. There may be a risk associated with the creation process of these attestations:

Verifying Attestations

Stakeholders, whether consumers of an artifact or internal teams, should verify created attestations before deployment. This can be done in the CD process or embedded in runtime environments like Kubernetes admission controllers.

SLSA attestations offer a more robust verification process than standard signing. Beyond verifying the artifact’s signature, SLSA attestations verify the artifact’s origin, the identity of the user who created it, and even the specific CI/CD job that created it. Combined with short-lived certificates, this approach offers better defense against build-system attacks and certificate theft.

The verification process using the Cimon CLI is straightforward, as explained here. Here’s how you can verify artifacts targeting different SLSA levels:

• If we receive an artifact to deploy, verifying that it has correct provenance and qualifies as SLSA 1 can be done by:

cimon attest verify --subjects dist/artifact

• Suppose we have signed our artifact with a company-generated key. Verifying the signature is one of the main requirements to qualify for the SLSA 2 level, so we can verify it with the appropriate public key:

cimon attest verify --subjects dist/artifact --key public.pem

• For a more robust approach, we can use organization certificates and also validate them against a certificate chain:

cimon attest verify --subjects dist/artifact --cert cert.pem --cert-chain chain.pem

• If you’re using the keyless signature process, you can verify it using the public Sigstore infrastructure with a single flag:

cimon attest verify --subjects dist/artifact --keyless

• To ensure privacy, organizations can use Cycode-managed Sigstore infrastructure, which can be verified with custom Fulcio, Rekor, or Timestamp authority servers

cimon attest verify --subjects dist/artifact --keyless \
  --rekor-server-url https://this.is.rekor.server \
  --fulcio-server-url https://this.is.fulcio.server \
  --timestamp-server-url https://this.timestamp.server

• Finally, we want to know whether the provenance origin is reliable. We can use several provenance predicates to do this, such as organization name, repository name, and branch name:

cimon attest verify --subjects dist/artifact --keyless --verify-repo "my-org/my-secure-repo" --verify-ref "main"

Summary

In this blog, we explored the critical importance of artifact integrity in software supply chains and introduced the innovative keyless signing solutions provided by Sigstore and Cimon. By leveraging short-lived certificates and transparent logging, these tools enhance security and simplify the signing process. Stay tuned for upcoming blogs where we’ll delve deeper into the technical details and security mechanisms that underpin these solutions, including how we leveraged the Sigstore open-source to create our secure Sigstore infrastructure, offering the unparalleled security of keyless signing together with the privacy organizations seek.

The post Securing Artifacts: Keyless Signing with Sigstore and CI/MON appeared first on Cycode.

*** This is a Security Bloggers Network syndicated blog from Cycode authored by Alex Ilgayev. Read the original post at: https://cycode.com/blog/securing-artifacts-keyless-signing-with-sigstore-and-ci-mon/