لماذا يصعب تأمين أجهزة الكمبيوتر

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

مقدمة

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

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

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

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

يُحدد نموذج التهديد ما يحتاج إلى حماية، وما يمكن للمهاجم تغييره، وأين تُتخذ القرارات ذات الامتيازات، وما هي الافتراضات التي قد تفشل. ويساعد هذا النموذج في الكشف عن مسارات الضرر المحتملة دون ادعاء القدرة على التنبؤ بكل هجوم. [2]

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

حيث يفشل الأمن أولاً

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

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

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

تستهدف الهندسة الاجتماعية الجانب البشري من عملية اتخاذ القرار. قد تدّعي رسالةٌ ما أن المورّد قد غيّر بياناته المصرفية، أو أن حسابًا ما يجب التحقق منه بشكل عاجل، أو أن مستندًا ما ينتظر خلف صفحة تسجيل الدخول. قد يؤدي الرابط الخبيث إلى تقليدٍ مُقنع لخدمةٍ شرعية، أو قد يحاول التنزيل استغلال ثغرةٍ في تطبيقٍ ما. إن مجرد فتح عنوان ويب لا يُعادل تسليم حساب أو إصابة جهاز كمبيوتر: فالنتيجة تعتمد على الوجهة، وحماية المتصفح والجهاز، وإصدار البرنامج، وما يحدث لاحقًا. يكمن الفرق الجوهري بين وصول صفحة عبر اتصالٍ محمي وبين كون الصفحة جديرة بالثقة. يُمكن للتشفير حماية البيانات أثناء نقلها إلى الموقع الذي تم الاتصال به فعليًا؛ لكنه لا يُمكنه إثبات أن الموقع هو الموقع الذي قصده المستخدم. [3]

لا يقتصر التصيد الاحتيالي على مجرد اختبار قدرة الشخص على تمييز الرسائل المشبوهة. فقد استعرضت دراسة تشو وزملاؤه لعام 2023، والتي تناولت قضايا المعرفة، 52 دراسة تجريبية، وصنفت العوامل المرتبطة بقابلية التعرض للخداع بناءً على الخصائص الفردية، والظروف المحيطة، والملابسات التي تُستقبل فيها الرسالة. ولا تدعم هذه الدراسة تحديد نمط عام لمن سيقع ضحية الخداع. لذا، يجمع نظام الحماية بين المصادقة المناسبة، وتصميم واجهة المستخدم، وإجراءات تأكيد التعليمات اللاحقة، والتدريب، بدلاً من الاكتفاء باليقظة وحدها لتحقيق النجاح. [6]

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

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

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

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

الهوية والإذن والسلطة المفوضة

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

تنشأ مشكلة إساءة استخدام صلاحيات الوسيط (confused deputy) عندما يستخدم برنامج ما صلاحياته الأوسع نطاقًا لتنفيذ طلب لا يحق للمستخدم تقديمه. على سبيل المثال، قد يكون لدى خدمة سجلات صلاحية قراءة جميع الملفات، بينما لا يحق للمستخدم العادي سوى استرجاع ملفاته الخاصة. إذا قبلت الخدمة أي مُعرِّف سجل دون التحقق من حقوق المستخدم، فقد تُعيد معلومات تخص شخصًا آخر. لا يحصل المستخدم أبدًا على الصلاحيات الرئيسية للخدمة؛ بل تُسيء الخدمة استخدامها نيابةً عنه. لذا، فإن عزل السجلات المحمية غير كافٍ إذا كان وسيط ذو صلاحيات سيجلبها لأي شخص يطلبها. [8]

تُضيّق واجهة تفويض سليمة نطاق العمل الذي يوافق المكون ذو الصلاحيات على القيام به. فبدلاً من قبول مسار ملف غير مقيد، يمكنه قبول عملية محددة مسموح بها مرتبطة بحقوق المُستدعي، أو قدرة محدودة النطاق تُثبت سلطته على مورد معين. هذا تطبيق لمبدأ أقل الصلاحيات: إذ لا تحصل الحسابات والمكونات والخدمات إلا على الوصول والعمليات التي تتطلبها مهامها. كما يحدّ هذا المبدأ من نطاق تأثير الخطأ، أي المعلومات والإجراءات التي يمكن أن يؤثر عليها الفشل، بما في ذلك من خلال مكونات أخرى مستعدة للعمل نيابةً عنه. قد لا يكون للمكون وصول مباشر إلى الملفات الخاصة، ومع ذلك قد يكشف تلك الملفات بشكل غير مباشر من خلال خدمة ذات صلاحيات أقوى إذا لم تكن طلباته مقيدة بشكل كافٍ. [9] [10]

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

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

لا يُعدّ منح الإذن بتنفيذ عملية ما دليلاً على صحة هذه العملية في جميع مراحل العملية الأكبر. لا يجوز تنفيذ أي طلب قبل استيفاء شروط الدفع المطلوبة. كما لا يجوز استرداد قسيمة مخصصة للاستخدام لمرة واحدة بشكل متكرر لمجرد أن كل طلب مستوفٍ للشروط ويأتي من حساب مؤهل. هذه أخطاء في منطق العمل: لم يفرض التطبيق الشروط المسبقة أو التسلسل الصحيح أو الحدود التي تحكم الإجراءات ذات الصلة. يجب التحقق من هذه القواعد مقابل الحالة المرجعية عند الانتقال اللاحق، بدلاً من استنتاجها من شاشة معروضة أو خطوة يدّعيها مقدم الطلب. قد يوجد هذا الخلل دون حدوث تضارب أو أمر خبيث أو سرقة حساب. [12]

عندما لا يعود الفحص الصحيح ساري المفعول

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

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

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

عندما يُسمح للمعلومات بتوجيه العمل

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

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

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

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

سلامة الذاكرة وضمانات لغات البرمجة

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

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

