One of the key tenets of the Sigstore community’s strategy has been to focus on open source package managers as our primary stakeholders. OSS package managers serve as a critical link in the overall software supply chain, both in the distribution of artifacts and metadata, but also often as an implicitly trusted actor that is expected to curate content based on static and transient information. Package managers also typically create command line tools used to download, install and manage packages on systems in a variety of environments.
A package manager looking to adopt Sigstore as part of its artifact signing and verification workflows will generally follow these steps, adjusted appropriately to the nuances of the specific programming language and/or ecosystem:
- Develop language-specific implementation of Sigstore’s signing and verification workflows (if one does not already exist)
- Integrate language-specific Sigstore signing and verification functionality into package management tooling
- Add support for storing Sigstore signatures and attestations in the package registry for consumers to access
- Publish community RFC proposal describing end-to-end workflows, ecosystem-specific threat model, and roadmap for adoption
- Once RFC proposal is approved per community norms, drive implementation plan
- Work to drive initial package adoption strategy; this often involves highly visible or valuable packages that can serve as references for other package maintainers within the ecosystem
- Work with popular build and packaging extensions (like GoReleaser, JReleaser) and builder templates (Jenkins plugins, GitHub Actions)
- Release all code and service extensions required for Sigstore support in a fully-supported mode
- Presuming success to this point, set date for mandating Sigstore signing and verification for all packages in ecosystem
Integrating Sigstore with your own applications provides an effective way to enhance security:
- The ability to control how Sigstore is used.
- The creation of your own user interfaces.
- Package integrity.
- Key management unnecessary.
You can achieve these enhancements in your application while using the underlying Sigstore software that already exists.
There are several libraries available for developers who want to integrate Sigstore signing and/or verification into their project:
- Cosign is a legacy system that still should be used for signing, and Sigstore-go, which is recommended for use in verification. Cosign was developed with a focus on container image signing and verification, and has a rich CLI and a long legacy of features and development.
- Sigstore-go is a more minimal and friendly API for integrating Go code with Sigstore, with a focus on a unified format for Sigstore verification metadata.
- Sigstore-python is a python language based API.
- Sigstore-js is for code signing NPM packages
- Sigstore-java is for Java based applications (pre-release).
- Sigstore-rs is for Rust applications (pre-release).
NOTE: Each of the above libraries has their own entry points. Refer to the specific documentation of each library for details. You can also get support on Slack at the “#clients” channel.
In addition to the individual libraries, a work-in-progress client specification describes the expected signer and verifier flows. You can find it here. Join https://groups.google.com/g/sigstore-dev to get access.
Cosign documentation and examples are available. A few relevant functions:
- For verifying containers or here.
- For verifying blobs. Note that it’s up to the caller to construct the function input structure.
- For signing blobs.
- For signing containers.
These functions were designed to be used within Cosign as a command line utility and not as an API. There are no API stability guarantees for Cosign, and we do not follow semantic versioning (semver). Note that we do not recommend Cosign for integration, as it will pull in a lot of dependencies that will cause your application to increase in size.
Also note that Cosign lacks support for the Protobufs-based bundle format.
The Sigstore-go library represents the future of Sigstore’s support for the Go programming language. It supports the Protobufs-based bundle format, and is a lightweight software package that is much simpler than Cosign. Cosign is focused on OCI use cases, which makes it difficult for library integrators who want to limit their implementations to core sign/verify flows. It can be used today as a smaller alternative than depending on Cosign’s internal libraries (which can come with potentially unnecessary transitive dependencies), and provides the basis for Sigstore bundle support in the policy controller. Cosign was designed as a CLI for signing containers, and Sigstore-go is designed as an API.
The Sigstore-python library is an interface for the Python programming language. Examine the repository for more information.
The Sigstore-js library is designed for code signing NPM packages. See the repository for more information.