۳ بهترین روش امنیتی برای همه تیم های DevSecOps

DevSecOps در دهه گذشته مورد توجه قرار گرفته است، اما تیم ها هنوز در تلاش هستند تا تشخیص دهند کدام روش های امنیتی برای موفقیت آنها بسیار مهم است. در اینجا سه ​​راه برای تغییر سمت چپ در مورد امنیت وجود دارد.

• ۳ بهترین روش امنیتی برای DevSecOps
• فراتر از ۳ مورد برتر

بیش از ۱۰ سال از زمانی که شانون لیتز اصطلاح DevSecOps را با هدف کسب امنیت معرفی کرد می گذرد. یک صندلی پشت میز با توسعه دهندگان و اپراتورهای فناوری اطلاعات. سوال اینجاست که از آن زمان تا کنون امنیت تا کجا پیش رفته است؟ آیا تیم‌های DevSecOps فرهنگ، شیوه‌ها و ابزار مورد نیاز برای عرضه سریع‌تر فناوری به تولید اما همچنین قابل اعتماد و ایمن را دارند؟

نظرسنجی SANS DevSecOps کشش قابل توجهی را نشان می دهد. سازمان‌های بیشتری به دنبال امنیت به چپ هستند تا اطمینان حاصل کنند که امنیت در شیوه‌های توسعه آنها برجسته است. بیش از ۵۰ درصد از پاسخ دهندگان ادعا کردند که خطرات و آسیب پذیری های امنیتی حیاتی را در هفت روز یا بهتر حل کرده اند. اما حتی اگر نزدیک به ۳۰ درصد از پاسخ دهندگان گفتند که به صورت هفتگی به تولید می پردازند، تنها ۲۰ درصد در حال ارزیابی یا آزمایش آسیب پذیری های امنیتی با سرعت مشابه بودند. علاوه بر این، نرخ پذیرش برای شیوه‌های DevSecOps به ۶۱ درصد برای اتوماسیون و ۵۰ درصد برای ادغام پیوسته (CI) رسید. بسیاری از سازمان‌ها هنوز به سمت امنیت بالغ و استقرار مستمر کار می‌کنند.

۳ بهترین روش امنیتی برای DevSecOps

رهبران فناوری و تیم‌های DevSecOps برای تعیین اینکه کدام شیوه‌های امنیتی اولویت‌بندی و بالغ شوند، در تلاش هستند. نظرسنجی SANS بیش از ۲۵ روش و تکنیک امنیتی را فهرست می کند که حداقل ۵۰ درصد از پاسخ دهندگان گفته اند مفید بوده اند. این نظرسنجی همچنین هشت روش مبتنی بر کد را شناسایی می‌کند، اما کمتر از ۳۰ درصد از پاسخ‌دهندگان گفتند که آنها را در حداقل ۷۵ درصد از پایگاه کد خود اعمال کرده‌اند.

در حالی که بسیاری از اقدامات DevSecOps نیاز به بررسی دارند، کارشناسان امنیتی پیامی ثابت در مورد اصول DevSecOps به اشتراک می گذارند. فرانک شوگار، مدیر عامل Aerstone، می‌گوید: «به یاد داشته باشید که امنیت را در آن ایجاد کنید، سعی نکنید آن را محکم کنید. و اینکه «اگر یک فرآیند الزامات خوب انجام می‌دهید، باید الزامات امنیتی را در نظر بگیرید، نه فقط موارد کاربردی را».

جان مورتون، مدیر ارشد فناوری می‌افزاید: «تغییر به چپ باید برای ایمن‌سازی تلاش‌های DevOps غیر مزاحم و بدون اصطکاک باشد. Britive. “در عمل، هر تمرین‌کننده‌ای باید در سیاست‌گذاری و ابزار، نرده‌های امنیتی در مقابل موانع امنیتی را مطالبه کند.”

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

1. ایمنی را در استراتژی‌های API-first ایجاد کنید
2. اسکن خودکار کد
3. روشهای مشاهده پذیری داده را استاندارد کنید

۱. ایجاد امنیت در استراتژی‌های API-first

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

ایوان نوویکوف، مدیر عامل در Wallarm.

گزارش Wallarm’s API ThreatStats Q3’2023 نشان می‌دهد ۲۳۹ آسیب پذیری API در سه ماهه سوم شناسایی شد که ۳۳ درصد آن به مجوز، احراز هویت و کنترل دسترسی مرتبط است. نوویکوف می‌گوید: «این روند بر ارتباط روزافزون امنیت API در توسعه‌دهندگان تاکید می‌کند، و آن را به یک جنبه حیاتی تبدیل می‌کند تا از فرآیندهای توسعه نرم‌افزار قوی و ایمن و دستیابی به نتایج مطلوب کسب‌وکار اطمینان حاصل شود.

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

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

