Building Security In, Not Bolting It On

Most security books teach you how to patch holes after they're discovered. Gregory Watson's Secure by Design: App Security Essentials takes a fundamentally different approach: it argues that security should be the foundation upon which applications are built, not a coat of paint applied at the end. The result is a 25-chapter playbook that moves systematically from design principles through deployment and incident response, treating security as a continuous engineering discipline rather than a compliance checklist.

What the book is about

The book targets engineers, architects, product leaders, and security practitioners who share accountability for user data and business operations. It assumes no specialist background — each chapter blends conceptual foundations with hands-on guidance. The structure follows the software lifecycle: Chapters 1–3 establish principles and threat modeling; Chapters 4–10 cover identity, authorization, sessions, secrets, data storage, and transport security; Chapters 11–15 serve as a field guide to the OWASP Top 10 risks; Chapters 16–21 address API security, supply chain, CI/CD, testing, logging, and cloud-native deployment; Chapters 22–24 dive into mobile-specific vectors like hardware-backed storage, certificate pinning, and reverse engineering; Chapter 25 closes with incident response, compliance mapping, and continuous improvement. Throughout, Watson emphasizes "secure defaults" and "least privilege" as decision filters, not slogans.

Threat modeling as an engineering habit, not a ceremony

Chapter 2 reframes threat modeling from a documentation exercise into a practical "engine" for security by design. Watson walks through building data flow diagrams, identifying trust boundaries, enumerating assets, and applying STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each diagram element. He supplements STRIDE with attack trees to break complex scenarios into testable mitigations. The key insight: "Threat modeling turns security from an abstract worry into concrete, trackable work." The chapter includes a worked example — a profile-picture upload feature — showing how a quick model surfaces risks like malicious file uploads, DoS via large files, and metadata privacy leaks, each with specific mitigations. Watson insists threat modeling is iterative: "Schedule regular threat modeling sessions, especially before major releases or significant architectural changes."

Authorization gets the granular treatment it deserves

Chapter 5 devotes over 100 pages to authorization, distinguishing three models — RBAC, ABAC, and ReBAC — and showing where each fits. RBAC is praised for manageability but flagged for rigidity when context matters (e.g., a manager approving expenses only up to a limit). ABAC introduces dynamic policies evaluating subject, object, action, and environment attributes, with a concrete example: "Permit 'read' access to 'Confidential' documents if the user's 'department' attribute matches the document's 'department' attribute AND the user's 'clearance_level' is 'Level 3' or higher." ReBAC models relationships like "owner_of" or "member_of" for collaborative apps (Google Docs–style sharing). The chapter ends with 13 implementation best practices, including centralized policy enforcement, explicit deny-by-default, and protection against Insecure Direct Object References (IDOR) — a recurring theme in Chapter 12.

Mobile security treated as a first-class platform, not an afterthought

Chapters 22–24 give mobile its due. Chapter 22 details iOS Keychain and Android Keystore as hardware-backed vaults for keys and small secrets, warning against UserDefaults/SharedPreferences for sensitive data. Chapter 23 covers Android's Network Security Configuration for declarative certificate pinning and iOS's programmatic URLSessionDelegate approach, noting pinning's operational challenge: "When your server's certificate or public key legitimately changes… you must update the pinned value in your mobile app." It also introduces Apple's App Attest and Google's Play Integrity API for device posture attestation. Chapter 24 tackles reverse engineering with obfuscation (R8/ProGuard), anti-tampering checksums, root/jailbreak detection, and Runtime Application Self-Protection (RASP) — acknowledging RASP's performance overhead and false-positive risk while calling it "a powerful layer of defense, particularly for high-risk mobile applications."

Supply chain and CI/CD security as inseparable from application security

Chapters 17 and 18 extend the security perimeter to the build pipeline. Chapter 17 introduces Software Bills of Materials (SBOMs) as "a nutritional label for your software" and cryptographic signing (Cosign, Notary) for container images, with Kubernetes admission controllers enforcing signature verification. Chapter 18 hardens the pipeline itself: ephemeral build agents, secrets injected from vaults at runtime (never stored in YAML), Policy-as-Code via Open Policy Agent, and SBOM generation as a build artifact. Watson connects these to the "poisoned pipeline" attack — compromising a build server to inject malware — and counters with immutable artifacts, least-privilege service accounts, and anomaly detection on build logs. The message: "The automation that delivers your software can also become a powerful weapon in an attacker's arsenal if not properly guarded."

Incident response as a design requirement, not a fire drill

Chapter 25 frames incident response using the NIST lifecycle — Preparation, Detection & Analysis, Containment, Eradication, Recovery, Post-Incident Activity — and maps each phase to the controls built in earlier chapters. Preparation means "assembling and training an incident response team" and having logging (Chapter 20) and monitoring ready. Detection relies on SIEM correlation and UEBA. Containment and eradication stress immutable infrastructure: "redeploying applications from trusted backups" rather than patching live systems. The post-incident review feeds directly into continuous improvement: updating threat models, policy-as-code, and architectural reviews. Watson also maps controls to GDPR, CCPA, HIPAA, and PCI DSS, arguing that "building security by design naturally helps meet many compliance requirements."

Who should read this

Teams building or maintaining web and mobile applications who want a single reference spanning design, code, pipeline, and operations will find this book immediately useful. It suits mid-level engineers ready to own security outcomes, architects evaluating patterns like Zero Trust or mTLS, and security practitioners needing a developer-friendly playbook. Readers looking for deep cryptographic theory, formal verification methods, or niche protocol analysis (e.g., OAuth 2.0 internals beyond OIDC/SAML) will need supplemental texts. For its intended scope — a practical, lifecycle-wide guide to "secure by design" — it delivers substantial, actionable material without hype.

Read “Secure by Design: App Security Essentials” on MixCache.com →