Security به عنوان یکی از جنبه های اصلی کیفیت محصولات نرم افزاری شناخته می شود. اگر امنیت را یک مشکل کیفی در نظر گرفته و نحوه تعیین کیفیت را از طریق اندازه گیری در نظر بگیریم، به این نتیجه می رسیم که در واقع ما با یک مشکل در اندازه گیری روبرو هستیم، اینکه How frequently و How Deeply اندازه گیری ها صورت می گیرد.

بر طبق مدل waterfall اندازه گیری های امنیتی در آخرین لحظات ارائه محصول صورت می گیرد، مثل اضافه کردن آخرین ادویه روی ظرف غذا قبل از ارائه اون به مشتری، به صورت معمول امنیت، کیفیت، Performance و Stability در آخرین مراحل مورد بررسی قرار گرفته و جزئی از فرآیند تولید در نظر گرفته نمی شوند، این مدل توسعه و نگهداری محصولات صحیح نبوده و کیفیت به صورت عام و Security به صورت خاص به شکل تصادفی به دست نیامده و نیازمند برنامه ریزی و در نظر گرفته شدن به عنوان First Class citizen است، هر چه زودتر در فرایند تولید بتوان اندازه گیری های کیفی را شروع نمود بهتر است. ( Shift Left )

همانند DevOps که تلاش نمود راهبری موارد مرتبط با زیرساخت را به مسئولیتی عمومی در تیم توسعه و زیرساخت تبدیل کرده و سیلوهای موجود را حذف نماید، DevSecOps و DB DevOps نیز تلاش در حذف سیلوهایی به نام تیم دیتابیس و یا تیم امنیت داشته و توقع وجود دانش و قبول مسئولیت مرتبط با دیتابیس و امنیت را در تمام تیم ها دارد.

این روش باعث حذف مدل حداکثر استفاده از منابع موجود بر اساس تخصص شده و تلاش می نماید با عمومی نمودن دانش آن را بخشی از فرآیند تولید و نگهداری محصولات بداند، در غیر اینصورت همیشه یک صف از افراد که نیازمند منابع محدود سازمان مثل DBA و یا متخصص security هستند وجود خواهد داشت .

به عنوان مثال در زمان Build کدها در ابزار Continuous Integration این موضوع مهم خواهد بود که آیا منابعی که Build Server از آنها جهت دانلود Package ها استفاده می نماید بر بستر Http هستند و یا Https ( استفاده از Http می تواند خطر حمله Man in the middle را افزایش دهد )، آیا package های دریافت شده با check sum ارائه شده توسط تولید کننده چک و صحت آنها تایید می گردد؟

مثال بالا به روشنی نشان می دهد محدود نمودن تخصص ها در سازمان باعث منتقل شدن تمام کارهای مرتبط با تخصص به منابع محدود خواهد شد و در مثال بالا شاید تنظیم کننده ابزار CI CD هیچوقت به خطر استفاده از Http پی نبرده و تیم امنیت هم از وجود چنین مشکلی مطلع نگردد، البته تا زمان بروز مشکل.

 تعریف DevSecOps

How you take security and put it into the devops process

در زمان پیاده سازی DevSecOps هدف شما باید افزایش میزان مالکیت Security توسط تیم توسعه باشد.

 

روش معمول Security Scan

 پس از توسعه محصول، کدها جهت بررسی به متخصصین امنیت تحویل داده شده و پس از بررسی نتایج به صورت یک گزارش آماده شده و در اختیار تیم توسعه قرار می گیرد تا بررسی و مشکلات مطرح شده بر طرف گردد و سپس کد مجددا جهت بررسی به متخصصین امنیت تحویل داده می شود و این فرآیند ادامه دارد. این روش زمانبر و غیر اتوماتیک بوده و در صورتی که تیم محصول به صورت اجایل فعالیت نماید می تواند باعث بروز مشکلات مختلفی گردد.

 

روش DevSecOps

رویکرد DevSecOps مشابه رویکرد موجود در DevOps تغییر وضعیت تیم امنیت از تنها تیم مسئول در زمینه security به Audit کننده تغییرات اعمال شده توسط تیم توسعه و ارائه راهکارها و ابزارها و آموزش است. توجه DevSecOps به سه بخش زیر است.

Automation

همه کارها باید سریع و خودکار صورت گیرند و این موضوع می تواند بر ابزارهای انتخابی شما تاثیر بگذارد، نتایج باید به صورت هشدارهای بر خط نه به صورت فایل PDF بلکه به صورت اطلاعات قابل استفاده و در ابزارهای مورد استفاده تیم توسعه ارائه گردد، ChatOps هایی مثل Slack، Microsoft Team، Rocket chat و ...

Education

 تیم توسعه باید در زمینه Security آموزش های لازم را دریافت کند، در ۱۵ سال گذشته مشکلات امنیتی مشخصی به صورت تکراری  در سازمان های متعددی مشاهده شده است که با آموزش های پایه امنیت و افزایش سطح دانش تیم توسعه قابل رفع هستند، SQL Injection امروزه به عنوان یکی از مشکلات امنیتی مطرح است همانطور که ۱۵ سال پیش بوده.

Empowerment of dev team

هدف اصلی DevOps توانمند سازی تیم توسعه و ذی نفعان است، فرآیندها و ابزارها باید تسهیلگر این موضوع باشند. ابزارها باید در اختیار تیم توسعه باشند، روش اضافه نمودن گام های امنیتی به build موجود در jenkins به تیم توسعه آموزش داده شده و مسئولیت این تیم است که در پروژه های مختلف اصول تعیین شده را پیاده سازی نماید، در نهایت تیم توسعه مسئولیت امنیت محصول خود را بر عهده دارد.

 

State of DevSecOps

همانطور که در سند DevOps چیست با استفاده از گزارش State of DevOps  وضعیت جاری پیاده سازی DevOps در جهان مورد بررسی قرار گرفت ( DevOps یک Practice است و برای بهبود و اثبات خود نیاز به اطلاعات میدانی از نحوه پیاده سازی DevOps دارد )، در زمینه پیاده سازی DevSecOps نیز نظرسنجی توسط شرکت Sonatype صورت گرفته که خلاصه آن به شرح زیر خدمتتان ارائه شده و فایل نظرسنجی به پیوست این سند ارائه گردیده است.

انگیزه اصلی از پیاده سازی Security در چرخه توسعه محصول چه بوده است.

چه منابع آموزشی در زمینه Application Security در اختیار تیم توسعه قرار گرفته است. 

در سازمان شما در چه مرحله ایی از توسعه محصول تحلیل های Application Security صورت می پذیرد. 

 

مستندات

نظرسنجی درباره DevSecOps در سال ۲۰۱۹