The fossa container subcommand supports analysis and testing of containers for vulnerabilities and compliance issues.
fossa container supports following subcommands:
analyze: Scan a container imagetest: Check for issues in a previously scanned container image
fossa container analyze scans container images from:
- Docker archive, e.g.
docker save redis:alpine > redis.tar - Docker Engine (accessed via unix socket
/var/lib/docker.sock) - OCI Registry
No arguments are required to specify the kind of image being analyzed:
fossa-cli automatically identifies the appropriate image source.
For example:
# Local image via Docker Engine
#
# Note: when pulling Docker Engine, the tag is required;
# otherwise the image is inferred to be `docker.io/library/<image>`.
fossa container analyze alpine:3.16.0
# Infers to `docker.io/library/debian:latest` and pulls the image from there.
fossa container analyze debian
# Tries to use the local Docker Engine, but if that fails
# infers to `docker.io/library/debian:latest`
# and pulls the image from there.
fossa container analyze debian:latest
# Explicit remote image with a host and namespace
fossa container analyze cgr.dev/chainguard/wolfi-base:latest
# Exported container image
# `docker save redis:latest > redis.tar`
fossa container analyze redis.tarYou can provide --only-system-deps to only analyze dependencies originating from following system package managers:
- dpkg
- rpm
- alpine
You can refer to scanner documentation, to learn more about how FOSSA CLI performs scan on a container image.
Note
FOSSA CLI uses circe, another binary
maintained by FOSSA, to download and export container images.
For more details on how this works refer to the Circe documentation;
you can also always try running circe directly if you encounter any issues.
Check for issues in a previously analyzed image. Exits non-zero if issues are found.
For example:
fossa container test redis:alpineTo render results in JSON format:
fossa container test redis:alpine --format jsonThe --output flag outputs dependency graph information to the terminal rather than uploading to FOSSA.
fossa container analyze redis:alpine --outputDefault filters are filters which fossa-cli applies by default. These filters,
provide sensible non-production target exclusion. As fossa-cli relies on manifest and lock files provided in the project's directory,
default filters, intentionally skip node_modules/ and such directories. If fossa-cli discovers and
analyzes project found in node_modules/: fossa-cli will not be able to infer
the dependency's scope (development or production) and may double count dependencies.
Specifically, fossa-cli by default skips any targets found within the following directories:
dist-newstyledoc/docs/test/tests/example/examples/vendor/node_modules/.srclib-cache/spec/Godeps/.git/bower_components/third_party/third-party/Carthage/Checkouts/
To disable default filters, provide --without-default-filters flag when performing fossa container analyze. Currently,
it is not possible to disable only a subset of default filters. If you would like to only apply a subset of default filters, you can
use --without-default-filters in conjunction with exclusion filters. Refer to
exclusion filters walkthough for example on how to apply path and target exclusion filters.
- How can I only scan system dependencies?
You can provide --only-system-deps, like following to scan only system dependencies.
fossa container analyze <IMAGE> --only-system-deps- How can I improve performance of fossa container scanning?
You can use docker-archive source with FOSSA CLI. This will reduce time required to retrieve container image from registry or from docker engine.
# save archive of the image
docker save redis:alpine > redis.tar
# scan and test the image
fossa container analyze redis.tar
fossa container test redis.tar- How can I exclude certain projects or targets from container image?
You can use fossa configuration file to exclude specific directory or projects.
Refer to target exclusion walk-through.