security

SECURITY LLD TRACEABILITY

Tamper resistance, sandboxing, remote scan policy, and security deep dives.

1. Purpose

This document provides end-to-end traceability from security design intent to concrete implementation and validation.

It maps:

1. Security requirements and controls
2. Implementation anchors (functions/files)
3. Runtime configuration surfaces (flags/env)
4. Test coverage and CI enforcement
5. Residual gaps and next validation actions

2. Traceability Model

Evidence levels used in this matrix:

• I = implemented
• T = tested
• C = CI wired
• P = partial / pending depth

3. Security Control Matrix

4. Runtime Decision Trace

5. Environment and Flag Traceability

5.1 Execution Flags

1. --secure / -secure

• default secure posture selector and explicit override
• anchor: main.go

2. --compat / -compat

• compatibility posture selector
• anchor: main.go

3. --dev / -dev

• compatibility posture + default local password fallback for .mu when password omitted
• anchors: main.go, main.go

4. -password, -pwd, --password=, --pwd=

• explicit password extraction
• anchor: main.go

5.2 runtime configuration settings

1. runtime setting

• secure runtime signer pinning requirement
• anchors: security/const.go, runner/runner.go

2. runtime setting

• stable build-time signer private key source
• anchors: security/const.go, generator/generate.go

3. runtime setting

• central response mode selection
• anchor: security/response_policy.go

4. runtime setting

• delay mode sleep tuning
• anchor: security/response_policy.go

5. runtime setting

• audit stderr event toggle
• anchor: security/telemetry.go

6. runtime setting

• telemetry JSON export target path
• anchors: security/telemetry.go, runner/runner.go

6. Test Coverage Map by Attack Scenario

7. Known Traceability Gaps

The following areas are represented in LLD but only partially evidenced at integration depth:

1. Real Windows runner integration execution with genuine debugger signals (P depth remains).
2. Full compile -> sign -> run -> tamper -> rerun lifecycle integration suite.
3. Dedicated CLI flag parsing tests for secure/compat/dev precedence.
4. Explicit unit coverage for generator password complexity rejection path.
5. Signed-key rotation lifecycle tests (multi-key trust/rollover not yet implemented).

8. Recommended Validation Backlog

1. Add main CLI parsing tests covering mixed mode flag order and dev fallback behavior.
2. Add e2e fixture tests that produce real .mu artifacts and validate tamper outcomes in all policies.
3. Add a Windows CI job for runtime anti-debug policy verification on hosted/self-hosted runner.
4. Add negative tests for malformed runtime setting and runtime setting values in integration context.
5. Add deterministic artifact compatibility tests to guard accidental secure/compat behavior drift.

9. Quick Audit Checklist (Reviewer Use)

1. Secure mode launch path requires trusted key env and fails if absent.
2. Any signature, debugger, or integrity event routes through policy layer.
3. Telemetry increments occur before policy returns error on terminate.
4. VM operand/opcode decode remains offset-aware.
5. CI security profile still executes targeted suites with strict defaults.
6. Dev mode remains explicit and does not silently alter secure mode defaults unless chosen.

10. Probe and Process-Protection Traceability

10.1 Control Additions

1. Master anti-tamper probe gate: runtime setting=1
2. Runner process-protection gate: runtime setting
3. Runner enforcement threshold: any probe signal with detected=true and confidence >= 80

10.2 Implementation Anchors

1. Probe gate and engine: security/antitamper_probe.go
2. Probe routing: security/antitamper_routing.go
3. Probe implementations:
   • security/antitamper_detectors.go
   • security/antitamper_windows.go
4. Runner enforcement path: runner/runner.go
5. Builtin diagnostics probe use: builtin/security_status.go

10.3 Operational Notes

1. Runner enforcement probe scope is intentionally narrower than builtin diagnostic scope.
2. If master probe gate is disabled, runner process-protection enforcement will not execute probe logic even when process-protection gate is enabled.

11. 2026-07 Code Sync Addendum

This addendum captures code-accurate deltas that must be read together with the matrix above.

11.1 Signer-Auth Runtime Semantics

Current implementation:

1. Secure mode selection and signer-auth are independent runtime switches.
2. Trusted signer verification path runs only when --signer-auth is present.
3. --no-signer-auth keeps secure-mode runtime gates but skips signature verification path in runner.

Anchors:

1. main.go
2. runner/runner.go
3. runner/runner_test.go

11.2 Remote Process Scan Control Surface

Current implementation:

1. Remote scan manager is gated by runtime setting.
2. Mode is controlled by runtime setting=off|observe|enforce.
3. Runner blocks only on enforce-mode critical verdicts.
4. Scan errors are non-blocking and telemetry-visible.

Anchors:

1. security/processscan_config.go
2. security/processscan_manager.go
3. runner/runner.go
4. runner/runner_test.go

11.3 Remote Scan Runtime Depth

Current implementation status:

1. Types/config/correlator/manager/telemetry and runner integration are implemented.
2. Windows scanner implementation currently returns empty verdicts (nil, nil), so enforcement path is wired but detector depth is still scaffolding-first.

Anchors:

1. security/processscan_windows.go
2. security/processscan_manager_test.go

End of document.