Rule 2 of 12 · Chapter I — One Secret, Clearly Named
Assume the adversary holds a complete description of your system, including source, protocol, and hardware layout.
Why this rule exists
Specifications leak through decompilation, insider departure, procurement documents, patent filings, and simple purchase of your product. Designing on the assumption that disclosure has already happened removes the worst class of surprise: a security property that evaporates the day someone reads your code. It also sharpens review, because reviewers can see what the attacker sees.
In practice
Run design reviews from the attacker's chair with full documentation on the table and ask what is still hard. Publish or internally circulate the protocol spec and let people attack it before shipping. When a defence depends on the adversary not knowing a detail, mark it as obfuscation and count it as zero in your threat model — keep it if it raises cost, but never let it carry load.
When it doesn't apply
Operational details with genuine short-term value — current infrastructure addresses, deployment schedules, live configuration — are worth withholding as friction. The rule is about what your security argument may rely on, not about volunteering every detail to the world.