هل يكفي الفحص الآلي؟

لا. تجد الأدوات الأنماط المعروفة والمكتبات المعرضة للثغرات، وهذا مفيد، لكنها نادرًا ما تفهم قواعد عملك. وغياب فحص الصلاحية يبدو شيفرة عادية في نظر الأداة. شغّل الأدوات عند كل تغيير، وأضف مراجعة بشرية للمصادقة والتحكم في الوصول والمسارات التي تتعامل مع المال أو البيانات الشخصية.

كم تستغرق مراجعة الشيفرة الآمنة؟

يعتمد ذلك على حجم قاعدة الشيفرة واللغات المستخدمة ومقدار الجزء الحساس أمنيًا فيها وكمية السياق المتاحة للمراجع. والمراجعة المركّزة على المسارات الأعلى خطورة أسرع من التدقيق الكامل. ولا يستطيع المراجع التقدير إلا بعد أن يرى المستودع ويتفق معك على النطاق.

هل يحتاج المراجع إلى كل شيفرتنا المصدرية؟

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

ما الفرق بين مراجعة الشيفرة واختبار الاختراق؟

تقرأ مراجعة الشيفرة المصدر ويمكنها تغطية كل مسار، بما فيها المسارات التي يصعب بلوغها من الخارج. أما اختبار الاختراق فيهاجم التطبيق العامل ويرى إعداداته الفعلية، لكنه لا يطرق إلا المسارات التي يصل إليها المختبِر في الوقت المتاح. وكل منهما يجد ما قد يفوت الآخر، ولذلك تستفيد الأنظمة المهمة من الاثنين.

هل تحتاج الشيفرة التي يكتبها مساعد ذكاء اصطناعي إلى مراجعة أمنية؟

نعم، كما تحتاج أي شيفرة أخرى. فقد تتضمن الشيفرة المولّدة أنماطًا غير آمنة أو مكتبات قديمة أو فحوصًا ناقصة، وتبدو واثقة في الحالتين. راجعها بالقواعد نفسها ومعها الفحص الآلي نفسه، أيًا كان من كتبها.

الأمن السيبراني

مراجعة الشيفرة الآمنة: مراجعة بشرية وأدوات آلية

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

ابدأ مشروعك

ما مراجعة الشيفرة الآمنة

تفحص مراجعة الشيفرة الآمنة الشيفرة المصدرية للتطبيق لاكتشاف العيوب الأمنية قبل أن يكتشفها المهاجمون. ولأن المراجع يرى كل سطر، فإنه يجد مشكلات قد لا يصل إليها مختبِر يعمل من الخارج: وظيفة إدارية بلا فحص صلاحية، أو نقطة نادرة الاستخدام، أو مسار تصحيح تُرك بالخطأ.

وهي تختلف عن اختبار الاختراق الذي يهاجم التطبيق وهو يعمل، فيرى الإعدادات الفعلية لكنه لا يرى إلا المسارات التي ينجح في بلوغها. وتختلف كذلك عن مراجعة الشيفرة اليومية لجودة العمل، وإن كانتا تجريان غالبًا ضمن عملية طلبات الدمج (pull requests) نفسها: الآلية واحدة، والأسئلة هنا أمنية. وراجع أيضًا مدخل المسرد.

طبقتان: أدوات آلية ومراجع بشري

لا تكفي إحدى الطبقتين وحدها.

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

شغّل الأدوات عند كل تغيير حتى لا تصل المشكلات السهلة إلى إنسان، واحفظ وقت المراجع للعيوب التي لا يراها إلا بشر.

ما الذي يبحث عنه المراجعون

هذه الفئات لا ترتبط بلغة برمجة بعينها. وهي تتقاطع مع قائمة OWASP لأخطر عشر ثغرات، وهي أساس جيد للتوعية، لكن المراجعة تذهب أبعد منها.

المصادقة والتحكم في الوصول. هل يُفحص كل مسار وكل إجراء على الخادم، للمستخدم والدور الصحيحين؟ وهل يستطيع مستخدم أن يغيّر رقم المعرّف في طلب فيقرأ سجل غيره؟ وهل تُصدر رموز الجلسات وتُخزَّن وتنتهي صلاحيتها كما ينبغي؟ وهل تُفرض المصادقة متعددة العوامل حيث وُعد بها؟
الحقن. هل تستخدم استعلامات قاعدة البيانات معاملات مستقلة عن النص، أم تُبنى من نصوص مدموجة؟ والسؤال نفسه ينطبق على أوامر نظام التشغيل والقوالب ولغات الاستعلام في البحث. راجع حقن SQL والبرمجة النصية عبر المواقع.
فك التسلسل غير الآمن. هل تعيد الشيفرة بناء كائنات من بيانات غير موثوقة بصيغ قد تنفّذ شيفرة؟ فبعض صيغ التسلسل الأصلية، مثل pickle في Python، قد تشغّل شيفرة أثناء تحميل البيانات، فلا يجوز أن تقرأ مدخلات من مصدر غير موثوق.
الأسرار في الشيفرة. مفاتيح وكلمات مرور ورموز داخل الملفات، أو في إعدادات أُودعت في المستودع، بما فيها عمليات الإيداع القديمة. أي سر أُودع يجب تدويره حتى لو حُذف لاحقًا، فالسجل يحتفظ به.
سوء استخدام التشفير. خوارزميات من تأليف الفريق، ومفاتيح مكتوبة في الشيفرة، وقيم عشوائية يمكن التنبؤ بها في الرموز، وتجزئة سريعة لكلمات المرور بدل دالة مخصصة لذلك مثل Argon2 أو scrypt أو bcrypt، وتعطيل فحص الشهادات.
معالجة الأخطاء والسجلات. تتبّع داخلي للأخطاء يُعرض على المستخدم، وفحوص تفشل بالسماح عند حدوث خطأ، وسجلات تحتوي على كلمات مرور أو رموز أو بيانات شخصية.
شيفرة الأطراف الثالثة. مكتبات معرضة للثغرات أو مهجورة، وحزم مضافة من أجل ميزة صغيرة، وسكربتات تعمل عند التثبيت، وإصدارات غير مثبّتة.

