Trust, support and known limitations

Xila reads the same files an attacker receives. Developer trust depends on being precise about what it does, what it sends, and what it cannot prove.

Data handling

• The built-in scanner works offline. It does not upload builds, findings, paths, usage data or crash reports.
• Reports are written only to stdout or the path selected with --out.
• Secret evidence is redacted when the finding is constructed. It retains at most a four-character type prefix and never includes surrounding source, because the surrounding source may hold a second credential.
• Built-in modules do not request network access. An external module declaring network access is skipped unless --allow-network is explicit.
• External modules are executable code. On a developer workstation, Xila checks their declarations but does not provide an OS sandbox capable of stopping a dishonest module from using undeclared access. Install external modules only from publishers you trust. Cloud workers must sandbox them.

Xila has no telemetry. Adoption and accuracy measurements are voluntary and must use aggregate counts or sanitized reports.

Supported build surfaces

A successful scan means Xila analyzed the components listed in the report. It does not prove the game is secure, that every packed/encrypted component was read, or that a credential is currently active.

Finding interpretation

• critical and high describe potential impact, not proof that a backend can be accessed.
• Xila never validates a discovered credential against a live service.
• Endpoint findings inventory destinations; an endpoint is not a vulnerability by itself.
• Dependency identification can be incomplete or ambiguous when version strings are stripped.
• Rules favor precision over recall. Obfuscation, encryption and values assembled at runtime can evade static matching.

Each finding includes a rule ID, confidence, location, remediation and source references. Use a baseline for reviewed existing findings; do not silence a rule solely to make CI green.

False positives and missed coverage

False positives are product defects. File a false-positive report with the rule ID and sanitized context. Never paste a credential or proprietary build. For an unsupported layout, use the build-support request.

Maintainers should:

1. acknowledge reproducible high/critical false positives within two working days when capacity permits;
2. fix the rule or document why the match is security-relevant;
3. add a synthetic regression fixture without copying proprietary data;
4. publish precision measurements with the corpus and labeling method.

Security boundary

Xila parses hostile input and may contain parser vulnerabilities. Report path traversal, resource exhaustion, code execution, unredacted secrets or permission bypasses privately to security@xila.us as described in SECURITY.md. Do not attach a private game build to a public issue.

Release trust

Release archives are built from tagged source by GitHub Actions and accompanied by SHA-256 checksums. Until signed provenance and reproducible-build comparison are published, checksums detect download corruption but do not independently prove who produced an archive. Source builds remain the strongest review path.