Scan Comparison (Diff) - Shieldome Docs

What scan comparison shows

Scan comparison produces a structured diff between any two completed scans of the same target URL. It categorizes every finding into one of three groups:

Category	Meaning
New findings	Appeared in the later scan but were not present in the earlier scan - potential regressions or newly introduced issues
Fixed findings	Present in the earlier scan but gone in the later scan - resolved issues; remediation confirmed
Unchanged findings	Present in both scans - open issues that persist across the comparison window and still require attention

In addition to findings, the diff shows a performance delta: side-by-side performance metrics (DNS time, TTFB, page size, response codes) with change indicators so you can see whether a deployment affected load times.

Opening the comparison view

Compare with the previous scan (quickest path)

After a scan completes, if a prior scan of the same URL exists in your history, a Compare with previous button appears in the scan result header. Clicking it opens the diff view immediately - you don't need to navigate to Scan History or select two scans manually.

ℹ️

The Compare with previous button only appears if there is at least one earlier completed scan of the same target URL in the account's history. For a first-ever scan of a target, the button is not shown.

Manual two-scan comparison

To compare any two scans - not just consecutive ones:

Open Scan History from the main navigation.
Filter by target URL to show only scans of the same domain.
Tick the checkbox next to the first scan.
Tick the checkbox next to the second scan (order does not matter - Shieldome sorts by date automatically).
Click the Compare selected button that appears in the action bar.

This method lets you compare any arbitrary pair: for example, the scan from three months ago against today's scan to measure overall remediation progress.

💡

You can only compare scans of the same target URL. Selecting two scans from different URLs shows an error before you navigate away - no wasted clicks.

The diff view

The diff view is organized into four collapsible sections:

New - findings that appeared since the baseline. Each card shows the finding name, severity, OWASP category, and evidence. Sorted by severity (critical first).
Fixed - findings that were in the baseline but are no longer detected. A green checkmark confirms resolution. Use this section as evidence when demonstrating remediation to auditors.
Unchanged - findings present in both scans. These are the persistent backlog items that still need attention.
Performance delta - a table of performance metrics from both scans side by side, with colour-coded change indicators (green for improvement, red for regression).

The diff view header shows a summary banner: "X new, Y fixed, Z unchanged" and the change in risk score between the two scans.

Delta email from scheduled scans

Scheduled scans automatically generate a comparison against the previous scheduled run and send a delta email when results change. The email includes:

New finding count by severity and a short summary of each new finding
Fixed finding count (optional - enabled in schedule notification settings)
Change in risk score (e.g. "Risk score increased from 32 to 47")
A direct link to the full diff view in the app

If nothing changed between runs, no email is sent. See the Scheduled Scans guide for configuration details.

API reference

Compare with the immediately previous scan

GET /api/scan/{scan_id}/compare

Returns a comparison between the given scan and the most recent prior scan of the same URL. If no prior scan exists, has_previous is false and the finding arrays are empty.

bash

curl -H "X-Shieldome-Key: YOUR_API_KEY" \
  https://yourdomain.com/api/scan/SCAN_ID/compare

json - response

{
  "has_previous":  true,
  "scan_id":       "a1b2c3d4-...",
  "previous_id":   "z9y8x7w6-...",
  "new_count":     3,
  "fixed_count":   1,
  "unchanged_count": 8,
  "new_findings": [
    {
      "id":       "f1a2b3-...",
      "name":     "Missing Content-Security-Policy",
      "severity": "high",
      "owasp_id": "A05:2021"
    }
    /* … */
  ],
  "fixed_findings": [
    {
      "id":       "f9e8d7-...",
      "name":     "Insecure Cookie (missing Secure flag)",
      "severity": "medium",
      "owasp_id": "A07:2021"
    }
  ]
}

Compare any two scans

GET /api/scan/compare-two?a={scan_id}&b={scan_id}

Compares an arbitrary pair of scans by ID. The scan with the earlier started_at timestamp is automatically treated as the baseline regardless of parameter order. Both scans must be of the same target URL.

bash

curl -H "X-Shieldome-Key: YOUR_API_KEY" \
  "https://yourdomain.com/api/scan/compare-two?a=SCAN_ID_A&b=SCAN_ID_B"

The response structure is identical to GET /api/scan/{scan_id}/compare, with scan_id and previous_id set to the two IDs you provided (sorted by date).

Full diff with all finding details

GET /api/scan/{scan_id}/diff/{other_scan_id}

Returns a verbose diff with complete finding objects for each row - all fields, evidence, remediation guidance, and suppression status. Suitable for exporting to a SIEM or ticketing system.

json - response structure

{
  "scan_a": { "id": "...", "started_at": "2026-07-01T03:00:00", "target_url": "https://example.com" },
  "scan_b": { "id": "...", "started_at": "2026-07-08T03:00:00", "target_url": "https://example.com" },
  "rows": [
    {
      "key":    { "owasp_id": "A05:2021", "name": "Missing Content-Security-Policy" },
      "diff":   "added",    // "added" | "removed" | "same" | "severity_changed"
      "scan_a": null,       // null when finding was absent in this scan
      "scan_b": { "severity": "high", "status": "vulnerable" /* … full finding */ }
    },
    {
      "key":    { "owasp_id": "A07:2021", "name": "Insecure Cookie (missing Secure flag)" },
      "diff":   "removed",
      "scan_a": { "severity": "medium" /* … */ },
      "scan_b": null
    }
  ]
}

Common use cases

Scenario	How to use comparison
After a deployment	Run a scan immediately after deploying, then compare it against the pre-deploy baseline to confirm no security regressions were introduced by the release
After applying a patch	Confirm the targeted finding appears in Fixed and that no new issues appeared in New as a side effect of the patch
Week-over-week remediation tracking	Schedule weekly scans and compare each Monday's scan against the previous week to measure how many findings were resolved vs introduced - makes sprint retrospectives data-driven
Auditor evidence of remediation	Use `GET /api/scan/{scan_id}/compare` to export diff JSON and present alongside the PDF report to demonstrate that a finding was open in one period and closed in the next
Regression detection	Set up a post-deploy CI step that calls the compare API and fails the build if `new_count` is greater than zero for critical or high severity findings

Example: CI regression gate

The following shell snippet runs a scan after a deployment and fails CI if any new high or critical findings appear compared to the previous scan:

bash - post-deploy CI step

# Trigger a scan and capture the scan ID
SCAN_ID=$(curl -s -X POST \
  -H "X-Shieldome-Key: $SHIELDOME_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target_url":"https://example.com","scan_type":"vuln"}' \
  https://yourdomain.com/api/scan | jq -r '.scan_id')

# Poll until completed (omitted for brevity), then compare
DIFF=$(curl -s \
  -H "X-Shieldome-Key: $SHIELDOME_KEY" \
  "https://yourdomain.com/api/scan/$SCAN_ID/compare")

NEW_HIGH=$(echo $DIFF | jq '[.new_findings[] | select(.severity == "critical" or .severity == "high")] | length')

if [ "$NEW_HIGH" -gt 0 ]; then
  echo "FAIL: $NEW_HIGH new high/critical finding(s) introduced by this deployment"
  exit 1
fi
echo "PASS: No new high/critical findings"