SSDLC چیست و چگونه میتونیم داشته باشیم ؟

چرخه عمر توسعه نرم‌افزار (SDLC) مخفف Software Development Life Cycle است. به زبان ساده، SDLC چارچوبی است که نحوه توسعه مطمئن یک نرم‌افزار باکیفیت را مشخص می‌کند. تیم‌های توسعه از این چارچوب برای حفظ تعادل میان هزینه‌ها، کارایی و ریسک‌ها استفاده می‌کنند. حرف S در SSDLC به معنای امنیت (Security) است. این مفهوم یک چارچوب بازبینی‌شده را معرفی می‌کند که ملاحظات و فعالیت‌های امنیتی را در تمام مراحل چرخه توسعه نرم‌افزار وارد می‌کند.

در این مطلب، توضیح خواهیم داد که چگونه انتقال از SDLC به SSDLC چرخه عمر توسعه نرم‌افزار را تغییر می‌دهد. همچنین مشخص می‌کنیم که چه فعالیت‌های امنیتی باید اضافه شوند و از دیدگاه هزینه‌ها و ساعات توسعه چه معنایی دارد.

پیش‌زمینه‌ای برای روندهای امنیتی

کسب‌وکارها با اندازه‌ها و حوزه‌های مختلف، موضوع امنیت را به شیوه‌های متفاوتی مدیریت می‌کنند. شرکت‌های بزرگ مانند گوگل و مایکروسافت از جمله پیشگامان در ارتقای مسائل و استانداردهای امنیتی هستند. این شرکت‌ها تیم‌های امنیتی کاملاً اختصاصی دارند.

به خاطر دارید زمانی که آدرس‌های وب‌سایت‌ها دیگر با "http…" شروع نمی‌شدند؟ اکنون وب‌سایت‌ها با"https…" شروع می‌شوند. اگر بدون s وارد HTTP شوید، مرورگر ممکن است حتی به شما هشدار دهد که امنیت شما در خطر است. به طور کلی، تا سال ۲۰۱۹، HTTPS به استانداردی برای تمام مرورگرهای معتبر مانند گوگل و موزیلا تبدیل شد.

رویکرد دیگر متعلق به کارآفرینان دیجیتال فردی، کسب‌وکارهای متوسط و حتی برخی سازمان‌های بزرگ است. برای آن‌ها، امنیت تنها یک هزینه‌ی ضروری بود.

• برخی از این سازمان‌ها امنیت را به پیمانکاران ثالث سپردند.
• برخی دیگر چند متخصص امنیتی استخدام کردند.
• به طور کلی، امنیت جایی بود که می‌شد هزینه‌ها را کاهش داد.
• در نهایت، اهداف کسب‌وکار همواره بر عرضه سریع‌تر محصولات کاربردی متمرکز بود. بنابراین، امنیت به ندرت موضوعی محبوب بود.

اما S-SDLC اوضاع را تغییر داد. اکنون کسب‌وکارها به امنیت نیاز دارند. چرا؟

جهان دیجیتال به سرعت در حال رشد بوده و سرعت عرضه اپلیکیشن‌های جدید به شدت افزایش یافته است. این رشد سریع بدون هزینه نبوده است. بسیاری از کسب‌وکارها به روش‌های "تحویل به‌موقع" (Just-in-Time) روی آوردند و معقول بود که مسائل امنیتی را تا زمان مناسب به تعویق بیندازند.

نگرانی‌های امنیتی پس از عجله ناشی از دوران کووید برای دیجیتالی شدن به موضوعی داغ تبدیل شد. مشتریان، دولت‌ها و صاحبان کسب‌وکار نگاه خود به امنیت را تغییر دادند.

آیا این موضوع در آمارها منعکس می‌شود؟ بله، قطعاً!
کمی آمار (بر اساس داده‌های سال 2021):

