شما می‌توانید پیشرفته‌ترین زیرساخت‌ها و امن‌ترین خطوط لوله کدی را مستقر کنید، اما اگر لایه انسانی و فرآیندهای سازمانی ناکارآمد باشند، سیستم‌های شما همچنان آسیب‌پذیر خواهند بود. تکنولوژی تنها یکی از اضلاع مثلث کلاسیک امنیت در کنار افراد و فرآیندها است، با این حال تیم‌های مهندسی به‌طور مرتب نود و نه درصد انرژی خود را صرف مهار بحران‌ها می‌کنند و از ریشه‌های سازمانی آن غافل می‌شوند. این فصل به بررسی واقعیت‌های انسانی و چالش‌برانگیز امنیت می‌پردازد و تمرکز ما را از ابزارهای خودکار به سمت پویایی تیم‌ها، مسئولیت‌های بین‌وظیفه‌ای و جریان‌های کاری هدایت می‌کند. بدون یک رویکرد عمدی به طراحی سازمانی، امنیت به یک فکر ثانویه یا یک مانع دست‌وپاگیر تبدیل می‌شود که نتیجه آن توسعه‌دهندگان فرسوده و مقصر دانستن یکدیگر در جلسات بررسی پس از حادثه است. هنگامی که مسئولیت‌ها مبهم باشند، آسیب‌پذیری‌ها از شکاف‌ها عبور می‌کنند؛ نه به این دلیل که کسی بی‌احتیاط است، بلکه به این خاطر که هیچ‌کس مالکیت مشخصی بر ریسک ندارد. مشکل اصلی که این فصل به آن می‌پردازد، نحوه ادغام مالکیت امنیتی در تار و پود روزمره سازمان بدون ایجاد فلج بوروکراتیک یا از بین بردن سرعت مهندسی است. در قلب هر سازمان مهندسی امن، بخش افراد: ساختارها و نقش‌های تیمی (People: Team Structures and Roles) قرار دارد که نحوه توزیع مسئولیت‌ها را در سراسر شرکت دیکته می‌کند. مهندسان امنیت به عنوان توانمندساز و معماران نرده‌های حفاظتی عمل می‌کنند و پیش‌فرض‌های امنی را طراحی می‌کنند که انجام کار درست را به ساده‌ترین مسیر تبدیل می‌کند. توسعه‌دهندگان تولیدکنندگان اصلی تغییرات هستند و اگر فاقد زمینه امنیتی باشند، هر درخواست ادغام به یک بدهی بالقوه تبدیل می‌شود؛ بنابراین آن‌ها به حلقه‌های بازخورد مستمر نیاز دارند. در همین حال، تیم انطباق (Compliance) تضمین می‌کند که پیاده‌سازی‌های فنی با چارچوب‌های قانونی هماهنگ است، مشروط بر اینکه این انطباق به بررسی‌های خودکار تبدیل شود. در نهایت، مدیران محصول نقشه راه را هدایت می‌کنند و باید بدهی‌های امنیتی را در کنار تحویل قابلیت‌ها در اولویت قرار دهند؛ اگر آن‌ها پاسخگوی یافته‌های امنیتی نباشند، رفع ریسک دائماً به تعویق می‌افتد. با انتقال تمرکز از چه کسی کار را انجام می‌دهد به نحوه انجام کار، به بخش فرآیندها: شیوه‌ها و ارتباطات (Processes: Practices and Communication) می‌رسیم که در آن هدف فرهنگی با واقعیت عملیاتی تلاقی می‌کند. ارتباطات جان مایه عملیات امنیتی است؛ سازمان‌ها باید به صورت منسجم با افراد مناسب ارتباط برقرار کنند تا هشدارهای حیاتی به افراد مسئول برسند. برای جلوگیری از منفک شدن امنیت از تحویل محصول، باید مالکان محصول را در قبال یافته‌های امنیتی آن‌ها مسئول بدانید. علاوه بر این، شما نمی‌توانید امنیت را به عنوان یک مرحله در انتهای چرخه توسعه در نظر بگیرید، بلکه باید مدل‌سازی تهدید (Threat Modeling) را از فاز طراحی در فرآیندهای خود بسازید. رسیدن به یک سطح بلوغ امنیتی نیازمند ساخت نقشه‌های راه برای رسیدن به اهداف امنیتی است که تحول فرهنگی را به گام‌های کوچک و دست‌یافتنی تبدیل می‌کند. پیمایش این تحول سازمانی بده‌بستان‌های (Trade-offs) عمیقی را آشکار می‌کند. تنش اصلی میان سرعت تحویل و کنترل دقیق وجود دارد: فرآیندهای انطباق سنگین سرعت تحویل را کاهش می‌دهند، اما فرهنگ بدون محدودیت خطرات امنیتی وجودی ایجاد می‌کند. بده‌بستان بزرگ دیگر میان تخصص متمرکز امنیت و مالکیت غیرمتمرکز است: تکیه صرف به یک تیم امنیتی اختصاصی یک گلوگاه خطرناک ایجاد می‌کند، در حالی که توزیع کامل امنیت میان تیم‌های محصول اغلب به استانداردهای ناسازگار منجر می‌شود. [ ] ساختارهای فعلی تیم را ترسیم کرده و شکاف‌های موجود در نقش‌های امنیت، توسعه، انطباق و مدیریت محصول را شناسایی کنید. [ ] کانال‌های ارتباطی مستقیم ایجاد کنید که هشدارهای امنیتی را بدون ایجاد خستگی از هشدار به مهندسان مربوطه هدایت کند. [ ] اصلاح ریسک‌های امنیتی را در اولویت‌بندی بکلاگ محصول در کنار کارهای استاندارد قرار دهید. [ ] جلسات مدل‌سازی تهدید را در فاز طراحی اولیه تغییرات زیرساختی تعبیه کنید. [ ] یک نقشه راه مرحله‌ای برای انتقال سازمان به سمت شیوه‌های بالغ DevSecOps طراحی کنید.