Skip to content

add blog post on a SigstoreCon talk: Understanding the Identity of a CI Platform #71

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

add blog post on a SigstoreCon talk: Understanding the Identity of a CI Platform #71

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions content/understanding-the-identity-of-a-ci-platform.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
+++
title = "Understanding the Identity of a CI Platform"
date = "2024-12-15"
tags = ["sigstore", "security", "identity", "devops"]
draft = false
author = "Richard Fan (@richardfan1126)"
type = "post"
+++

_This post is based on a talk on SigStoreCon Supply Chain Day 2024. Checkout the [recording](https://youtu.be/-GkfNeE_7us?si=cqAj60-zwJp0n66Z) on sigstore YouTube channel_

### TL;DR

When verifying a sigstore keyless signature, solely relying on the Subject Alternative Name (SAN) is sometimes unreliable, especially when the signature is generated by a CI platform. This post talks about a [security research] where [GitHub reusable workflow](https://docs.github.com/en/actions/sharing-automations/reusing-workflows) can be misused to generate signatures bearing SANs of another entity.

Verifying additional [Fulcio certificate extensions](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md) (e.g., Source Repository URI) is a way to ensure the real source of a CI-generated signature, but supports from different sigstore clients are not unified. sigstore users, both software maintainers and users, need to pay attention to using Fulcio certificates to verify software sources.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you point out where we have inconsistencies across Sigstore clients? I'd like to fix the bugs here too :)

Copy link
Author

@richardfan1126 richardfan1126 Jan 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reviewing my post.

The inconsistencies I observed are basically 2 things:

  1. The support of OID extension verification
    As the table at the end shows, not all clients support verifying the signature against OID extension. Some are partially supported only for GitHub signature.
    This is not a problem because there are different timelines on each client dev teams and we shouldn't expect all client support everything on the first day.
    However, I raise this situation on the post so users won't start implementing their software using one client, and then find out it doesn't support this feature.

  2. (This is a little bit technical, so I didn't mention in the post) The verification logic among 3 clients with full support (sigstore-java, sigstore-python (API), sigstore-go) are different

    1. First, sigstore-java only provides low-level APIs for user to verify extension, it's the user's responsibility to know what the extension number, and data format the value are.
    2. For sigstore-python and sigstore-go, they provide the enums (Ref.1, Ref. 2) for user to specify their extension match requirements. But when interpreting those extensions, they have different logics on some fields
      1. IssuerV2: sigstore-python separate Issuer and IssuerV2 and exposes both fields for user to specify the matching requirement (as OIDCIssuer and OIDCIssuerV2 class). (Ref)
        But sigstore-go merge them into a single object Issuer. Also, the parsing logic on whether Issuer or IssuerV2 is being used for matching is non-deterministic (Ref. 1, Ref.2). So as a user, I'm not sure which field is being matched against.
      2. OtherName SAN: sigstore-python extract this field and add it to the SAN list for the matching logic, but sigstore-go seems only allowing one SAN to be verified (Ref)


### Picking the right SAN is difficult

One of the main features of sigstore is keyless signing, where sigstore clients use the signing entities' OIDC token to [exchange a signing certificate](https://docs.sigstore.dev/certificate_authority/oidc-in-fulcio/).

Despite Fulcio mapping most of the CI platform OIDC token attributes into the certificate as extensions, we still need to pick the most suitable attribute to be the signer's primary identity (or SAN). And picking the best representative from many attributes is always a difficult task.

#### GitHub Actions SAN

One of the examples to showcase the difficulties is GitHub Actions. Fulcio uses `job_workflow_ref` as [the SAN of GitHub Actions workflow](https://docs.sigstore.dev/certificate_authority/oidc-in-fulcio/#github).

From GitHub [documentation](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/using-openid-connect-with-reusable-workflows#how-the-token-works-with-reusable-workflows), `job_workflow_ref` refers to the **called workflow** in a reusable workflow scenario.

The problem now is: There are 2 workflows (**caller** and **called**) involved, and Fulcio certificate SAN can only describe one of them. And now, sigstore chooses to describe the **called** workflow by using the `job_workflow_ref` claim.

In my [security research], I demonstrated how a random GitHub user can call the reusable workflow in the `argoproj/argo-cd` repository, generate a signature bearing its identity, and ultimately pass the `cosign verify` check. This scenario is possible because Fulcio certificate SAN only describes the **called** workflow, but not the **caller** workflow, where the real software source code comes from.

### Checking certificate extensions

The solution to this problem is straightforward: Checking the certificate extensions.

Fulcio's certificate includes many other OIDC claims as certificate extensions. When verifying sigstore signatures, we can add more conditions based on those extensions.

E.g., we can add the following flag into the `cosign verify` command to verify the GitHub source code repository:

```bash
--certificate-github-workflow-repository "argoproj/argo-cd"
```

When designing the signature verification procedure, read the [Mapping OIDC token claims to Fulcio OIDs](https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#mapping-oidc-token-claims-to-fulcio-oids) in addition the official documentations of each CI platform. This way, we can understand which certificate extensions best fit our requirements.

#### Clients support status

Unfortunately, verifying certificate extensions is not fully supported by all sigstore clients.

Below is the table of the current support status _(As of 12th Nov 2024)_

| Not Supported | Only for GitHub | New OID scheme |
|:-----------------:|:-----------------------:|:-----------------------:|
| sigstore-js | [sigstore-python (CLI)] | [sigstore-java] |
| sigstore-rs | [cosign] | [sigstore-python (API)] |
| sigstore-ruby | | [sigstore-go] |
| policy-controller | | |

[security research]: https://blog.richardfan.xyz/2024/08/02/reusable-workflow-is-good-until-you-realize-your-identity-is-also-reusable-by-anyone.html
[sigstore-python (CLI)]: https://github.com/sigstore/sigstore-python/tree/0ac33eeaeb62ca466cef2708ca1dd5864382a008?tab=readme-ov-file#signatures-from-github-actions
[sigstore-java]: https://github.com/sigstore/sigstore-java/blob/cc82dd21b8bbb32624790efa0d169f093b348ef8/sigstore-java/src/test/java/dev/sigstore/fulcio/client/FulcioCertificateMatcherTest.java#L53-L66
[cosign]: https://github.com/sigstore/cosign/blob/main/doc/cosign_verify.md#options
[sigstore-python (API)]: https://github.com/sigstore/sigstore-python/blob/0ac33eeaeb62ca466cef2708ca1dd5864382a008/test/unit/verify/test_policy.py#L173
[sigstore-go]: https://github.com/sigstore/sigstore-go/blob/aff64448eb1f85271fc4753b3ba016e15d9bbfa4/pkg/verify/certificate_identity.go#L150
Loading