۲. اسکن خودکار کد

اسکن کد برای آسیب‌پذیری‌ها زمانی یک فرآیند دستی بود و به عنوان بخشی از رشته‌های برنامه‌نویسی جفتی انجام می‌شد یا به عنوان مرحله‌ای دیرهنگام در فرآیند توسعه ایجاد می‌شد. امروزه ابزارهای تجزیه و تحلیل کد استاتیک زیادی وجود دارد که به آنها ابزارهای تست امنیت برنامه استاتیک (SAST) نیز می‌گویند. تا تیم های DevSecOps در نظر بگیرند.

Carl Froggett، CIO Deep Instinct، می‌گوید که برنامه‌های امروزی چیزی فراتر از کد هستند. او می‌گوید: «از آنجایی که فایل‌ها، داده‌ها، کدها و مؤلفه‌ها در یک مخزن devops مصرف می‌شوند، باید برای محتوای مخرب در هنگام جذب و در صورت موجود بودن در مخزن اسکن شوند». «یک سرویس اسکن امنیتی باید به آسانی در دسترس باشد و قبل از انتشار برای آزمایش و عرضه به تولید یا مشتریان و در طول هر عنصری از خطوط لوله CI/CD دوباره بررسی شود. هرچه یک تهدید زودتر شناسایی شود، رفع آن آسان تر است و مخل کمتری برای خط لوله کلی ایجاد می کند.”

ابزارهای اسکن کد می توانند بسیاری از اشتباهات رایج توسعه دهندگان را پیدا کنند که خطرات امنیتی بالایی دارند. کایل توبنر، رئیس امنیت و فناوری اطلاعات در Copado. «با ایجاد اسکن مخفی در خط لوله devops خود، می‌توانید نشت گذرواژه‌ها و کلیدهای API را در کد خود شناسایی کرده و از آن جلوگیری کنید.»

از آنجایی که سازمان‌ها با استفاده از هوش مصنوعی مولد در کسب‌وکار و جاهایی که خلبان‌ها و مدل های زبان بزرگ بر توسعه نرم افزار تأثیر می گذارد. تیم‌های Devsecops همچنین باید توسعه روش‌های آزمایش مداوم خود را برای پشتیبانی از قابلیت‌های هوش مصنوعی مولد در نظر بگیرند.

در حالی که SAST به توسعه‌دهندگان کمک می‌کند تا قبل از تولید، آسیب‌پذیری‌ها را شناسایی کنند، دن گارسیا، CISO در EDB، اضافه کردن پویا را توصیه می‌کند. قابلیت تست امنیت برنامه (DAST). او می‌گوید: «DAST نوعی آزمایش در برابر محیط زمان اجرا است که تکنیک‌های خودکار را از بازیگران تهدید اجرا می‌کند و به تیم‌ها اجازه می‌دهد تا پوشش آزمایشی خود را با گسترش پلت فرم مقیاس‌بندی کنند.

اگر در توسعه نرم‌افزار، معماری بومی ابری، و خطوط لوله CI/CD سرمایه‌گذاری می‌کنید، بهانه‌ای نیست که قابلیت‌های اسکن کد را برای بررسی کد و برجسته کردن آسیب‌پذیری‌های امنیتی در نظر نگیرید.

۳. استاندارد کردن شیوه های مشاهده پذیری داده ها

من اخیراً انتشار ۱۰۰۰^مینام را جشن گرفتم sup> مقاله، پس از نزدیک به ۲۰ سال نوشتن در مورد فناوری، داده ها و بهترین شیوه های تحول دیجیتال. من شروع به وبلاگ نویسی کردم تا آنچه را که به عنوان یک مدیر ارشد فناوری نوپا یاد گرفتم به اشتراک بگذارم، و اولین پست من درباره گزارش برنامه. در آن زمان، من توسعه‌دهنده، مهندس قابلیت اطمینان سایت و عملیات‌های فناوری اطلاعات راه‌اندازی خود بودم، بنابراین زمانی که یک حادثه تولید رخ داد، من بودم که آن را برطرف می‌کردم، علت اصلی را شناسایی می‌کردم و تعیین می‌کردم که آیا و چگونه مشکلات برنامه را برطرف کنم.

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

