Sanitization Policy

Purpose

Everything published here is meant to teach defenders, not to help attackers or to expose the people and organisations I work with. This policy sets out the rules I apply before anything goes online: research write-ups, findings, home lab documentation and incident response case studies.

Clients and organisations are anonymised

• Names of clients, employers and affected organisations are not published. Where context matters I describe them only coarsely, for example “a mid-sized retailer”.
• Domains, hostnames, IP addresses, account IDs and locations are removed or replaced with reserved documentation values such as example.com and the 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 ranges.
• People are never named, and their roles are generalised.
• Times in case studies are relative to detection (T+0, T+2h) rather than calendar timestamps.

Sensitive data is redacted

• Credentials, keys, tokens, session identifiers and password hashes are removed or replaced with obvious placeholders.
• Personal data in logs, screenshots and packet captures is cropped or redacted before publication.
• Document and image metadata (EXIF, author, tool and path information) is stripped.
• No real data from a client environment is ever used in the lab.

No active vulnerabilities

I do not publish vulnerabilities that are still exploitable. A finding appears only after the affected party has fixed or mitigated it. If the 90-day disclosure window passes with no fix and no response, the most I will publish is a high-level description of the vulnerability class and its impact, with no target, no reproduction steps and no payload.

No exploit payloads

Write-ups explain root cause, impact and mitigation. They contain no weaponised exploit code, shellcode, payloads or ready-to-run scripts. Where a reproduction is needed so defenders can verify a fix, I describe the minimum steps in prose against a safe or synthetic target.

Pre-publication checklist

1. Names, domains, addresses and locations removed or replaced.
2. Credentials, tokens and personal data redacted; metadata stripped.
3. Timestamps made relative where an incident is described.
4. Fix or mitigation confirmed for any vulnerability.
5. No exploit code or payloads included.
6. Final read-through as an attacker would: could this help locate or compromise the subject?

If you spot a problem

If you think something here identifies you or your organisation, or could be misused, send a note through the contact form and I will review it promptly and correct or remove it.