يحدث خطأ ذاكرة مختلف عندما يحتفظ البرنامج بمرجع لكائن ما بعد تحرير مساحة تخزينه. إذا أُعيد استخدام نفس المنطقة لاحقًا لكائن آخر، فقد يقرأ المرجع القديم معلومات غير ذات صلة أو يكتب فوقها. يُعرف هذا بخطأ "الاستخدام بعد تحرير الذاكرة (use-after-free)". لا يكفي فحص الحدود وحده لجعل الوصول صحيحًا: فقد يقع العنوان داخل منطقة مُخصصة، لكن الكائن الذي جعل المرجع ذا معنى في الأصل لم يعد موجودًا. تعالج آليات الحماية المكانية وحماية دورة الحياة حالات فشل مختلفة.

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

تُخفف إمكانيات لغات البرمجة الآمنة للذاكرة بعض العبء، إذ تُنقل إلى قواعد تُفرضها اللغة أو بيئة تشغيلها. ترفض الشيفرة الآمنة بلغة Rust العديد من المراجع غير الصالحة قبل تشغيل البرنامج، ويتحقق من الوصول المُفهرس حسب الحاجة. بينما تُفرض إمكانيات Swift الآمنة العادية حدودًا وقيودًا على دورة حياة الكائنات المُدارة. عادةً ما يعمل كود تطبيقات Python على كائنات مُدارة بدلًا من إجراء عمليات حسابية مباشرة على المؤشرات. لا تُغني هذه اللغات عن الحاجة إلى اتخاذ قرارات أمنية سليمة، ولا تمتد حمايتها بالضرورة لتشمل جميع المكونات الأصلية. يحتوي Rust على مناطق غير آمنة بشكل صريح؛ وقد يستدعي Swift مكتبات C أو يستخدم مؤشرات غير آمنة؛ وقد يُحمّل Python امتدادات أصلية. يرث التطبيق الآمن للذاكرة الذي يُمرر البيانات إلى كود غير آمن للذاكرة الحاجة إلى فحص هذا الحد والكود الذي يليه. يُغير اختيار اللغة فئات مهمة من المخاطر، ولكن يجب تقييم المنتج بناءً على العمليات التي يُنفذها فعليًا. [17] [18] [19]

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

تُسهم اللغات الأكثر أمانًا في تقليل بعض مخاطر الذاكرة، لكن لا يمكن استبدال الأنظمة الحالية بين عشية وضحاها. فلغتا C و⁦C++⁩ مُدمجتان بعمق في أنظمة التشغيل والبرامج الثابتة والمكتبات المتخصصة، ويواجه العديد منها قيودًا تتعلق بالأداء أو الأجهزة أو التوافق. وقد تُؤدي إعادة كتابتها إلى ظهور عيوب جديدة، وتحتاج الفرق إلى المهارات والأدوات اللازمة للتحقق من صحة البدائل. وهذا لا يُبرر قبول معالجة الذاكرة غير الآمنة إلى أجل غير مسمى. يكمن التقييم العملي في تحديد مواضع وصول البيانات غير الموثوقة إلى عمليات غير مُدققة، وما هي التبعيات الأصلية المتبقية، وما هي صلاحيات هذه المكونات، وكيف تُعالج الاختبارات وإجراءات التخفيف والصيانة هذه المخاطر. ولا يُمكن لمُجرد تسمية اللغة الإجابة على هذه الأسئلة. [2]

عندما يكون التصميم نفسه عرضة للثغرات الأمنية

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

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

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

لنفترض برنامجًا يتصل بموقع ويب. قد يُنشئ البرنامج اتصالًا مُشفّرًا ويقبل شهادة من جهة إصدار موثوقة دون التحقق مما إذا كانت هذه الشهادة تُعرّف الموقع المقصود. يعمل التشفير، لكن البرنامج قد يتصل بموقع مُنتحل. يحدث خطأ مماثل مع رموز الوصول المُوقّعة، وهي بيانات اعتماد رقمية تستخدمها بعض الخدمات لتحديد قبول الطلبات. قد يتحقق البرنامج من توقيع الرمز، لكنه لا يتحقق مما إذا كان صادرًا عن جهة إصدار معتمدة، أو مُخصصًا لهذه الخدمة، أو لا يزال ساريًا. في كلتا الحالتين، يُبقي فحص صحيح قرارًا ضروريًا آخر دون حسم. لا يتطلب أي من الفشلين تشفيرًا معيبًا أو توقيعًا مُزوّرًا. يتناول كتاب روس أندرسون "لماذا تفشل أنظمة التشفير" الفجوة الأوسع بين الحماية التشفيرية وإخفاقات الأنظمة الحقيقية. [22] [23] [24]

استعرضت دراسة كلارك وفان أورشوت لعام 2013 حول بروتوكولي SSL وHTTPS كيفية تأثير إصدار الشهادات، وقرارات الثقة في المتصفحات، وممارسات البنية التحتية على أمان الاتصالات المشفرة. وقد وضعت دراستهما الهوية وثقة الشهادات ضمن النظام الأوسع بدلاً من اعتبار التشفير كافياً بحد ذاته. كما فحصت آليات تلك الفترة، وليس تطبيقات TLS الحالية أو وسائل الحماية التي أُدخلت لاحقاً؛ إذ تتطلب التطبيقات الحالية تقييماً وفقاً للمعايير الحالية. [25]

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

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

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

عندما يكون الجهاز نفسه عرضة للخطر

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

