I read Secure by Design for my job, which is usually the best way to read a technical book. The ideas are not floating around as abstract wisdom; they immediately start colliding with real systems, real constraints, and the little architectural compromises that quietly accumulate interest.
The book’s strongest point is that security should live inside the model of the system. Types, boundaries, invariants, domain language, validation, permissions, defaults: these are not decorative details. They are where the application decides what kind of world is allowed to exist.
I liked the emphasis on domain primitives and explicit concepts. A string is cheap, but a string pretending to be an email address, a token, a money amount, or a user identifier is also an invitation for confusion. Stronger modeling makes illegal states harder to express, which is a very elegant form of security.
This matters even more now that AI can make development brutally fast. Faster code generation is useful, but speed also makes weak thinking propagate faster. If the architecture is vague, AI will happily help produce more vague architecture. Very productive. Also a little terrifying.
Good secure design feels calm. The system has boundaries. Data enters through known gates. Important decisions are visible. Concepts have names. Permissions are not scattered like confetti. You can look at the structure and understand where trust is created, reduced, or refused.
That is probably why the book is useful beyond security specialists. More developers should know this architecture vocabulary, especially in the AI-assisted era. We are getting better at producing software quickly; the responsibility is to make sure we are not producing beautifully accelerated liabilities.