• 88٪ از کاربران به امنیت اپلیکیشن شما اهمیت می‌دهند. تا جایی که اگر اپلیکیشن امن نباشد، از خدمات شما استفاده نمی‌کنند.
• 38٪ از کاربران هرگز باز نمی‌گردند. این موضوع پس از اخبار مربوط به نقض داده‌ها یا سوءاستفاده از اطلاعات کاربران رخ می‌دهد.

مطالعه‌ای کمی قدیمی‌تر (سال 2020) نشان داد که صاحبان کسب‌وکار ارزش امنیت برای کاربران خود را به‌شدت دست‌کم می‌گیرند.

• 85٪ از کاربران مورد بررسی گفتند که یک شکاف در بازار وجود دارد: شرکت‌های امن کافی وجود ندارند.
• 83٪ از کاربران خواستار کنترل بر داده‌های خود بودند.

حال تصور کنید کسب‌وکارها از رقابت شدید و بازار اشباع‌شده شکایت می‌کنند. در حالی که کاربران می‌گویند تقریباً گزینه‌ای برای انتخاب وجود ندارد. کاربران بازار را به چشم نیمه‌خالی می‌بینند، حتی اگر اغراق‌آمیز نباشد. به همین دلیل اکنون بهترین زمان برای ادغام امنیت و تبدیل آن به یک مزیت رقابتی قابل بازاریابی است.

فعالیت‌های امنیتی (S-security) که اکنون بخشی از چرخه عمر توسعه نرم‌افزار (SDLC) هستند:

چرخه سنتی SDLC شامل این ۵ مرحله است:

1. برنامه‌ریزی: جمع‌آوری نیازمندی‌ها؛

2. طراحی: معماری و نمونه‌سازی اولیه؛

3. توسعه: کدنویسی؛

4. تست؛

5. راه‌اندازی و نگهداری.

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

شما می‌توانید مراحل چرخه عمر استارتاپ‌ها را بررسی کنید تا ببینید این مفهوم چگونه در آژانس‌های توسعه مدرن استارتاپ به کار گرفته می‌شود. همچنین، برای تکمیل این دانش، می‌توانید از نکات دایره استارتاپ ناب (Lean Startup Circle Tips) استفاده کنید.

برنامه‌ریزی: جمع‌آوری نیازمندی‌ها
این مرحله، اساسی‌ترین بخش چرخه عمر توسعه نرم‌افزار است. شامل تحقیق در بازار، مطالعه مشتریان و ارزیابی فرصت‌ها و ریسک‌ها می‌شود. سپس مطالعه امکان‌سنجی پروژه از این اطلاعات استفاده می‌کند تا پیش‌بینی‌های بلندمدت و کوتاه‌مدت برای پروژه را ارزیابی کند.

معمولاً نتیجه این مرحله یک سند نیازمندی‌های فنی است. اعضای ارشد تیم آن را تأیید کرده و مشخصات نیازمندی‌های نرم‌افزار (SRS) را توسعه می‌دهند.

فعالیت‌های امنیتی در چرخه عمر توسعه امن نرم‌افزار (SDLC امن) پیشنهاد می‌کنند که حداقل یکی از موارد زیر اضافه شود:

تحلیل آسیب‌پذیری‌ها

این تحلیل شامل پرسش‌هایی مانند این است:

• آیا مکانیزم احراز هویت شما به اندازه کافی قوی است؟
• آیا ممکن است منجر به دسترسی یا کنترل غیرمجاز شود؟

برای مثال، در اپلیکیشن‌های IoT مانند خانه‌های هوشمند، اگر کسی هک کند و دستگاه‌های کاربر را کنترل کند، چه می‌شود؟

تحلیل آسیب‌پذیری شامل موارد زیر است:

• شناسایی تهدیدها،
• تحلیل ریسک،
• ابزارهای تست، و
• تکرار این فعالیت‌ها در صورت به‌روزرسانی یا انتشار ویژگی‌های مهم.

تست نفوذ(Pentesting)

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

برای مثال، در یک اپلیکیشن تجارت الکترونیک، تهدیدهای رایج شامل موارد زیر هستند:

