CS Compendium · Part VIII — Security, Trust & Adversarial Defense
How software defends itself when the other side is trying — not against random faults, but against a deliberate adversary who reads the wire, replays the session, scripts the API, and sometimes is a legitimate user. This part is the encyclopedic ground for application security, bot and automation defense, insider threat, authorization, and platform attestation: the field's controls, their honest limits, and the one truth that organizes all of them — *server-side authorization is the root; everything else is defense in depth*.
Why this part has gravity now
Every other part of this compendium assumes a cooperative environment — the program runs, the query returns, the bytes arrive. Security is the part that drops that assumption. It earns first-class gravity in the Koder Stack the moment the Stack starts hosting *other people's systems*: multi-tenant applications where operators are known and credentialed, data is sensitive (public-health records, personal data under data-protection law), and the realistic attacker is not an anonymous botnet but a *technical insider or recently-departed contractor* who already knows the API. That threat model — the authorized adversary — is where obfuscation collapses and only real authorization, possession, and auditability remain. The chapters here document that field knowledge vendor-agnostically; the Stack's own decision on how to compose these controls lives in engineering canon (stack-RFC-036, Secure Surface), which cites this part.
The map of this part
| Doc | Content | Status |
|---|---|---|
01-defending-applications-against-automated-abuse |
Threat taxonomy (bots, insiders, stolen sessions, machine-to-machine); the root-cause truth (object-level authorization + state invariants, not obfuscation); the full control catalog (RLS, anti-replay, device binding, step-up auth, fingerprinting, attestation, honeytokens, WAF, SIEM/UEBA); the configurable-posture model; and the honest limits of every control | seeded (real content) |
02-insider-resistant-system-design |
The deeper companion to ch. 01, focused on the authorized-insider adversary: self-hosted UEBA (peer-group + unsupervised + sequence models, explainable, cold-start); autonomous response (SOAR) with human-in-the-loop for irreversible actions; tamper-evident / verifiable audit (hash-chainMerkleWORManchoring); capability-URLs & moving-target; data-centric defense (DLP, per-operator watermark, traitor-tracing); anti-instrumentation as signal; insider governance (JITSoDrecertificationbreak-glass); ATT&CK coverage & purple-team; adversarial robustness & privacy-by-design. Field grounding for stack-RFC-037 |
seeded (real content) |
03-authorization-models |
Access-control models: DACMACRBACABACReBAC, capabilities, row/object-level security, policy engines | planned |
04-authentication-and-identity |
Passwords, MFA, WebAuthnpasskeys, OAuthOIDC, token binding, PKI & national identity | planned |
05-applied-cryptography |
Symmetric/asymmetric primitives, hashing & KDFs, signatures, key management, protocol pitfalls | planned |
Reference vs decision (D6 — no duplication)
This part holds knowledge ("what the field knows about defending a surface"). The Koder Stack's decision about which controls to enable, per tenant and per surface, is engineering canon: stack-RFC-036 (Secure Surface & Tenant Security Alerting) cites this chapter for the field grounding and adds the Stack-specific policy on top. One fact, one home — the control catalog lives here; the posture decision lives there.