يرسل أحد الموزعين بريدًا إلكترونيًا يطلب إعلان المطابقة الخاص بك. يذهب البريد إلى قسم المبيعات، الذين يحيلونه إلى مدير المنتج، الذي يحيله إلى قسم الهندسة، حيث يتوقف الأمر. لقد تم شحن الجهاز لمدة أربع سنوات. تُبنى البرامج الثابتة على جهاز مهندس واحد. لا أحد لديه جرد لما بداخله، وقد تم استبعاد آلية التحديث من الإصدار الأول للوفاء بموعد الإطلاق، والشخص الذي كتب محمّل الإقلاع غادر في عام 2023.
لم يكن أي من ذلك إهمالاً. كان أمراً طبيعياً، وكان جيداً حتى اللحظة التي احتاج فيها شخص ما في سلسلة القيمة إلى إجابة مكتوبة.
قانون الاتحاد الأوروبي للمرونة السيبرانية هو ما غيّر ذلك. إنه لائحة تنظيمية للوصول إلى السوق، وليس دليلاً لأفضل ممارسات الأمان: المنتجات ذات العناصر الرقمية التي تُباع في الاتحاد الأوروبي يجب أن تفي بمتطلباته، وتقع الالتزامات على عاتق الشركة المصنّعة طوال دورة حياة المنتج بدلاً من شهادة تُصدر مرة واحدة.
تتناول هذه المقالة العواقب الهندسية — ما الذي يغيّره الامتثال لقانون CRA فعليًا في كيفية بناء البرامج الثابتة وتحديثها وتوثيقها، وكيفية الحكم على ما إذا كان فريقك قادرًا على استيعاب ذلك جنبًا إلى جنب مع خارطة الطريق. إذا كنت في مرحلة أبكر من ذلك ولا تزال تحدد كيفية بناء البرنامج نفسه، فابدأ بـ دليل تطوير البرمجيات المدمجة.
- قانون المرونة السيبرانية يحوّل القدرة على التحديث ومعالجة الثغرات من تفضيلات هندسية إلى شروط للبيع في الاتحاد الأوروبي، مما ينقلها من قائمة المهام المؤجلة إلى البنية المعمارية.
- ثلاثة تواريخ تحدد الجدول الزمني: دخلت اللائحة حيز التنفيذ في 10 ديسمبر 2024، وتبدأ التزامات الإبلاغ في 11 سبتمبر 2026، وتُطبَّق الالتزامات الرئيسية اعتبارًا من 11 ديسمبر 2027.
- الالتزامات ترتبط بدورة حياة المنتج — التخطيط والتصميم والتطوير والصيانة — وليس بمستند يُنتَج في النهاية، ولهذا السبب يكون التعديل اللاحق هو المسار المكلف.
- العمل الهندسي الذي يخلقه هذا ملموس: مسار تحديث موقّع وقابل للاسترجاع، وجرد للتبعيات يمكنك إعادة إنشائه، وعملية للثغرات الأمنية تعمل طالما ظل المنتج معروضًا للبيع.
- سؤال البناء مقابل الشراء ليس ما إذا كان مهندسوك قادرين على القيام بذلك. بل ما إذا كان بإمكانهم القيام بذلك مع إطلاق خارطة الطريق في الوقت نفسه، وللمنتجات الموجودة بالفعل في السوق وكذلك المنتج التالي.
- لا أحد ممن يتصدرون نتائج البحث بخصوص هذه اللائحة اليوم يكتب من منظور هندسة برمجيات الأجهزة، وهذا يوضح لك مدى كون التوجيهات المتاحة قانونية أكثر منها عملية.
ما الذي يعنيه الامتثال لقانون المرونة السيبرانية (CRA) فعليًا لصانع الأجهزة
تصف المفوضية الأوروبية لائحة تغطي الأجهزة والبرمجيات القابلة للاتصال — وتتراوح أمثلتها الخاصة من أجهزة مراقبة الأطفال والساعات الذكية إلى التطبيقات وبرامج الكمبيوتر — وتضع الالتزام على عاتق المصنّعين لمعالجة الأمن السيبراني من خلال تخطيط المنتج وتصميمه وتطويره وصيانته، ومعالجة الثغرات الأمنية عبر دورة حياته. تحمل المنتجات علامة CE لإظهار المطابقة، وتتطلب الفئات الأعلى خطورة تقييماً من طرف ثالث بواسطة جهة إخطار مُعتمَدة قبل أن يمكن بيعها.
اقرأ ذلك كمهندس بدلاً من محامٍ وتتبع ذلك ثلاثة أمور.
إنه يرتبط بالعملية، وليس بالإصدار. “التخطيط والتصميم والتطوير والصيانة” هي دورة الحياة الكاملة. يمكن لعملية تقييم المطابقة التي تُجرى في السباق الأخير قبل الإطلاق أن تصف عملية؛ لكنها لا تستطيع إنشاء واحدة بأثر رجعي.
إنها تستمر بعد الشحن. إن معالجة الثغرات الأمنية عبر دورة الحياة تعني أن الالتزام لا يزال قائماً على منتج بعته قبل ثلاث سنوات. وهذا هو المتطلب الأكثر عرضة للتقليل من شأنه، لأنه يحوّل تكلفة مشروع لمرة واحدة إلى تكلفة تشغيلية دائمة.
إنه ينطبق على ما تبيعه، بما في ذلك ما لم تكتبه. الجهاز يتكوّن في معظمه من شيفرة أشخاص آخرين — نظام تشغيل في الوقت الفعلي (RTOS)، وحزمة TCP/IP، ومكتبة تشفير، وحزمة دعم لوحة من المورّد (BSP)، وعشرات المكونات مفتوحة المصدر التي يجلبها البناء. الالتزام بمعالجة الثغرات لا يميّز بين الشيفرة التي كتبتها والشيفرة التي شحنتها.
التواريخ الثلاثة التي تحدد جدولك الزمني
التاريخ الأوسط هو الذي يوقع الفرق في المشاكل. يصل الإبلاغ قبل أكثر من عام من الالتزامات الرئيسية، والإبلاغ ليس مهمة توثيق — لا يمكنك الإبلاغ عن ثغرة أمنية يجري استغلالها بنشاط في منتجك ما لم يكن هناك شيء يراقبها، وشخص يملك اتخاذ القرار، ووجود مسار لإطلاق الإصلاح. من الناحية العملية، يتطلب تاريخ سبتمبر الآلية التي يطالب بها تاريخ ديسمبر 2027 رسميًا.
بالعمل بشكل عكسي انطلاقًا من منتج ضمن دورة أجهزة مدتها سنتان، فإن قرارات البنية التي تجعل هذا الأمر ميسور التكلفة تُتخذ الآن، في تصميم أي شيء بدأته هذا العام.
متطلبات قانون المرونة السيبرانية التي تغيّر البرامج الثابتة الخاصة بك
تنتقل أربعة أشياء من “ينبغي علينا” إلى “يجب علينا”، وكل واحد منها يمثل قرارًا معماريًا وليس ميزة.
مسار تحديث موقّع يمكن أن يفشل بأمان
الالتزام بمعالجة الثغرات طوال دورة حياة المنتج هو التزام بالقدرة على إصدار إصلاح، ما يعني أن آلية تحديث البرامج الثابتة عبر الأثير تتوقف عن كونها اختيارية. المحتوى الهندسي محدد: الإقلاع الآمن حتى لا يشغّل الجهاز إلا البرامج الثابتة التي وقّعتها، والتحقق من سلامة الصورة، والحماية من التراجع بحيث يترك التحديث المطبّق جزئياً على جهاز في قبو أحد العملاء منتجاً يعمل بدلاً من جهاز معطّل تماماً. المنتجات الموجودة بالفعل في الميدان دون هذه الميزات هي الحالة الصعبة، لأن آلية التحديث نفسها يجب أن تصل عبر قناة لا وجود لها بعد.
جرد لما تشحنه فعليًا
التعامل مع الثغرات الأمنية في المكونات التي لم تكتبها بنفسك يتطلب معرفة المكونات التي قمت بشحنها، وبأي إصدار، وفي أي صورة برمجية ثابتة (firmware)، وعلى أي وحدات. يمكن لمعظم الفرق إعادة بناء هذه المعلومات بعد أسبوع من الجهد، لكنها لا تستطيع إعادة توليدها عند الطلب — وهذا هو الفرق الذي يهم، لأن الكشف عن ثغرة أمنية في مكتبة واسعة الاستخدام هو سؤال تجيب عليه في غضون ساعات، بشكل متكرر، لسنوات. الاختبار العملي هو ما إذا كانت عملية البناء لديك تنتج ذلك الجرد تلقائيًا أم أن شخصًا ما يقوم بتجميعه.
التعامل مع الثغرات الأمنية كعملية مستمرة
يجب أن يكون هناك شخص ما يراقب موجزات الإفصاح مقابل قائمة مكوناتك، ويصنّف ما ينطبق على منتجك، ويقرر ما الذي سيتم إصداره ومتى. هذا هو الالتزام الذي يغيّر شكل فريق الهندسة أكثر من غيره، لأنه مستمر ويتنافس مباشرة مع أعمال خارطة الطريق. وهو أيضاً الالتزام الذي تكون الإجابة الصادقة عنه بالنسبة للكثير من شركات المنتجات هي أنه لا توجد مثل هذه العملية اليوم.
الوثائق التي تبقى بعد الأشخاص الذين كتبوها
يعتمد الامتثال على القدرة على إظهار كيفية تصميم المنتج، وما الذي تم تقييمه، وما الذي تم اتخاذ قرار بشأنه. وهذا نوع مختلف من المخرجات عن مخطط معماري رُسم مرة واحدة — إنه توثيق يُحدّث باستمرار جنبًا إلى جنب مع الكود، وهو انضباط أكثر من كونه مُخرجًا نهائيًا. البرمجيات المضمّنة لدى العمل الأمني عادة العيش في عقول شخصين؛ وهذا المتطلب هو ما يجبره على الخروج منهما.
أي المنتجات مشمولة بالنطاق، ومن يتحمل الالتزام
النطاق أوسع مما تفترضه معظم فرق الأجهزة عند القراءة الأولى. فهو لا يقتصر على المنتجات المُسوَّقة كأجهزة أمنية، ولا يقتصر على السلع الاستهلاكية — والمعيار هو ما إذا كان المنتج يحتوي على عناصر رقمية ويمكنه الاتصال، وهو ما يشمل معظم ما يشحنه حاليًا صانعو الأجهزة الصناعية أو الطبية أو الاستهلاكية.
يقع الالتزام على عاتق الشركة المصنّعة. وهذا مهم في حالتين تظهران باستمرار:
- لقد جعلت شخصًا آخر يبني البرنامج الثابت. لا يزال الالتزام يقع على عاتقك. إن عقد التطوير الذي ينتهي عند التسليم يتركك تحمل واجب دورة الحياة دون أي قدرة هندسية مرتبطة به، وهذه مسألة تحديد نطاق يجب تسويتها قبل العقد، لا بعده.
- أنت تبيع في الاتحاد الأوروبي من خلال موزّع. يجب استيفاء المتطلبات عبر سلسلة القيمة بأكملها، لذا يصل الطلب في النهاية إلى فريق الهندسة لديك بغض النظر عن من باع الوحدة.
بالنسبة لفئات المنتجات ذات المخاطر الأعلى، يُشترط إجراء تقييم من طرف ثالث بواسطة جهة مُخوَّلة قبل البيع، مما يضيف اعتمادية خارجية لها مدة زمنية خاصة بها إلى جدول زمني يحتوي بالفعل على مكونات مادية.
هل يستطيع فريقك استيعاب هذا داخلياً؟
هذا هو السؤال الحقيقي، وهو ليس سؤالاً عن الكفاءة. تستطيع معظم الفرق المدمجة بناء الإقلاع الآمن ومسار التحديث؛ والكثير منها قد بنى كليهما بالفعل. السؤال هو عن القدرة والاستمرارية، وينحل إلى أربعة فحوص صادقة.
هل يمكنك إعادة إنشاء جرد المكونات الخاص بك اليوم، عند الطلب؟ إذا كانت الإجابة تتضمن شخصًا وجدول بيانات، فإن الفجوة تكمن في الأدوات، والأدوات هي الأرخص من بين الفجوات الأربع التي يمكن سدها.
هل يمتلك المنتج المطروح في الميدان مسار تحديث فعّالاً؟ إن لم يكن كذلك، فإن العمل ليس عمل امتثال — بل هو مشروع برمجيات ثابتة يتضمن تغييراً في محمّل الإقلاع، وبنية تحتية للتوقيع، وخطة طرح، ويجب جدولته على هذا الأساس.
من المسؤول عندما يصل إفصاح ما يوم الجمعة؟ شخص محدد بالاسم يملك صلاحية الإطلاق، أو لا أحد. هذا سؤال يتعلق بنموذج التشغيل لا يمكن لقيادة الهندسة الإجابة عنه بمفردها.
ما الذي يخرج من خارطة الطريق؟ العمل حقيقي وهو متكرر. الخطة التي تفترض أنه سيتم استيعابه دون إزاحة أي شيء هي خطة لن تتحقق بهدوء.
حيث تختار الفرق الاستعانة بالمساعدة، يكون ذلك عادةً للأمرين الثاني والثالث من هؤلاء: مشروع منفصل لبناء مسار التحديث والتوقيع في منتج موجود، وعملية يديرها شخص آخر حتى تصبح روتينية. حيث تكون الإجابة هي التوظيف أو الشراكة على نطاق أوسع، فإن أفضل شركات تطوير البرمجيات المضمنة هذا التقرير المجمّع يقارن إحدى عشرة شركة بناءً على القدرات التي تنشرها كل واحدة منها فعليًا، بما في ذلك أيٌّ منها تعتبر التمهيد الآمن والتحديث عبر الهواء والصيانة طويلة الأمد جزءًا من عملها الخاص بدلًا من كونها مشكلة العميل.
ما تكلفة هذا، وأين تقع التكلفة فعلياً
لا يوجد رقم واحد، والنطاقات المتداولة في التسويق لدى البائعين ليست موثوقة المصدر بما يكفي لتكرارها. ما يمكن التنبؤ به هو أين أين تتركز التكلفة، وهو أمر أكثر فائدة عندما تكون بصدد بناء دراسة جدوى تجارية.
التعديل التحديثي هو الفئة المكلفة، بفارق كبير. إضافة مسار تحديث موقّع إلى منتج صُمّم بدون واحد يمسّ محمّل الإقلاع، وخريطة الذاكرة، وعملية التصنيع، والطرح الميداني. بناؤه ضمن المنتج الآن يكلّف جزءًا يسيرًا من ذلك.
التكلفة المتكررة هي التي يتم إغفالها. تستمر المراقبة وفرز المشكلات وإصدارات التصحيح طالما يتم بيع المنتج ودعمه. إن دراسة الجدوى التي تسعّر المشروع الأول فقط تقلل من شأن الالتزام، وهو البند المتكرر الذي يحدد ما إذا كان سيتم استيعاب هذا أم توفير الموارد له.
تجزئة الأسطول تضاعف كل شيء. أربع مراجعات للأجهزة وثلاثة فروع للبرامج الثابتة يعني أن كل إصلاح هو أربعة إصدارات أو أكثر. غالبًا ما يكون توحيد المتغيرات هو الشيء الأكثر فائدة الذي يمكن لأي فريق القيام به قبل أن تبدأ الالتزامات، وهو تمرين هندسي بحت لا يحتوي على أي محتوى تنظيمي على الإطلاق.
التوثيق رخيص عندما يكون مستمرًا وباهظ الثمن عندما يكون أثريًا. عند الاحتفاظ به إلى جانب الكود يكون ضريبة صغيرة لكل تغيير. أما عند إعادة بنائه لاحقًا، على قاعدة كود غادر مؤلفوها، فإنه يصبح مشروعًا.
أين يتناسب Crunch-IS
لدينا خدمات تطوير البرامج الثابتة نبني أدوات الإقلاع وآليات التحديث الميداني مع التحقق من الإقلاع الآمن والحماية من التراجع والتحقق من السلامة كمعايير قياسية، ونحدد نطاق التحصين — الاتصالات المشفرة والتخزين الآمن والتحكم في الوصول وتقليل مساحة الهجوم — من مرحلة التصميم المعماري بدلاً من بعد أن يعمل المنتج. وهذه هي مجموعة القرارات نفسها التي تجعلها هذه اللائحة الآن غير اختيارية، ولهذا السبب يكون العمل في كثير من الأحيان مشروع برامج ثابتة أكثر من كونه مشروع امتثال.
النصف الآخر منه هو انضباط الإصدار، لأن الالتزام بشحن الإصلاحات بشكل موثوق هو التزام بامتلاك عملية إصدار لا تتسبب هي نفسها في تعطيل الأمور. في نظام إدارة شبكة الاتصالات، أدت إعادة البناء حول حدود أوضح وعملية إصدار منضبطة إلى تقليل المشكلات المتعلقة بالنشر بنسبة 60% وتحسين وقت تشغيل النظام وموثوقيته بنسبة 50% — نفس القدرة، مقاسة على مشكلة مختلفة.
الخلاصة
قانون الصمود السيبراني لا يطلب من صانعي الأجهزة القيام بأي شيء لم تكن الفرق المضمّنة الأفضل تدعو إليه بالفعل. ما يغيّره هو أن القدرة على التحديث، ووضوح رؤية التبعيات، ووجود عملية فعّالة للتعامل مع الثغرات أصبحت الآن شروطًا للبيع بدلًا من كونها أمورًا يُموَّل تنفيذها في العام المقبل — وأن المنتجات الموجودة بالفعل في الميدان تقع ضمن النطاق إلى جانب المنتج التالي.
القراران الجديران باتخاذهما الآن هما قراران معماريان: صمّم مسار التحديث ضمن أي شيء تبدأ به هذا العام، واجعل جرد مكوّناتك شيئًا تنتجه عملية البناء بدلًا من أن يجمّعه شخص ما. كلاهما أرخص الآن من أي وقت لاحق، ولا يتطلب أيٌّ منهما أن تُحسم اللوائح التنظيمية بالكامل قبل أن تتحرك.