• تزریق SQL،
• حملات اسکریپت‌نویسی بین سایتی (XSS)،
• یا سوءاستفاده از نقاط بارگذاری فایل.

مدل‌سازی تهدیدها (Threat Modeling)

این شامل مدل‌سازی منابع و دارایی‌های برنامه است. سپس تیم، تمام تهدیدهای ممکن برای این منابع را فهرست می‌کند. مرحله بعدی، ارائه استراتژی‌های کاهش تهدید است.

برای مثال، در برنامه‌های SaaS، کاربران مخرب ممکن است داده‌ها را رهگیری کنند. برای کاهش این مشکل، باید پروتکل‌های HTTPS را برای رمزگذاری داده‌های در حال انتقال پیاده‌سازی کنیم.

تحلیل کد (Code Analysis)

این تحلیل می‌تواند به صورت دستی یا با استفاده از ابزارها انجام شود.

دو نوع تحلیل کد وجود دارد:

• تحلیل کد استاتیک (Static)
• تحلیل کد دینامیک (Dynamic)

تحلیل کد استاتیک زمانی است که توسعه‌دهندگان کد را با پایگاه داده آسیب‌پذیری‌های امنیتی (CVE) بررسی می‌کنند. برای مثال، SonarQube ابزاری رایگان است که بررسی‌های استاتیک انجام می‌دهد. اما هنوز هم نیاز به شخصی دارید که:

• تحلیل کد را تنظیم کند،
• آن را اجرا کند،
• نتایج را تفسیر کند، و
• توصیه‌هایی ارائه دهد.

تست جعبه سفید/خاکستری/سیاه

• تست جعبه سفید: آزمایش‌کننده با سیستم داخلی و نحوه کارکرد آن آشنا است.
• تست جعبه خاکستری: آزمایش‌کننده با بخش‌هایی از کد برنامه آشنا است.
• تست جعبه سیاه: آزمایش‌کننده هیچ اطلاعی از کد ندارد.

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

طراحی: معماری و نمونه‌سازی اولیه
به طور ایده‌آل، پس از مرحله برنامه‌ریزی، چند معماری یا طراحی مختلف برای پیاده‌سازی ممکن است. تمام ذی‌نفعان اصلی این موارد را ارزیابی می‌کنند. این ارزیابی شامل معیارهای مختلفی است، اما اکنون امنیت نیز بخشی از این معیارهاست.

برای پروژه‌های کوچک‌تر و کمتر پیچیده، به جای ارزیابی معماری‌ها، بیشتر درباره مجموعه ویژگی‌ها صحبت می‌کنیم. هر ویژگی امتیازدهی می‌شود:

• پیچیدگی توسعه (زمان و هزینه)،
• تأثیر بر سودآوری، و
• امنیت.

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

• تاریخچه خرید،
• آدرس تحویل،
• آیتم‌های مشاهده شده،
• آیتم‌های مورد علاقه و غیره داشته باشند.

با این حال، احراز هویت امن کاربران زمان پروژه را افزایش می‌دهد.

از طرف دیگر، اگر این ویژگی را به کلی حذف کنیم چه می‌شود؟ اجازه دهیم کاربران فروشگاه را مرور کنند، آیتم‌ها را به سبد خرید اضافه کنند و به‌عنوان مهمان تسویه‌حساب کنند. روش‌شناسی استارتاپ ناب که بر MVP یا MMP تمرکز دارد، به احتمال زیاد از این تصمیم طراحی حمایت می‌کند.

بعداً، هنگام توسعه یک اپلیکیشن کامل، ویژگی احراز هویت امن کاربران می‌تواند به اولویت تبدیل شود.

توسعه: کدنویسی
پس از اتمام برنامه‌ریزی، طراحی و نمونه‌سازی اولیه، توسعه‌دهندگان برنامه موردنظر را کدنویسی می‌کنند. مشخص است که همیشه راه‌های میانبر وجود دارد. یا به عبارتی، استفاده از کتابخانه‌های اختصاصی شامل ماژول‌های کد قابل استفاده مجدد. این میانبرها به توسعه‌دهندگان امکان می‌دهد زمان توسعه را کاهش دهند و نرخ‌های جذاب‌تری به مشتریان ارائه دهند.

