Skip to content

Latest commit

 

History

History
101 lines (69 loc) · 4.06 KB

File metadata and controls

101 lines (69 loc) · 4.06 KB

Functionality and purpose

Why Docker Analyzer exists

Docker Analyzer is a local dashboard for structured Docker image security analysis. It does not simply display scanner output. It keeps the selected policy template, submitted Docker images, raw scan data, CWE enrichment, vulnerability cache, and final report connected by one stable identifier: request_id.

Problems the project solves:

  • raw Trivy output is hard to hand over without context;
  • several images can belong to one analysis and need one shared report;
  • policy matching requires a clear link between template CWE lists and discovered vulnerabilities;
  • CWE enrichment should be cached and reviewable instead of repeated blindly;
  • failed, canceled, or incomplete runs need visible status and retry/edit actions.

Main workflow

The implemented workflow is fixed and deterministic:

  1. The user opens New Analysis.
  2. The user selects a policy template or creates a custom one.
  3. The user enters Docker image digests in image@sha256:... format.
  4. The user optionally enables secret scanning for individual images.
  5. The UI sends the analysis request to the UI API.
  6. The orchestrator creates a job and runs the backend pipeline.
  7. Service A saves the selected template summary.
  8. Service C checks runtime readiness.
  9. Service D runs the raw Trivy scan and writes raw JSON artifacts.
  10. Service E maps vulnerabilities to CWE and updates the cache.
  11. Service F reads the artifacts and builds final report views.
  12. The UI displays overview, findings, policy matches, incomplete items, and vulnerabilities without CWE.

UI sections

Dashboard

The start page gives quick access to the main workflow, recent analyses, templates, and cache views. It is intended as the operator entry point.

New Analysis

The analysis form contains:

  • editable request_id;
  • policy template selection;
  • inline custom template creation;
  • Docker image digest list;
  • per-image secret scan switch;
  • validation before start;
  • live run status after start;
  • cancel, retry, edit, and clean-reset actions for failed or canceled runs.

Analysis Detail

The detail page reads final report data by request_id and shows:

  • user input context;
  • per-image vulnerability overview;
  • all findings above the selected severity threshold;
  • policy-relevant findings;
  • findings with missing required report fields;
  • findings without CWE mapping.

Templates

The templates section works with two template sources:

  • system templates from services/ServiceA-Templates/templates/templates.system.json;
  • user templates from services/ServiceA-Templates/templates/templates.users.json.

Supported actions:

  • list templates by perimeter: INTERNAL, EXTERNAL, BOTH, ALL;
  • read a full template;
  • create a user template;
  • delete a user template;
  • refresh the local CWE catalog.

Template creation uses three levels. The backend validates weights, CWE count per level, and existence of CWE IDs in the local catalog.

Vulnerability Cache

The cache page displays normalized cache entries from Service E. It groups vulnerability identifiers by mapping state:

  • mapped directly;
  • mapped through alias;
  • no CWE available;
  • not found;
  • incomplete.

This helps the operator understand which mappings are reliable and which need additional attention.

History

The history page uses browser-side state for recent analyses. It is not a database-backed audit log. It is a convenience view that helps reopen recently used request_id values from the same browser.

Languages and visual behavior

The frontend supports RU/EN language switching. The UI runs in a dark visual style and uses React components, TanStack Query, and local browser storage for lightweight UI state such as recent analyses, the last selected perimeter, and analysis draft data.

Scope boundaries

Docker Analyzer is designed as a local analysis workspace. There is no authentication layer, no multi-user access model, and no external database in the current implementation. Runtime state is stored mainly as JSON artifacts in services/DockerHub and browser-side local storage.