⚠️ تكشف ثغرة Rowhammer نقطة ضعف فيزيائية غير متوقعة. ففي بعض رقائق الذاكرة، قد يؤدي الوصول المتكرر إلى مواقع ذاكرة معينة إلى إحداث اضطراب كهربائي في الخلايا المجاورة حتى تتغير البتات المخزنة. ولم يطلب البرنامج هذه التغييرات. وقد أظهر الباحثون أنه في الأنظمة المعرضة لهذه الثغرة، وفي ظل ظروف معينة، يمكن استغلال هذا التأثير لتجاوز حماية الذاكرة والحصول على صلاحيات أعلى. قد يلتزم البرنامج بالقواعد المتعلقة بمواقع الكتابة المسموح بها، ومع ذلك، لا تزال الذاكرة الفعلية قادرة على تغيير المعلومات خارج هذه الحدود. لا تؤثر ثغرة Rowhammer على جميع تصميمات الذاكرة بالتساوي، وتعتمد إمكانية استغلالها عمليًا وسبل التخفيف من آثارها على الأجهزة والنظام. [28] [29]

⚠️ قد تكشف نقاط ضعف أخرى في الأجهزة عن معلومات دون تغييرها. أحيانًا، تُنفّذ المعالجات الحديثة بعض العمليات مسبقًا، متوقعةً التعليمات اللازمة لتوفير الوقت. يُسمى هذا التنفيذ التخميني. إذا ثبت خطأ التوقع، تُهمل النتيجة الأولية، لكن قد تبقى آثار هذا العمل في ذاكرة التخزين المؤقت، وهي مساحة تخزين صغيرة تُساعد المعالج على استرجاع المعلومات المستخدمة مؤخرًا بسرعة. قد يكشف قياس هذه الآثار أحيانًا عن أسرار لم يُسمح للبرنامج بقراءتها. تستغل ثغرة Spectre التلاعب بالتوقعات لحثّ على مثل هذه الإفصاحات؛ بينما استغلت ثغرة Meltdown نقطة ضعف مختلفة في كيفية تعامل بعض المعالجات مع البيانات المحمية قبل حدوث انتهاك الوصول. هذه قنوات جانبية للمعالج، مرتبطة بتسريبات التوقيت الموصوفة سابقًا. وهي تتعلق بكيفية تنفيذ المعالج للتعليمات داخليًا، وليس فقط بمجموعة التعليمات المنشورة التي تصف العمليات التي قد يطلبها البرنامج. تختلف المعالجات المتأثرة والظروف والتدابير المضادة. [30] [31] [32]

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

⚠️ يُوضح كشف Fusée Gelée في عام 2018 عن ثغرة أمنية في وضع الاسترداد في Tegra X1 وجود خلل يمكن الوصول إليه من خلال منفذ USB فعلي، وليس من خلال خدمة شبكة عن بُعد. قد تُقلل تغييرات البرامج والقيود التشغيلية من المخاطر، لكنها لا تستطيع إعادة كتابة ذاكرة القراءة فقط الخاصة بالتمهيد غير القابلة للتغيير. يظل التمهيد الآمن ذا قيمة ضمن ضمانات جذر الثقة وظروف الهجوم التي يُغطيها. [33] [34] [35]

⚠️ حلّلت دراسة SoK التي نشرها Glosner وMachiry عام 2026 عدد 43 محمّل إقلاع ضمن سلسلة الإقلاع البرمجية، بعد تسليم التحكم من جذر الثقة العتادي. وتضم مجموعة بيانات BOOTBENCH الخاصة بها 3658 ثغرة أمنية مُبلغ عنها والتغييرات المرتبطة بها، وقد حدد الباحثان قصورًا في تقنيات الكشف والتحصين الحالية. لا تُثبت هذه الأرقام أن كل برنامج إقلاع قابل للاستغلال أو أن أي جهاز مُعين مُعرّض للاختراق. بل تُبين سبب اختلاف التحقق من أن برنامج الإقلاع صادر من مصدر مُعتمد عن التأكد من خلو التنفيذ المُعتمد من أي عيب قابل للاستغلال. [36]

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

احتواء الفشل قبل انتشاره

تُسهم هندسة الأمن أيضًا في الحدّ من عواقب أي خلل لم يُمنع. لا ينبغي لبرنامج يتعامل مع تنسيق ملف غير مألوف أن يحصل تلقائيًا على نفس صلاحيات الوصول إلى السجلات الخاصة وخدمات الشبكة والعمليات القوية التي يتمتع بها التطبيق الذي استدعاه. يمكن لأنظمة التشغيل فرض حدود بين العمليات الجارية وتقييد صلاحياتها. تُعدّ بيئة الحماية المعزولة (Sandbox) مجموعة من هذه الحدود المفروضة. السؤال المهم هو: أي مكون قيد التشغيل ممنوع من الوصول إلى أي موارد؟ إن وضع الملفات في مجلدات مصدر منفصلة، ​​أو استدعاء دالة من خلال لغة برمجة مختلفة، أو وصف مكتبة بأنها معزولة، لا يُنشئ في حد ذاته حدودًا لنظام التشغيل. [10]

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

توجد أبحاثٌ كثيرةٌ حول كيفية نجاح هذه الحدود أو فشلها عمليًا. حلّل Lefeuvre وزملاؤه في دراسة SoK نُشرت عام 2025 عدد 211 عملاً بحثيًا و61 نظامًا رئيسيًا لعزل المكونات. وحدّدت الدراسة صعوباتٍ مُستمرةً في وضع سياسات عزلٍ قابلةٍ للتطبيق، وترجمة الأبحاث إلى تطبيقاتٍ عملية، وتقييم التهديدات التي تنطوي على إساءة استخدام صلاحيات الوسطاء وقيودٍ في الأجهزة. لا يُعدّ وجود عمليةٍ منفصلةٍ دليلًا على احتواءٍ فعّالٍ إذا كانت صلاحياتها مُفرطةً أو إذا كان مُضيفٌ ذو صلاحياتٍ مُميّزةٍ يستجيب لطلباتٍ غير مُقيّدةٍ منها. وتتمثّل المهمة الهندسية ذات الصلة في تحديد الصلاحيات المُتاحة على جانبي واجهةٍ ما، وإثبات أن الحدود المفروضة تتوافق مع هذا التصميم. [37]

