امنیت نرم‌افزار از زمانی شروع می‌شود که کد نوشته می‌شود. اگر دادهٔ ورودی بدون کنترل مناسب به یک عملیات حساس برسد، ممکن است زمینهٔ یک آسیب‌پذیری ایجاد شود؛ حتی اگر برنامه تست‌های عملکردی را با موفقیت گذرانده باشد.
تست امنیت ایستای برنامه یا SAST به تیم کمک می‌کند بخشی از این ضعف‌ها را پیش از استقرار شناسایی کند. این روش، کد یا مصنوعات مرتبط با آن را بررسی می‌کند و برای تحلیل، به اجرای برنامهٔ هدف نیاز ندارد. راهنمای تحلیل ایستا در OWASP
SAST چیست؟
SAST مخفف Static Application Security Testing است. ابزارهای این حوزه، بسته به طراحی خود، کد منبع یا نسخه‌های کامپایل‌شدهٔ آن را برای یافتن الگوهای امنیتی مشکوک تحلیل می‌کنند.
خروجی معمولاً به بخشی از کد اشاره دارد که نیازمند بررسی است؛ برای مثال، نام فایل، شمارهٔ خط و توضیح قاعده‌ای که نقض شده است. این اطلاعات می‌تواند رسیدگی را برای توسعه‌دهنده آسان‌تر کند. معرفی ابزارهای SAST در OWASP
بااین‌حال، هشدار ابزار را نباید بدون بررسی، آسیب‌پذیری قطعی تلقی کرد. باید مشخص شود مسئله در بافت واقعی برنامه چه معنایی دارد.
تحلیل ایستا چگونه انجام می‌شود؟
همهٔ ابزارهای SAST روش یکسانی ندارند. بعضی بر الگوهای مشخص تمرکز می‌کنند و برخی، جریان داده را در بخش‌های مختلف برنامه دنبال می‌کنند.
در تحلیل جریان داده، سؤال این است که یک مقدار از کجا آمده، از چه مسیرهایی عبور کرده و به کدام عملیات رسیده است.
سه اصطلاح رایج در این بحث عبارت‌اند از:
- Source: نقطهٔ ورود داده؛ مانند دریافت یک پارامتر از درخواست کاربر.
- Sink: نقطهٔ مصرف حساس داده؛ مانند اجرای یک پرس‌وجو یا فرمان.
- Sanitizer یا Barrier: پردازش یا کنترلی که ابزار آن را برای محدودکردن یک مسیر ناامن مدل می‌کند.
در روش Taint Tracking، ابزار انتشار دادهٔ بالقوه نامطمئن را دنبال می‌کند؛ حتی اگر مقدار آن در مسیر تغییر کرده باشد. کیفیت این تحلیل به مدل‌سازی زبان، کتابخانه‌ها و مسیرهای داده وابسته است. مستندات تحلیل جریان داده در CodeQL
یک مثال ساده برای درک مفهوم
فرض کنید برنامه، شناسهٔ دریافتی از کاربر را با اتصال مستقیم رشته‌ها وارد یک پرس‌وجوی پایگاه داده می‌کند.
یک ابزار SAST ممکن است این مسیر را مشکوک تشخیص دهد: داده از ورودی کاربر آمده و به عملیات پایگاه داده رسیده است.
در این مرحله، توسعه‌دهنده باید بررسی کند:
- آیا ورودی واقعاً قابل کنترل توسط کاربر است؟
- آیا ساختار پرس‌وجو اجازهٔ تفسیر ناخواستهٔ ورودی را می‌دهد؟
- آیا روش امن متناسب با کتابخانه، مانند پرس‌وجوی پارامتری، استفاده شده است؟
- آیا اصلاح پیشنهادی، عملکرد برنامه را حفظ می‌کند؟
هدف مثال، نشان‌دادن مسیر بررسی است؛ تشخیص نهایی به جزئیات پیاده‌سازی وابسته خواهد بود.
تفاوت SAST با DAST چیست؟
SAST ساختار و منطق قابل تحلیل کد را بررسی می‌کند؛ DAST رفتار برنامهٔ اجراشده را ارزیابی می‌کند.
SAST می‌تواند پیش از آماده‌شدن محیط استقرار اجرا شود. در مقابل، DAST به نسخهٔ قابل اجرا و مسیرهای قابل دسترسی برنامه نیاز دارد. این دو روش مکمل یکدیگرند و دید متفاوتی از امنیت ارائه می‌کنند. توسعه و یکپارچه‌سازی امن در OWASP
برای آشنایی با روش دوم، مقالهٔ مفهوم تست DAST را بخوانید.
تفاوت SAST با SCA چیست؟
SAST و تحلیل ترکیب نرم‌افزار یا SCA را نیز باید از یکدیگر تفکیک کرد.
SAST به ضعف‌های قابل شناسایی در کد می‌پردازد؛ SCA برای بررسی کتابخانه‌ها و وابستگی‌های شخص ثالث، از جمله آسیب‌پذیری‌های شناخته‌شدهٔ آن‌ها، استفاده می‌شود.
ممکن است یک محصول هر دو قابلیت را ارائه دهد، اما داشتن اسکن کد به‌تنهایی به معنای بررسی کامل وابستگی‌ها نیست. راهنمای تحلیل ایستا و SCA در OWASP
هشدار مثبت کاذب و منفی کاذب چه معنایی دارند؟
مثبت کاذب یا False Positive زمانی است که ابزار هشدار می‌دهد، اما پس از بررسی مشخص می‌شود مسئلهٔ گزارش‌شده در آن شرایط آسیب‌پذیری واقعی نیست.
منفی کاذب یا False Negative یعنی یک ضعف وجود دارد، اما ابزار آن را شناسایی نکرده است.
این محدودیت‌ها باعث می‌شوند گزارش SAST به بررسی انسانی نیاز داشته باشد. همچنین نبود هشدار، اثبات امنیت کامل برنامه نیست. OWASP محدودیت در تشخیص برخی مسائل و دشواری تأیید قابل بهره‌برداری‌بودن یافته‌ها را از چالش‌های تحلیل ایستا می‌داند. توانمندی‌ها و محدودیت‌های SAST
SAST را کجای فرایند توسعه قرار دهیم؟
ابزارهای SAST می‌توانند در محیط توسعه یا فرایند یکپارچه‌سازی مداوم استفاده شوند. راهنمای OWASP
پیشنهاد اجرایی ما، شروع تدریجی است:
- یک مخزن مشخص انتخاب کنید. ابتدا پوشش ابزار برای زبان، فریم‌ورک و روش ساخت پروژه را بررسی کنید.
- از گزارش‌گیری شروع کنید. تیم باید نوع یافته‌ها و میزان کار لازم برای بررسی آن‌ها را بشناسد.
- یافته‌های جدید را از بدهی قبلی جدا کنید. می‌توان یک وضعیت مبنا ثبت کرد تا رسیدگی به مشکلات قدیمی، مانع مشاهدهٔ مسائل تازه نشود.
- قواعد توقف ادغام را روشن تعریف کنید. مشخص کنید چه نوع یافتهٔ معتبر و با چه اولویتی باید پیش از ادغام اصلاح شود.
- پس از اصلاح، دوباره بررسی کنید. رفع هشدار باید همراه با حفظ رفتار درست برنامه باشد.
یک یافتهٔ SAST چگونه به اقدام تبدیل می‌شود؟
برای هر یافته، پیشنهاد می‌کنیم این موارد ثبت شود:
- محل و توضیح مسئله
- مسیر داده یا شواهد ارائه‌شده
- نتیجهٔ بررسی توسعه‌دهنده
- تصمیم اصلاح یا دلیل استثنا
- مسئول رسیدگی و موعد بازبینی
- نتیجهٔ اسکن مجدد
بستن هشدار بدون ثبت دلیل، امکان یادگیری و بازبینی را کاهش می‌دهد. اگر قاعده‌ای مرتب هشدار نامرتبط تولید می‌کند، تنظیم یا مدل‌سازی آن را بررسی کنید؛ خاموش‌کردن گستردهٔ قواعد نباید پاسخ پیش‌فرض باشد.
معیار موفقیت SAST چیست؟
تعداد هشدارها به‌تنهایی معیار خوبی نیست. پیشنهاد می‌کنیم کیفیت یافته‌ها، زمان بررسی، تعداد ضعف‌های معتبر اصلاح‌شده و تکرار مسائل مشابه را دنبال کنید.
همچنین روشن باشد چه بخش‌هایی از پروژه تحلیل شده‌اند و چه بخش‌هایی خارج از پوشش بوده‌اند. گزارش سبز برای یک اسکن ناقص، همان معنای گزارش سبز برای محدودهٔ بررسی‌شده و مشخص را ندارد.
ارزش SAST در ایجاد بازخورد امنیتی قابل استفاده برای توسعه‌دهنده است. این بازخورد زمانی مؤثر می‌شود که به فرایند بررسی، اصلاح و یادگیری تیم متصل باشد.
برای طراحی Pipelineهای DevSecOps و یکپارچه‌سازی آزمون‌های امنیتی با چرخهٔ توسعه، با خدمات دواپس ایران آشنا شوید.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300