[security] Protection against supply chain attacks (SLSA, checksum, reproducible builds, etc)

[vermeeren]

Originate from https://github.com/yuzutech/kroki/pull/1530#discussion_r1196583936

In general I also tried looking into dependency checksum verification for the pom.xml, but this appears to be a real rabbit hole with Maven. Ideally all dependencies that are pinned have their checksum pinned in the Kroki repository too to prevent man-in-the-middle supply chain attacks. package-lock.json does this for node, but I couldn't really find info about this with Maven and only some vague hits with Gradle.

This is a meta issue for security when it comes to supply chain attacks and reproducibility of artefacts built by Kroki project. https://slsa.dev/ and https://slsa.dev/spec/v1.0/levels

I realise it's extremely broad so this probably serves as a starting point. Sub-issues for specific items should probably be used for implementation work.

Supply chain attacks

This is a significant attack surface that nowadays is seeing a lot of real exploits, imo this is number one priority.

• Formal auditing of all third-party dependencies is not feasible, so a trust-on-first-use with tests is considered acceptable.
• We want that anyone building Kroki themselves, no matter the installation method, is guaranteed to build using the exact same source code as Kroki project.
  • This protects against man-in-the-middle attacks, compromised CDN/proxy serving malicious file, resulting in running malicious code which might steal sensitive diagram data or compromise system in general, production or dev machine.
• Requires that all downloaded items are verified against their checksum for integrity.
  • If a Kroki dev, Kroki CICD or a third party builds Kroki and checksums fail this must error the build, which then raises many red flags, resulting in investigation and usually issue reported upstream (Kroki).
  • This way, either all deployed Kroki instances are vulnerable, or none at all. Targeted attacks to specific people/companies through supply chain attacks, which would go under the radar easily, are no longer possible.
  • For example npm already does this in package-lock.json through SHA512-sums.
  • Anything downloaded without checksum is equivalent to curl http://no-tls-insecure.site/script | bash -.
• Everything needed must be downloaded at build-time, nothing at runtime.
  • Pretty sure Kroki already does this.

Artefact signing (post-build tampering)

This mostly only makes sense to do after doing the above. A lot of this is also quite young/early. Security-minded deployments have a high chance of being from source, so this is mostly just ideas.

OpenPGP (gpg) is one way to do things, but for containers etc there appear to be many other possibilities. I don't have much experience with this yet. Some references are https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/assembly_signing-container-images_building-running-and-managing-containers and https://github.com/sigstore.

• When one downloads official Kroki binaries, kroki-server.jar, Docker images, there should be a way to verify this is the official Kroki binary and not modified by third party (GitHub, CDN, ...).
  • This requires some form of integrity+authenticity verification that this asset is indeed signed by Kroki project.

Reproducible builds

• To verify Kroki project's build chain is not compromised the artefacts/assets generated by Kroki need to be reproducible.
• Typically the goal is to be able to get exactly same SHA512-sum given the same build environment and source code, so third parties can independently check the official kroki-server.jar.
• For Docker images this is way more complicated, you cannot SHA-sum-check the image, not sure how to handle that.

cc @ggrossetie

[ggrossetie]

As a first step, I've added a m5sum and sha512sum for the kroki-server.jar on the latest release: https://github.com/yuzutech/kroki/releases/tag/v0.21.2

[vermeeren]

@ggrossetie Thanks! I do realise this turned out a lot bigger than expected and is more of a long-term incremental goal than a quick fix.

Kroki is a great project so really appreciate your work!