2.3 KiB
Architecture
Design goals
AAISA prioritizes inspectability, deterministic evidence, safe handling of untrusted artifacts, and low barriers for research contributors. The initial implementation uses only the Python standard library and keeps discovery, normalization, policy evaluation, and reporting separate.
Data flow
approved path
|
v
safe discovery -> immutable artifact evidence -> independent rules -> filtered findings
|
v
JSON or SARIF
|
v
human review
Trust boundaries
The scan root is untrusted input. File names, content, encodings, and metadata can be malicious. AAISA therefore does not execute artifacts, does not follow symbolic links, applies a size limit before reading content, decodes text with replacement, and isolates rule failures as scan errors.
The configuration and enabled-rule set are trusted operator inputs. Reports are security-sensitive outputs even though known secret matches are redacted.
Extension contract
A rule exposes an identifier, title, description, default severity, and an evaluate(artifact) method. It returns zero or more immutable findings. A rule must be deterministic for the same artifact and configuration, must not mutate the artifact, must not perform network access, and must never place a matched credential value into a finding.
Future parser and analyzer plugins will require a versioned interface and explicit isolation policy before they are loaded dynamically.
Evidence model
Each artifact records a relative path, class, media type, byte size, and SHA-256 digest. Each finding records its rule, severity, message, artifact path, optional location, redacted evidence, remediation guidance, and tags. The report adds tool version, timestamps, root, summary counts, and nonfatal errors.
Non-goals
The foundation is not a sandbox, endpoint protection product, malware-analysis environment, vulnerability exploit framework, or autonomous remediation system. It does not prove that an artifact is safe.