كيف تُجري مراجعة أمنية للكود الذي يكتبه وكيل البرمجة بالذكاء الاصطناعي

وكلاء البرمجة بالذكاء الاصطناعي سريعون، وهذه السرعة سلاح ذو حدَّين. سيُنشئون بكل سرور ميزةً عاملةً في دقائق — وبالسرور نفسه سيُركّبون استعلام SQL باستخدام تسلسل السلاسل النصية، أو يُسجّلون سرًّا في السجلّات، أو يتخطّون فحص التفويض. يعمل الكود، وتنجح الاختبارات، وتُطلَق الثغرة. المراجعة الأمنية ليست اختيارية عندما يكون الوكيل هو من يقوم بالكتابة؛ إنها الجزء الذي أنت لا تزال مسؤولًا عنه.

إليك سير عمل عملي ومستقل عن الأدوات لمراجعة الكود المُولَّد بالذكاء الاصطناعي قبل وصوله إلى بيئة الإنتاج.

اعرف ما الذي تبحث عنه

معظم الثغرات في العالم الواقعي تتجمّع في حفنة من الأنماط. عندما تُراجع (أنت أو أداة) مُخرَجات الوكيل، افحص هذه أولًا:

• الحقن (Injection) — مُدخَلات SQL أو الصدفة (shell) أو القوالب المبنية بتسلسل السلاسل النصية بدلًا من استخدام الاستعلامات ذات المعاملات.
• البرمجة عبر المواقع (XSS) — مُدخَلات المستخدم المعروضة داخل HTML دون escaping.
• مصادقة/تفويض معطوب — نقاط نهاية تفحص مَن أنت لكن ليس ما إذا كان مسموحًا لك؛ غياب فحوصات ملكية السجلّات.
• التعامل غير الآمن مع البيانات — أسرار داخل الكود، وبيانات اعتماد في السجلّات، ومعلومات حسّاسة في رسائل الخطأ.
• تبعيات معرّضة للخطر — حزمة أضافها الوكيل تحتوي على CVEs معروفة.

هذه ترتبط ارتباطًا وثيقًا بـ OWASP Top 10، وهي بالضبط الفئات التي تقول Anthropic إن مراجعتها الأمنية الآلية تبحث عنها. إبقاء هذه القائمة القصيرة في ذهنك يجعل المراجعة اليدوية أكثر فعالية بكثير.

استخدم الوكيل ليراجع نفسه — في سياق جديد

النموذج نفسه الذي كتب الكود يستطيع مراجعته، لكن ليس في النَّفَس نفسه. الوكيل الذي أمضى للتوّ 20 دورةً في جعل ميزةٍ ما تعمل يكون مهيّأً للدفاع عنها. ابدأ جلسة جديدة وأسنِد إليه مهمة واحدة: العثور على العيوب.

مُوجّه (prompt) يعمل بشكل جيّد:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

عبارة "concrete exploit scenario" هي الجزء المهم. فهي تُجبر النموذج على إثبات أن المشكلة حقيقية بدلًا من سرد عباراتٍ مبهمة من نوع "فكّر في التحقّق من المدخلات".

استعِن بالأدوات المدمجة

إذا كنت تستخدم Claude Code، فهناك أمر مخصّص /security-review يُحلّل تغييراتك بحثًا عن أنماط الثغرات الشائعة، وعند موافقتك، يطبّق الإصلاحات مباشرة. وهو متاح في خطتَي Pro وMax المدفوعتين وعلى حسابات API التي تُدفَع حسب الاستخدام.

للحصول على تغطية مستمرة، تُطلق Anthropic أيضًا GitHub Action مفتوح المصدر يعمل على كل pull request ويَنشُر تعليقات مضمّنة على الأسطر ذاتها التي تُقلقه. إدراجه في مستودع يبدو تقريبًا هكذا:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

الآن كل PR — سواء فتحه إنسان أو وكيل — يحصل على تمريرة أمنية قبل أن يضغط أحدٌ على merge. تُقدّم Cursor وCopilot ومساعدون آخرون عمليات دمج مراجعة مماثلة؛ والمبدأ نفسه بغضّ النظر عن الأداة.

لا تتخطَّ الفحوصات الحتمية

مراجعة الذكاء الاصطناعي إضافة قوية، وليست بديلًا عن الأدوات المملّة التي لا تتعب أبدًا:

• فحص التبعيات — يلتقط npm audit أو pip-audit أو Dependabot الحزم المعروفة بثغراتها التي لن يتعرّف عليها نموذج اللغة بالاسم.
• فحص الأسرار — أدوات مثل gitleaks أو حماية الدفع (push) في GitHub تمنع مفتاحًا مُسرَّبًا من الوصول أصلًا إلى السجلّ التاريخي.
• التحليل الساكن (SAST) — تفرض أدوات الـ linters وأدوات مثل Semgrep القواعد باتّساق عبر قاعدة الكود بأكملها.

استخدم الذكاء الاصطناعي للاستدلال حول المنطق والسياق — "هل يستطيع مستخدم مُصادَق قراءة سجلّات مستخدم آخر هنا؟" — واستخدم الماسحات الحتمية للأمور الآلية القابلة لمطابقة الأنماط. كلٌّ منهما يُغطّي النقاط العمياء للآخر.

مثال ملموس

لنفترض أن وكيلك يُولّد نقطة النهاية هذه:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

ينبغي أن تُشير التمريرة الأمنية إلى مشكلتَين اثنتَين: الاستعلام هو حقن SQL في انتظار الحدوث (بسبب إدراج invoice_id داخل السلسلة النصية)، ولا يوجد فحص لكون الفاتورة تخصّ فعلًا user — أي حساب مسجّل الدخول يستطيع قراءة أي فاتورة عبر تخمين المعرّفات. الإصلاح هو استعلام ذو معاملات بالإضافة إلى مُرشّح ملكية:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

الحقن هو من النوع الذي يلتقطه الماسح. أما فحص التفويض المفقود فهو من النوع الذي يحتاج إلى شخصٍ — أو مُراجِع بالذكاء الاصطناعي مزوّد بالمُوجّه الصحيح — ليفهم ما الغرض الذي يخدمه الكود. هذا هو الفصل الذي يجب أن تضعه في اعتبارك.

الخلاصة

تعامل مع كل diff يُنتجه وكيلك على أنه غير موثوق حتى تتم مراجعته — المعيار نفسه الذي تطبّقه على أول pull request لزميل جديد. اجمع بين مراجعة بالذكاء الاصطناعي في سياق جديد، وفحص آلي لـ PR، وماسحات حتمية، وستحصل على معظم سرعة التطوير المدعوم بالذكاء الاصطناعي دون أن ترث أسوأ عاداته.