You have important controls throughout your CI/CD process—from peer review to security testing and supply chain management to code quality tools and packaging standards—but how do you ensure that those processes are being followed? How do you guarantee that containers, application binaries, configuration files (including Infrastructure as Code), etc. are the right ones before they’re deployed? And once they are deployed, how do you rapidly find the correct pipeline and developer team to help address defects and vulnerabilities discovered in production?

Strong cryptographic artifact signatures are a powerful tool to enable strong admission control, provenance, and traceability that support effective security, quality, and compliance programs.

What are Code Signing and Artifact Signing?

Code Signing is providing a trusted cryptographic signature on executable code. It can establish that an authority has approved the release of a particular component. When code is signed, you can have high confidence that the code was created and distributed by the person or organization (entity) that signed it, and you can apply automation that makes sure you’re only running code distributed by entities you trust.

For example, if Whisker Wellness signs their iOS mobile app with Apple’s help, your phone can examine the signature and determine that Apple trusts that Whisker Wellness signed the app, which means it really is their app. If verification succeeds, the phone will run the app. If it fails, it blocks the app from running because it has no way of knowing if the app is from a trustworthy source.

Artifact Signing expands the concept of code signing beyond applications and their components to any artifact you might produce. This means you can get the benefits of being able to verify the source of not only the code, but things like a complete container, system configuration files, media assets—in short, whatever you’re willing to sign and verify.

Confidently Deploy and Run Applications with Artifact Signing

Artifact signing with Endor Labs CI/CD helps you improve traceability, incident response, and compliance.

• Go beyond code signing: Verify applications, containers, configurations and more before launch with fully automated artifact signing and verification.
• Establish full artifact provenance: Code-to-cloud and cloud-to-code traceability lower risks and enable more rapid incident response.
• Integration with SBOM and SCA findings: Connect production artifacts to verified SBOM and VEX documentation.

Launch Your Applications and Containers with Confidence

Endor Labs CI/CD’s artifact signing and verification system allows you to ensure that applications can’t be launched unless they were produced by approved build processes that have signed the containers, code objects, configuration files, etc. that will be deployed and run. Instituting launch controls helps prevent “shadow deployments” and malicious deployments by enabling your admission controller to identify trusted artifacts and revoke permission to launch specific artifacts. Further, your operational controls can reliably identify deployments that bypass admissions control.

Enable Traceability: Code-to-Cloud and Cloud-to-Code

Code-to-Cloud Traceability

Consider a scenario where an Endor Labs Open Source scan reveals a newly-discovered vulnerability in Whisker Wellness’s MobileMeow backend. Whisker Wellness needs to know where this vulnerability affects their production environment to ensure that everything is patched—they are, after all, running different versions of MobileMeow across hundreds or thousands of container instances. Code-to-cloud traceability with Endor Labs CI/CD enables incident responders to provide an artifact identity, digest, and signature to operations teams. These data allows an ops team to do two very important things rapidly:

1. Identify where affected code is running in their environment so it can be upgraded/replaced.
2. Ensure that no new instances of the vulnerable MobileMeow version can ever be deployed.

Cloud-to-Code Traceability

Let’s consider another scenario: Whisker Wellness’s CNAPP (Cloud-Native Application Protection Platform) alerts you that there’s evidence of adversarial activity in the MobileMeow backend. Cloud-to-code traceability with Endor Labs CI/CD enables your ops team to:

• Speed up the investigative process by verifying that the affected artifacts are valid (approved versions, have gone through standard build and deploy processes, etc.).
• Quickly connect the affected artifacts to the responsible teams for deeper investigation and correction.
• Draw a bright line to the code, package, and configuration repositories the artifacts belong to, and quickly determine what controls and tools ran in the pipeline.

Speed up incident response

Code-to-cloud traceability speeds proactive security responses and ensures that vulnerable versions don’t reappear in production after remediation efforts complete. And its companion, cloud-to-code traceability, speeds reactive security responses, allowing operations teams and SOC engineers to rapidly scope the issue and massively reduce research time required to identify root causes.

Lower Compliance Costs

Endor Labs CI/CD enables teams to connect deployed and distributed artifacts with the correct, verified versions of their SBOM documents. This allows rapid response to compliance requests for SBOM data while avoiding problems and costs associated with sending incorrect versions of SBOMs.

Enabling Artifact Signing and Verification with Endor Labs CI/CD

Endor Labs CI/CD is deployed into your existing build pipeline for releasable artifacts. After the pipeline produces an artifact, it makes a signature request to Endor Labs CI/CD. The signature and the event log data are stored into the tamper-resistant Endor Labs CI/CD database for later verification and audit.

When you launch the artifact, your launcher/admission controller uses Endor Labs CI/CD to verify the signature. The verification command accepts information about the artifact’s canonical location (such as a Docker container registry or artifact registry URL) and verifies that the artifact at that location:

1. Is signed with a certificate that was issued by the trusted Certificate Authority (CA).
2. The signature is valid (made correctly, with a valid certificate, within a valid time window).
3. The claims in the signature regarding provenance and other metadata are valid.
4. The version has not been added to the admission blocklist or had its signature revoked.

You can also use the metadata in the signature for an artifact to identify the related package(s) in Endor Labs, along with relevant SBOM and VEX data.

