Lab 03 — Evidence Redaction Pipeline

Difficulty: 2/5 | Runs locally: yes, standard library only

Pairs with the Phase 00 WARMUP Chapter 8 (privacy, data minimization, redaction).

Why This Lab Exists (Purpose & Goal)

During real testing you will brush against real secrets and real personal data — bearer tokens, emails, IP addresses, API keys. The moment any of it lands in a report, a ticket, a chat message, or a screenshot, you have potentially turned a vulnerability finding into a data breach that you caused. The purpose of this lab is to make redaction a deterministic, auditable transformation rather than a manual, error-prone afterthought. You build the pipeline that strips sensitive tokens from a report while producing a stable count of exactly what was removed.

The Concept, In the Weeds

Two principles govern handling sensitive evidence:

Data minimization — proof, not plunder. To prove broken object-level authorization you need one record you shouldn't be able to read, not the whole table. The size of your evidence is a liability, not a trophy.
Redaction is an irreversible transformation, by design. A good redaction cannot be undone from the published artifact. Beware fake redactions — a black box drawn over still-present text, metadata that retains the original, or reversibly "hashing" a low-entropy value like a phone number that can be brute-forced back. You must redact the bytes, not the appearance.

This lab's pipeline has two properties that matter:

Determinism — the same input always redacts to the same output, so the same entity maps to the same placeholder and analysts can correlate occurrences without ever seeing the raw value.
Counting — the number of redactions ("17 email addresses redacted") is itself evidence of thoroughness and a check against leaks: if the count is zero where you expected secrets, your patterns are wrong.

Why This Matters for Protecting the Company

A leaked report is a new incident, on top of the one you were investigating, and it is one you are personally responsible for. Regulators (GDPR, HIPAA, PCI) treat the unnecessary collection or exposure of personal data as a violation regardless of intent. A redaction pipeline with a verifiable count is how a mature security team demonstrates — to its own privacy/legal function and to a customer — that findings were communicated without ever spreading the sensitive data they concerned. This is also why you redact before storing in any shared location, not just before publishing: the published report is rarely the only leak surface.

Build It

Implement redact(text): replace synthetic bearer tokens, email addresses, IPv4 addresses, and API-key assignments with stable placeholders, returning (redacted_text, counts_by_category). Raw evidence stays unchanged and access-controlled; only sanitized report copies pass through this tool.

LAB_MODULE=solution pytest -q

Secure Implementation Patterns

The anti-pattern. A "redaction" that overlays text it doesn't remove, or that can't report what it did:

report = report.replace(secret, "████")    # if you miss one secret, you don't know; no count, no audit

The secure pattern — deterministic, counted, byte-level redaction (mirrors solution.py):

PATTERNS = (
    ("bearer",  re.compile(r"(?i)\bBearer\s+[A-Za-z0-9._~-]+")),
    ("email",   re.compile(r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b")),
    ("ipv4",    re.compile(r"\b(?:\d{1,3}\.){3}\d{1,3}\b")),
    ("api_key", re.compile(r"(?i)\bapi[_-]?key\s*[:=]\s*\S+")),
)

def redact(text: str) -> tuple[str, dict[str, int]]:
    counts, output = {}, text
    for name, pattern in PATTERNS:
        output, count = pattern.subn(f"[REDACTED:{name}]", output)   # replace the BYTES, not the display
        counts[name] = count                                          # COUNT each category (evidence + leak check)
    return output, counts

The counts are the security feature: "17 emails redacted" is auditable proof of thoroughness, and a count of zero on a report you know contained secrets means your patterns are broken — not that the report is clean.

Production practices to carry forward:

Redact the bytes, not the appearance — never a black box over still-present text, and strip document metadata that retains the original.
Determinism enables correlation — the same entity maps to the same placeholder, so analysts can correlate occurrences without seeing the raw value.
Redact before any shared location (report, ticket, chat, screenshot), not just before publishing.
Data minimization first — collect one record that proves the finding, not the table; a smaller artifact is a smaller liability.
Beware reversible "redaction" of low-entropy values (a phone number "hashed" is brute-forceable).

Validation — What You Should Be Able to Do Now

Explain why a matching redaction count is evidence, and why a count of zero on a report you know contained secrets means your detection (not the report) is broken.
Recognize fake redactions (overlay, retained metadata, reversible low-entropy hashing) and why they leak.
State the minimization rule: collect and retain the least data that proves the finding, and redact before the artifact enters any shared location.

The Broader Perspective

This lab teaches a habit that distinguishes a trusted senior engineer: treat every artifact you produce as a potential leak surface, and make safety mechanical. The same instinct later drives your decision logging (never log a bearer token), your detection telemetry (Phase 09 redaction of PII in alerts), and your AI-agent design (Phase 11 redaction before the provider boundary). Handling other people's data carefully, by default, is not bureaucracy — it is the foundation of being trusted with access to systems that matter.

Interview Angle

"How do you preserve evidence while minimizing personal data?" — Collect the minimum that proves the finding; preserve the raw artifact read-only with a recorded hash and provenance; analyze copies; redact deterministically before the artifact enters any shared location, and report the redaction counts.

Extension (Stretch)

Add policy-selected pseudonyms (stable per-entity aliases) and emit a transformation entry for the evidence manifest, so the redaction itself is part of the chain of custody.

References

Phase 00 WARMUP Chapter 8; NIST SP 800-86 (evidence handling).
GDPR data-minimization principle; PCI DSS / HIPAA handling of sensitive data.

Security Engineer