يُجسّد الاحتواء مبدأً عامًا: الوقاية والحد من الضرر لهما وظائف مختلفة. تهدف فحوصات المدخلات إلى رفض أي عملية ضارة قبل بدء تنفيذها. تمنع قواعد أمان الذاكرة بعض عمليات الوصول غير الصالحة. يُقيّد نظام الحماية المعزول الموارد التي يمكن أن يصل إليها الكود المعيب. تساعد المراقبة والاسترداد الخدمة على التعرف على الأعطال المحتملة والاستجابة لها. يمكن لعدة وسائل حماية أن تُقلل من عواقب خطأ واحد، ولكن يجب إثبات استقلاليتها بدلًا من افتراضها. لذلك، قد يبقى العيب الذي تم استغلاله بنجاح محصورًا في مكون مُقيّد؛ فهو لا يمنح تلقائيًا حق الوصول إلى كل جزء من النظام. يُحدد الادعاء الأمني ​​الصادق التأثير المحظور والآليات التي تُفرض الحدود ذات الصلة، بدلًا من حصر التقنيات أو الترويج لكلمة "آمن". [38]

⚠️ حدود الاحتواء وحماية الأجهزة

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

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

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

تُعدّ "Secure Enclave" مثالاً على حدود إنفاذ منفصلة. في أجهزة Apple المدعومة، تُمثّل معالج أمان مزوّدًا ببدء تشغيل آمن خاص به، وذاكرة محمية، ونواة مصغّرة. صُمّم هذا المعالج لحماية بيانات سرية مُحدّدة حتى في حال اختراق نواة نظام التشغيل الرئيسي. يُمكن للتطبيق إنشاء مفتاح خاص للعمليات التي يُديرها "Secure Enclave"، وطلب عمليات تشفير مُصرّح بها دون استلام المفتاح نفسه. يعتمد ما يبقى محميًا على سياسة الوصول الخاصة بالمفتاح والعمليات التي يُشرف عليها "Secure Enclave"، وليس فقط على وجود الشريحة. [41] [42]

تستخدم أنظمة أخرى حدودًا مختلفة تُفرض بواسطة مكونات مادية. تحمي وحدة النظام الأساسي الموثوقة (TPM)، المُنفذة كجهاز منفصل أو داخل المعالج، مفاتيح تشفير مُحددة، ويمكنها ربط استخدامها بقياسات كيفية بدء تشغيل النظام؛ وهي ليست بيئة عامة لتشغيل تعليمات التطبيق البرمجية. يفصل Arm TrustZone بين حالات التنفيذ الآمنة والعادية على المعالجات المدعومة، بحيث يمكن أن تظل البرامج والموارد المُخصصة غير قابلة للوصول لنظام التشغيل العادي عند تصميم النظام بشكل صحيح. تعمل ملحقات حماية البرامج من Intel (SGX)، على المعالجات المدعومة، على عزل تعليمات التطبيق البرمجية والبيانات المُحددة في بيئات معزولة عن البرامج ذات الامتيازات، بما في ذلك نواة نظام التشغيل. على عكس Secure Enclave من Apple، لا يتطلب TrustZone وSGX معالج أمان منفصل. كما أنهما يحميان موارد مختلفة، ولا يمكن اعتبارهما قابلين للتبديل. [43] [44] [45]

يُمكن أن يُساعد الحفاظ على سلطة أمنية مستقلة عن النواة الرئيسية في استعادة ثقة النظام الأساسي بعد اختراق النواة. إذ يُمكن لمسار بدء تشغيل أو استعادة موثوق، خارج نطاق سيطرة النواة، التحقق من البرامج الثابتة وبرامج نظام التشغيل المُصرّح بها قبل عودة الجهاز إلى الخدمة. وقد تدعم المفاتيح المحمية وقياسات عملية الإقلاع هذه الفحوصات. يُميّز المعهد الوطني للمعايير والتكنولوجيا (NIST) جذور الثقة للكشف عن التغييرات غير المصرح بها، والموافقة على التحديثات، واستعادة البرامج الثابتة التالفة للنظام الأساسي. يجب تجميع هذه العناصر في عملية استعادة فعّالة: فوجود وحدة TPM أو بيئة آمنة (Secure Enclave) أو منطقة ثقة (TrustZone) أو بيئة SGX لا يُمكنه، بمفرده، استعادة نظام تشغيل مُخترق. [35] [38]

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

تناولت دراسة زينكوس وجويس وغرين لعام 2022 (SoK) سرية البيانات على الأجهزة المحمولة في مواجهة جهات معادية قوية قادرة على استخراج البيانات، بما في ذلك تلك التي تمتلك وصولاً فعلياً إلى الجهاز أو إلى خدمات سحابية ذات صلة. ويتجاوز نطاقها مجرد حماية المفتاح، إذ قد تُكشف المعلومات قبل تأمينها، أو بعد فك تشفيرها، أو من خلال خدمات تابعة. ولا يُؤكد هذا التحليل التاريخي صحة سلوك مراقب جداول الصفحات الآمنة (SPTM) أو البيئة الآمنة (Secure Enclave) الحالي، بل يُعزز الحاجة إلى تحديد المعلومات التي تبقى محمية، والقدرات التي تُمكّنها من الوصول إليها، ومتى تتجاوز حدود الأمان. [46]

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

قد يحافظ مراقب جداول الصفحات الآمنة (SPTM) على قيود الذاكرة المحددة بعد اختراق النواة، وقد يحمي Secure Enclave المفاتيح المخصصة. ولا يُعيد أيٌّ منهما الثقة في نظام التشغيل بمفرده.

