Reviewing a Security Scan

The security test case panel is where you configure a scan and read its results. Attack instances are deliberately kept out of the project tree — the tree holds the case node, the panel holds the detail.

Panel Header

The header shows the case name and a summary:

• dimensions — how many attack dimensions are enabled
• instances — how many attack instances were generated
• chains — how many stateful chains are configured

The action buttons depend on the state:

State	Buttons
Not configured (no template yet)	Highlighted Configure...
Configured	Reconfigure..., Regenerate, Clear, Run all

An unconfigured case shows an empty state explaining that the template request and attack dimensions must be configured first.

The Stats Strip

After a run, a single line summarises the verdicts across all instances:

Vulnerable: N · NeedsReview: N (config N) · Secure: N · NotRun: N

• Vulnerable — a vulnerability signal fired.
• NeedsReview — ambiguous outcomes. The (config N) part counts configuration fingerprints (server banners, stack traces, DB versions, debug flags) that are shown but not treated as vulnerabilities.
• Secure — the attack was properly rejected.
• NotRun — not executed yet, including instances skipped because the baseline failed.

The Instance List

The list has one row per attack instance:

Column	Meaning
Category	The attack dimension, e.g. SQL Injection
Instance	The generated instance name (category, mutation target, index)
Severity	The severity of the vulnerability class if the attack succeeds
Verdict	Colour-coded: Vulnerable (red), NeedsReview (amber), Secure (green)
Status	Passed / Failed / Ignored / No Run
Information	The step's own status text

Each row has two actions:

• Run — execute only that instance again (useful to re-check a finding after a change).
• View — open the request/response detail.

Use Run all in the header to execute the whole scan (this is also what running the case from the tree does).

The Detail View

View opens an in-panel detail view:

• The header shows the instance name, its verdict, the mutation strategy, the target, and the payload.
• The Request pane shows exactly what was sent, formatted. The URL bar reflects what the engine will send (the template URL plus the frame's path).
• The Response pane appears only once the instance has run; request and response are side by side with a draggable splitter.
• The assertion diagnostic is shown under the response — it names the signal that fired.

Use Back to return to the list.

Reports

Every run produces a report that can be viewed in Aethrix or exported.

What the summary contains

• Verdict counts: total instances, Secure, Vulnerable, NeedsReview, BaselineFailed, NotRun.
• A findings list for every Vulnerable and NeedsReview instance: category, mutation target, payload, severity, verdict, diagnostic, and request URI.
• Standard identifiers per finding: CWE, CAPEC, and OWASP WSTG, with an NVD search link (CWE is the bridge into the CVE ecosystem).
• The OWASP API Top 10 reference and a plain-language remediation for the category.
• Top Weaknesses — vulnerable findings grouped by CWE, most frequent first.

Report formats

Format	How to enable	Notes
JSON	default CLI report; Studio report panel	Raw structured data
HTML	--html	Self-contained report with the security scan block, stat cards, Top Weaknesses and the findings list
JUnit XML	--junit	For CI dashboards. Findings are attached to the failing test case; on a passing scan with review-only findings the summary is attached as system-out so it is not lost
SARIF 2.1.0	--sarif	For code-scanning integrations. One result per finding, ruleId set to the CWE, level error for Vulnerable and warning for NeedsReview

The HTML security block

The HTML report renders:

• Stat cards: Vulnerable, Needs Review, Baseline Failed, Not Run, Secure. Baseline-failed and not-run instances are shown explicitly, so a scan that was not actually assessed never reads as clean.
• Top Weaknesses with the CWE and an NVD link.
• A two-column findings list: pick a finding on the left, read its detail on the right (verdict, severity, target, payload, CWE/CAPEC/WSTG, OWASP API reference, remediation, and the diagnostic).
• A tree badge on the case: N Vulnerable when findings exist, N Needs Review when only review items exist, Not Run when the scan was not assessed, or Secure only when the scan completed with no findings and no review items.

Stateful chains are listed under Attack Chains (not as data-driven iterations), one group per chain.

Running in CI

Use the CLI run command with the export flags your pipeline consumes and, optionally, the security gate:

aeth run MyProject.aprj --junit --sarif --html --fail-on vulnerable

--fail-on maps security findings to the process exit code so the pipeline can gate on the CLI result directly:

Value	Behavior
none (default)	Never fails on security findings — the run exits 0
vulnerable	Completes with exit code 2 when at least one instance is Vulnerable
needs-review	Completes with exit code 2 when at least one instance is Vulnerable or NeedsReview

Reports are written before the gate is evaluated, so the full evidence is always kept.

Notes:

• Findings are deterministic and persisted, so a scan that passed yesterday fails today only if the API changed (or you regenerated against a new template).
• An invalid --fail-on value is rejected before the run starts.

See Also

• Security Testing
• Stateful Attack Chains
• Understanding Test Reports
• CLI & CI/CD