cert-manager

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Before a final release, we publish alpha and beta versions for community review, with well defined meanings for both (beta differs in that it has a feature freeze except for bug fixes).

Our releases page has examples: https://github.com/cert-manager/cert-manager/releases

Repository on GitHub, which uses git. git is distributed.

We use semver for all releases. Each release has a corresponding branch, such that that minor version can be patched independently of any other release.

Every release has a corresponding git tag.

Each release of cert-manager has hand written release notes along with a summary of changes. For example, see the release notes for v1.13.0: https://github.com/cert-manager/cert-manager/releases/tag/v1.13.0

We also publish release notes on the website: https://cert-manager.io/docs/releases/

There have been no CVEs reported for cert-manager. If any were reported, we would definitely prominently display it in all applicable release notes. As a general policy we seek to document every bug fix in the release in which it was fixed.

Mailing list: https://groups.google.com/g/cert-manager-dev Issue tracker: https://github.com/cert-manager/cert-manager/issues

https://github.com/cert-manager/cert-manager/issues

I don't have any specific data to back this up, but we try to at least acknowledge any bug report we get. Often these aren't actually bugs. We have a separate policy for security bugs, where we have a separate mailing list and we'll response within days to any valid report (see https://github.com/cert-manager/community/blob/f04069b6e874bbbd0ae15dd057f44329eb2022a9/SECURITY.md)

Again, no data to back it up but I believe we do this. Most requests which meet our criteria will be acknowledged and discussed, often in our daily standups or biweekly meetings (see https://cert-manager.io/docs/contributing/#meetings)

Searchable on https://github.com/cert-manager/cert-manager/issues (and on google groups for the mailing list)

https://github.com/cert-manager/community/blob/main/SECURITY.md

https://github.com/cert-manager/community/blob/main/SECURITY.md

Details that people should use email for contacting us, using Google Groups so TLS should be enabled. We don't mention PGP support because it's generally ineffective, but we would gladly discuss alternative channels if needed (such as Signal).

For reports which match our criteria, we aim to reply within days and we document this on https://github.com/cert-manager/community/blob/main/SECURITY.md

Non-trivial build file in repository: https://github.com/cert-manager/cert-manager/blob/master/Makefile.

Anybody can build any release from the makefile, and the makefile is used for all releases we perform as well. The build system is non-trivial, but is open source.

Non-trivial build file in repository: https://github.com/cert-manager/cert-manager/blob/master/Makefile.

Make, go and some other dependencies. All are FLOSS. The makefile has the ability to download and "vendor" dependencies so each dependency version is tracked in each git commit.

All methods of running tests are defined in the Makefile. Our automated tests apply on PRs and periodically, and are defined using prow.

As an example of our tests, see: https://github.com/cert-manager/testing/blob/master/config/jobs/cert-manager/cert-manager/master/cert-manager-master.yaml

An example of a test being run can be seen on any PR, e.g. https://github.com/cert-manager/cert-manager/pull/6495

An example test run from that PR: https://prow.build-infra.jetstack.net/view/gs/jetstack-logs/pr-logs/pull/cert-manager_cert-manager/6495/pull-cert-manager-master-e2e-v1-28/1725480560475770880

We support go test for unit tests, and all tests are runnable via the Makefile

We don't have any specific metrics on this, but our end-to-end tests are extensive and aim to test all relevant issuers and methods of creating certificates

All PRs are tested by prow, and then re-tested if merging them requires a rebase (i.e. if the target branch changed after the PR was raised). We have periodic tests which run regularly. Each supported release (currently 1.13 and 1.12) has similar tests for changes and periodic regular tests.

All PRs are tested in an automated way before being merged.

As general policy we require tests to be added for important features. A recent example would be this community member's PR: https://github.com/cert-manager/cert-manager/pull/6486/files

It adds tests for the feature, which is quite small in scope in this case. If the PR were larger we'd likely also require more testing.

We use go vet by virtue of running go tooling, and we have other tooling to check our code / distributable artifacts, including our own tooling to ensure that our go module state is synced.

All code is has formatting checks too.

We generally treat warnings as errors when we see them. The nature of Go development means that often warnings would be fixed locally before new code gets merged.

I believe in our tooling we generally have warnings enabled as strictly as possible. We'd like to expand our use of linting tools, and when we do we'd aim to be as strict as is reasonable.

Many of the primary developers work for security companies where secure software development is the default.

The developer writing this application has a background in PKI / TLS / security and is a primary developer.

We regularly check the OWASP top 10 and the kubernetes equivalent.

We use the go standard library where possible, which is generally an excellent cryptographic library maintained by experts.

NB: As a general rule, since cert-manager is a project centred around the handling of cryptographic material, we are exceptionally cautious when it comes to cryptography and we have experts within the team who ensure that we support good cryptography.

We use external libraries for our cryptography and would avoid "rolling our own". Mostly, we use the Go standard library.

The go standard library is FLOSS

cert-mangager will not create RSA keys below 2048 bits. Our "minimum" curves are P-256 and Ed25519. We use sha256 as a minimum hash where possible.

Our only support for these broken algorithms would be in parsing legacy certificates which use these algorithms. Our ability to do that is delegated to the go standard library. We'd be highly critical of any attempt to use any broken algorithm in any context.

We avoid SHA-1 as a general rule.

The go standard library supports PFS in TLS, and cert-manager uses TLS where possible, at a minimum of TLS 1.2

We don't support passwords for authentication of external users. Where we use the concept of a password it relates to things like PKCS#12 passwords, which tend to be more analagous to shared secrets.

We use the cryptographically secure RNG from the go standard library

TLS everywhere possible, including when talking to the Kubernetes API which forms the basis of most of our work

Where we check hashes (e.g. for provisioning vendored tooling) we generally embed the hashes into code. When they're fetched by a developer they'll be fetched over HTTPS. Before the hashes are added to code, the reviewer should generally check that the hashes match their expectations.

We run regular scans using trivy and we seek to fix any major vulnerability as soon as possible. The vast majority of reports are false positives but we err on the side of caution if there's any chance that a report is applicable.

Any applicable critical vuln would be handled as a matter of urgency.

We sometimes have embedded private keys in our code for testing purposes, but these are always for testing only. All other credentials which we use and which might be committed anywhere are encrypted.

We use go vet since we use standard go tooling. We'd like to expand this in the future.

We'd like to implement govulncheck soon for this purpose. We do have this kind of scanning today through trivy.

We'd fix any vulnerability of any non-trivial severity as a matter of extreme urgency if we suspected it might be exploitable. We regularly issue patch releases including fixes to any reported vulnerability even if we doubt it's exploitable.

go vet is run on every PR and is run periodically. Trivy scans are run regularly.

We have some fuzzing (https://github.com/cert-manager/cert-manager/blob/7dca7210e799f84446aac168e5ff2a0f02734435/internal/apis/acme/fuzzer/fuzzer.go#L20) as part of our test suite. We'd like to expand this.

We use Go, and we avoid any use of "unsafe" where possible.

We'd treat this like any other vuln - anything exploitable would be fixed as a matter of urgency.