Assess SLSA Level

[matheuscscp]

As a security project, an assessment about the SLSA Level of the project should be made and documented at SLSA.md.

Several best practices for supply chain provenance are already employed:

1. All the GitHub security features are already enabled for the repository
2. Users that are not members of the repository cannot trigger GitHub workflows
3. No static/long-lived credentials exist for the purpose of implementing this project (all the access and ID tokens used in the GitHub workflows are 1h-lived)
4. The pull request approval process is very strict, requiring all commits to be signed and three strong status checks to pass, covering: build, linting, tests, advanced static code analysis from GitHub, repository formatting and CI infrastructure planning
5. The dependencies of the project are restricted to a small set of strongly trusted sources: Go's base images, trusted GitHub Actions, Kubernetes and Google official libraries, the netlink library for adding the Google IP address to the loopback interface, and a few other very popular Go libraries with large communities
6. The go mod download build layer is pushed to ghcr.io on every build (useful for disaster recovery)
7. The GitHub workflows are built in a way that CI builds of the emulator are fully isolated
8. Dependencies are monitored and proactively updated by GitHub security tools like Dependabot
9. The main branch is protected with several rules including no deletion, no force push, administrators (except the owner) cannot bypass branch protection rules, etc.
10. All artifacts are cryptographically signed using Sigstore's cosign
11. Pull request authors cannot approve their own pull requests
12. The release GitHub workflow carries the images through their digests all the way from building to testing, pushing, signing, verifying and creating a GitHub release
13. GitHub Actions inputs are never interpolated inside shell scripts or commands (but rather passed as environment variables)

A few obvious items for achieving Level 3:

1. Pull request approval by at least two more people besides the author is still not enforced (but authors, including the owner, already cannot approve their own pull requests)
2. A general review of the core decisions and codebase by more people
3. Evaluate how much "hermetic" a build needs to be. Do we need to vendor dependencies?

Then a badge with the Level can be added to README.md.