Supported Scan Targets
TL;DR
- Syft automatically detects scan target type, simply pass it as an argument:
syft <target> - Supports container images (Docker/Podman/Containerd/registries), directories, files, and archives
- Use
--from <type>to explicitly specify scan target type (e.g.,--from registryto bypass local daemons)
Syft can generate an SBOM from a variety of scan targets including container images, directories, files, and archives. In most cases, you can simply point Syft at what you want to analyze and it will automatically detect and catalog it correctly.
Catalog a container image from your local daemon or a remote registry:
syft alpine:latest
Catalog a directory (useful for analyzing source code or installed applications):
syft /path/to/project
Catalog a container image archive:
syft image.tar
To explicitly specify the scan target type, use the --from flag:
--from ARG | Description |
|---|---|
docker | Use images from the Docker daemon |
podman | Use images from the Podman daemon |
containerd | Use images from the Containerd daemon |
docker-archive | Use a tarball from disk for archives created from docker save |
oci-archive | Use a tarball from disk for OCI archives (from Skopeo or otherwise) |
oci-dir | Read directly from a path on disk for OCI layout directories (from Skopeo or otherwise) |
singularity | Read directly from a Singularity Image Format (SIF) container file on disk |
dir | Read directly from a path on disk (any directory) |
file | Read directly from a path on disk (any single file) |
registry | Pull image directly from a registry (bypass any container runtimes) |
Instead of using the --from flag explicitly, you can instead:
provide no hint and let Syft automatically detect the scan target type implicitly based on the input provided
provide the scan target type as a URI scheme in the target argument (e.g.,
docker:alpine:latest,oci-archive:/path/to/image.tar,dir:/path/to/dir)
Scan Target-Specific Behaviors
Container Image Scan Targets
When working with container images, Syft applies the following defaults and behaviors:
- Registry: If no registry is specified in the image reference (e.g.
alpine:latestinstead ofdocker.io/alpine:latest), Syft assumesdocker.io - Platform: For unspecific image references (tags) or multi-arch images pointing to an index (not a manifest), Syft analyzes the
linux/amd64manifest by default. Use the--platformflag to target a different platform.
When you provide an image reference without specifying a scan target type (i.e. no --from flag), Syft attempts to resolve the image using the following scan targets in order:
- Docker daemon
- Podman daemon
- Containerd daemon
- Direct registry access
For example, when you run syft alpine:latest, Syft will first check your local Docker daemon for the image.
If Docker isn’t available, it tries Podman, then Containerd, and finally attempts to pull directly from the registry.
You can override this default behavior with the default-image-pull-source configuration option to always prefer a specific scan target.
See Configuration for more details.
Directory Scan Targets
When you provide a directory path as the scan target, Syft recursively scans the directory tree to catalog installed software packages and files.
When you point Syft at a directory (especially system directories like /), it automatically skips certain filesystem types to improve
scan performance and avoid indexing areas that don’t contain installed software packages.
Filesystems always skipped
proc/procfs- Virtual filesystem for process informationsysfs- Virtual filesystem for kernel and device informationdevfs/devtmpfs/udev- Device filesystems
Filesystems conditionally skipped
tmpfs filesystems are only skipped when mounted at these specific locations:
/dev- Device files/sys- System information/runand/var/run- Runtime data and process IDs/var/lock- Lock files
These paths are excluded because they contain virtual or temporary runtime data rather than installed software packages. Skipping them significantly improves scan performance and enables you to catalog entire system root directories without getting stuck scanning thousands of irrelevant entries.
Syft identifies these filesystems by reading your system’s mount table (/proc/self/mountinfo on Linux).
When a directory matches one of these criteria, the entire directory tree under that mount point is skipped.
File types excluded
These file types are never indexed during directory scans:
- Character devices
- Block devices
- Sockets
- FIFOs (named pipes)
- Irregular files
Regular files, directories, and symbolic links are always processed.
Archive Scan Targets
Syft automatically detects and unpacks common archive formats, then catalogs their contents.
If an archive is a container image archive (from docker save or skopeo copy), Syft treats it as a container image.
Supported archive formats:
Standard archives:
.zip.tar(uncompressed).rar(read-only extraction)
Compressed tar variants:
.tar.gz/.tgz.tar.bz2/.tbz2.tar.br/.tbr(brotli).tar.lz4/.tlz4.tar.sz/.tsz(snappy).tar.xz/.txz.tar.zst/.tzst(zstandard)
Standalone compression formats (extracted if containing tar):
.gz(gzip).bz2(bzip2).br(brotli).lz4.sz(snappy).xz.zst/.zstd(zstandard)
OCI Archives and Layout Scan Targets
Syft automatically detects OCI archive and directory structures (including OCI layouts and SIF files) and catalogs them accordingly.
OCI archives and layouts are particularly useful for CI/CD pipelines, as they allow you to catalog images, scan for vulnerabilities, or perform other checks without publishing to a registry. This provides a powerful pattern for build-time gating.
Create OCI scan targets without a registry
OCI archive from an image:
skopeo copy \
docker://alpine@sha256:eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f \
oci-archive:alpine.tar
OCI layout directory from an image:
skopeo copy \
docker://alpine@sha256:eafc1edb577d2e9b458664a15f23ea1c370214193226069eb22921169fc7e43f \
oci:alpine
Container image archive from an image:
docker save -o alpine.tar alpine:latest
Container Runtime Configuration
Image Availability and Authentication
When using container runtime scan targets (Docker, Podman, or Containerd):
- Missing images: If an image doesn’t exist locally in the container runtime, Syft attempts to pull it from the registry via the runtime
- Private images: You must be logged in to the registry via the container runtime (e.g.,
docker login) or have credentials configured for direct registry access. See Authentication with Private Registries for more details.
Environment Variables
Syft respects the following environment variables for each container runtime:
| Scan Target | Environment Variables | Description |
|---|---|---|
| Docker | DOCKER_HOST | Docker daemon socket/host address (supports ssh:// for remote connections) |
DOCKER_TLS_VERIFY | Enable TLS verification (auto-sets DOCKER_CERT_PATH if not set) | |
DOCKER_CERT_PATH | Path to TLS certificates (defaults to ~/.docker if DOCKER_TLS_VERIFY is set) | |
DOCKER_CONFIG | Override default Docker config directory | |
| Podman | CONTAINER_HOST | Podman socket/host address (e.g., unix:///run/podman/podman.sock or ssh://user@host/path/to/socket) |
CONTAINER_SSHKEY | SSH identity file path for remote Podman connections | |
CONTAINER_PASSPHRASE | Passphrase for the SSH key | |
| Containerd | CONTAINERD_ADDRESS | Containerd socket address (overrides default /run/containerd/containerd.sock) |
CONTAINERD_NAMESPACE | Containerd namespace (defaults to default) |
Podman Daemon Requirements
Unlike Docker Desktop, which typically auto-starts, Podman requires explicitly starting the service.
Syft attempts to connect to Podman using the following methods in order:
Unix Socket (primary)
- Checks
CONTAINER_HOSTenvironment variable first - Falls back to Podman config files
- Finally tries default socket locations ($XDG_RUNTIME_DIR/podman/podman.sock
and/run/podman/podman.sock`)
- Checks
SSH (fallback)
- Configured via
CONTAINER_HOST,CONTAINER_SSHKEY, andCONTAINER_PASSPHRASEenvironment variables - Used for remote Podman instances
- Configured via
Direct Registry Access
The registry scan target bypasses container runtimes entirely and pulls images directly from the registry.
Credentials are resolved in the following order:
- Syft first attempts to use default Docker credentials from
~/.docker/config.jsonif they exist - If default credentials are not available, you can provide credentials via environment variables. See Authentication with Private Registries for more details.
Troubleshooting
Image not found in local daemon
If Syft reports an image doesn’t exist but you know it’s available:
- Check which daemon has the image: Run
docker images,podman images, ornerdctl imagesto see where the image exists - Specify the scan target type explicitly: Use
--from docker,--from podman, or--from containerdto target the correct daemon - Pull from registry: Use
--from registryto bypass local daemons and pull directly
Authentication failures with private registries
If you get authentication errors when scanning private images:
- For daemon scan targets: Ensure you’re logged in via the daemon (e.g.,
docker login registry.example.com) - For registry scan target: Configure credentials in
~/.docker/config.jsonor use environment variables (see Private Registries) - Verify credentials: Check that your credentials haven’t expired and have appropriate permissions
Podman connection issues
If Syft can’t connect to Podman:
- Start the service: Run
podman system serviceto start the Podman socket - Check socket location: Verify the socket exists at
$XDG_RUNTIME_DIR/podman/podman.sockor/run/podman/podman.sock - Use environment variable: Set
CONTAINER_HOSTto point to your Podman socket location
Slow directory scans
If scanning a directory takes too long:
- Exclude unnecessary paths: Use file selection options to skip build artifacts, caches, or virtual environments (see File Selection)
- Avoid system directories: Scanning
/includes all mounted filesystems; consider scanning specific application directories instead - Check mount points: Ensure you’re not accidentally scanning network mounts or remote filesystems
Next steps
Continue the guide
Next: Learn about Output Formats to understand how to generate SBOMs in different standard formats like SPDX and CycloneDX.Additional resources:
- Authenticate with registries: Set up Private Registry Authentication for scanning private images
- Control what gets scanned: Use File Selection to include or exclude specific files
- Configure defaults: See Configuration for setting default source preferences