How the scanner works

Ruleset versioning and lifecycle

Every report snapshots the scanner version and each selected module ruleset. Active versions carry their release date and the date they were last checked against Amazon documentation. Re-scan comparison discloses a ruleset change instead of attributing every difference to source changes.

Finding confidence and typed evidence

Evidence is typed as SOURCE_LINE, SAMPLE_DATA, WORKFLOW_ANSWER, FILE_CONFIGURATION or MANUAL_VERIFICATION so consumers do not assume every result has a source line.

Evidence-context severity caps

Scanner rules may start from whole-word, path-pattern or keyword matches, but the evidence context caps the final confidence and severity before a report is generated.

Supported and unsupported patterns

• Supported: direct SDK calls, REST paths, request literals, common parser patterns, configuration and structured samples.
• Limited: dynamic dispatch, reflection, generated clients, wrapper functions and runtime-computed dates.
• Excluded by default: dependency/vendor directories, build output, binary files and unsupported extensions.
• Documentation/text matches are retained at reduced severity and marked for verification.

Scan coverage and partial scans

Coverage records submitted, scanned and skipped files; detected languages; applicable and completed rule groups; ruleset versions; and unverified scope. Unsupported, oversized or skipped inputs cannot silently produce a full green status.

• READY_WITHIN_TESTED_SCOPE means no unresolved blocker in completed supported scope.
• NOT_VERIFIED is used when there is not enough evidence to conclude.
• SCAN_PARTIAL identifies skipped or incomplete processing and explains recovery actions.

False positives, suppressions and accepted risk

Stable finding fingerprints let a user suppress a false positive or record accepted risk without losing the original evidence. Suppressions carry reason, note and optional expiry; expired suppressions return to active review.

Sample-data validator methodology

Deterministic quality gate

The versioned quality gate derives one of four states from active findings, completed coverage and pending verification. LOW-confidence findings and MANUAL_VERIFICATION findings never force BLOCKED; only deterministic direct evidence can create a blocking gate reason. The same report and gate version always produce the same decision; no generative model participates.

Read the quality-gate specification

Re-scan fingerprinting

Layered fingerprints combine rule identity, normalized location and semantic evidence. They tolerate line movement while preserving distinctions between fixed, remaining, new, regressed and moved findings.

Read the comparison workflow

Security and retention

• Source is statically analyzed and not retained; reports store findings and metadata only.
• Secret-like values are masked and excluded from analytics.
• Archive safety checks reject encrypted, unsafe-path, symlink and bomb-like uploads.
• Reports use private tokens, expire and can be deleted.

Security details

Benchmark methodology

Labeled fixtures contain expected and forbidden rule IDs for representative code. Golden scenarios cover clean, blocked and mixed reports; property tests check fingerprint and diff invariants; integration tests exercise scan, unlock, re-scan, validators, export and deletion. This curated benchmark is not advertised as 100 percent precision or recall for commercial production use; paid launch should add 20-30 real or anonymized repositories with SDK wrappers, monorepos, dead code, comments/docs, generated clients, dynamic endpoints, mixed old/new code and negative controls.

• Track precision on executable evidence separately from config evidence and docs/test evidence.
• Track recall on direct SDK calls separately from raw REST paths.
• Track unsupported/dynamic rate, partial scan rate and false blocker rate.
• Do not promote 100 percent precision/recall from curated fixtures alone.

Public paid beta launch corpus gate

Before advertising accuracy percentages, the launch corpus should include real or anonymized repositories that exercise different languages and integration styles, not only curated fixtures.

Commercial accuracy metrics to track

Accuracy claims should remain internal until these metrics are measured on the launch corpus. Do not advertise 100 percent precision/recall before representative coverage exists.

• Executable-evidence precision, configuration precision and docs/tests precision.
• Direct SDK-call recall and raw REST-path recall.
• False blocker rate, partial scan rate and unsupported/dynamic rate.
• Suggested internal gate: false blocker rate below 2 percent.
• Suggested internal gate: executable-evidence precision at least 95 percent.
• Suggested internal gate: direct-call recall at least 90 percent.
• No known critical false negative for removal operations.

Known limitations

• Static analysis cannot observe production traffic, runtime feature flags or code generated after upload.
• A clean result is not Amazon certification and does not replace staged rollout or reconciliation.
• Custom wrappers and novel parsers can require manual verification by development or QA.
• Sample validators only establish behavior for the supplied payloads and manifests.