Aevrin

Scanners and Coverage

Every scanner, what it detects, and how stage reliability is calculated.

Aevrin normalizes specialist scanners into one finding model. Each scanner contributes evidence to a specific stage.

StageScannerPrimary signal
Static analysisSemgrepInjection, traversal, SSRF, unsafe subprocess, and framework patterns
Static analysisBanditPython security mistakes and dangerous APIs
SecretsGitleaksHigh-confidence secret patterns
SecretsTruffleHogSecret detection with verification metadata when supported
DependenciesOSV-ScannerKnown vulnerable packages across manifests and lockfiles
DependenciesTrivyVulnerabilities, secret patterns, and configuration issues
DependenciesOpenSSF ScorecardOptional supply-chain posture when GITHUB_TOKEN is configured
Tool descriptionsmcp-shieldHidden instructions and suspicious tool-description language
Tool descriptionsMCP SDK inspectionSafely enumerates tools from public remote endpoints
Tool descriptionsAevrin rulesWeak auth, missing audit signals, excessive scope, and manifest concerns

Stage outcomes

  • Completed means at least one required tool ran and its output was parsed.
  • Failed means the stage could not produce reliable evidence.
  • Skipped means the check is not applicable, such as no discoverable safe MCP entrypoint.
  • Incomplete scan means a required category has no reliable tool result. Its score reflects only checks that ran and cannot be treated as a clean pass.

Finding severities and locations come from scanner evidence, then map to a consistent OWASP MCP category and remediation field. Raw scanner data remains available for audit, while secrets and runtime errors are redacted before display or upload.

Deliberate limits

Static scanning cannot prove runtime authorization behavior, detect a future rug pull, or adversarially test prompt injection in live tool responses. Aevrin records these as limitations; it does not manufacture coverage for tests that did not run.