خصوصيات اللغات والأطر

الفئات واحدة عبر اللغات، لكن الفخاخ تختلف.

البيئة	أماكن النظر المعتادة
JavaScript وTypeScript (Node.js وReact)	إدراج HTML خام في الصفحات مثل dangerouslySetInnerHTML، واستخدام eval، وأوامر الصدفة المبنية من مدخلات المستخدم، وتلويث النموذج الأولي (prototype pollution) عند دمج الكائنات، وفحوص تُجرى في المتصفح فقط.
Python	تحميل بيانات غير موثوقة عبر pickle أو محمّل YAML غير آمن، واستعلامات SQL المبنية بتنسيق النصوص، واستدعاءات الصدفة التي تتضمن مدخلات المستخدم.
Java وKotlin	التسلسل الأصلي للكائنات، ومحللات XML التي تسمح بالكيانات الخارجية، واستعلامات SQL المبنية بضم النصوص، وفي أندرويد المكوّنات المكشوفة لتطبيقات أخرى.
Swift وتطبيقات الجوال	أسرار داخل حزمة التطبيق، وبيانات حساسة في تخزين محلي عادي بدل التخزين الآمن في النظام، وفحص شهادات معطَّل.
الأطر وطبقات ORM	منافذ الاستعلام الخام، وربط حقول الطلب بالنموذج مباشرة (mass assignment)، ومسارات أُضيفت بلا طبقة المصادقة.

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

كيف تُنفَّذ المراجعة وماذا تتسلم

النطاق والسياق. أي المستودعات والفروع، وماذا يفعل التطبيق، وأي البيانات والأدوار أهم. وإن وُجد نموذج تهديدات فهو يدل المراجع على مواضع تركيز وقته.
المرور الآلي. التحليل الساكن وفحص الاعتمادات وفحص الأسرار، مع فرز النتائج لإزالة الإنذارات الكاذبة.
المرور اليدوي. يتتبع المراجع المسارات الأعلى خطورة عبر الشيفرة: تسجيل الدخول والصلاحيات والمدفوعات ومعالجة الملفات وميزات الإدارة.
التقرير. تُكتب النتائج وتُرتَّب حسب الأولوية.
الجلسة الشرحية. مكالمة مع مطوّريك لشرح النتائج والاتفاق على الإصلاحات.
إعادة التحقق. يؤكد المراجع الإصلاحات، والأفضل أن يكون ذلك على طلبات الدمج نفسها التي تجريها.

ويشمل التقرير المفيد:

ملخصًا لأصحاب القرار.
كل نتيجة مع الملف والسطر، وشرحًا لسبب كونها مشكلة، ودرجة خطورة، واقتراحًا للإصلاح، غالبًا بمثال شيفرة قصير.
قائمة بالاعتمادات المعرضة للثغرات وأيها يُرقّى أولًا.
بيانًا بما روجع وما لم يُراجع.
اقتراحات لفحوص تُضاف إلى خط النشر، لتُلتقط المشكلة نفسها آليًا في المرة القادمة.

متى في دورة حياة المنتج تراجع

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

مراجعة مستمرة لطلبات الدمج أم تدقيق لمرة واحدة

النهج	نقاط القوة	نقاط الضعف	يناسب
مراجعة طلبات الدمج	تلتقط المشكلات والكاتب ما زال يذكر السياق. إصلاحها رخيص. وتبني عادات في الفريق.	يرى المراجع التغيير لا النظام كله، وتعتمد على الانضباط.	الفرق التي تنشر كثيرًا.
تدقيق لمرة واحدة	ينظر إلى قاعدة الشيفرة كلها بعين جديدة. ومفيد كدليل لأطراف أخرى.	لقطة في لحظة: فالشيفرة تتغير في اليوم التالي، وقد تتراكم النتائج.	قبل الإطلاق، والشيفرة الموروثة، والمراحل الكبرى.

تحتاج معظم الفرق إلى الاثنين: فحوص آلية وقائمة أمنية قصيرة في كل طلب دمج، إضافةً إلى تدقيق أعمق عند المحطات الكبرى. وهكذا نفكر في تطوير التطبيقات الآمنة: فحوص عند كل تغيير، ونظرة أعمق في اللحظات المهمة.

تجد مراجعة الشيفرة ما هو موجود في الشيفرة، لا طريقة نشر التطبيق. اجمعها مع اختبار الاختراق لفحص النظام العامل، بما فيه إعدادات الخادم والسحابة.

أسئلة تصلنا كثيرًا

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

تابع الاستكشاف

هل أنت مستعد لبناء منتج آمن؟

حدّثنا عن منتجك، وسنرد بخطة واضحة.