با این حال، S-SDLC از این رویکرد حمایت نمی‌کند.

• تمام زبان‌های مدرن به‌گونه‌ای تکامل یافته‌اند که امنیت کد بالاتری را شامل شوند.
• شیوه‌های کدنویسی امن با کدنویسی معمولی متفاوت است.
• کتابخانه‌های قدیمی دیگر قابل قبول نیستند.
• توسعه‌دهندگان باید این کتابخانه‌ها را بازبینی، به‌روزرسانی، جایگزین و گاهی از ابتدا کدنویسی کنند.

بخش بزرگی از کدنویسی امن شامل مخفی کردن متغیرها و محدود کردن دسترسی به متغیرها و توابع است. اما تمرکز اصلی بر اعتبارسنجی داده‌هاست؛ داده‌هایی که از کاربر، API یا پایگاه داده دریافت می‌شوند.

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

برای مثال، درخواست‌های HTTP Patch و PUT مشابه هستند، اما هر پروژه یکی از آنها را پیاده‌سازی می‌کند.
در گذشته، توسعه‌دهنده اهمیتی نمی‌داد اگر یک درخواست PATCH ارسال شود، وقتی در مشخصات فنی درخواست PUT تعریف شده بود. اما اکنون باید این درخواست PATCH یک پیام خطای مشخص ارسال کند. علاوه بر این، بهتر است چنین تلاش‌هایی لاگ شوند. به این ترتیب، APIهای بک‌اند و میکروسرویس‌ها امن‌تر می‌شوند.

همچنین مجموعه‌ای از شیوه‌ها برای مدیریت رفتار برنامه در پاسخ به پیکربندی‌های نادرست وجود دارد.

آزمایش
آزمایش یک فصل کاملاً جداگانه است.

• در پروژه‌های بزرگ، ممکن است تیم‌های آزمایش با برنامه‌ها، موارد، سناریوها و ابزارهای آزمایش مختص به خود وجود داشته باشند.
• علاوه بر این، هر توسعه‌دهنده مسئول آزمایش واحد خود است.
• همچنین، تیم‌ها آزمایش‌های عملکردی انجام می‌دهند.

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

در S-SDLC، آزمایش‌های امنیتی یک فعالیت جداگانه است. این آزمایش‌ها باید از دستورالعمل‌های تعریف‌شده در مراحل برنامه‌ریزی و طراحی معماری پیروی کنند.

راه‌اندازی و نگهداری
راه‌اندازی و نگهداری به اندازه مراحل قبلی مهم هستند.

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

این نوع راه‌اندازی تکراری به شما اجازه می‌دهد پذیرش بازار را مدیریت کنید و محصول نهایی را بهینه‌سازی کنید.

چرخه حیات توسعه نرم‌افزار امن از نظر هزینه‌ها و ساعات توسعه

چرخه حیات توسعه نرم‌افزار یک مفهوم است که از طریق متدولوژی‌های مختلف پیاده‌سازی می‌شود. برای مثال، دو روش بزرگ و معروف در این زمینه، آبشاری(Waterfall) و چابک (Agile) هستند.

چابک (Agile) SDLC را به‌عنوان یک مفهوم پایه می‌گیرد و سپس آن را برای برآورده‌سازی نیازهای خاص تغییر می‌دهد. در چارچوب Agile، معروف‌ترین تغییرات شامل کانبان (Kanban)، اسکرام (SCRUM)، لین (Lean)، مایکروسافت SDL و SECDEVOPS هستند.

مایکروسافت و SECDEVOPS جامع‌ترین و متمرکز بر امنیت هستند، اما این روش‌ها بیشتر برای پروژه‌های بزرگ مناسب‌اند. شرکت‌های بزرگ فناوری از این‌ها استفاده می‌کنند. اما برای دیگران، اجرای تمام قوانین به‌صورت کامل می‌تواند بی‌هدف و اتلاف منابع باشد.