قد يدعم جهاز iPhone كلاً من MIE وPAC، لكن هذا لا يعني أن جميع التطبيقات التي تعمل عليه تستخدم كلا الحمايتين. تقوم Apple بنشر MIE تلقائيًا عبر أسطح الهجوم المحددة في النظام، بما في ذلك نواة النظام. ولا تمتد هذه التغطية تلقائيًا إلى جميع تطبيقات الطرف الثالث أو الإضافات أو العمليات المساعدة أو المكتبات. لذلك، قد يمتلك تطبيقان على نفس جهاز iPhone المدعوم حمايات مختلفة. يجمع MIE بين مكونات من تصميم Apple، ومخصصات ذاكرة آمنة، وضوابط نظام التشغيل؛ وهو ليس مجرد إضافة Arm Memory Tagging Extension (MTE) العامة.

لاستخدام تقنية وضع علامات على ذاكرة الأجهزة في تطبيقاتهم، يجب على المطورين تفعيلها لأهداف Xcode ذات الصلة والتأكد من دعم الجهاز لها. كما أن الصلاحيات وإعدادات وقت التشغيل مهمة أيضًا: فوضع التشخيص الذي يُبلغ عن حالات فشل مُحاكاة لا يُغني عن فرض عمليات التحقق. يُعدّ PAC إجراءً وقائيًا منفصلاً. لا يعني توافق الأجهزة وحده أن كل ملف تنفيذي للتطبيق يستخدم PAC؛ إذ يجب بناء الكود ذي الصلة لبنية arm64e المناسبة، كما تحتاج المكتبات الأصلية الخارجية إلى إصدارات متوافقة. ينبغي على المطورين التحقق من الحمايات المُفعّلة في الإصدار الفعلي، بما في ذلك مكوناته وتوابعه، واختباره على أجهزة فعلية مدعومة. لا تُعدّ مواصفات الجهاز دليلاً على عمل الحمايات في تطبيق مُحدد. [47] [48] [49]

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

عندما تفشل إجراءات الحماية

يجب أن تظل القيود الأمنية سارية حتى في حال فشل عملية فحص أو إجراء مطلوب. إذا كانت خدمة التفويض غير متاحة، فإن عدم الحصول على قرار لا يُعدّ إذنًا بالمتابعة. إذا توقف تغيير متعدد الخطوات في منتصفه، فقد تنتهك السجلات المُحدَّثة جزئيًا القواعد التي صُمِّمت العملية للحفاظ عليها. يجب تحديد الاستجابة للمهمة المحددة: رفض أو تأجيل إجراء غير مُتحقَّق منه، والحفاظ على حالة متسقة، وجعل العمل المُتوقَّف قابلاً للاستعادة. يُعدّ التعامل مع الخطأ على أنه موافقةً عيبًا من نوع السماح عند فشل التحقق (fail-open)؛ كما أن التعامل مع كل خطأ على أنه انقطاع دائم ليس تصميمًا مناسبًا. [50]

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

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

عندما تقوض سلسلة التوريد الأمن

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

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

يستخدم أبو إشغير وزملاؤه في دراستهم لعام 2026 نموذج AStRA لفحص الجهات الفاعلة والخطوات والموارد والمنتجات المستخدمة في إنتاج وتوزيع البرمجيات. ويميز هذا النموذج بين الأسئلة التي يمكن أن يجيب عنها قائمة مكونات البرمجيات (SBOM) وتلك التي تتطلب أدلة حول تغييرات المصدر، وسلامة البناء، وسلطة الإصدار، والتسليم. ولا يُعدّ الجرد الكامل دليلاً على موثوقية البناء، كما أن إثبات المصدر لا يضمن خلو البرنامج الناتج من العيوب. ويجب أن تتوافق الأدلة مع مخاطر سلسلة التوريد المحددة التي يجري تقييمها. [55]

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

لا ينتقل البرنامج مباشرةً من محرر المبرمج إلى جهاز المستخدم. يمر الكود عبر القائمين على الصيانة، والمستودعات، وأدوات البناء، والخدمات الآلية، ومفاتيح التوقيع، وموافقي الإصدارات، وقنوات التوزيع. قد يفحص المراجع الكود المصدري ولكنه يغفل عن تغيير خبيث أُدخل أثناء التغليف؛ كما أن نظام البناء المُحكم لا يوفر حماية كافية إذا تمكن متسلل من المصادقة على ما يتم بناؤه. يُعد فصل هذه المسؤوليات والتحقق منها أمرًا بالغ الأهمية، لأن إصدارًا يبدو شرعيًا قد يكون قد تم تعديله في خطوة غير مرئية للمستخدم النهائي. [56]

كشف الباب الخلفي xz Utils لعام 2024 عن هذه المشكلة بوضوح غير مسبوق. فقد تم إخفاء مواد خبيثة في أرشيفات الإصدارات، ورُتبت لتؤثر على إصدارات معينة من حزم لينكس، مما قد يُضعف مصادقة تسجيل الدخول عن بُعد على الأنظمة ذات التبعيات المحددة. لم يكن أرشيف الإصدار الموزع مُكافئًا ببساطة للمصدر الذي قد يفحصه المُراجع في المستودع العام، بل إن عملية البناء هي التي حددت ما سينتهي به المطاف في البرنامج. تم اكتشاف الهجوم قبل أن تصبح الإصدارات المتأثرة شائعة في توزيعات لينكس المستقرة، ولكنه أظهر أن إصدارًا أصليًا مُرخصًا ظاهريًا قد يحمل وظائف خبيثة مُدخلة عمدًا في الحزم اللاحقة. لهذا السبب، فإن الثقة في مشروع مألوف أو مسار تنزيله الرسمي لا تكفي وحدها. لقد كان هذا اختراقًا لسلسلة التوريد، وليس عيبًا برمجيًا عرضيًا. [57] [58]

