أفضل ممارسات SAST وإدارة الإيجابيات الخاطئة

التحدي الأكبر مع SAST ليس العثور على الثغرات—بل إدارة الضوضاء. إليك كيفية جعل SAST قابلاً للتنفيذ.

مشكلة الإيجابيات الخاطئة

أدوات SAST غالباً ما تبلغ عن مشاكل ليست ثغرات حقيقية:

نوع النتيجة	الوصف	الإجراء
إيجابي حقيقي	ثغرة حقيقية	أصلحها
إيجابي خاطئ	ليس قابلاً للاستغلال فعلياً	اكتمها
سلبي حقيقي	لا توجد مشكلة، تم تجاهلها بشكل صحيح	لا شيء
سلبي خاطئ	ثغرة مفقودة	خطير!

أداة SAST صاخبة تؤدي إلى:

• إرهاق التنبيهات: المطورون يتجاهلون كل النتائج
• وقت ضائع: التحقيق في غير المشاكل
• خطوط أنابيب بطيئة: مراجعة مئات النتائج

ضبط قواعد SAST

1. ابدأ بالقواعد عالية الثقة

# Semgrep: ابدأ صارماً، توسع لاحقاً
semgrep --config p/security-audit \
        --severity ERROR \
        --exclude-rule "generic.secrets.gitleaks.*"

2. إنشاء ملفات خط الأساس

تتبع النتائج المعروفة لتجنب إعادة المراجعة:

# إنشاء خط الأساس (التشغيل الأول)
semgrep --config auto --json > .semgrep-baseline.json

# التشغيل مع خط الأساس (التشغيلات اللاحقة)
semgrep --config auto --baseline-commit HEAD~1

3. تخصيص خطورة القواعد

# .semgrep/settings.yml
rules:
  - id: hardcoded-password
    severity: ERROR  # أوقف خط الأنابيب

  - id: missing-csrf-token
    severity: WARNING  # تحذير لكن لا توقف

كتم الإيجابيات الخاطئة

الكتم المضمن (عند الضرورة)

# nosemgrep: hardcoded-password
TEST_PASSWORD = "test123"  # هذا مقصود للاختبار

# أو مع السبب
password = get_from_vault()  # nosemgrep: hardcoded-password (مأخوذ من Vault)

استثناءات مستوى الملف

# .semgrep.yml
exclude:
  - "tests/**"
  - "*.test.js"
  - "migrations/**"
  - "vendor/**"

الكتم القائم على الأنماط

# كتم أنماط محددة
rules:
  - id: sql-injection
    patterns:
      - pattern: cursor.execute($QUERY)
      - pattern-not: cursor.execute($QUERY, $PARAMS)  # محدد المعلمات = آمن

سير عمل الفرز

إنشاء عملية متسقة:

┌─────────────┐
│ نتيجة جديدة │
└──────┬──────┘
       │
       ▼
┌─────────────────┐     نعم    ┌──────────────┐
│ هل هي ثغرة      │ ─────────▶ │ إنشاء مشكلة  │
│ حقيقية؟         │            │ وإصلاحها     │
└────────┬────────┘            └──────────────┘
         │ لا
         ▼
┌─────────────────┐     نعم    ┌──────────────┐
│ هل ستتكرر       │ ─────────▶ │ تحديث القاعدة│
│ بشكل متكرر؟     │            │ أو خط الأساس │
└────────┬────────┘            └──────────────┘
         │ لا
         ▼
┌─────────────────┐
│ إضافة كتم       │
│ مضمن            │
└─────────────────┘

المقاييس للتتبع

المقياس	الهدف	لماذا
معدل الإيجابيات الخاطئة	< 20%	الثقة في الأداة
متوسط وقت الفرز	< 1 ساعة	سرعة المطور
متوسط وقت المعالجة	< 1 أسبوع	الوضع الأمني
النتائج لكل 1000 سطر	اتجاه نزولي	التحسن
معدل الكتم	< 30%	جودة القواعد

قائمة التحقق من أفضل الممارسات

تكوين الأداة

• ابدأ بمجموعات قواعد منسقة (مثل p/security-audit)
• استثنِ ملفات الاختبار والكود المولد
• حدد عتبات الخطورة المناسبة
• فعّل الفحص التزايدي لـ PRs

العملية

• عيّن أبطال أمان للفرز
• وثّق قرارات الكتم
• راجع الكتم كل ربع سنة
• تتبع الاتجاهات بمرور الوقت

تجربة المطور

• قدم إرشادات معالجة واضحة
• اربط بتدريب الأمان
• فعّل تكامل IDE للتغذية الراجعة الفورية
• احتفِ بإصلاحات الأمان

أنماط SAST المضادة الشائعة

النمط المضاد	المشكلة	الحل
فحص كل شيء	الضوضاء تطغى على الإشارة	ابدأ بالمسارات الحرجة
الحظر على كل النتائج	المطورون يعطلون الأداة	احظر فقط على الحرج/العالي
لا خط أساس	إعادة مراجعة النتائج القديمة	أنشئ وحافظ على خط الأساس
لا ملكية	النتائج تتعفن	عيّن لمالكي الكود
اضبط وانسَ	القواعد تصبح قديمة	راجع القواعد كل ربع سنة

في الوحدة التالية، سنتناول أمان التبعيات والحاويات مع أدوات SCA. :::