Design a container image vulnerability scanner: system design interview question

How the interviewer opens it

“Design a service that finds known vulnerabilities in container images. Users submit images and expect results to remain current as vulnerability information changes.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Image submission and access
Supported software
Retained scale
Request volume
Image layers
Latency
Vulnerability data
Consistency and availability
Durability and tenant access
Scope limits

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Scan a container image and report its software dependencies and known vulnerabilities
Reuse analysis across shared image layers
Report known fixed versions for affected packages
Reassess retained images when vulnerability data changes

Usually out of scope

Analyze application source code
Run images to detect malicious behavior
Discover unknown vulnerabilities
Support multiple CPU architectures
Build the external vulnerability data sources

What interviewers ask about

Software across image layers: Layers describe filesystem changes, not independent package lists. Later layers can remove or replace software that earlier layers contain.
Changes to vulnerability data: One advisory can affect millions of images. Repeated updates can race with scans and leave reports incomplete or older than their predecessors.
Image identity and shared work: Many images share the same bytes. Worker failures and analyzer changes can make shared results incomplete, obsolete, or unsafe to publish.
Images from unknown sources: The service parses attacker-controlled archives and metadata. A small image can consume excessive resources or attempt access beyond its permitted files.

Common mistakes

The design treats an image as an unordered union of packages from its layers.
The design uses a mutable tag as the identity for reusable analysis.
The service downloads every image whenever vulnerability data changes.
The matcher ignores distribution fixes and ecosystem version rules.
The service presents an incomplete or outdated report as a current clean result.
The service trusts image contents or a known digest without resource limits and tenant access checks.

The bar by level

Senior (L5/E5): The candidate separates layer evidence, final inventories, and vulnerability assessments. The candidate handles shared work, feed changes, withdrawals, retries, tenant access, and unsafe archives.
Staff (L6+/E6+): The candidate closes races between inventory publication and feed updates. The candidate plans selective reassessment at fleet scale. The candidate defines analyzer upgrade, freshness, isolation, and recovery guarantees.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a container image vulnerability scanner
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service that finds known vulnerabilities in container images. Users submit images and expect results to remain current as vulnerability information changes.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Scan a container image and report its software dependencies and known vulnerabilities
Reuse analysis across shared image layers
Report known fixed versions for affected packages
Reassess retained images when vulnerability data changes

Usually out of scope

Analyze application source code
Run images to detect malicious behavior
Discover unknown vulnerabilities
Support multiple CPU architectures
Build the external vulnerability data sources

What interviewers ask about

Software across image layers

Layers describe filesystem changes, not independent package lists. Later layers can remove or replace software that earlier layers contain.

Changes to vulnerability data

One advisory can affect millions of images. Repeated updates can race with scans and leave reports incomplete or older than their predecessors.

Image identity and shared work

Many images share the same bytes. Worker failures and analyzer changes can make shared results incomplete, obsolete, or unsafe to publish.

Images from unknown sources

The service parses attacker-controlled archives and metadata. A small image can consume excessive resources or attempt access beyond its permitted files.

Common mistakes

The design treats an image as an unordered union of packages from its layers.

The design uses a mutable tag as the identity for reusable analysis.

The service downloads every image whenever vulnerability data changes.

The matcher ignores distribution fixes and ecosystem version rules.

The service presents an incomplete or outdated report as a current clean result.

The service trusts image contents or a known digest without resource limits and tenant access checks.

The bar by level

Senior (L5/E5)

The candidate separates layer evidence, final inventories, and vulnerability assessments. The candidate handles shared work, feed changes, withdrawals, retries, tenant access, and unsafe archives.

Staff (L6+/E6+)

The candidate closes races between inventory publication and feed updates. The candidate plans selective reassessment at fleet scale. The candidate defines analyzer upgrade, freshness, isolation, and recovery guarantees.