Scan binaries for dependency problems and gate/report them

[mogul]

@JeanMarie-TTS points out that since we're now distributing our own version of the Caddy binary that includes our selected plugins, we should have a process in place to check that we don't release binaries created from vulnerable dependencies.

Trivy has the ability to scan both Go binaries (no dependencies) and Go modules (including dependencies). I'm unsure how to generate a go.mod as a side effect of compiling our binary with xcaddy; someone with more golang experience probably knows how to do that. Even if we can't do that directly by customizing Caddy's compilation process, apparently it's possible to extract the necessary info from a Go binary.

We should incorporate a scan by Trivy into our GitHub Action workflow that recompiles the binary nightly, and only make a PR adding the binary if the scan is clean.

Ideally, we'd also have a nightly workflow to check for vulnerabilities in our most recent existing binary, and make a vulnerability report if anything is found.

[jadudm]

This may not be the answer you're looking for...

I pulled the caddy repository, removed the go.mod file, and then did a build with xcaddy to see that I could do the build.

After that, I then ran

go mod init caddy

at the top of the tree, and

go mod tidy

to generate the go.mod file.

However, it did error out with:

caddy/modules/caddyhttp/standard imports
	github.com/caddyserver/caddy/v2/modules/caddyhttp/proxyprotocol: module github.com/caddyserver/caddy/v2@latest found (v2.6.4), but does not contain package github.com/caddyserver/caddy/v2/modules/caddyhttp/proxyprotocol
caddy/modules/caddypki/acmeserver imports
	github.com/smallstep/certificates/acme tested by
	github.com/smallstep/certificates/acme.test imports
	go.step.sm/crypto/tpm imports
	github.com/google/go-attestation/x509: module github.com/google/go-attestation@latest found (v0.4.3), but does not contain package github.com/google/go-attestation/x509

For it to error out worries me, because it makes me wonder what xcaddy is doing instead...

Although you're running the two processes separately (xcaddy build and go mod tidy), I'd argue that you're doing it to the same source tree, and therefore are generating the dependencies of the binary you're building. (Granted, you have to trust xcaddy for that be true. Queue Ken Thompson...)

There may be a gopher who is able to take this a bit further. I thought I'd note this much for the conversation's sake.

[jameshochadel]

(Edit: Sorry, sent too soon)

I haven't looked closely at your build process here yet, but I see that xcaddy's README contains the following disclaimer:

⚠️ Pro tip
If you find yourself fighting xcaddy in relation to your custom or proprietary build or development process, it might be easier to just build Caddy manually!

Building from source with a go.mod available would allow you to run the first-party govulncheck tool on the source code (link). That's the tool recommended by the Go team.

[mogul]

Thanks! I'm a Golang neophyte myself, but I'm sure these notes will make more sense to someone with more experience (or me when I circle back around to work on this myself in the future)!

[jadudm]

I just realized that I have no idea if main is where they do new work, and if I should have done my testing against a tag of some sort. (Which may be why my tidy (which pulls the modules, builds the manifest, etc.) didn't work/broke.)

Noting this for the conversation/future selves.