۰۱ / مرزهای اعتماد
از اینجا شروع کنید که سیستم مجاز است به چه چیزی اعتماد کند.
کاربر، مدیر، سرویس داخلی و یکپارچه‌سازی خارجی سطح اعتماد یکسانی ندارند. این تفاوت باید در معماری با Authentication، Authorization، Validation و تفکیک مسئولیت دیده شود.
وقتی مرز اعتماد مبهم بماند، تصمیم‌های امنیتی در صفحه‌ها و Endpointهای مختلف پخش می‌شوند. در نتیجه فهم سیستم دشوارتر و احتمال پیکربندی اشتباه در زمان تکامل بیشتر می‌شود.
۰۲ / مرزهای داده
امن‌ترین داده غیرضروری، داده‌ای است که سیستم هرگز جمع نکرده است.
کمینه‌سازی داده یک ابزار معماری است. اگر گردش‌کار به یک اطلاعات حساس نیاز ندارد، جمع نکردن آن هم‌زمان ریسک ذخیره، دسترسی، نگهداری و افشا را حذف می‌کند.
برای داده‌ای که واقعاً لازم است، مالکیت و دیدپذیری باید صریح باشد: چه کسی می‌سازد، چه کسی می‌بیند، چه کسی تغییر می‌دهد و تا چه زمانی باید باقی بماند.
۰۳ / شکست بخشی از طراحی است
سیستم امن برای خطا، قطعی و فرضیات شکسته برنامه دارد.
یکپارچه‌سازی از کار می‌افتد. Credential منقضی می‌شود. انسان اشتباه می‌کند. زیرساخت در دسترس نیست. طراحی امنیت‌محور به‌جای فرض اینکه همه وابستگی‌ها همیشه درست کار می‌کنند، حالت خطای کنترل‌شده، لاگ مفید و مسیر بازیابی دارد.
این به معنی ساخت پیچیده‌ترین Stack امنیتی ممکن نیست. کنترل‌ها باید متناسب با ارزش سیستم، حساسیت داده و پیامد شکست باشند.
۰۴ / امنیت بدون نمایش
یک نشان یا Badge، شاهد امن بودن سیستم نیست.
کلماتی مثل رمزنگاری‌شده، امن یا Enterprise-grade را می‌توان به‌راحتی روی سایت نوشت اما بدون زمینه ارزیابی آن‌ها سخت است. ارتباط مسئولانه امنیتی باید کنترل‌های پیاده‌شده را از فرضیات، کار برنامه‌ریزی‌شده و ارزیابی مستقل جدا کند.
همین انضباط داخل پروژه هم مفید است. تیم باید بداند کدام ریسک‌ها در حال مدیریت‌اند، کدام پذیرفته شده‌اند و کدام هنوز نیازمند اعتبارسنجی‌اند. مرزهای روشن از ادبیات مطلق ارزشمندترند.