ما هو قانون المرونة الإلكترونية؟
قانون CRA (اللائحة (EU) 2024/2847) نص أفقي يشمل جميع المنتجات التي تحتوي على عناصر رقمية المتاحة في سوق الاتحاد والتي يتضمن استخدامها المقصود اتصالًا مباشرًا أو غير مباشر بجهاز أو شبكة: المنتجات المادية (أجهزة التوجيه، كاميرات IP، منظمات الحرارة المتصلة) والبرمجيات الخالصة أيضًا (تطبيقات الهاتف، الإضافات، المكتبات، أنظمة التشغيل). إنه أول تنظيم أوروبي يطال أمن الشيفرة طوال دورة حياة المنتج.
وهو ليس توجيهًا تنقله كل دولة على طريقتها، بل لائحة ذات تطبيق مباشر وموحّد في الدول الأعضاء الـ27. تُطبَّق ابتداءً من 11 ديسمبر 2027، مع مرحلتين سابقتين: أحكام هيئات تقييم المطابقة (الفصل الرابع) منذ 11 يونيو 2026، والتزام الإبلاغ الوارد في المادة 14 منذ 11 سبتمبر 2026.
ثلاثة مستويات من المنتجات وثلاثة مستويات من التقييم:
- المنتجات العادية: الغالبية العظمى من البرمجيات والأجهزة المتصلة. يثبت الصانع المطابقة عبر الرقابة الداخلية (الوحدة A، أي التقييم الذاتي).
- المنتجات المهمة (الملحق الثالث)، وهي فئتان. الفئة الأولى: أنظمة إدارة الهويات، المتصفحات، مديرو كلمات المرور، برامج مكافحة البرمجيات الخبيثة، منتجات VPN، أنظمة SIEM، مديرو الإقلاع، أنظمة التشغيل، أجهزة التوجيه والمبدّلات، وغيرها. يبقى التقييم الذاتي ممكنًا فقط إذا طبّق الصانع بالكامل معيارًا منسّقًا أو مواصفة مشتركة أو مخطط اعتماد، وإلا تتدخل هيئة مُخطَرة. الفئة الثانية: برامج المراقبة الافتراضية (hyperviseurs) وبيئات تشغيل الحاويات، الجدران النارية وأنظمة كشف التسلل أو منعه، المعالجات والمتحكمات الدقيقة المقاومة للعبث. تدخّل هيئة مُخطَرة (فحص النوع الأوروبي أو ضمان الجودة الكامل) أو اعتماد أوروبي إلزامي.
- المنتجات الحرجة (الملحق الرابع): الأجهزة المادية ذات صناديق الأمان، بوابات العدادات الذكية، البطاقات الذكية والعناصر الآمنة. تخضع لمخطط أوروبي لاعتماد الأمن السيبراني حين يكون مفروضًا، وإلا لإجراءات الفئة الثانية.
ما يُلزم به CRA عمليًا
- الأمن منذ التصميم (security by design): تُقيَّم مخاطر الأمن السيبراني وتُوثَّق منذ مرحلة التصميم، ولا تُعالج كتصحيحات بعد الإطلاق.
- إعدادات آمنة افتراضيًا: يُسلَّم المنتج في حالة آمنة، دون بيانات اعتماد افتراضية متروكة، مع إمكانية إعادته إلى حالته الأصلية. وفي المنتج المصمم حسب الطلب، يمكن للصانع وعميله المهني الاتفاق على إعدادات أخرى.
- غياب أي ثغرة معروفة قابلة للاستغلال عند الطرح في السوق: التبعيات محدّثة ومدقّقة وقابلة للتصحيح عبر تحديثات أمنية.
- معالجة الثغرات طوال فترة الدعم، ومدتها خمس سنوات على الأقل ما لم يكن عمر الاستخدام المتوقع أقصر: تصحيحات تُنشر دون تأخير ومجانًا، ومنفصلة عن الميزات الجديدة متى أمكن، ويبقى كل تحديث أمني متاحًا عشر سنوات على الأقل.
- قائمة مكونات البرمجيات (SBOM) لـكل المنتجات، بصيغة شائعة قابلة للقراءة آليًا، تغطي على الأقل التبعيات من المستوى الأول. وهي جزء من الوثائق التقنية، ولا تفرض اللائحة نشرها.
- سياسة إفصاح منسّق عن الثغرات، مع عنوان اتصال لبلاغات الأطراف الثالثة، وإعلام المستخدمين بالثغرات المصحّحة.
- الإبلاغ عن كل ثغرة مستغلة فعليًا وكل حادث خطير، عبر منصة الإبلاغ الموحدة، خلال 24 ساعة (إنذار مبكر) ثم 72 ساعة (إخطار)، منذ 11 سبتمبر 2026.
- علامة CE: ابتداءً من 11 ديسمبر 2027، تحمل المنتجات المشمولة علامة CE بموجب CRA، مرفقة بإعلان مطابقة أوروبي.
هل تعني هذه اللائحة وكالتك؟
يُطبَّق CRA إذا كنت تتيح منتجًا في سوق الاتحاد الأوروبي في إطار نشاط تجاري، وهذا يتجاوز البيع المباشر بكثير:
- تنشر برنامجًا تجاريًا (تطبيق هاتف، برنامج قابل للتثبيت، تطبيق مكتبي) موزّعًا على شركات أو أفراد أوروبيين: نعم، أنت الصانع.
- توزّع إضافات أو امتدادات على منصات (WordPress.org، Shopify App Store، امتدادات Chrome/Firefox) وتحقق منها دخلًا: نعم.
- تطوّر حسب الطلب منتجًا سيطرحه عميلك في السوق باسمه: عميلك هو الصانع. وعليه بذل العناية الواجبة تجاه مكونات الأطراف الثالثة التي يدمجها (المادة 13، الفقرة 5)، لذا سيطلب منك ضمانات: SBOM، تصحيحات، سياسة إفصاح. وإذا بعت بنفسك مكوّنًا برمجيًا كمنتج مستقل، فهذا المكوّن منتج بمفهوم CRA وأنت صانعه.
- تدمج مكتبات مفتوحة المصدر: تبقى مسؤولًا عن أمن المجموع. وعندما تكتشف ثغرة في مكوّن، عليك إبلاغ القائم على صيانته ومعالجتها في منتجك.
- تشغّل خدمة SaaS أو موقعًا إلكترونيًا: لا يشمل CRA خدمة عبر الإنترنت إلا إذا كانت حل معالجة البيانات عن بُعد لمنتج ما (مثل التطبيق السحابي الذي يتحكم في جهاز متصل). أما الموقع أو خدمة SaaS المستقلة فتخضع بالأحرى لـ NIS2 واللائحة العامة لحماية البيانات.
- تمارس البحث والتطوير أو نماذج أولية غير موزّعة أو استشارات بحتة: خارج النطاق المباشر لـ CRA.
البرمجيات الحرة ومفتوحة المصدر التي لا يحقق منها صانعها دخلًا لا تُعد مقدَّمة في إطار نشاط تجاري، فهي خارج النطاق. أما المؤسسات والجهات التي تدعم بشكل مستدام مشروعًا مفتوح المصدر موجّهًا للاستخدام التجاري فتخضع لنظام مخفف، هو نظام أمناء البرمجيات مفتوحة المصدر (المادة 24)، ولا تسري التزاماتهم في الإبلاغ إلا ابتداءً من 11 ديسمبر 2027. انتبه: بمجرد أن تحقق وكالتك دخلًا من إضافة مفتوحة المصدر تنشرها، يتغير التحليل ويُحسم حالةً بحالة.
العقوبات ومنطقها
تحدد المادة 64 من CRA ثلاثة سقوف للغرامات الإدارية، ويُعتمد المبلغ الأعلى:
1. عدم احترام المتطلبات الأساسية في الملحق الأول والالتزامات الواردة في المادتين 13 و14 (التصميم الآمن، معالجة الثغرات، الإبلاغ): حتى 15,000,000 يورو أو 2.5 % من رقم الأعمال السنوي العالمي.
2. عدم احترام الالتزامات الأخرى للفاعلين الاقتصاديين (المستوردون، الموزعون، الممثلون المفوضون، علامة CE، إعلان المطابقة، إجراءات التقييم): حتى 10,000,000 يورو أو 2 %.
3. تقديم معلومات غير صحيحة أو ناقصة أو مضللة للهيئات المُخطَرة أو لسلطات مراقبة السوق: حتى 5,000,000 يورو أو 1 %.
إذن فالتأخر في الإبلاغ أو إغفاله يقع في الشريحة الأعلى لا الثانية. وهناك استثناءان: المؤسسات الصغيرة جدًا والصغيرة لا تُعاقَب لمجرد تجاوز مهلة 24 ساعة للإنذار المبكر، وأمناء البرمجيات مفتوحة المصدر لا يخضعون للغرامات.
تفرض العقوبات سلطات مراقبة السوق التي تعيّنها كل دولة عضو، مع مراعاة طبيعة المخالفة ومدتها وحجم المؤسسة. وتتلقى فرق CSIRT الوطنية ووكالة ENISA البلاغات. ويشبه هذا الإطار إطار اللائحة العامة لحماية البيانات: تُعدّل السلطة العقوبة، لكن ثبوت عدم الامتثال يكفي لجعلها ممكنة.
الإبلاغ عن ثغرة مستغلة: ما يُطبَّق منذ 11 سبتمبر 2026
المادة 14 هي أول التزام تشغيلي في CRA، وتشمل أيضًا المنتجات المطروحة في السوق قبل 11 ديسمبر 2027 (المادة 69، الفقرة 3). فور علمك بثغرة مستغلة فعليًا في أحد منتجاتك، تبلّغ عنها في آن واحد فريق CSIRT المنسّق في الدولة العضو التي يقع فيها مقرك الرئيسي ووكالة ENISA، عبر منصة الإبلاغ الموحدة التي أنشأتها ENISA والعاملة منذ 11 سبتمبر 2026. يكفي إيداع واحد: ينقله فريق CSIRT بعد ذلك إلى فرق CSIRT في البلدان الأخرى التي يوزَّع فيها المنتج.
يتم الإبلاغ على ثلاث مراحل:
- إنذار مبكر خلال 24 ساعة، مع ذكر الدول الأعضاء التي يوزَّع فيها المنتج إن أمكن. ويُرسل حتى لو لم يتوفر أي تصحيح بعد.
- إخطار خلال 72 ساعة: معلومات عامة عن المنتج، وطبيعة الاستغلال والثغرة، والتدابير التصحيحية المتخذة والتدابير التي يمكن للمستخدمين تطبيقها، ودرجة حساسية المعلومات.
- تقرير نهائي في موعد أقصاه 14 يومًا بعد إتاحة التصحيح: وصف الثغرة وخطورتها، ومعلومات عن الجهة الخبيثة عند الاقتضاء، وتفاصيل التحديث الأمني.
ويتبع الحادث الخطير الذي يمس أمن المنتج النمط نفسه 24 / 72 ساعة، مع تقرير نهائي خلال الشهر الذي يلي الإخطار. ويمكن لفريق CSIRT أيضًا طلب تقرير مرحلي. وفي كل الأحوال، تُعلم المستخدمين المتأثرين بالأمر وبالتدابير التي يمكنهم اتخاذها، بصيغة منظمة قابلة للقراءة آليًا عند الاقتضاء.
وللتطبيق العملي، نشرت المفوضية الأوروبية في 27 يوليو 2026 إرشادات حول تطبيق CRA، وتخصص صفحة لالتزامات الإبلاغ. اقرأها قبل صياغة نماذجك الخاصة.
جهّز وكالتك قبل ديسمبر 2027
الخطوة 1 — حصر منتجاتك وتصنيفها
أعدّ جردًا لكل المنتجات التي تطرحها في سوق الاتحاد (تطبيقات، إضافات، مكونات تبيعها لأطراف ثالثة)، وبشكل منفصل للمنتجات التي تطوّرها لعملاء يسوّقونها. حدّد لكل منها:
- منتج عادي، أم منتج مهم من الفئة الأولى أو الثانية، أم منتج حرج؟
- من الصانع بمفهوم CRA: أنت أم عميلك؟
- نموذج التوزيع: بيع مباشر، منصة، مصدر مفتوح مُدرّ للدخل أم لا؟
- عمر الاستخدام المتوقع، الذي يحدد فترة الدعم (خمس سنوات على الأقل في معظم الحالات).يحدد التصنيف إجراء التقييم: رقابة داخلية أو هيئة مُخطَرة.
الخطوة 2 — إنشاء SBOM وصيانتها
تحصي SBOM (Software Bill of Materials) مكونات المنتج البرمجية: المكتبات الخارجية، التبعيات المباشرة وغير المباشرة، الإصدارات والتراخيص. يشترطها CRA لـكل المنتجات، على الأقل للتبعيات من المستوى الأول، بصيغة قابلة للقراءة آليًا مثل SPDX أو CycloneDX. أنشئها مع كل build بدل مرة في السنة.
# Syft — ينشئ SBOM بصيغة CycloneDX أو SPDX من مجلد أو صورة curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin syft dir:/path/to/your/project -o cyclonedx-json > sbom.json # Trivy — يبحث عن الثغرات المعروفة انطلاقًا من SBOM trivy sbom sbom.json # cdxgen — SBOM لمشاريع Node.js وPython وPHP وGo cdxgen -t php -o sbom-php.json /path/to/projectالخطوة 3 — إرساء معالجة الثغرات
يفرض CRA عملية نشطة طوال فترة الدعم. عمليًا:
1. مراقبة CVE: تنبيهات على تبعياتك (GitHub Dependabot، npm audit، Composer audit، Trivy في CI/CD)، تكمّلها تغذيات NVD وCERT-EU والنشرات الأمنية للناشرين الذين تدمج منتجاتهم.
2. سياسة الإفصاح المنسّق: انشر ملفsecurity.txtفي جذرyourdomain.comوملفSECURITY.mdفي كل مستودع، مع عنوان اتصال والتزام بمهلة المعالجة.
3. عملية التصحيح: حدّد اتفاقية مستوى خدمة داخلية (مثلًا: ثغرة CVSS ≥ 9 → تصحيح خلال 7 أيام)، وانشر التصحيحات الأمنية منفصلة عن الميزات الجديدة متى أمكن.
4. إعلام المستخدمين: مع كل تصحيح، تصف نشرة الثغرة المصحّحة وخطورتها والإصدارات المعنية.الخطوة 4 — تنظيم مسار الإبلاغ وإعداد النماذج
مهلة 24 ساعة لا تترك وقتًا لاكتشاف الإجراء. عيّن من يصنّف الثغرة على أنها «مستغلة فعليًا»، ومن يوافق على الإرسال، ومن يصوغه، ومن يودعه على منصة الإبلاغ الموحدة، مع نائب لكل دور.
أعدّ مسبقًا نموذجًا لكل مرحلة: الإنذار المبكر (المنتج، الإصدارات، بلدان التوزيع، أولى المعطيات)، والإخطار خلال 72 ساعة (طبيعة الاستغلال، تدابير التخفيف للمستخدمين)، والتقرير النهائي (الخطورة، السبب، التصحيح). اعرضها على مستشارك القانوني، ثم اختبر المسار بتمرين تجريبي.
الخطوة 5 — توثيق المطابقة
تشمل الوثائق التقنية:
- وصف المنتج وبنيته الأمنية.
- تقييم مخاطر الأمن السيبراني (threat modeling).
- التدابير الأمنية المنفذة والاختبارات المجراة.
- سياسة معالجة الثغرات والإفصاح عنها.
- قائمة SBOM.
- تعليمات الاستخدام الآمن ومدة فترة الدعم.تُحفظ مع إعلان المطابقة الأوروبي عشر سنوات على الأقل بعد طرح المنتج في السوق، أو طوال فترة الدعم إن كانت أطول.
الخطوة 6 — مراجعة العقود والوثائق المسلَّمة
مع كل عميل، دوّن كتابةً من هو الصانع بمفهوم CRA ومن يتولى ماذا خلال فترة الدعم: مراقبة التبعيات، آجال التصحيح، تسليم SBOM، المشاركة في الإبلاغ. فعقد الصيانة الذي يسكت عن هذه النقاط يترك عميلك وحيدًا أمام المادة 14، ويعرّضك لمطالباته.
ويجب أن تتضمن الوثائق المسلَّمة دليل إعدادات آمنة، وإجراء الإبلاغ الموجّه للمستخدمين، وتاريخ انتهاء فترة الدعم.
الخطوة 7 — تقدير الحاجة إلى تدقيق خارجي
بالنسبة لمنتجات الفئة الثانية ومنتجات الفئة الأولى المقيَّمة دون تطبيق كامل لمعيار منسّق، تدخّل هيئة مُخطَرة إلزامي. وقواعد إخطار هذه الهيئات سارية منذ 11 يونيو 2026: حدّد مبكرًا الهيئات التي تغطي فئتك، لأن الطلب على قدرتها سيرتفع مع اقتراب 2027.
أما المنتجات العادية فيكفيها التقييم الذاتي، شرط الاحتفاظ بملف تقني كامل. ويمكن لتدقيق طوعي أن يعزز مصداقيتك التجارية لدى كبار العملاء من الشركات، الذين سيطلبون إثبات الامتثال لـ CRA قبل التوقيع.
الأثر على بنية الاستضافة لديك
لا يستهدف CRA خدمات الاستضافة في حد ذاتها: فالخدمة السحابية غير المصممة تحت مسؤولية صانع منتج ما تقع خارج نطاقه، والاستضافة تخضع لـ NIS2 (راجع ما يفرضه NIS2 على عملائكم المستضافين). يجتمع النصان دون أن يختلطا: السلطات والآجال والنطاقات مختلفة، والتدبير المتخذ لأحدهما لا يسري تلقائيًا على الآخر. ومع ذلك تبقى بنيتك التحتية معنية بامتثالك لـ CRA في أربع نقاط:
1. المكونات التي تشغّلها جزء من المنتج. إذا كان تطبيقك يضم PostgreSQL أو Redis أو Nginx داخل صورته، فهذه المكونات من سطح الهجوم الذي يُوثَّق في SBOM ويُراقَب بحثًا عن CVE.
2. خط CI/CD يحمل الضوابط. تشغّل مسارات GitHub Actions أو GitLab CI أو غيرها فحوص التبعيات بشكل منهجي (npm audit، Composer audit، Trivy)، وتوقف النشر عند وجود ثغرة حرجة غير محلولة.
3. اكتشاف الاستغلال يتطلب المراقبة. تبدأ مهلة 24 ساعة من لحظة علمك بالاستغلال: من دون تنبيهات على السلوكيات غير الطبيعية وعلى CVE مكونات الإنتاج، ستعلم بعد فوات الأوان. وتسهم أداة مثل CrowdSec على خوادمك في ذلك.
4. إدارة الحوادث تتطلب إمكانية التتبع. يجب أن تكون سجلاتك مفصلة بما يكفي ومحفوظة مدة كافية لتحديد متى وكيف استُغلت الثغرة: فهذه عناصر الإخطار خلال 72 ساعة والتقرير النهائي. والخادم الذي تملك صلاحية root عليه وتختار فيه أدوات التسجيل والكشف يسهّل هذا الجمع أكثر بكثير من بيئة مشتركة مغلقة.
CRA وNIS2 واللائحة العامة لحماية البيانات — التنظيمات الثلاثة الرئيسية
مرّر الجدول أفقيًا
| النص | النطاق | الفئة المستهدفة | تاريخ التطبيق | الغرامة القصوى |
|---|---|---|---|---|
| **CRA** (اللائحة 2024/2847) | المنتجات التي تحتوي على عناصر رقمية المطروحة في سوق الاتحاد | صانعو المنتجات البرمجية والمادية ومستوردوها وموزعوها | 11 سبتمبر 2026 (الإبلاغ) / 11 ديسمبر 2027 (جميع المتطلبات) | 15 مليون يورو أو 2.5 % من رقم الأعمال العالمي |
| **NIS2** (التوجيه 2022/2555) | كيانات القطاعات الـ18 في الملحقين الأول والثاني (الطاقة، الصحة، البنية التحتية الرقمية، السحابة، الاستضافة…) | الكيانات الأساسية والمهمة، ومنها مزودو السحابة ومراكز البيانات وCDN وDNS والخدمات المُدارة | 18 أكتوبر 2024، عبر قوانين النقل الوطنية | 10 ملايين يورو أو 2 % على الأقل (الأساسية)، 7 ملايين يورو أو 1.4 % (المهمة) |
| **GDPR** (اللائحة 2016/679) | معالجة البيانات الشخصية لأشخاص في الاتحاد | كل مسؤول عن المعالجة أو معالج من الباطن | 25 مايو 2018 | 20 مليون يورو أو 4 % من رقم الأعمال العالمي |
أدوات SBOM مجانية لدمجها في CI/CD
إنشاء SBOM تلقائيًا مع كل build هو الإجراء الأعلى مردودًا للاستعداد لـ CRA: فهو يخدم الوثائق التقنية ومراقبة الثغرات معًا. ثلاث أدوات مفتوحة المصدر لدمجها من الآن:
Syft (Anchore) — ينشئ SBOM بصيغتي SPDX وCycloneDX من مجلد أو صورة Docker:
# التثبيت
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
# إنشاء SBOM للمستودع الحالي
syft dir:. -o cyclonedx-json > sbom.jsonTrivy (Aqua Security) — ينتج SBOM بصيغة CycloneDX لصورة Docker، ثم يفحصها بحثًا عن الثغرات:
trivy image --format cyclonedx --output sbom.cdx.json my-app:latest
trivy sbom sbom.cdx.jsoncdxgen (مشروع CycloneDX) — متخصص في مشاريع Node.js وPython وPHP وGo وJava وRuby:
npx @cyclonedx/cdxgen -t php -o sbom-php.json /my-projectأرشف SBOM مع حزمة كل إصدار مُسلَّم: عند ظهور ثغرة، هي التي تخبرك في دقائق بالإصدارات المتأثرة من كل منتج.
جدول الالتزامات — الدرجة الأولى تجاوزناها بالفعل
يُطبَّق CRA على مراحل. يسبق 11 ديسمبر 2027 موعدان وسيطان، وأثقلهما على الفريق التقني، أي الإبلاغ، ساري المفعول منذ 11 سبتمبر 2026.
الخطأ الذي يجب تجنبه: الظن بأن لا شيء عاجل قبل 2027. إذا استُغلت اليوم ثغرة في منتجك ولم تبلّغ عنها في الآجال، فأنت مخالف بالفعل — بما في ذلك لمنتج طُرح في السوق قبل سريان المتطلبات الأخرى.
مواعيد CRA
مرّر الجدول أفقيًا
| الموعد | ما يُطبَّق | ما يجب أن يتوفر لديك |
|---|---|---|
| **10 ديسمبر 2024** | دخول اللائحة حيز النفاذ | حصر أولي لمنتجاتك |
| **11 يونيو 2026** | قواعد هيئات تقييم المطابقة (الفصل الرابع) | تحديد الهيئات المُخطَرة المناسبة للمنتجات المهمة |
| **11 سبتمبر 2026** | الإبلاغ عن الثغرات المستغلة فعليًا والحوادث الخطيرة (المادة 14)، بما فيها المنتجات المطروحة سابقًا | مسار إبلاغ عامل ومُختبَر |
| **11 ديسمبر 2027** | التطبيق الكامل: المتطلبات الأساسية، تقييم المطابقة، علامة CE | الملف التقني، SBOM، إعلان المطابقة الأوروبي |
| **10 سنوات بعد الطرح في السوق**، أو نهاية فترة الدعم إن كانت لاحقة | حفظ الوثائق التقنية وإعلان المطابقة | أرشفة مؤرخة لكل إصدار من المنتج |
ServOrbit وامتثالك لـ CRA
نوفر خوادم VPS وخدمات استضافة تشكّل البنية التحتية التي تعمل عليها منتجاتك. دورنا في امتثالك لـ CRA غير مباشر لكنه ملموس:
- عزل البيئات: تتيح لك خوادم VPS لدينا نشر بيئات منفصلة لكل عميل ولكل مستوى حساسية، مما يحدّ من نطاق الضرر عند الاختراق.
- النسخ الاحتياطية: تمنحك اللقطات عند الطلب المتوفرة في عروضنا نقطة استعادة قابلة للتوثيق بعد أي حادث، وهي معلومة مفيدة لتقارير الإبلاغ. ولسياسة كاملة، اجمعها مع نسخ Restic احتياطية خارجية.
- الوصول إلى السجلات: لديك وصول كامل إلى خادمك وتضبط التسجيل على مستوى تطبيقك، وعليه تتوقف إمكانية تتبع الحوادث.
- موقع البيانات: خوادم VPS لدينا مستضافة في مراكز بيانات في أوروبا، مما يساعدك على توثيق موقع بنيتك التحتية في ملف الامتثال.
الخطوات التالية
الإبلاغ إلزامي منذ 11 سبتمبر 2026، والامتثال الكامل مطلوب في 11 ديسمبر 2027. وهي مدة قصيرة لوكالة لم تضع قط ممارساتها الأمنية في إطار رسمي.
خلال 30 يومًا:
1. حصر منتجاتك في سوق الاتحاد، وتحديد تصنيفها ومن هو صانعها.
2. تعيين المسؤولين عن الإبلاغ، وإعداد النماذج، والتعرف على منصة الإبلاغ الموحدة.
3. التحقق من وجود SECURITY.md في مستودعاتك وsecurity.txt في موقعك، وتثبيت Syft أو Trivy في خط CI/CD.
خلال 6 أشهر:
4. إنشاء SBOM لكل منتج وكل إصدار مُسلَّم.
5. إضفاء الطابع الرسمي على عملية معالجة الثغرات (المسؤول، اتفاقية مستوى الخدمة، إعلام المستخدمين) وتحديث عقود الصيانة.
6. للمنتجات المهمة: التواصل مع هيئة مُخطَرة لجدولة التقييم.
قبل 11 ديسمبر 2027:
7. استكمال الملف التقني وإعلان المطابقة الأوروبي وعلامة CE لكل منتج مشمول.
