anchore / grype

A vulnerability scanner for container images and filesystems
Apache License 2.0
8.65k stars 562 forks source link

FIPS-140-2 Compliance #833

Closed mparuszewski closed 2 years ago

mparuszewski commented 2 years ago

Background:

FIPS 140-2 is a U.S. government computer security standard used to approve cryptographic modules. Recently we see increased interest in developing and using FIPS-compliant software. It is especially needed when working with the U.S. government or other regulated industries.

What would you like to be added:

It would be great to see a build of grype that is FIPS-compliant.

To make sure grype is FIPS-compliant, we need to build it with Go with crypto libraries that are FIPS-compliant. In the industry BoringSSL fork of Go is used to create FIPS-compliant builds, ie: RKE2, Contour, Konvoy, etc., so we could go with this path or investigate other approaches.

Challenges:

  1. We need to compile grype using Go with FIPS-compliant crypto libraries, as we are using Goreleaser to build grype and Goreleaser does not allow to specify custom build environment, the main problem is then to use Goreleaser in Docker container with FIPS-compliant crypto libraries. Alternatively, we could provide another approach to building FIPS-compliant binary, like in Contour.

Additional context:

There are multiple articles about the possibility to build go apps that are FIPS-compliant. The main problem that we need to solve is that the app must use FIPS-verified cryptographic libraries. Unfortunately, native golang libraries are not FIPS-verified.

More information:

  1. https://kupczynski.info/posts/fips-golang/
  2. https://gokulchandrapr.medium.com/go-crypto-and-kubernetes-fips-140-2-fedramp-compliance-66d852ccccd2
  3. https://docs.gitlab.com/ee/development/fips_compliance.html#go
  4. https://github.com/microsoft/go-crypto-openssl
  5. https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant#how_to_get_started
joshbressers commented 2 years ago

Hi @mparuszewski,

I gave your links a read to see if building FIPS 140 compliant applications has gotten any easier (I haven't tried to do this in a few years). It's still a pretty heavy lift it looks like.

We would not shy away from patches that allow this build to happen, but we don't currently expect to make building Grype in a FIPS 140 environment a priority for the foreseeable future.

I haven't tried, but it looks like the Red Hat instructions in your above links could result in the binary you are looking for. If you try this and have success we would love to hear about it.

Good luck!

daxxog commented 2 years ago

Something else to consider is FIPS 140-2 has been superseded by FIPS 140-3, so if possible, the new version should be targeted. FIPS 140-2 is supported until 2026. https://csrc.nist.gov/Projects/fips-140-3-transition-effort

mparuszewski commented 2 years ago

I haven't tried, but it looks like the Red Hat instructions in your above links could result in the binary you are looking for. If you try this and have success we would love to hear about it.

@joshbressers I've tried with instructions for Red Hat, however it failed as Golang 1.18 is not yet available as go-toolset (and using 1.17 will fail):

...
   • building binaries
      • building                  binary=/opt/app-root/src/grype/snapshot/linux-build_linux_amd64/grype
   ⨯ release failed after 5.84s error=failed to build for linux_amd64: exit status 1: ../go/pkg/mod/github.com/anchore/syft@v0.51.0/syft/pkg/cataloger/golang/scan_bin.go:4:2: package debug/buildinfo is not in GOROOT (/usr/lib/golang/src/debug/buildinfo)

I've tried with building grype with us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7 image:

$ docker pull us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7
$ docker run --rm -it us-docker.pkg.dev/google.com/api-project-999119582588/go-boringcrypto/golang:1.18.4b7 bash

# apt-get update && apt-get install docker
# git clone https://github.com/anchore/grype.git
# cd grype && make bootstrap
# make build

# ./snapshot/linux-build_linux_amd64/grype ubuntu:18.04
...
# ./snapshot/linux-build_linux_amd64/grype version
Application:          grype
Version:              0.43.0-SNAPSHOT-2c7d4e6
Syft Version:         v0.51.0
BuildDate:            2022-07-22T10:25:01Z
GitCommit:            2c7d4e66d47e914b8dd6869593ccc98d2d2022b1
GitDescription:       v0.43.0-4-g2c7d4e6
Platform:             linux/amd64
GoVersion:            go1.18.4b7
Compiler:             gc
Supported DB Schema:  4

and it worked fine. however we need to check additionally if this is indeed FIPS-compliant or not. 🤔

spiffcs commented 2 years ago

👋 Thanks for checking @mparuszewski and showing that these can run on a FIPS-enabled OS.

Right now the team doesn't have enough bandwidth to take on the lengthy task of validating and submitting Grype or Syft for FIPS compliance. I'm going to close this issue for now with the hope of reopening and investigating when we have the time and developer power to get this accomplished.

joshsleeper commented 2 years ago

fwiw, closing this as completed feels misleading, as does it appearing as something added in the latest release.

https://github.com/anchore/grype/releases/tag/v0.45.0

image

spiffcs commented 2 years ago

@joshsleeper I apologize for this making it onto the release. It was part of our automated changelog generator. We've removed this from the release notes.

spiffcs commented 2 years ago

Also I don't want there to be any confusion here about this being closed as "completed".

The previous comment still stands for closing this issue for the time being. We will reopen again when we have the intent/time/resources to dedicate to the FIPS process.

joshsleeper commented 2 years ago

@joshsleeper I apologize for this making it onto the release. It was part of our automated changelog generator. We've removed this from the release notes.

no worries at all and hopefully I didn't come off gruff, I just want things to be clear to others who do have FIPS requirements to meet that the way this was closed/reported wasn't quite right.

I'm unsure if the two reasons for closure shown here are still the only options: https://docs.github.com/en/issues/tracking-your-work-with-issues/closing-an-issue

but since the work explicitly wasn't done, I would've chosen the "Close as not planned", or ideally even tagged it as a future work item and left it open!