تسعى عملية تتبع مصدر البناء إلى ربط الملف التنفيذي المُسلّم بالمصدر والأدوات والإعدادات والخدمة التي أنتجته. ويمكن لعمليات البناء القابلة للتكرار أن توفر أدلة إضافية عندما تُنتج جهات مستقلة نتائج متطابقة من المصدر نفسه. وتصف أُطر عمل مثل SLSA طرقًا لتسجيل هذا التاريخ والتحقق منه. ولكن لا يكون السجل موثوقًا إلا بقدر موثوقية الأنظمة التي أنتجته والتوقعات المستقلة التي يتم التحقق منها بناءً عليها. فمن الممكن بناء مصدر مُخترق بشكل قابل للتكرار؛ وقد تُنتج خدمة بناء تالفة ضمانات زائفة؛ ولا يُحقق بيان مُوقّع لا يتم التحقق منه سوى القليل. يُمكن لتتبع المصدر أن يُثبت أجزاءً من سلسلة الحفظ، وليس ما إذا كان البرنامج الأساسي يعمل بشكل آمن. [59] [60]

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

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

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

الصيانة والسباق نحو الإصلاح

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

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

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

أحيانًا لا يوجد حلٌّ جاهز. حتى عند إصدار حلٍّ سريع، يجب فحصه والتأكد من توافقه مع المنتج، واختباره لتجنب تعطيل الوظائف المهمة، وتسليمه والتحقق منه في النسخة المستخدمة فعليًا. خلال هذه الفترة، قد تظل ثغرة أمنية معروفة قابلة للاستغلال. قد يلزم تقييد الوصول، أو تعطيل ميزة متأثرة، أو عزل خدمة، أو إيقافها عن العمل عند الضرورة. يجب مراقبة هذه الإجراءات المؤقتة ومراجعتها حتى يتم إصلاح الخلل. كما أن تثبيت التحديث لا يُلغي هجومًا قد يكون قد وقع بالفعل. [65]

قد يتحرك المهاجمون بوتيرة أسرع من وصول التحديثات إلى المستخدمين المحتاجين إليها. في دراساتٍ رصدت استغلال الثغرات الأمنية، أفادت شركة مانديانت أن متوسط ​​وقت الاستغلال بلغ 63 يومًا للفترة 2018-2019، و32 يومًا للفترة 2021-2022، وخمسة أيام لعام 2023. وقدّرت تقاريرها لعام 2026 أن متوسط المدة حتى الاستغلال في عام 2025 كان سالب سبعة أيام (−7 أيام)، ما يعني أن أول استغلال مُلاحَظ سبق توفر التحديثات في المتوسط ​​في الحالات المدروسة. هذه قياسات لثغرات مُختارة تم استغلالها، وليست جداول زمنية لكل ثغرة أو قياسات لسرعة تثبيت العملاء للتحديثات. تؤثر هجمات اليوم الصفر على المتوسطات. بدأ هذا التسارع أيضًا قبل أنظمة الذكاء الاصطناعي التوليدية الحالية. [66] [67] [68]

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

لا تقتصر هذه الإمكانية على خدمات النماذج التي يمكن لمشغليها مراقبة الطلبات أو تقييدها. تُصدر بعض نماذج اللغة القوية بأوزان قابلة للتنزيل، ويمكن تشغيلها أو تعديلها خارج سيطرة مُنشئيها؛ وقد تغيب إجراءات الحماية الخاصة بها، أو تُعدّل، أو تُزال. وقد كشفت التقييمات العامة في عام 2026 عن نماذج ذات أوزان مفتوحة ذات قدرات متزايدة في مهام الأمن السيبراني. هذا لا يجعل كل نموذج مهاجمًا فعالًا، ولا يجعل استغلال كل ثغرة أمنية معروفة أمرًا سهلًا. كما يساعد الذكاء الاصطناعي المدافعين على مراجعة التعليمات البرمجية، واكتشاف العيوب، وإعداد الاستجابات. ما يتغير هو تكلفة وسرعة البحث عن نقاط الضعف، بما في ذلك من قِبل جهات فاعلة لا تحتاج إلى مراعاة قيود مُزوّد ​​النموذج. [71] [72]

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

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

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

تتيح البرمجيات مفتوحة المصدر شكلاً قيماً من أشكال التدقيق، إذ يُمكن فحص شفرتها البرمجية والتحقق منها خارج نطاق فريق التطوير الأصلي. إلا أن الحجة الشائعة القائلة بإمكانية فحص الشفرة من قِبل العديد من الأشخاص لا تُثبت بالضرورة وجود عدد كافٍ من الأشخاص المؤهلين الذين يقومون بذلك، أو أن العيوب المُبلغ عنها ستُحل على الفور. تتراوح مشاريع البرمجيات مفتوحة المصدر بين منظمات ممولة تمويلاً جيداً وفرق صغيرة تُدير مكونات واسعة الانتشار؛ كما تختلف البرمجيات الاحتكارية اختلافاً كبيراً في كيفية مراجعتها وصيانتها. يُوضح إصدار PHP الأمني ​​لشهر أكتوبر 2026 هذا التباين. فبعد إصلاح ثغرتين أمنيتين حرجتين، أوضحت مؤسسة PHP كيف أدت المفاضلات التقنية الصعبة، وقلة عدد القائمين على الصيانة ذوي الخبرة، وعملية اتخاذ القرار لديها، إلى تأخير العمل على إحدى المشكلات الأساسية. كما أقرت المؤسسة بدور المهندسين الممولين والباحثين الخارجيين في إتمام عمليات الإصلاح. تمثلت الأخطاء في تلف الذاكرة بعد استنفاد الموارد، وحالة داخلية قديمة عبر الطلبات، مما يربط بين آليات الذاكرة ومعالجة الأخطاء التي نوقشت سابقاً والصيانة المتخصصة اللازمة لإصلاح بيئة تشغيل واسعة الانتشار. لا يُقصد هنا أن البرمجيات مفتوحة المصدر أضعف بطبيعتها، أو أن المنتج المغلق أكثر أماناً. إن توفر شفرة المصدر يخلق فرصة للتدقيق، بينما تحول الخبرة المستمرة والمسؤولية الواضحة والصيانة الفعالة النتائج إلى حماية. [73]

