47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
# Threat Model
|
|
|
|
## Assets to protect
|
|
|
|
- Credentials and sensitive content inside scanned artifacts
|
|
- Integrity of source artifacts
|
|
- Integrity and confidentiality of generated reports
|
|
- Operator workstation availability
|
|
- Reproducibility of research results
|
|
|
|
## Adversary capabilities
|
|
|
|
An adversary may control file names, directory depth, encodings, content, sizes, symbolic links, prompt text, configuration-like syntax, and misleading metadata inside the approved scan root. An adversary may attempt resource exhaustion, path escape, credential disclosure through reports, rule evasion, or false-positive flooding.
|
|
|
|
## Security controls in the foundation
|
|
|
|
- Symbolic links are not traversed.
|
|
- Only regular files are discovered.
|
|
- Per-file size limits are enforced before content is read.
|
|
- Artifacts are read, never executed or imported.
|
|
- No rule performs network access.
|
|
- Credential-shaped matches are replaced with category-only redacted evidence.
|
|
- Findings preserve source paths and hashes for review.
|
|
- Rule selection is explicit and unknown rule identifiers fail closed.
|
|
- Scan errors produce a distinct exit code.
|
|
|
|
## Residual risks
|
|
|
|
- Large numbers of small files can still consume time and memory.
|
|
- Unicode control characters and deceptive file names can confuse a human reviewer.
|
|
- Pattern rules can miss obfuscated risks and flag benign examples.
|
|
- The current process does not sandbox rule code; built-in rules are trusted code.
|
|
- Reports can reveal file names, repository structure, and nonsecret security context.
|
|
- SHA-256 establishes content identity, not trustworthiness.
|
|
|
|
## Required future controls
|
|
|
|
Before accepting third-party executable plugins, the project must define signing, capability restrictions, time and memory budgets, process isolation, dependency policy, and a plugin evidence schema. Before any cloud or model-backed analyzer is introduced, the project must define consent, data minimization, retention, provider trust, prompt-injection boundaries, model provenance, and offline fallback behavior.
|
|
|
|
## Security invariants
|
|
|
|
1. Default scans do not transmit artifact content.
|
|
2. Default scans do not modify source artifacts.
|
|
3. Reports do not contain full matched secrets.
|
|
4. Untrusted artifacts are never executed.
|
|
5. A successful scan is not represented as proof of security.
|