چالش امروز در اینجا نهفته است، و جرمی برتون، مدیر عامل Observe, Inc.، می گوید: “بیشتر ابزارها برای عیب‌یابی مشکلات در برنامه‌های کاربردی توزیع‌شده مدرن استفاده می‌شود – در اصل برای تجزیه و تحلیل گزارش‌ها، نظارت بر معیارها یا تجسم ردیابی‌ها طراحی شده‌اند و هرگز برای مدیریت حجم داده‌هایی که امروزه می‌بینیم طراحی نشده‌اند.

اگر مشاهده‌پذیری برنامه، بهبود قابلیت اطمینان و افزایش عملکرد هدف باشد، تیم‌های DevSecOps ابزارها و روش‌های زیادی را برای بررسی پیدا خواهند کرد. راه‌حل‌های مشاهده‌پذیری شامل ابزارهای نظارت برنامه، پلتفرم‌های AIops و ابزارهای SRE برای مدیریت اهداف سطح خدمات است.

DevSecOps باید دامنه مشاهده پذیری را در دو حوزه گسترش دهد. یکی از آنها قابلیت مشاهده امنیتی برای پوشش کامل پشته، از جمله برنامه، یکپارچه سازی، و زیرساخت ابری است. دیوید لینتیکوم می‌گوید: «مشاهده‌پذیری امنیتی شامل جمع‌آوری داده‌ها از ابزارها و سیستم‌های امنیتی مختلف، از جمله گزارش‌های شبکه، راه‌حل‌های امنیتی نقطه پایانی، و پلت‌فرم‌های اطلاعات امنیتی و مدیریت رویداد (SIEM) و سپس استفاده از این داده‌ها برای دستیابی به بینش‌هایی درباره تهدیدات بالقوه است. /p>

DevSecOps همچنین باید شیوه‌های مشاهده‌پذیری را به قلمرو dataops و مدل یادگیری ماشین (MLops) گسترش دهد، زیرا مشکلات در این حوزه‌ها نیز می‌توانند بر قابلیت اطمینان، عملکرد و امنیت تأثیر بگذارند.

Rohit Choudhary، یکی از بنیانگذاران و مدیر عامل Acceldata. “این نه تنها قابلیت اطمینان و دقت داده های مصرف شده توسط کاربران را تضمین می کند، بلکه از یکپارچگی و اعتماد فرآیندهای پایین دستی و تصمیم گیری نیز محافظت می کند.”

MLops خط لوله تحویل است برای یادگیری ماشینی مدل‌هایی شبیه به آنچه CI/CD برای برنامه‌ها و زیرساخت به‌عنوان کد (IaC) برای معماری‌های ابری است. ایجاد قابلیت مشاهده در Mlops به ردیابی امنیت کمک می کند مسائلی مانند عوامل تهدید که خطوط لوله را راه اندازی می کنند یا داده ها را دستکاری می کنند.

فیل موریس، مدیر عامل NetSPI، گسترش devops به شیوه‌های Mlops را پیشنهاد می‌کند و می‌گوید: «در محیط در حال تغییر امروزی ، کار، فرآیندها و کنترل‌های تغییر که به طور سنتی عبارت devops را ساخته‌اند، اهداف و پارادایم‌های MLO را در نظر نمی‌گیرند.

با روش‌ها، ابزارها و ریسک‌هایی که بهبود قابلیت مشاهده می‌تواند برطرف شود، نکته کلیدی برای تیم‌های DevSecOps جایی است که استانداردها را ایجاد کنند. اگر هر برنامه کاربردی، خط لوله داده و مدل ML از قراردادها، شیوه‌ها و ابزارهای نام‌گذاری مشاهده‌پذیری متفاوتی استفاده کند، SREها و مراکز عملیات امنیتی (SOC) می‌توانند به سرعت مسائل امنیتی را شناسایی و حل کنند، پیچیده می‌شود.

فراتر از ۳ تای برتر

من سه روش امنیتی را برجسته کردم که احتمالاً روی بسیاری از تیم‌های DevSecOps تأثیر می‌گذارد و سرمایه‌گذاری مستمر و استانداردها می‌توانند بسیاری از خطرات امنیتی را برطرف کنند.

گزارش SANs بسیاری دیگر از اقدامات امنیتی برنامه‌ها را که باید در سازمان‌های فناوری اطلاعات رایج باشد، برجسته می‌کند، مانند تست نفوذ شخص ثالث، آموزش امنیتی، و پیاده‌سازی فایروال برنامه وب (WAF). وقتی DevSecOps روی معماری‌های مدرن پیاده‌سازی می‌شود، سایر روش‌ها، مانند اسکن امنیتی کانتینر و پلت‌فرم‌های محافظت از برنامه‌های بومی ابری، مرتبط هستند.

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