ماسح التبعيات لا يرى الخطر الذي يُيتّم شفرتكم
المخاطر الحقيقية في سلسلة إمداد المصادر المفتوحة ليست في الترخيص أو جودة الشفرة، بل في اليوم الذي يُستبعد فيه أحد القائمين على المشروع لأسباب لا علاقة لها بالكود، فيرث عملكم شفرة بلا راعٍ.
ماسح التبعيات لديكم بارع فيما يمكنه رؤيته. يقرأ رقم الإصدار، يتحقق من الترخيص، يطابق الثغرات المعروفة مع قاعدة بيانات، وينتج تقريرًا مرتبًا. لكن ذلك التقرير لديه نقطة عمياء بحجم إنسان.
المكوّن الذي يستقر في أسفل بنيتكم التقنية يصيّنه شخص ما. أحيانًا فريق، وغالبًا فرد واحد يقوم بذلك في أوقات فراغه. لا شيء في قائمة مكونات برمجياتكم (SBOM) يسجّل من يكون ذلك الشخص، ولأي ولاية قانونية يخضع، أو ماذا سيحدث للشفرة إذا أُقصي من المشروع بين إصدار وآخر.
هذا الاحتمال الأخير ليس افتراضيًا. في أكتوبر 2024 أزالت نواة لينكس نحو أحد عشر من القائمين عليها المرتبطين بشركات روسية، فحذفت أسماءهم من ملف MAINTAINERS الخاص بالنواة. الالتزام الذي نفّذ ذلك اكتفى بسبب مقتضب، هو أن الإدراجات أُزيلت بسبب متطلبات امتثال متعددة، وأيّد لينوس تورفالدس الخطوة علنًا، مشيرًا إلى قانون العقوبات وراءها لا إلى أي جدل حول جودة الشفرة. لم يكن الدافع جودة الكود أو حادثة أمنية أو خلافًا في الحوكمة، بل التزامًا قانونيًا لم يكن بمقدور المشروع رفضه. الآلية هنا أهم من العنوان: الامتثال تجاوز الشفرة وأقصى من يصونها.
الصورة المعاكسة لهذا الخطر هي الباب الخلفي في xz-utils، الذي كُشف في مارس 2024. هناك، أمضى أحد القائمين نحو عامين في كسب ثقة مشروع تطوعي منهك، ثم استغل ذلك الموقع لزرع باب خلفي خفي في مكتبة ضغط تُشحن مع معظم توزيعات لينكس (CVE-2024-3094). حالة تُقصي قائمًا موثوقًا بقوة القانون، وأخرى تكشف قيمة مقعد القائم لمن يريد استغلاله. كلتاهما تشيران إلى الحقيقة ذاتها التي يتجاهلها ماسحكم: النفوذ يقبع مع من يملك صلاحية الدمج (commit)، لا مع الصياغة التي يدمجها.
ماذا يحدث فعليًا حين يُقصى أحد القائمين على مشروع؟
تتبعوا التسلسل. القائم يملك وحدة برمجية. يراجع الرقع (patches)، يصنّف الأعطال، ويعتمد الإصدارات لذلك الجزء من الشجرة. أقصوه، وستستمر الرقع بالوصول، لكن لن يملك أحد الصلاحية أو السياق لدمجها. الوحدة لا تنهار يوم الإقصاء، بل تتحلل ببطء، رقعة أمنية واحدة غير مراجعة تلو الأخرى.
المشروع لا يتحمل هذه التكلفة، أنتم من يتحملونها. المشروع جهد تطوعي بلا عقد ولا اتفاقية مستوى خدمة ولا التزام تجاهكم. حين يصبح مكوّن بلا راعٍ، فإن الشركة التي تنشره ترث التزامًا غير مرقّع وغير مصنّف لم تختره ولا يسهل التخلص منه. حياد الحوكمة لا يهم هنا، لأن الإقصاء كان متطلبًا قانونيًا لا خيارًا سياسيًا.
لماذا لا يرى الماسح هذا الخطر؟
قواعد المشاركة في أي مشروع تأسيسي تضعها قيادته، وفق تقديرها وحدها. هذا ليس انتقادًا، فكل مشروع يحتاج من يقرر من يملك صلاحية الدمج. لكنه يعني أن تعرّضكم لتلك التبعية يشمل بصمت قرارات لا رأي لكم فيها ولا رؤية لديكم عليها: من يُقبل، ومن يُقصى، وعلى أي أساس. الترخيص لا يلتقط هذا. قائمة مكونات البرمجيات لا تلتقطه. وماسح الثغرات بالتأكيد لا يلتقطه.
أزيلوا الغلاف، وسيبقى تعرّضان مألوفان: مخاطر الأفراد الرئيسيين، ومخاطر السلطة التقديرية في الحوكمة، كامنان تحت بنية تحتية تعاملونها كأصل ثابت. الوظيفة المالية لديها مصطلحات جاهزة لهذا حين يظهر في علاقة مع مورّد. نادرًا ما تُطبَّق على المكتبة مفتوحة المصدر الكامنة ثلاث طبقات أسفل، لأن تلك المكتبة تبدو أقرب إلى قانون فيزيائي منها إلى علاقة مع بشر يمكن أن يُطلب منهم الرحيل.
ثمة ضغطان يتقاطعان الآن. أنظمة العقوبات وضوابط التصدير باتت تصل مباشرة إلى قوائم القائمين على المشاريع، ونطاقها يتّسع باستمرار، وهو ما يستدعي انتباهًا خاصًا من الجهات التي تبني برامج تحوّل رقمي سيادية، من رؤية السعودية 2030 إلى استراتيجيات الذكاء الاصطناعي الإماراتية، والتي تعتمد بدورها على مكدّسات مفتوحة المصدر. في الوقت نفسه، غالبًا ما تكون أكثر التبعيات حيوية هي الأقل تزوّدًا بالطاقم البشري، مدعومة بحفنة من المتطوعين، كما أظهر كل من ما كاد يقع في xz-utils وأزمة Log4Shell في ديسمبر 2021. كلما قلّ عدد البشر الموثوقين، ازداد احتمال إقصاء أحدهم بقاعدة لا يملك المشروع حق الاعتراض عليها، واتسعت النافذة التي تبقى فيها الشفرة غير المصانة دون ترقيع. على الفرق التي تبني على وكلاء آليين يسحبون التبعيات ويحدّثونها بسرعة أن تتعامل مع هذا باعتباره قيدًا تصميميًا، لا حالة استثنائية. إنه أحد أكثر التحديات دقة في الأنظمة العاملة بالوكالة الآمنة.
الاستجابة الصحيحة ليست الذعر من مشروع بعينه، ولا التوهم بأنكم قادرون على استضافة كامل شجرة تبعياتكم داخليًا. إنها إضافة سؤال واحد إلى الفحص الدقيق للاستراتيجية التقنية لا تطرحه معظم الفرق أبدًا: أي حدث قانوني أو تقديري قد يُقصي القائمين على هذا المكوّن بين ليلة وضحاها، وما خطتنا للشفرة اليتيمة صباح اليوم التالي؟
هذا السؤال يفرز تبعياتكم بسرعة. معظمها بخير: قاعدة واسعة من القائمين، عدة جهات مشاركة، وعامل حافلة (bus factor) صحي. لكن قلّة منها ليست كذلك: قائم واحد، ولاية قانونية واحدة، نقطة فشل وحيدة لا تلتقطها أي أداة آلية لأن الفشل يقبع في البشر والقانون، لا في الصياغة البرمجية. تلك القلة تستحق خطة طوارئ، سواء كانت تمويل قائم ثانٍ، أو تجميد نسخة معروفة الموثوقية (vendoring)، أو بناء القدرة الداخلية على ترقيع الأداة بأنفسكم إن لزم الأمر.
بنيتكم التقنية ليست مجرد شفرة استوردتموها، بل مجموعة علاقات مع بشر يمكن إقصاؤهم بقوى لا علاقة لها بكم. دقّقوا في البشر، لا في الحزم وحدها.
أسئلة شائعة
هل تحمي قائمة مكونات البرمجيات (SBOM) من مخاطر القائمين والعقوبات؟
لا. قائمة مكونات البرمجيات تحصر المكونات والإصدارات التي تشحنونها، وما تحمله من تراخيص وثغرات معروفة. لكنها لا تقول شيئًا عمّن يصون كل مكوّن، ولا كم شخصًا يمكنه مراجعة رقعة أمنية، ولا ما إذا كان حدث قانوني أو حوكمي قد يُقصي هؤلاء الأشخاص. هذه الفجوة هي بالضبط حيث يكمن خطر الشفرة اليتيمة، لذا فإن قائمة المكونات ضرورية لكنها غير كافية.
ما هو خطر الأفراد الرئيسيين في تبعية مفتوحة المصدر؟
هو التعرّض الناشئ حين يعتمد مكوّن على شخص واحد، أو عدد قليل جدًا من الأشخاص، لمراجعة التغييرات ودمجها. إذا غادر ذلك الشخص، أو أُقصي لأسباب امتثال، أو توقف عن المساهمة ببساطة، تتوقف الرقع عن الدمج رغم استمرار تقديمها. تتدهور الشفرة بصمت، وترث الشركة التي تنشرها النتيجة غير المصانة.
كيف تُقيَّم مخاطر الحوكمة في تبعية مفتوحة المصدر؟
انظروا إلى ما وراء الترخيص والشفرة، إلى البشر والقواعد. تحققوا من عدد القائمين النشطين وعامل الحافلة، وما إذا كان المساهمون موزعين على عدة جهات وولايات قانونية، ومن يملك سلطة قبول أو إقصاء أصحاب صلاحية الدمج. ثم اسألوا عن الحدث القانوني أو القيادي الواحد الذي قد يُقصي القائمين بين ليلة وضحاها، ودوّنوا خطة الطوارئ للمكونات التي تكون الإجابة عنها مقلقة.
مواضيع ذات صلة
- في أوبونتو 26.04 LTS، حزمة coreutils التي تعتمد عليها بنيتكم التقنية لم تعد GNU
- علاوة السيادة: لماذا تكسب حلول الذكاء الاصطناعي السيادي للمؤسسات الرهان على حرية الوصول لا على السرعة
- قضايا الأسرار التجارية تُحسم قبل سنوات من استقالة أي موظف. اسألوا شركة فاسيندا تشيكن
- Security & Trust
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.