Security Scanner

The Security view orchestrates third-party security scanners and presents their findings in a single, filterable table. It supports static analysis of source code, dependency audits for known vulnerabilities, and dynamic testing of running applications — all launched from one place, with results normalised into a common format.

Scanners

Seven scanners are supported, spanning three categories. Consuela orchestrates each tool and collects its output — it does not bundle the scanners themselves. Each must be installed separately and available on your PATH before it can be used.

Scanner	Category	Input
Semgrep	SAST	Directory
CodeQL	SAST	Directory
Trivy	SCA	Directory
Grype	SCA	Directory
Dependency-Check	SCA	Directory
ZAP (OWASP)	DAST	URL
Wapiti	DAST	URL

Scanner categories

SAST (Static Application Security Testing) analyses source code without executing it. It inspects files on disk for patterns that match known vulnerability classes — injection flaws, insecure cryptography, hard-coded secrets, and similar issues that are visible in the code itself.

SCA (Software Composition Analysis) checks project dependencies against databases of known vulnerabilities. It reads lock files, manifests, and container images to identify packages with published CVEs.

DAST (Dynamic Application Security Testing) tests a running application by sending requests to it and observing the responses. It discovers issues that only appear at runtime — misconfigured headers, exposed endpoints, injection points that accept unexpected input.

Running a scan

Select a scanner from the dropdown, point it at a target, and start the scan. SAST and SCA scanners take a directory path — typically the root of the project you want to inspect. DAST scanners take a URL pointing to a running instance of the application.

Scanner-specific options

Semgrep offers a set of config presets that control which rules are applied:

auto — recommended rules selected by Semgrep based on the project's languages and frameworks.
p/default — Semgrep's default ruleset.
p/owasp-top-ten — rules targeting the OWASP Top 10 vulnerability categories.
p/r2c-security-audit — a broader security audit ruleset.
p/secrets — detects hard-coded secrets, API keys, and credentials.
Language-specific presets such as p/python, p/javascript, and p/typescript.

CodeQL requires selecting the language of the codebase being analysed and a query suite. Query suites range from a focused default set to extended suites that include more experimental checks. CodeQL builds a database from the source before running queries, so scans take longer than pattern-based tools.

Trivy and Grype both offer a toggle to respect .gitignore rules when scanning a directory. Enabling it skips files and directories that the project already excludes from version control — typically node_modules, build output, and vendored dependencies.

ZAP and Wapiti take a target URL. The URL should point to a running instance of the application under test. Both tools crawl from the given entry point and probe discovered endpoints for vulnerabilities.

Findings

Results from every scanner are normalised into a single findings table with these columns:

Column	Description
Severity	One of CRITICAL, HIGH, MEDIUM, LOW, or INFO.
Rule ID	The identifier assigned by the scanner for the rule that matched.
Target file	The file where the finding was detected (SAST and SCA scanners).
Line	The line number within the target file, when the scanner provides one.
Message	A short description of the finding from the scanner.

Each row expands to show the full detail view: the complete message text, a code snippet with the affected lines highlighted, and badges for any associated CWE identifiers or OWASP categories that the scanner reports.

Filters

The findings table supports two filters. The severity filter narrows results to one or more severity levels — selecting CRITICAL and HIGH, for example, hides everything below HIGH. The file path filter accepts a substring match against the target file column, making it straightforward to focus on findings within a specific directory or file.

Scan history

Every completed scan is recorded with its timestamp, scanner name, target, and a severity count summary showing how many findings fell into each level. Past scans are listed in reverse chronological order. Selecting a past scan loads its findings into the table, so you can compare results across runs without re-scanning.

The severity summary gives a quick read on whether a codebase is trending in the right direction between scans. A new critical finding after a dependency update, for instance, is immediately visible in the count without opening the full results.