دراپباکس با MCP و Dash شکاف امنیتی طراحی تا کد رو میبنده
هوش مصنوعیخلاصهٔ کاملتر
به گفتهٔ نویسندهها، تو خیلی از سازمانها یه روال آشنا هست: یه فیچر جدید ریویو امنیتی میشه، یه مدل تهدید (سندی که ریسکها و محافظتهای لازم رو مشخص میکنه) نوشته میشه و سر راهکارها توافق میشه؛ بعد توسعه شروع میشه. اما وقتی کار به کدریویو میرسه، اون نیازمندیهای امنیتی اولیه دیگه تو جریان کار دیده نمیشن، چون مدل تهدید معمولاً تو یه سند یا سیستم جدا از خود کد زندگی میکنه.
تو این مقاله اومده که این جدایی یه مشکل واقعیه. دراپباکس رابطهٔ بین مدلهای تهدید و PRهایی که فیچرها رو پیاده میکنن بررسی کرده و دیده فقط ۱۲٪ از PRها به ریویو طراحی و مدل تهدید اصلیشون لینک دارن. بدتر از اون، فاصلهٔ زمانی زیاده: بیشتر از نصف PRها (۵۴٪) بیشتر از یه ماه بعد از ثبت ریویو باز شدن، با میانهٔ حدود پنج هفته و دنبالهای که تا بیشتر از ۱۱ ماه کش میآد.
نویسنده میگه ابزارهای موجود این شکاف رو نمیبندن. مثلاً ابزارهای تحلیل استاتیک فقط میتونن بگن یه کنترل امنیتی سر جاش هست یا نه، ولی نمیتونن بگن که آیا طبق نیازمندیهای توافقشده تو طراحی پیاده شده یا نه؛ اونا خود کد رو میبینن، نه نیت و زمینهٔ پشتش. یادآوری به مهندسها یا باتهای تذکردهنده هم به مرور کماثر میشن.
راهحل دراپباکس ترکیب سهتا فناوریه: Dash (قابلیتهای هوش مصنوعی دراپباکس برای پیدا کردن و فهمیدن محتوای تیم)، MCP و مدلهای زبانی پایه. چون Dash از قبل محتوای دراپباکس و اپهای متصل رو ایندکس کرده، مدلهای تهدید هم کنار بقیهٔ مستندات مهندسی قابل جستوجو هستن. یه ایجنت ریویو امنیتی از سرور MCP خود Dash استفاده میکنه تا همون محتوا رو بخونه، بدون اینکه برای هر منبع یه اتصال جدا لازم باشه.
وقتی یه تغییر کد برای ریویو باز میشه، ایجنت مدلهای تهدید مرتبط رو از طریق MCP میآره و مدل زبانی نیازمندیهای مستندشده و خود کد رو کنار هم بررسی میکنه. مثلاً میفهمه که مدل تهدید روی یه اندپوینت احراز هویت میخواد و چک میکنه که کد واقعاً اون رو اعمال کرده یا نه. تفاوتش با تحلیل استاتیک همینه: مقایسهٔ پیادهسازی با تصمیمهای امنیتیای که قبلاً مستند شدن.
برای اعتبارسنجی، دراپباکس هر ۱۵۰ ریویو طراحی امنیتی یکسالونیم اخیر رو به کدهای پیادهسازش نگاشت. با جستوجوی معنایی Dash تونستن ۸۰٪ ریویوها رو به کدشون وصل کنن، در حالی که فقط ۱۲٪ صراحتاً به ریویو اشاره داشتن و ۶۹٪ از این ارتباطها فقط با جستوجوی معنایی قابل بازیابی بودن. تو تستها، آوردن مدل تهدید موقع ریویو، یافتههایی مثل کنترلهای جاافتاده و مغایرت با طراحی تأییدشده رو رو کرد که بدونش نامرئی بودن.
نویسنده تأکید میکنه که این معماری فقط مال امنیت نیست و برای هر تیمی که سند طراحی تولید میکنه و میخواد مطمئن شه تو پیادهسازی رعایت شده — مثل تیمهای حریم خصوصی، پلتفرم و انطباق — کار میکنه. اصول کارشون هم اینه: هر یافته قبل رسیدن به توسعهدهنده روی خود کد اعتبارسنجی بشه (چون false positive اعتماد رو زودتر از بین میبره)، قابل ردیابی به یه نیازمندی مشخص باشه، و بیشتر یافتهها بهجای بلاککردن، مشورتی باشن.
نکات کلیدی:
- فقط ۱۲٪ از PRها به ریویو طراحی و مدل تهدید اصلیشون لینک دارن
- بیشتر از نصف PRها بیشتر از یه ماه بعد از ریویو امنیتی باز میشن
- سیستم با MCP و Dash خودکار مدل تهدید مرتبط رو موقع کدریویو میآره
- مدل زبانی کد رو با نیازمندیهای مستند مقایسه میکنه، ولی قضاوت نهایی با آدمهاست
- همین الگو برای تیمهای حریم خصوصی، پلتفرم و انطباق هم قابل استفادهست
