osv-scanner-fips

packaged by Chainguard

Chainguard Container for osv-scanner-fips

FIPS-compliant vulnerability scanner written in Go which uses the data provided by https://osv.dev

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/osv-scanner-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

Chainguard's osv-scanner-fips image is comparable to the official OSV-Scanner image published at ghcr.io/google/osv-scanner, with the following differences:

• The image runs as the nonroot user (UID 65532) by default, whereas the upstream image runs as root.
• The entrypoint /osv-scanner is kept for compatibility; it points to the binary installed at /usr/bin/osv-scanner.
• Like upstream, the image includes the Go toolchain and git so that Go call analysis works, and it sets GOTOOLCHAIN=local. Upstream runs git config --global --add safe.directory '*'; this image applies the same setting through the GIT_CONFIG_COUNT, GIT_CONFIG_KEY_0, and GIT_CONFIG_VALUE_0 environment variables. The image does not include a shell or package manager, and GOLANG_VERSION and GOPATH are not set, so Go uses its default GOPATH in the user's home directory.

FIPS Support

The osv-scanner-fips Chainguard Container ships with a validated redistribution of OpenSSL's FIPS provider module. For more on FIPS support in Chainguard container images, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

OSV-Scanner is built with Chainguard's FIPS Go toolchain, which prefers the OpenSSL FIPS provider for cryptographic operations from the Go standard library. The toolchain defaults to GODEBUG=cgr_fips=openssl+geomys: when the OpenSSL FIPS provider is not available, it falls back to the validated Go Cryptographic Module embedded in the binary. Set GODEBUG=cgr_fips=openssl to require OpenSSL and turn off the fallback. The image includes the hardened FIPS OpenSSL configuration.

To check that the OpenSSL FIPS provider is installed and operational, run the openssl-fips-test utility included in the image:

docker run --rm --entrypoint openssl-fips-test cgr.dev/ORGANIZATION/osv-scanner-fips:latest

The output identifies the provider as Chainguard FIPS Provider for OpenSSL and includes Lifecycle assurance satisfied.

To check which cryptographic module OSV-Scanner uses at runtime, run a scan with GODEBUG=cgr_verbose=1:

docker run --rm -e GODEBUG=cgr_verbose=1 -v "$PWD:/src" cgr.dev/ORGANIZATION/osv-scanner-fips:latest \
  scan source --lockfile=/src/requirements.txt

The log output includes a line ending in cgr_fips: openssl when OSV-Scanner uses the OpenSSL FIPS provider, which is the expected result for this image. If it reports a fallback to geomys, the binary is using the embedded Go Cryptographic Module instead.

The image is built from upstream source and is licensed under the Apache License 2.0. A non-FIPS variant is available as osv-scanner.

Prerequisites

• The files you scan, such as lockfiles, source directories, or image archives created with docker save, must be readable by UID 65532 inside the container.
• Any directory OSV-Scanner writes to, such as an offline database cache, must be writable by UID 65532.
• By default OSV-Scanner needs outbound HTTPS access to the following hosts:
  • api.osv.dev to query vulnerabilities.
  • api.deps.dev to resolve transitive dependencies of manifest files.
  • osv-vulnerabilities.storage.googleapis.com when you download offline databases with --download-offline-databases.
  • proxy.golang.org and sum.golang.org (or your configured GOPROXY) when Go call analysis fetches modules for a scanned Go project.
  • The container registry that hosts an image, when you scan an image directly from a registry instead of from an archive.

In disconnected environments, use --offline, which turns off every feature that needs network access, including transitive dependency resolution and Go call analysis. Because transitive resolution is turned off, the scanned input must list every dependency you want scanned. The Configuration section shows how to download the offline databases first. For details, refer to the upstream usage documentation and offline mode documentation.

Getting Started

Print the version of OSV-Scanner:

docker run --rm cgr.dev/ORGANIZATION/osv-scanner-fips:latest --version

Scan a lockfile in the current directory against the osv.dev database:

docker run --rm -v "$PWD:/src" cgr.dev/ORGANIZATION/osv-scanner-fips:latest \
  scan source --lockfile=/src/requirements.txt

OSV-Scanner exits with status code 1 when it finds vulnerabilities.

Scan a container image saved with docker save:

docker save <image> -o image.tar
docker run --rm -v "$PWD:/src" cgr.dev/ORGANIZATION/osv-scanner-fips:latest \
  scan image --archive /src/image.tar

Use --format=json or --format=sarif to produce machine-readable output for CI integrations.

Kubernetes Usage

The following example mounts a lockfile from a ConfigMap and scans it in a Job:

apiVersion: v1
kind: ConfigMap
metadata:
  name: osv-scanner-input
data:
  requirements.txt: |
    Django==3.2.0
---
apiVersion: batch/v1
kind: Job
metadata:
  name: osv-scanner
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: osv-scanner
          image: cgr.dev/ORGANIZATION/osv-scanner-fips:latest
          args: ["scan", "source", "--lockfile=/src/requirements.txt"]
          volumeMounts:
            - name: input
              mountPath: /src
              readOnly: true
      volumes:
        - name: input
          configMap:
            name: osv-scanner-input

Because OSV-Scanner exits with status code 1 when it finds vulnerabilities, the Job is marked as failed when the scan reports findings. Read the results with kubectl logs job/osv-scanner.

Configuration

The image runs as UID 65532. When you mount a directory that OSV-Scanner must write to, such as a directory used to store offline databases, make sure the user can write to it.

To scan without network access, first run the scan with --offline --download-offline-databases while network access is available, so OSV-Scanner downloads the offline databases. Then run the same scan with --offline and no network. Both runs use the same --offline scope, which turns off every feature that needs network access, including transitive dependency resolution. Because of this, the offline input must already list every dependency you want scanned, for example a complete lockfile instead of a manifest that needs resolving:

docker run --rm -v "$PWD:/src" -e OSV_SCANNER_LOCAL_DB_CACHE_DIRECTORY=/src/.osv-db \
  cgr.dev/ORGANIZATION/osv-scanner-fips:latest \
  scan source --lockfile=/src/requirements.txt \
  --offline --download-offline-databases

docker run --rm --network none -v "$PWD:/src" -e OSV_SCANNER_LOCAL_DB_CACHE_DIRECTORY=/src/.osv-db \
  cgr.dev/ORGANIZATION/osv-scanner-fips:latest \
  scan source --lockfile=/src/requirements.txt --offline

The --offline-vulnerabilities flag alone only switches vulnerability matching to the local databases and leaves dependency resolution turned on, so it is not enough for a disconnected scan.

Documentation and Resources

• OSV-Scanner documentation
• OSV-Scanner on GitHub

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.