الأمان والمراجعة والتقوية

عمل أمني مبني على عقد من تشغيل بنية العملات المشفَّرة التحتية — وليس مسرحية امتثال بعلامات اختيار. نراجع الأماكن التي تنزف فيها أنظمة العملات المشفَّرة فعلًا: التعامل مع المفاتيح، سلاسل التبعيات، والفجوة بين «يعمل» و«يفشل بأمان».

ما نراجعه

• كود الواجهة الخلفية للتطبيق وNode.js للعملات المشفَّرة، مع أولوية لمسارات لمس الأموال
• شجرة التبعيات وسلسلة التوريد: سكربتات التثبيت، أخطاء الكتابة المشابهة، إصدارات غير مثبَّتة، حزم مهجورة
• التعامل مع مفاتيح API والبورصة: الصلاحيات، التخزين، التدوير، ومن يستطيع قراءتها
• إدارة الأسرار: تسرّب البيئة، السجلات، متغيرات CI، تعرّض النسخ الاحتياطية
• البنية التحتية والتعرّض الشبكي: ما يستمع، وما هو عام ولا ينبغي أن يكون
• مسارات CI/CD والنشر: من وما الذي يستطيع دفع كود يحرّك المال
• التسجيل والمراقبة: هل ستُلاحظون الاختراق أصلًا

كيف تسير المراجعة

1. نموذج التهديد أولًا. جلسة واحدة لرسم ما يريده المهاجم فعلًا من نظامكم — تفريغ المحفظة الساخنة، سرقة المفاتيح، التلاعب بالأوامر — حتى يتبع عمق المراجعة المخاطر الحقيقية، وليس ترتيب الملفات.
2. المراجعة. مراجعة يدوية للكود والإعدادات من مهندسين يشحنون واجهات خلفية للعملات المشفَّرة، مدعومة بأدوات لكن دون اختزالها إلى تقرير ماسح.
3. التقرير. نتائج مرتبة حسب قابلية الاستغلال والأثر، كل منها بإصلاح ملموس — ملف، سطر، وتغيير مقترح، وليس «فكّروا في تحسين الأمان».
4. التحقق من الإصلاح. بعد أن يصلح فريقكم (أو نحن)، نعيد فحص النتائج ونؤكد الإغلاق كتابيًا.

لماذا هذا الفريق

أنشأنا وما زلنا نشغّل بنية ADAMANT الحساسة أمنيًا — محافظ، عقد، روبوتات، وتدفقات دفع عملت في بيئة عدائية لسنوات. النتائج تأتي من خبرة التشغيل، وليس من قالب AppSec عام.

ما لا نبيعه

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