Doogree
DevSec · التحول لليسار

التقاط السرّ قبل الـ commit: فحص شيفرة لا يغادر الجهاز أبدًا

02/07/2026 · قراءة ~7 دقائق
فحص الشيفرةالأسرارمحلي أولًاCIوكيل الذكاء الاصطناعي

أشيع تسريب في شركة صغيرة ليس هجومًا متطورًا — بل كلمة مرور أو مفتاح API نُسِيا في الشيفرة، دُفِعا إلى git، ومن هناك إلى العالم كله. أردنا التقاطه لحظة كتابته، لا بعد أسبوعين من الاختراق. لكن كان هناك شرط واحد غير قابل للتفاوض.

الشرط: ألّا تغادر الشيفرة الجهاز أبدًا

ترفع أدوات فحص كثيرة شيفرتك المصدرية إلى سحابتها لتحليلها. بالنسبة لشركة — بشيفرتها وأسرارها وأحيانًا بيانات عملائها — تلك بالضبط هي المشكلة التي انطلقنا لحلّها، لا لخلقها. فكانت القاعدة الأولى: يجري الفحص 100% على جهاز المطوّر. لا تصل الشيفرة وقيم الأسرار إلى سحابتنا أبدًا؛ يُرفَع إلى لوحة المؤسسة فقط اكتشافٌ مُنقّى (معرّف القاعدة، الخطورة، الملف:السطر، بصمة مُقنّعة للسرّ — لا السرّ نفسه أبدًا).

وعدٌ يمكنك شرحه لمحاسبك: "مفاتيحك وشيفرتك المصدرية لا تغادر حاسوبك أبدًا — نفحص محليًا، في المحرر وفي git، قبل أن يصل سرٌّ أو ثغرة إلى commit أصلًا".

القرار الجوهري: محرك واحد، لا عشرة إضافات

كان بوسعنا بناء إضافة منفصلة لكل محرر — واحدة لـ VSCode، وأخرى لـ Cursor، وثالثة لـ JetBrains، وأكثر. هذا فخّ: عشر قواعد شيفرة للصيانة، ومنطق يتشظّى، وعِلل مختلفة في كل مكان. بدلًا من ذلك بنينا محركًا واحدًا — ملفًّا تنفيذيًا ساكنًا واحدًا (بلغة Rust) — يحتوي كل المنطق، وكل "سطح" غلافٌ رفيع حوله:

يُكتَب المنطق مرة واحدة. القاعدة ذاتها بالضبط التي تحمي الـ commit تحمي أيضًا الـ CI وما يحاول وكيل ذكاء اصطناعي كتابته.

ماذا يلتقط

يجمع الجوهر بين كشف الأسرار بأسلوب gitleaks (كتالوج من التعبيرات النمطية) ومقياس إنتروبيا شانون — للتمييز بين سلسلة عشوائية تبدو كمفتاح حقيقي وحاجب بريء مثل "your-api-key-here". مفاتيح AWS، ورموز GitHub، والمفاتيح الخاصة، وكلمات المرور داخل سلاسل الاتصال، والمزيد — كلها مُعلَّمة مع إصلاح بلغة واضحة ومرجع CWE. القادم: فحص عميق للثغرات (Semgrep) وفحص الاعتماديات (CVE).

لماذا هذا حرِج: السرّ المدفوع إلى git يبقى في السجلّ إلى الأبد — حتى لو حذفته في الـ commit التالي. السبيل الوحيد لإبقائه نظيفًا هو التقاطه قبل دخوله. هناك تكمن كل القيمة.

الزاوية التي لا يتحدث عنها أحد: وكلاء الذكاء الاصطناعي الذين يكتبون شيفرة

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

كيف اختبرناه

شغّلنا الأداة على قاعدة شيفرتنا الخاصة. أمران هامّان: أن يلتقط أسرارًا حقيقية (اختبرنا بعيّنات مُصطنعة — AWS، Stripe، سلاسل اتصال — وأُمسِكت كلها)، وألّا يُحدِث ضوضاء على شيفرة صالحة (رُفِضت الحواجب بشكل صحيح). النتيجة على شيفرتنا الخاصة: 100/100 — صفر أسرار مضمَّنة، لأنها كلها تعيش في المكان الصحيح (مدير أسرار)، تمامًا كما نوصي عملاءنا.

كيف نواصل تحسينه — مراقبة جودة مستمرة

تشغّل الأداة نفسها على كل تغيير شيفرة نُجريه (بوابة CI)، بما يشمل فحص الاعتماديات (SCA) الذي يُعلِم حين تصبح مكتبة نعتمد عليها معرَّضة للثغرات. الخطوات التالية: سطح المحرر (LSP) وسطح الوكيل (MCP) لكل عميل، ومحرك diff يُنبّه فقط على ما هو جديد (لا الضوضاء القديمة)، ورؤية ذكاء اصطناعي اختيارية تشرح كل اكتشاف. الفلسفة ذاتها: أداة واحدة، محلية، شفافة — المعرفة مكشوفة، والشيفرة تبقى لديك.

يصف هذا المقال النهج على مستوى المبدأ. لا يحتوي على تواقيع كشف حسّاسة، ولا مفاتيح، ولا تفاصيل تساعد مهاجمًا — بل على العكس، شفافية النموذج نقطة قوة.

← كل المقالات