Scans & Results

Understand how scans work, how to read results, and what each test finding means.

What is a scan?

A scan is a single execution of security tests against one of your monitored domains. When a scan runs, it executes every enabled test for that check, collects results, detects issues, and sends notifications if configured.

Each scan produces a report showing which tests passed, which failed, and which generated warnings. Failed tests automatically create or update issues for tracking.

How to trigger a scan

There are four ways to run a scan:

Manual scan

Click Run Scan on any check from the checks list or the check detail page. You'll be redirected to the scan progress page.

Scheduled scan

Configure a schedule (hourly, daily, weekly, monthly) on the check and scans run automatically. See Scheduling.

CI/CD trigger

Use the hash-based CI/CD URL to trigger scans from your deployment pipeline. See CI/CD Integration.

API trigger

Use the REST API to programmatically trigger scans. See API Documentation.

Scan lifecycle

Every scan progresses through these statuses:

Pending Scan has been created and is queued for processing.
In Progress Tests are actively running. You can see individual test results as they complete.
Completed All tests have finished. Results are available.
Failed The scan encountered an error and could not complete. This is different from tests failing — it means the scan process itself errored.

Understanding scan results

Summary metrics

At the top of every scan result, you'll see a summary with three counts:

  • Passed (green) — tests that found no issues. Your application is correctly configured for these checks.
  • Failed (red) — tests that detected security problems. These generate issues that need attention.
  • Warning (yellow) — tests that found potential concerns but not definitive vulnerabilities. Worth reviewing but not urgent.

Individual test results

Click on any test in the scan results to see its full details. Each test result includes:

Findings

A list of specific security issues detected by the test. Each finding has:

  • Title — a brief description of the finding
  • Severity — Critical, High, Medium, or Low
  • Description — detailed explanation of what was found and why it's a security concern

Remediation steps

Step-by-step instructions for fixing the issue, often with code examples you can copy directly into your application. These are also available in the security documentation for each test type.

Technical details

Raw data from the test execution — HTTP response headers, DNS records, certificate details, etc. This is useful for debugging or verifying what StackShield observed.

Severity levels

Severity Meaning Example
Critical Immediately exploitable, high impact. Fix now. Exposed .env file, SQL injection, debug mode enabled in production
High Significant risk, likely exploitable. Fix within days. Missing security headers, weak SSL configuration, no rate limiting
Medium Moderate risk, may require specific conditions. Plan to fix. Missing HSTS header, information leakage, directory listing
Low Minor risk, best practice recommendations. Missing optional headers, suboptimal configurations

Scan history

The Scan History page shows all scans across all your domains, sorted by most recent. You can filter by:

  • Domain — show scans for a specific check
  • Status — filter by completed, in progress, or failed
  • Critical issues — show only scans that detected critical findings
  • Search — search by domain name

Scan history is retained indefinitely so you can track your security posture over time and verify that fixes are working.

Comparing scans

To see how your security posture has changed, compare the results of two scans for the same domain. Look at the pass/fail counts — a decreasing number of failed tests means you're making progress. Issues that were present in an earlier scan but not in a later one are automatically marked as resolved.

Tips

  • Run a scan after deploying fixes to verify they work. Don't just trust local testing — StackShield checks what's actually accessible externally.
  • Schedule daily scans for production domains. Security configurations can regress with deployments, certificate renewals, or infrastructure changes.
  • Focus on Critical and High severity first. These represent the most exploitable issues.
  • Use the CI/CD integration to automatically scan after every deployment, so you catch regressions immediately.