An open source initiative to harden the SDLC
Policy Labs is the home of 🔴🟡🟢 AMPEL and the libraries around it. Together they answer one question at every step of the software development lifecycle: can this source code, this tool, this build be trusted? The answer comes from verifying signed attestations against policies, not from taking anyone's word for it.
| Project | What it is |
|---|---|
| ampel | The Amazing Multipurpose Policy Engine (and L). A lightweight supply chain policy engine that verifies signed attestations, such as SLSA provenance, SBOMs and vulnerability scans, against policies. Runs as a CLI and embeds as a library. |
| policy | The AMPEL policy framework: the data structures, tooling and libraries to define, distribute and manage policies. |
| attestation | The attestation framework the other projects share, built on top of the in-toto attestation formats. |
| collector | Finds and parses attestations wherever they live: files, releases, registries, repositories. |
| signer | A signing and verification library with support for sigstore bundles, DSSE envelopes and plain key pairs. |
| signer-extras | Extra providers and plugins for the signer, kept apart to keep its dependency tree small. |
| predicates | Attestation predicates for AMPEL's own policy material and results. |
| oss | Policies for open source projects. |
The project is run in the open by a steering committee, and no single organization may hold more than a third of its seats. A few principles guide its decisions:
- Open source first. The goal is to bind the open source supply chain ecosystem together, not to replace parts of it.
- Non-partisan. There are no winning formats or technologies. The tools stay format and technology agnostic wherever that is technically feasible.
- Security and compliance by design. Downstream users must be able to audit and trust what they get from us.
- Interoperability. The tools should fit into the signing frameworks, container environments and CI/CD pipelines people already use.
The full rules are in the governance document.
Issues and pull requests are welcome in every repository. Two things to know before sending a patch:
- All commits need a
Signed-off-byline (git commit -s), certifying the Developer Certificate of Origin. - Project-wide discussions, proposals and steering committee votes happen in the community repository.
Everyone taking part is expected to follow the OpenSSF Code of Conduct.
The code is released under the Apache 2.0 license; the policies in oss are dedicated to the public domain under CC0.