A peek behind the curtain

In order to be able to sign and verify an artifact, a signature system has to do the following:

1. Strongly establish the identity of the signing entity and generate a single-use signing certificate with an acceptable chain of trust and preserve the public key for verification purposes and connect it to the identity.
2. Sign artifact identity and metadata, and store this data and signature together.
3. Create a tamper-resistant log of these events.

Endor Labs CI/CD provides these services transparently, while allowing organizations to use existing PKI and identity infrastructure if they choose.

Produce A Trustworthy Signature

Step 1: Establish Identity

The Endor Labs client (endorctl) establishes strong identity through secretless authentication in your AWS, GCP, or GitHub Actions CI runners, optionally backed by your organization’s SAML or OIDC single-sign-on technology. This allows you to use your Okta, Azure AD, Google Workspace, etc. managed accounts as signing agents in your CI pipeline.

This identity is then connected to a securely-generated ephemeral signing certificate. The certificate is in turn signed by a trusted CA (Certificate Authority). 

Step 2: Sign the Artifact

Information about the artifact’s identity, provenance, and other desired metadata is collected, along with the digest of the artifact itself. This information is collected and signed with the signing certificate, after which the private key portion is destroyed -- this means a given signing certificate is single use for signing.

The signature and metadata are stored in your Endor Labs tenant for use in future verification, and can be retrieved via endorctl or an API request.

Step 3: Log the Signature Event

To reduce the risks of tampering with the signature store, the signing system also creates an tamper-resistant log event detailing what was signed (which includes a copy of the signature and metadata, along with contextual data). This means that an adversary who wished to introduce a false signature would have to not only insert or replace a signature in the signature store (which is already difficult), but also have the ability to make a valid log entry that matched that signature.

Verify A Signed Artifact

To verify the signature, the verification service uses the identity and context data from your artifact store and admission controller, retrieves the signature from the signature store and the signed log event from the signature log, and verifies that all the assertions in the signature (identity, time, trust chain, etc.) hold true. If they do, the signature is valid and you can have confidence that the artifact is the specific one you requested.

This verification can be used to support things like admission control (e.g. a CNAPP admission controller making a decision about whether to allow a container to start) and run-time control (e.g. terminating and reporting invalid or unsigned applications). All that’s required is an authenticated call to the Endor Labs verification service.

Trace Code To Or From An Artifact

The signature metadata has identity information that not only allows you to associate the signature with a particular artifact, but also with relevant package versions within your Endor Labs tenant. This gives you access to the dependency graph, risks, vulnerabilities, and other data, as well as a bridge to the specific git ref used to create that version. This allows bi-directional traceability: from a source repository reference to an Endor Labs data entry, to a signature, to an artifact, to a deployed copy of the artifact in production (code-to-cloud), but also the reverse (cloud-to-code). You can trace at any point in that chain to any other point in that chain.

For code-to-cloud traces, a call to the Endor Labs API—either using our provided command-line tool or a client you generate from our OpenAPI specification—quickly connects a git reference to the artifact signature data. This allows you to quickly and systematically hunt for affected binaries using data from your CSPM or other ops management tools. A research project that used to take hours or days can be reduced to minutes by using the signature to find and verify versions affected by an issue.

For cloud-to-code traces, a similar API call allows you to trace backward from artifact to build. If your ops or security teams and tools identify issues with a particular container, application, or any other artifact, you can check the artifact’s signature and use that to quickly connect the artifact to its specific version in the source repository; in turn, this lets you dramatically speed up identification of an artifact’s owner and contributors so you can recruit the right resources to respond promptly to risk.

Why Not Just Use Sigstore?

The Sigstore project aims to address artifact signing, so why not just use that over Endor Labs CI/CD artifact signing? Sigstore is a fast-growing community within OpenSSF, and we’re big fans of OpenSSF’s work! In fact, when we were first exploring a solution to the problem of artifact signing, we considered simply adopting Sigstore. After all, it already provides a free and open system for strong and safe cryptographic signatures that are publicly auditable alongside a Blockchain-like transparency log.

As we examined this solution for our customers, though, it became clear that the need for a publicly-viewable transparency log was a deal-breaker for many use cases. And we heard many organizations concerned about the complexity of deploying and managing the necessary infrastructure to implement Sigstore at scale.

Endor Labs’ artifact signing is built on many of the same principles as Sigstore, but with different privacy and management goals.

This means that we offer a strong artifact signing solution with a few unique benefits:

1. Private: Control access to signature and verification data, eliminating worries of exposing sensitive metadata to competitors or adversaries.
2. Seamless: No new identity system to manage. Use your existing SSO identities for keyless authentication at both signing and verification points.
3. Simple: A few lines of configuration in your pipelines is all it takes to begin signing artifacts; no new infrastructure or complex key management to maintain.

Build a CI/CD Security Program with Endor Labs

In addition to artifact signing, Endor Labs CI/CD includes:

• CI/CD Discovery: Get visibility into tools used in pipelines across your org, understand security coverage, and find policy violations.
• Repository Security Posture Management (RSPM): Detect repo misconfigurations, best practices, and risks with over 50 out-of-the-box policies.

Endor Labs CI/CD is available in our free trial, where you can explore the Endor Labs Software Supply Chain Security platform on a pre-populated demo environment and with your own projects.