[Feature] Scan Comparison View — Side-by-Side Diff for Same-Target Scans Over Time

Abierto
  • ¿Algo no está bien?
#2,354 1 comentario 0 reacciones 1 asignado Ver en GitHub

@harshitavaishnav7878 ya está trabajando en esto.

Desde el 4/8/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

priority:medium type:feature
Problem

Currently, SecuScan stores scan history and findings per task, but there's no way to compare two scans of the same target run at different times. Users running recurring or periodic scans (e.g. weekly nmap or nikto runs against the same host) have no built-in way to answer:

  • What new vulnerabilities appeared since the last scan?
  • What findings were resolved/fixed?
  • What stayed the same (persistent findings)?

This makes tracking security posture over time manual and error-prone — users currently have to eyeball two separate report pages.

Proposed Solution

Add a Scan Comparison View that lets users select two completed scans (same target, same or different plugin run) and see a side-by-side diff of findings, categorized as:

  • 🟢 New — present in the newer scan only
  • 🔴 Resolved — present in the older scan only
  • ⚪ Unchanged — present in both
Suggested Implementation

Frontend (frontend/)

  • New route/page: ScanComparisonView (under existing scan/report pages)
  • Selector UI: pick Scan A and Scan B (dropdown filtered by same target)
  • Fetch both scans' normalized findings in parallel using Promise.all, with skeleton loaders while both requests resolve
  • Diff logic: compare findings by a stable identifier (finding_id, or a composite key of plugin_id + rule_id + affected_asset if no stable ID exists)
  • Visual layout: side-by-side columns or a unified list with color-coded badges (new / resolved / unchanged)

Backend (backend/)

  • May not need a new endpoint if existing findings/report routes can be called twice (once per scan)
  • Alternatively, a dedicated endpoint like GET /api/v1/scans/compare?scan_a={id}&scan_b={id} could return a pre-computed diff, useful for large finding sets
Open Questions for Maintainers
  1. Do normalized findings already have a stable identifier across scans, or would diffing need to match on a composite key?
  2. Should diff computation happen client-side (simpler, works with existing endpoints) or server-side (better for large scans)?
  3. Is there an existing "reports" or "history" page this should extend, or should it be a standalone view?
Why This Is Useful
  • Directly supports SecuScan's use case for recurring/periodic authorized scanning
  • Low risk of merge conflicts — mostly additive (new page/component + optional new endpoint)
  • Fits naturally into the existing "Reports, finding normalization, grouping, workflows" feature area

I'd be happy to pick this up and submit a PR if the maintainers are open to the approach above.

Lenguaje dominante
Python
Estrellas
36
Forks
234
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de utksh1/SecuScan

Todos los issues de utksh1/SecuScan

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.