يجب أيضًا اختبار البرمجيات في ظل ظروف استخدامها الفعلية. لا يُقدم عرضٌ ناجحٌ للميزة الرئيسية معلوماتٍ كافيةً حول ما يحدث عند طلب حسابٍ خاطئٍ لسجلٍ ما، أو عند تضارب عمليتين، أو عند تلف ملف، أو عند تلقي مُساعدٍ ذي صلاحياتٍ أمرًا غير متوقع. يتحقق التحقق الأمني ​​من استيفاء المتطلبات المُحددة في الإصدار والتكوين المُستخدمين فعليًا. ويمكنه الجمع بين مراجعة الشفرة والتبعيات مع اختبارات العمليات المحظورة والمشروعة، والتعافي من الأعطال. لا تُثبت الاختبارات عدم وجود ثغرةٍ أمنية، وقد لا تُحدد نتيجة اختبارٍ من جهاز مُطورٍ القيود المفروضة على منتجٍ مُصدر. في المقابل، لا يُعد غياب التدقيق العام دليلًا على عدم أمان الخدمة. الدليل الموثوق هو الذي يُحدد بدقةٍ ما تم فحصه، والإصدار والتكوين المُستخدمين، وما تم العثور عليه، وما لا يزال غير مؤكد. [2]

كيفية تقييم التحذير الأمني

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

يُساعد مُعرّف الثغرة الأمنية العام، والذي يُكتب غالبًا برقم CVE، المؤسسات المختلفة على مناقشة نفس الخلل المُبلّغ عنه. وهو ليس سجلًا لكل تثبيت مُتأثر، ولا يُعدّ دليلًا على استغلاله بنجاح. يُقدّر مُؤشّر الخطورة خصائص الثغرة باستخدام نموذج تقييم مُحدّد؛ وتظلّ الحاجة المُلِحّة للعمليات تعتمد على بيئة التشغيل وما يُمكن للمُهاجم الوصول إليه. يُستخدم مُصطلح "يوم الصفر" غالبًا لوصف ثغرة يتم استغلالها قبل توفّر حلّ فعّال أو قبل أن يعلم بها المُدافع، على الرغم من اختلاف اصطلاحات الإبلاغ. تكمن أهميته في محدودية فرصة المُدافع لإصلاح نقطة الضعف مُسبقًا، وليس في غموض الاسم. يُمكن أن تُشكّل ثغرة أمنية قديمة، حتى مع وجود رقعة منشورة، حالة طوارئ فورية إذا تم استغلالها ضد أجهزة مكشوفة لم يتم تحديثها مُطلقًا. [74] [75]

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

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

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

الخلاصة

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

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

أشياء يجب أن تعرفها:

المراجع

تم ذكر المصادر المرقمة في النص. يشير n.d. إلى عدم وجود تاريخ نشر محدد.

