Secure Software Concepts
Properties before products
Secure software concepts are the vocabulary every other domain builds on. Confidentiality, integrity, and availability (CIA) are the properties; authentication, authorization, auditing/accountability, and non-repudiation are the supporting services. Risk ties them together: risk = likelihood × impact, and each risk is avoided, mitigated, transferred, or accepted. A threat is an actor or event; a vulnerability is a weakness it can exploit; exposure is the potential loss.
Saltzer and Schroeder drive most design questions: least privilege, separation of duties, defense in depth, fail-safe defaults, complete mediation, open design (no security through obscurity), economy of mechanism, least common mechanism, psychological acceptability. Add isolation, encapsulation, modularity, layering, and abstraction. Threat modeling relies on assets, trust boundaries, and attack surface. Compliance drivers (PCI DSS, HIPAA, GDPR, SOX) and maturity models (BSIMM, OpenSAMM) appear as context, not as controls.
Traps
- Fail-safe vs fail-open: a door that unlocks when power dies is fail-open; a firewall that drops all traffic on crash is fail-safe.
- Defense in depth means independent, overlapping controls - not one very strong control.
- Obscurity can supplement a control but never replace one.
- Encryption satisfies confidentiality; it does not by itself authenticate the sender or prove whole-message integrity.
Rule of thumb
Ask 'what state does the system land in when this control fails?' The answer identifies fail-safe vs fail-open and whether the stated security property actually holds.