پروژه‌های کوچک‌تر و کسب‌وکارهای تجاری اغلب از SCRUM، Kanban یا Lean پیروی می‌کنند. در اجرای خالص SDLC:

اسکرام (SCRUM) به‌طور صریح هیچ فعالیت امنیتی خاصی را مشخص نمی‌کند؛ اما هر فرد را تشویق می‌کند تا در این زمینه بهترین تلاش خود را بکند.

کانبان (Kanban) تیم را تشویق می‌کند که امنیت را به‌عنوان یکی از عوامل در کار خود ببینند. این روش شامل وظایف مرتبط با امنیت و SLAها می‌شود.

لین (Lean) امنیت را از دیدگاه یکپارچگی تضمین می‌کند و تمرکز آن بر جریان داده و دسترسی به داده است. همچنین معمولاً بر جلوگیری از نفوذ داده‌ها یا دسترسی غیرمجاز تمرکز دارد.

برای پیروی از چارچوب S-SDLC، نیاز به استخدام یک متخصص اضافی وجود دارد:

• در اسکرام، همان‌طور که اسکرام مستر وجود دارد، باید امنیت مستر نیز باشد.
• در کانبان و لین، یک متخصص امنیت باید به تیم ملحق شود. این به معنای تعهد کامل به پروژه نیست و به اندازه، پیچیدگی و ماهیت پروژه بستگی دارد.

جلسات بازبینی کد جایی است که این متخصص امنیت به‌ویژه اهمیت پیدا می‌کند. و البته، مرحله برنامه‌ریزی، زمانی که فعالیت‌های امنیتی برای کل پروژه انتخاب می‌شوند.

هزینه‌ها نیز متغیرند:

• از ۳۰ تا ۹۰ دلار در ساعت بسته به سطح تخصص متخصص.
• گاهی ممکن است ۱۰ ساعت کار یک مشاور امنیتی خبره معادل ۹۰۰ دلار باشد.
• گاهی ممکن است نیاز به استخدام یک متخصص امنیتی دارای گواهی‌نامه باشد.

در صورت بروز مشکلات امنیتی یا خرابی سیستم، کل تیم درگیر رفع آن خواهند شد:

• تحلیل خطاها و نشت داده‌ها و بررسی لاگ‌ها.
• همه توسعه‌دهندگان باید منابع احتمالی آسیب‌پذیری‌ها را تحلیل کنند.
• تمامی تیم‌های کدنویسی ساعات اضافی برای رفع مشکلات صرف خواهند کرد.

در نتیجه، پیشگیری اغلب ارزان‌تر از رفع مشکل است، به‌ویژه با کاربران امروزی.

S-SDLC معمولاً از طریق صرفه‌جویی در هزینه‌های رفع مشکل خود را جبران می‌کند. علاوه بر این، باید خسارت ناشی از از دست دادن کاربران پس از مشکلات امنیتی را نیز در نظر گرفت. در واقع، این همان چیزی است که بودجه امنیت را تشکیل می‌دهد: درصدی از ساعات تخمینی توسعه و احتمال از دست دادن مشتریان.

جمع‌بندی:
مطمئناً اضافه کردن امنیت به SDLC هزینه‌هایی به همراه دارد، اما در حال حاضر این هزینه‌ها ارزشمند هستند.
۱. محصولات دیجیتال امن در بسیاری از صنایع یک بازار آزاد و بدون رقابت هستند.
۲. رفع آسیب‌پذیری‌ها پس از یک رخنه امنیتی ارزان‌تر نیست. در نتیجه، اتخاذ رویکرد امنیتی از ابتدا سودمند است. کافی است هزینه‌ای که برای امنیت صرف می‌کنید را با هزینه‌ای که باید برای رفع مشکلات صرف کنید، مقایسه کنید.