What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current language ecosystem coverage in the indexer: verify against project documentation
- Supported registry and authentication configurations: confirm against project documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Clair splits image analysis into distinct services rather than shipping a single scanning binary. The indexer pulls an image manifest, fetches each layer, and walks the filesystem to identify installed packages and the distribution they came from. The result is stored as an index report in Postgres, keyed by layer, so layers shared between images are analyzed once and reused. The matcher compares that report against vulnerability data which a set of updaters periodically ingests from distribution security trackers for Debian, Ubuntu, Alpine, Red Hat, SUSE and others, plus language ecosystem advisories. A notifier can push events when new data changes the answer for an image you already scanned.
The consequence of that architecture is that Clair is an API, not a product. It has no user interface, no policy engine and no build gate of its own. You call it over HTTP, or you run a registry that calls it for you, which is how most people encounter it: Clair is the scanning engine behind Quay, and it appears embedded in other registry products as well.
Where it fits
This is registry side infrastructure operated by a platform team. It runs as one or more long lived services with a Postgres database, either as a single combined process or split into indexer, matcher and notifier for scale. The workflow is push triggered: an image lands in the registry, the registry asks Clair to index and match it, and results surface in the registry interface. Using it from CI means writing the glue yourself, or using a client such as clairctl.
Strengths
- Layer level indexing and caching means a fleet of images built from the same base is scanned efficiently rather than repeatedly.
- Distribution specific feeds and backport awareness cut the false positives you get from naive version comparison against NVD alone.
- Rescanning is cheap: a new advisory is matched against stored index reports without pulling images again.
- A clean HTTP API makes it practical to embed in another product.
Limitations
- No interface, no policy language, no reporting. Everything above raw findings you build, or get from the registry that wraps it.
- Running it properly means maintaining Postgres plus several services, more operational weight than a single scanner binary.
- Language coverage is narrower than distribution package coverage, and it sees only what package metadata records, not vendored code.
Who it suits
A good fit if you operate your own registry, especially Quay, or are building a product that needs an embeddable scanning backend with a stable API. A poor fit for a team that wants to scan images in a pipeline today, where a single binary scanner gives results with none of the infrastructure.
Used Clair? Recommend it under your own name and title.
Recommend this tool