1. National Institute of Standards and Technology (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.
2. National Institute of Standards and Technology (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. DOI: 10.6028/NIST.SP.800-218.
3. OWASP Foundation (n.d.). Authentication Cheat Sheet. OWASP Cheat Sheet Series.
4. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation (2025). Product Security Bad Practices: Updated Guidance. CISA/FBI advisory, 17 January 2025.
5. OWASP Foundation (n.d.). Session Management Cheat Sheet. OWASP Cheat Sheet Series.
6. Zhuo, S., Biddle, R., Koh, Y. S., Lottridge, D. and Russello, G. (2023). SoK: Human-centered Phishing Susceptibility. ACM Transactions on Privacy and Security, 26(3), Article 24. DOI: 10.1145/3575797.
7. OWASP Foundation (n.d.). Authorization Cheat Sheet. OWASP Cheat Sheet Series.
8. Hardy, N. (1988). The Confused Deputy (or Why Capabilities Might Have Been Invented). ACM SIGOPS Operating Systems Review, 22(4), pp. 36–38. DOI: 10.1145/54289.871709.
9. OWASP Foundation (n.d.). Authorization Patterns Cheat Sheet. OWASP Cheat Sheet Series.
10. The Chromium Project (n.d.). Sandbox Design. Chromium design documentation.
11. National Institute of Standards and Technology (n.d.). Insider Threat. NIST CSRC Glossary.
12. OWASP Foundation (n.d.). Business Logic Security Cheat Sheet. OWASP Cheat Sheet Series.
13. MITRE (n.d.). CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Common Weakness Enumeration.
14. OWASP Foundation (n.d.). Input Validation Cheat Sheet. OWASP Cheat Sheet Series.
15. OWASP Foundation (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series.
16. OWASP Foundation (n.d.). Cross Site Scripting Prevention Cheat Sheet. OWASP Cheat Sheet Series.
17. The Rust Project (n.d.). The Rust Programming Language: References and Borrowing; Unsafe Rust. Rust language documentation.
18. The Swift Project (n.d.). Memory Safety. The Swift Programming Language, Swift.org.
19. Python Software Foundation (n.d.). Extending and Embedding the Python Interpreter. Python 3 documentation.
20. Szekeres, L., Payer, M., Wei, T. and Song, D. (2013). SoK: Eternal War in Memory. IEEE Symposium on Security and Privacy, pp. 48–62. DOI: 10.1109/SP.2013.13.
21. Anderson, R. (1993). Why Cryptosystems Fail. Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 215–227. DOI: 10.1145/168588.168615.
22. Internet Engineering Task Force (2023). Service Identity in TLS. RFC 9525.
23. Internet Engineering Task Force (2020). JSON Web Token Best Current Practices. RFC 8725.
24. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446. DOI: 10.17487/RFC8446.
25. Clark, J. and van Oorschot, P. C. (2013). SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP.2013.41.
26. National Institute of Standards and Technology (n.d.). Side Channel. NIST CSRC Glossary.
27. Anderson, R. and Needham, R. (1995). Programming Satan's Computer. In Computer Science Today, pp. 426–440. DOI: 10.1007/BFB0015258.
28. Kim, Y., et al. (2014). Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. Proceedings of the 41st International Symposium on Computer Architecture, pp. 361–372. DOI: 10.1109/ISCA.2014.6853210.
29. Seaborn, M. and Dullien, T. (2015). Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges. Google Project Zero research, March 2015.
30. Kocher, P., et al. (2018). Spectre Attacks: Exploiting Speculative Execution. arXiv:1801.01203, security research preprint.
31. Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory from User Space. 27th USENIX Security Symposium.
32. Intel (n.d.). Analysis of Speculative Execution Side Channels. Intel Software Security Guidance.
33. NVIDIA (2018). Security Notice: NVIDIA Tegra RCM Vulnerability. NVIDIA Product Security Notice, 24 April 2018.
34. Temkin, K. and ReSwitched (2018). Fusée Gelée: Boot ROM Vulnerability Disclosure. Research disclosure.
35. National Institute of Standards and Technology (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. DOI: 10.6028/NIST.SP.800-193.
36. Glosner, C. and Machiry, A. (2026). SoK: All You Ever Wanted to Know About Bootloader Security but Were Afraid to Ask. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP63933.2026.00163.
37. Lefeuvre, H., Dautenhahn, N., Chisnall, D. and Olivier, P. (2025). SoK: Software Compartmentalization. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP61157.2025.00075.
38. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D. and McQuaid, R. (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160, Vol. 2 Rev. 1. DOI: 10.6028/NIST.SP.800-160v2r1.
39. Apple (n.d.). Operating System Integrity. Apple Platform Security.
40. Apple Security Research (2025). Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices. Apple Security Research technical blog.
41. Apple (n.d.). Secure Enclave. Apple Platform Security.
42. Apple Developer (n.d.). Protecting Keys with the Secure Enclave. Apple Developer Documentation, Security.
43. Microsoft (n.d.). Trusted Platform Module (TPM) fundamentals. Microsoft Learn.
44. Arm (n.d.). TrustZone for Cortex-A. Arm Technologies.
45. Intel (n.d.). Intel Software Guard Extensions SDK for Linux OS. Intel Developer Documentation.
46. Zinkus, M., Jois, T. M. and Green, M. (2022). SoK: Cryptographic Confidentiality of Data on Mobile Devices. Proceedings on Privacy Enhancing Technologies, 2022(1), pp. 586–607. DOI: 10.2478/popets-2022-0029.
47. Apple Developer (n.d.). Enabling Enhanced Security for Your App. Apple Developer Documentation, Xcode.
48. Apple Developer (n.d.). Preparing Your App to Work with Pointer Authentication. Apple Developer Documentation, Security.
49. LLVM Project (n.d.). Pointer Authentication. Clang Compiler Documentation.
50. OWASP Foundation (2025). A10: Mishandling of Exceptional Conditions. OWASP Top 10: 2025.
51. MITRE (n.d.). Privilege Escalation (TA0004). MITRE ATT&CK knowledge base.
52. MITRE (n.d.). Lateral Movement (TA0008). MITRE ATT&CK knowledge base.
53. OWASP Foundation (2025). A03: Software Supply Chain Failures. OWASP Top 10: 2025.
54. Cybersecurity and Infrastructure Security Agency and international partners (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). Joint government guidance.
55. Abu Ishgair, E., Gomez, J., Melara, M. S., Cárdenas, A. A. and Torres-Arias, S. (2026). SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. IEEE European Symposium on Security and Privacy, pp. 836–859. DOI: 10.1109/EuroSP68448.2026.00059.
56. Boyens, J., et al. (2024). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1, Update 1.
57. Arasaratnam, O., et al. (2024). xz Backdoor CVE-2024-3094. Open Source Security Foundation, 30 March 2024.
58. Cox, R. (2024). Timeline of the xz Open Source Attack. Research note, 2024.
59. Supply-chain Levels for Software Artifacts (n.d.). Provenance. SLSA Specification, version 1.2.
60. Supply-chain Levels for Software Artifacts (n.d.). Build: Verifying Artifacts. SLSA Specification, version 1.2.
61. The Update Framework (2024). Overview. TUF Documentation, last updated October 2024.
62. Rekhi, S., Amberiadis, K., Akib, A. A., and Srivastava, A. (2025). Analyzing Collusion Threats in the Semiconductor Supply Chain. NIST Cybersecurity White Paper 46. DOI: 10.6028/NIST.CSWP.46.
63. National Institute of Standards and Technology (n.d.). Supply Chain. NIST Mobile Threat Catalogue.
64. Cybersecurity and Infrastructure Security Agency (n.d.). Known Exploited Vulnerabilities Catalog. CISA vulnerability catalogue.
65. UK National Cyber Security Centre (n.d.). Vulnerability Management: Carry Out Assessments. NCSC vulnerability management guidance.
66. Charrier, C., and Semrau, J. (2023). Analysis of Time-to-Exploit Trends: 2021–2022. Mandiant / Google Threat Intelligence, 28 September 2023.
67. Charrier, C., and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant / Google Threat Intelligence, 15 October 2024.
68. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Threat Intelligence.
69. Fang, R., Bindu, R., Gupta, A., and Kang, D. (2024). LLM Agents Can Autonomously Exploit One-Day Vulnerabilities. arXiv preprint 2404.08144.
70. Grunewald, R., Mazumdar, S., and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 1 October 2026.
71. UK AI Security Institute (2026). How Far Behind the Frontier Are Leading Open-Weight Models on Cyber? AISI Work.
72. International AI Safety Report (2026). International AI Safety Report 2026. Section 3.4, Open-weight models.
73. The PHP Foundation (2026). Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation Blog, 21 October 2026.
74. CVE Program (n.d.). Common Vulnerabilities and Exposures: CVE Program Mission and Records. CVE Program.
75. FIRST (n.d.). Common Vulnerability Scoring System (CVSS) v4.0: User Guide. FIRST.org, document version 1.2.