TRUSTIVAN’s misconfiguration scanning is one scanner (Trivy, embedded as a Go library — not shelled out, and not a network call) run offline against the embedded aquasecurity/trivy-checks bundle. The same air-gapped path a customer with no outbound network runs is the one every deployment runs by default.

​
Kinds covered, with proof

Every kind below is asserted by a fixture test in the same scan, in the same offline run, alongside a clean file that must produce nothing — a scanner that flags correct configuration cannot be trusted about the one finding it reports next to it. Azure ARM templates and Ansible playbooks are enabled by the same scanner list (Trivy’s own default) but do not yet have a fixture test in this repository proving a specific finding — treat their coverage as claimed by the upstream engine, not independently verified here until one exists.

​
Not covered

docker-compose is not a supported misconfiguration target. Trivy has no docker-compose config analyzer — there is no rule catalogue that understands a docker-compose.yml’s shape the way it understands a Kubernetes manifest’s. Scanning a compose file today finds nothing not because your compose file is clean, but because nothing looked. This is stated here rather than left to be discovered from an empty findings list.

​
Remediation, not just a rule id

Every misconfiguration finding carries:
  • the file and exact line range the rule matched (location.path, location.start_line, location.end_line),
  • the resolved resource name where the engine can name one (e.g. aws_s3_bucket.logs), not merely the file it lives in,
  • the rule id (e.g. AVD-AWS-0001), and
  • a resolution — what to change and why it matters, in prose, not only a link.
Line numbers are asserted against a known fixture in this repository’s test suite specifically because an off-by-one here reaches a customer as a fix applied to the wrong line of their own file.

​
Severity overrides: per-organization policy control

A customer who has already compensated for a specific rule elsewhere — a WAF in front of the bucket a rule flags, say — can set what severity their organization treats that rule as, without suppressing the finding and losing visibility into recurrences:
A rule with no override keeps the scanning engine’s own severity — never a stored default nobody configured, the same rule TRUSTIVAN’s SLA policy follows. Setting, changing or removing an override is recorded on the tamper-evident identity audit trail (iac_severity_override.set / .removed), with the stated reason kept verbatim, because a severity a customer disagrees with the engine about is exactly the kind of decision an auditor needs to see who made and why. An override never moves a finding’s identity. A misconfiguration’s fingerprint is built from its rule id and its resolved resource — deliberately never from severity, a file path once a resource name exists, or a line number — so a triage decision made under one severity survives the override being set, changed or removed, and survives the resource moving to a different file or the file gaining an import above it that shifts every line number below. Suppression — silencing a specific finding, with a reason and a bounded expiry — is a separate, general mechanism that already applies to every finding kind including misconfigurations; see Suppression. A severity override changes how severe a rule IS; suppression changes whether a specific finding is currently being triaged. Requires policies:manage to set or remove, policies:read to list.

​
Surfaces

  • API — GET/PUT/DELETE /api/v1/settings/iac-severity-overrides (see API reference).
  • Dashboard — misconfiguration findings appear in the shared findings list and detail view alongside every other finding kind, filterable by kind; severity overrides are managed from Settings.
  • This page — the kinds covered, the rule source, and this scanner’s actual limitations.