search

GSA-TTS / cg-egress-proxy

Provides controlled egress for apps in a restricted-egress cloud.gov space
Other
11 stars 4 forks source link

Scan binaries for dependency problems and gate/report them #24

Open mogul opened 1 year ago

mogul commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

(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 commented 1 year ago

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 commented 1 year ago

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.