تصور کنید ابزاری امنیتی را برای محیط عملیاتی عرضه کنید، در حالی که حتی یک خط کد پایتون نمی‌توانید بخوانید. با همین سطح از شفافیت، یک مشاور امنیتی که قادر به خواندن حتی یک خط کد پایتون نبود، ابزاری آماده برای محیط تولید (Production-ready) به نام triage-lens را عرضه کرد. توسعه‌دهنده این ابزار هیچ کدی ننوشت و هیچ بخشی از پیاده‌سازی را بازبینی نکرد و برای تمام مراحل مهندسی، به‌طور کامل به Claude Code تکیه کرد.
این تجربه در حالی رخ می‌دهد که عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهای هوشمندی که نه‌تنها حرف می‌زنند، بلکه می‌توانند مستقیماً روی کامپیوتر شما کار کنند، فایل بسازند و دستورات را اجرا کنند — از محیط‌های چت ساده به محیط‌های کدنویسی خودمختار نقل مکان می‌کنند. همان‌طور که پیش‌تر پوشش دادیم که چگونه Anthropic هزاران دسترسی را در اختیار دانشمندان قرار داد تا تحقیقات را تسریع کنند، این مورد نشان می‌دهد که همان قابلیت‌ها چگونه به متخصصان حوزه‌های غیرفنی اجازه می‌دهد تا نرم‌افزارهای کاربردی بسازند. برای اکثر متخصصان، مانع اصلی برای خلق ابزارها همیشه «دیوار نحو» (Syntax Wall) بود؛ یعنی نیاز به درک زبان برنامه‌نویسی برای اطمینان از اینکه ابزار واقعاً همان کاری را می‌کند که ادعا می‌کند. محرک این پروژه خاص، موضوعی روزمره بود: نویسنده اشتراک Claude Max داشت و متوجه شد توکن‌های ماهانه‌اش بدون استفاده می‌مانند؛ بنابراین کنجکاو شد ببیند ابزاری برای حوزه تخصصی خودش، یعنی مدیریت آسیب‌پذیری‌ها، در عمل چگونه شکل می‌گیرد.
مشکل: نویز در شناسایی آسیب‌پذیری‌ها
بسیاری از اسکنرهای آسیب‌پذیری، مانند Trivy، یک «دیوار» از یافته‌های با امتیاز CVSS بالا تولید می‌کنند. یک گزارش معمولی ممکن است صدها آسیب‌پذیری با امتیاز شدت ۹.۸ را لیست کند. از آنجا که استراتژی «اصلاح همه چیز در همین لحظه» یک برنامه عملیاتی نیست، تیم‌های امنیتی اغلب نمی‌توانند تا زمانی که ترتیب عملیات مشخص نشود، اقدامی انجام دهند.
برای حل این مشکل، triage-lens دو منبع داده عمومی خاص را روی امتیازات استاندارد CVSS قرار می‌دهد تا موارد معدود خطرناک را از نویز جدا کند:
- EPSS (سیستم امتیازدهی پیش‌بینی اکسپلویت): احتمال بهره‌برداری از یک آسیب‌پذیری را تخمین می‌زند.
- CISA KEV (کاتالوگ آسیب‌پذیری‌های شناخته‌شده): فهرستی از آسیب‌پذیری‌هایی که تأیید شده در دنیای واقعی مورد استفاده قرار گرفته‌اند.
این ابزار با فراخوانی این APIهای رایگان و عمومی، خروجی JSON ابزار Trivy را پردازش کرده و یافته‌ها را در چهار سطح، از P0 (بهره‌برداری شناخته شده) تا P3، مرتب می‌کند. ابزار نهایی با زبان پایتون نوشته شده، تحت لایسنس MIT منتشر شده و هزینه اجرای آن صفر است.
اعتبارسنجی بدون بازبینی کد
از آنجا که نویسنده نمی‌توانست بازبینی کد (Code Review) سنتی را انجام دهد، سه حفاظ (Guardrails) رفتاری را پیاده کرد تا اطمینان حاصل کند ابزار ایمن و دقیق است. نگرانی اصلی این بود که در حالی که خروجی نهایی یک ابزار را می‌توان قضاوت کرد، اما سلامت پیاده‌سازی در میانه مسیر برای یک غیربرنامه‌نویس نامرئی است. این چالش‌ها به‌ویژه زمانی اهمیت می‌یابند که عامل‌های هوش مصنوعی دسترسی مستقیم به سیستم‌فایل داشته باشند و نیاز به نظارت دقیق بر رفتارهای آن‌ها باشد.
حفاظ اول: محدودیت‌های سخت
او ابتدا یک فایل قوانین به نام CLAUDE.md در مخزن ایجاد کرد تا به عنوان مجموعه‌ای از محدودیت‌های سخت عمل کند. این قوانین شامل موارد زیر بود:
- ممنوعیت Push مستقیم به شاخه main.
- عدم پیاده‌سازی کد بدون تست‌های همراه.
- عدم پیاده‌سازی ویژگی‌های خارج از نیازمندی‌های فاز جاری.
- نیازمندی‌ها باید در یک فایل مجزا قرار داشته باشند.
- Claude Code باید پیش از نوشتن هر خط کد، یک برنامه ارائه دهد و تأییدیه دریافت کند.
- گزارش‌ها باید به زبان ساده برای غیرمهندسان باشد و شامل دستورات تأییدی باشد که بتوان آن‌ها را کپی و پیست کرد.
در این راستا، نحوه تعریف این دستورالعمل‌ها حیاتی است، چرا که دقت در انتخاب واژگان در تنظیمات Claude Code می‌تواند تفاوت چشم‌گیری در کیفیت خروجی مدل ایجاد کند.
حفاظ دوم: بررسی‌های پذیرش رفتاری
در مرحله دوم، نویسنده به جای منطق کد، روی «بررسی‌های پذیرش» بر اساس رفتار متمرکز شد. او هوش مصنوعی را مجبور کرد سه سناریوی خاص را اجرا کرده و خروجی کامل را نمایش دهد:
- نمونه عادی: اطمینان از اینکه یک ورودی استاندارد، یک گزارش معتبر تولید می‌کند.
- JSON معیوب: اطمینان از اینکه ابزار در مواجهه با ورودی غلط، با یک خطای واضح و خوانا متوقف می‌شود.
- قطعی شبکه: اطمینان از اینکه در صورت قطع شبکه، ابزار دچار حلقه تکرار یا هنگ نمی‌شود، بلکه صراحتاً اعلام می‌کند که داده‌ها قابل دریافت نبودند و با داده‌های موجود ادامه می‌دهد.
حفاظ سوم: داده‌های مرجع خارجی
در نهایت، نویسنده از «داده مرجع خارجی» (External Ground Truth) برای تأیید ادعاهای ابزار استفاده کرد. وقتی ابزار یک CVE را به عنوان عضو کاتالوگ CISA KEV علامت‌گذاری می‌کرد، نویسنده به‌طور دستی کاتالوگ واقعی CISA را دانلود می‌کرد (با دور زدن کامل ابزار) تا تطابق را بررسی کند. در یک تست، هر سه مورد P0 — شامل Log4Shell, Heartbleed و Spring4Shell — کاملاً با کاتالوگ رسمی مطابقت داشتند، در حالی که تمام ۹ مورد رتبه‌بندی شده در سطح P1 یا پایین‌تر، به‌درستی در کاتالوگ نبودند.
بازبینی خصمانه توسط هوش مصنوعی
با وجود ۱۱۱ تست موفق و چراغ سبز CI در سه نسخه مختلف پایتون، نویسنده همچنان تردید داشت. او تشخیص داد که چون یک AI واحد هم کد و هم تست‌ها را نوشته است، ممکن است هر دو دچار نقاط کور مشترکی باشند. تست‌های سبز و پیاده‌سازی درست، دو ادعای متفاوت هستند.
برای شکستن این حلقه بازخورد، او کل Diff مربوط به Pull Request را صادر کرد و آن را به یک AI دوم و مجزا (codex CLI) داد و تنها یک دستور نوشت: «این را به‌صورت خصمانه بازبینی کن و مشکلات را به ترتیب شدت لیست کن». این AI دوم، ۹ نقص را شناسایی کرد. نویسنده طبق اصل بی‌اعتمادی، حرف بازبین را نپذیرفت؛ بلکه از Claude Code خواست هر یک از یافته‌ها را بازتولید کند تا واقعیت آن‌ها تأیید شود. این رویکرد برای مقابله با جایگزینی تحلیل سیستماتیک با حدس‌های احتمالی در کدنویسی ضروری است تا از خطاهای پنهان جلوگیری شود.
شش مورد از یافته‌ها بازتولید شدند و نیاز به اصلاح داشتند. سه مورد باقی‌مانده در تئوری محتمل بودند اما چون خارج از محدوده فاز جاری بودند، به تعویق افتادند. برای یافته‌هایی که نویسنده شخصاً نمی‌توانست ارزیابی کند، از AI خواست موضوع را تا حدی خرد کند که نویسنده بتواند آن را با کلمات خودش توضیح دهد و سپس اجازه اصلاح را صادر کند.
نقص‌های بحرانی و قضاوت‌های امنیتی
از میان شش اصلاحیه، یکی از همه جدی‌تر بود. زمانی که ابزار در دریافت امتیاز EPSS شکست می‌خورد، ستون توضیحات گزارش می‌نوشت: «احتمال بهره‌برداری پایین است». در حالی که عبارت درست باید «نامشخص» می‌بود. این یک خطای خطرناک بود زیرا موارد ریسکی را امن جلوه می‌داد؛ یعنی تنها نوع دروغی که یک ابزار اولویت‌بندی (Triage) هرگز نباید بگوید.
باگ قابل توجه دیگر مربوط به حذف موارد تکراری (Deduplication) بود. وقتی یک CVE در دو جای مختلف ظاهر می‌شد — یک بار در بسته‌های سیستم‌عامل و یک بار در وابستگی‌های برنامه — ابزار به‌طور خاموش یکی از آن‌ها را حذف می‌کرد. این به معنای از دست دادن یک فرصت برای اصلاح بود. هیچ‌کدام از این دو باگ از طریق بررسی‌های رفتاری در مسیرهای عادی (Happy-path) قابل شناسایی نبودند.
پس از این شش اصلاح، مجموعه نهایی به ۱۴۵ تست موفق رسید که شامل ۲۲ تست رگرسیون جدید بود. سپس نویسنده کد را ادغام (Merge) کرد.
نتیجه: تغییر نقش به مدیریت محصول
این فرآیند نشان می‌دهد که برای غیربرنامه‌نویسان، نقش «توسعه‌دهنده» در حال تبدیل شدن به نقش «مدیر محصول» و «سرپرست QA» است. نویسنده به این نتیجه رسید که هنوز به دیواری برخورد نکرده است که دلیلش ناتوانی در خواندن کد باشد. اگرچه اندازه کوچک ابزار کمک کرد، اما توانایی تأیید رفتار و بررسی قضاوت‌ها در برابر داده‌های مرجع خارجی، اطمینان کافی را فراهم کرد.
آنچه بیش از کد اهمیت داشت، هر چیزی خارج از آن بود: نوشتن قوانین در ابتدا، تقسیم نیازمندی‌ها به فازها و تعیین معیارهای پذیرش پیش از شروع — همان کارهایی که نویسنده در شغل روزمره خود به عنوان مشاور انجام می‌دهد. این ثابت می‌کند که تخصص در حوزه (Domain Expertise) — یعنی دانستن اینکه کدام منابع داده مهم هستند و شکست در دنیای واقعی چه شکلی است — پیش‌نیاز اصلی برای ساخت ابزارهای مبتنی بر هوش مصنوعی است.
اگر می‌خواهید پیاده‌سازی را بررسی کنید، مخزن در آدرس https://github.com/secleeman/triage-lens عمومی است. فاز دوم، پشتیبانی از ورودی‌های CycloneDX (SBOM) و گزارش‌دهی به زبان انگلیسی را اضافه خواهد کرد (گزارش‌های فعلی فقط به زبان ژاپنی هستند).
گام بعدی شما
- اگر متخصص حوزه‌ای هستید اما کد نمی‌زنید، سعی کنید نیازمندی‌های ابزار خود را در فایل‌های متنی مجزا و به‌صورت فازبندی شده برای AI تعریف کنید.
- برای اعتبارسنجی خروجی‌های AI، از متد «داده مرجع خارجی» استفاده کنید و هرگز به تست‌های نوشته شده توسط خودِ مدل اعتماد نکنید.
- از یک مدل زبانی متفاوت برای بازبینی خصمانه (Adversarial Review) کدهای تولید شده توسط مدل اول استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو