Security Lab Engineering Standard

Every lab in this track is a security engineering exercise, not a command transcript.

Required Files

Platform-specific labs may add docker-compose.yml, Terraform, Rego, Kotlin, C/C++, Rust, Go, Java/JVM, packet captures, manifests, or scripts, but they still need an offline-testable core.

Deep Guide Standard

Every phase has two complementary guides. They must not repeat a shallow tool tutorial.

WARMUP.md: explain the system

The warm-up must answer:

1. What problem does the subsystem solve, and why does it exist?
2. Which state, identities, objects, and authority does it maintain?
3. Which components execute in user space, kernel, hypervisor, control plane, or external service?
4. What exact data/control path occurs under the hood?
5. Where is policy evaluated and which component enforces it?
6. Which invariants define correct and secure behavior?
7. How do bugs compose into an attack chain?
8. What do mitigations prevent, and what do they explicitly not prevent?
9. Which evidence distinguishes observation from inferred impact?
10. How do patching, rotation, recovery, and residual risk work?

Use mechanism diagrams, state transitions, trust/authority tables, and small code/configuration fragments where they clarify causality. Define acronyms and connect abstractions to the runnable labs.

HITCHHIKERS-GUIDE.md: operate the system

The operator guide must provide:

• a purpose-built authorized range architecture;
• build and inspection workflow;
• safe attack/failure fixtures with expected observations;
• hardening steps tied to the mechanism they change;
• negative, boundary, compatibility, and failure-injection tests;
• runtime verification that proves effective state rather than intended configuration;
• telemetry, detection, triage, containment, and recovery;
• cleanup/teardown and cost/resource controls;
• evidence packet and completion criteria;
• common false claims and control limitations.

Commands without expected state, explanation, and verification do not meet this standard.

Required Learning Loop

1. Authorize: define owner, scope, permitted methods, data, time, rates, and stop conditions.
2. Model: draw assets, identities, flows, trust boundaries, and security invariants.
3. Attack safely: run a seeded case only against the owned fixture.
4. Observe: collect the log, packet, trace, crash, policy decision, or evidence manifest.
5. Explain: distinguish precondition, root cause, demonstrated impact, and plausible impact.
6. Mitigate: change design/code/configuration, not only the triggering input.
7. Regress: prove the attack fails and legitimate behavior still works.
8. Operate: add telemetry, response, rollback, cleanup, and ownership.
9. Communicate: write developer remediation and executive decision summaries.

Test Taxonomy

Every flagship lab must include:

• happy-path tests;
• malformed and oversized input;
• deny-by-default behavior;
• cross-tenant, cross-scope, or privilege-negative cases where relevant;
• race/replay/duplicate/idempotency cases where relevant;
• log redaction and secret canaries;
• regression tests for every seeded weakness;
• failure cleanup and fail-closed behavior.

Safety Rules

• Use only included fixtures, owned local services, CTFs, or explicitly authorized programs.
• Do not target public hosts, neighboring networks, real users, or third-party infrastructure.
• Do not add persistence, stealth, credential theft, destructive payloads, or defense evasion.
• Stop at minimum proof and preserve only the data required to explain and remediate the issue.
• Any lab involving vulnerable services, mobile instrumentation, malware-like samples, cloud accounts, or OT protocols must pass templates/lab-acceptance-checklist.md.

Definition of Done

A lab is complete only when the reference suite passes, the learner implementation passes after the TODOs are completed, the setup works from a clean checkout, and the report states limitations.