تخيّل السؤال ده جايلك في إيميل من عميل: “قوللي بالظبط إيه اللي كان جوه النسخة اللي نزلتها في مارس؟” لو إجابتك محتاجة يومين حفر في Git وفي إيميلاتك القديمة، فالمشكلة مش في ذاكرتك.
مطوّر جرّب يجمّع ملف الإثبات الكامل لإصدار واحد من إضافة تجارية عادية، وطلع بقائمة الناقص. القائمة دي هي اللي تحت، وكلها شغل تنظيم مش شغل قانون.
سياق التجربة
اختار الكاتب إصدارًا مركّبًا من عدة إضافات حقيقية حتى لا يُشار إلى أحد بالتحديد: إضافة نماذج بسعر 99 دولارًا سنويًا (حوالي 4,900 جنيه بسعر تقريبي) بنحو 20,000 تثبيت، تُباع من موقع صاحبها لا من المستودع الرسمي.
الدافع كان أن واجبات الإبلاغ في المادة 14 من قانون الصمود السيبراني (Cyber Resilience Act) الأوروبي أصبحت سارية بالفعل منذ 11 سبتمبر 2026. والسؤال العملي: ماذا يعني أن يكون بائع إضافة صغير “جاهزًا”؟
ملاحظة: هذا يهمّك مباشرة إذا كنت تبيع إضافة أو قالبًا من مصر أو الخليج إلى عملاء في أوروبا، وهو الحال الشائع لمن يبيع عبر موقعه أو عبر أسواق مثل CodeCanyon. مكان جلوسك لا يغيّر شيئًا؛ ما يهمّ هو سوق عملائك. وهذه ليست استشارة قانونية — الكاتب مهندس برمجيات لا محامٍ، وكذلك هذا المقال.
ما كان موجودًا فعلًا
النقطة الجيدة أن الأساسيات كانت متوفرة، وهي أكثر مما يملكه كثيرون:
- رقم إصدار وسجل تغييرات (Changelog) حقيقي، والإصدار 4.3.1 يوثّق فيه إصلاحًا أمنيًا صريحًا: تجاوز في التحقق من رفع الملفات.
- ملف الإصدار المضغوط متاحًا للتنزيل من موقع البائع.
- مستودع عام على GitHub بوسم (Tag) مطابق للإصدار.
الفجوات تبدأ بعد ذلك، وهي المهمة.
1. أي نسخة من الكود بَنَت هذا الملف؟
الوسم موجود في المستودع. لكن هل الملف المضغوط المعروض للتنزيل مطابق تمامًا لبناء آلي (CI Build) من ذلك الوسم، أم أن أحدهم ضغطه من جهازه بعد الظهر؟
لا يوجد سجل بناء: لا بصمة التزام (Commit Hash)، ولا معرّف بناء، ولا هوية من قام به، ولا طابع زمني. وعندما يسأل عميل مؤسسي “أثبت أن هذا الملف جاء من هذا الكود”، فالجواب المتاح هو “ثق بي”.
2. لا توجد قائمة مكونات مرتبطة بالإصدار
في المستودع ملف composer.json، وهو يخبرك بما نوى المطوّر الاعتماد عليه. ولا يخبرك بما شُحن فعلًا داخل الملف المضغوط بعد ستة أشهر: المكتبات المضمَّنة، وإصداراتها بالتحديد، وملفات JavaScript المصغَّرة المسحوبة من npm.
المطلوب هو قائمة مكونات البرمجية (SBOM) مولَّدة على الملف النهائي نفسه. القائمة الوحيدة المفيدة وقت الحادثة هي القائمة المرتبطة بالنسخة التي ثبّتها العميل بالفعل.
3. الإصلاح الأمني بلا طابع زمني للعلم به
الإصدار 4.3.1 أصلح تجاوزًا في التحقق. هل كان مستغلًّا فعليًا؟ إذا كان الجواب نعم، فمهلة الإبلاغ المبكر المحددة بـ24 ساعة تبدأ من لحظة العلم، لا من لحظة الفهم الكامل للمشكلة.
فهل يوجد سجل بطابع زمني يبيّن متى وصل التقرير، ومن فحصه، وماذا قُرِّر؟ سجل التغييرات ليس سجل استلام.
4. لا مخرجات فحص ولا قرارات مسجَّلة
هل فحص أحد الإصدار 4.3.1 قبل شحنه؟ عندما يرفع فاحص أمني تنبيهًا على مكتبة الشهر القادم، فالسؤال لن يكون “هل هناك ثغرة معروفة؟” بل: هل كان التنبيه إيجابية خاطئة، أم كودًا غير مستخدَم، أم مخففًا، أم أنه فاتنا فعلًا — ومن قرّر ذلك ومتى؟
تنبيه فحص بلا قرار مسجَّل باسم مسؤول وسبب ومهلة هو قلق موثَّق في لوحة تحكم، لا أكثر.
5. لا مدة دعم معلنة
كم من الوقت يستقبل الإصدار 4.3.1 إصلاحات أمنية؟ التنظيم الأوروبي يتوقع إعلان مدة الدعم الأمني صراحة. أما عبارة “ندعم أحدث إصدار” فهي العُرف السائد في السوق، وهي بالضبط ما تدفع القواعد الجديدة البائعين بعيدًا عنه.
شكل الملف كاملًا
هذا هو كل شيء، ستة ملفات إلى جانب الملف المضغوط:
formspro-4.3.1/
release.json # version, commit sha, build id, builder, timestamp
sbom.cdx.json # CycloneDX SBOM generated against the final zip
changelog.md
vuln-intake.log # every report, timestamped, with triage decision
scan-results/ # scanner output + per-finding disposition
support-window.txt # "4.3.x receives security fixes until 2027-06"
لا إدارة امتثال ولا مكتب محاماة. ساعتان تقريبًا من نظافة الإصدار، ومعظمها قابل للأتمتة داخل مسار النشر نفسه.
والفرق العملي أن سؤال “ماذا كان في إصدار مارس؟” يُجاب في عشر دقائق بدل أسبوعين من الحفر في تاريخ المستودع وسط حادثة جارية.
في ووردبريس: ابدأ بأرخص ثلاث خطوات ولا تحاول بناء الستة مرة واحدة. أولًا: ولّد ملف الإصدار عبر GitHub Actions بدل الضغط اليدوي، واكتب
release.jsonتلقائيًا من متغيرات المسار. ثانيًا: أضف عنوان بريد أمني وملفSECURITY.mdفي المستودع، وسجّل كل تقرير يصل إليه بوقته. ثالثًا: اكتب سطرًا واحدًا عن مدة الدعم في صفحة المنتج. الثلاثة معًا عمل يوم واحد ويغطّيان أكثر الفجوات إيلامًا.تنبيه: اختبار الجمعة 5:20 مساءً هو المعيار الحقيقي: يصل تقرير استغلال، والمسؤول نائم، ونسختان منتشرتان لدى العملاء. الفرق بين فريق يتجاوز الموقف وفريق يغرق فيه ليس جودة خطة الاستجابة، بل هذا العمل الممل المنجَز مسبقًا.
اقرأ أيضًا
الأسئلة الشائعة
س: هل هذا يخصّني إذا كنت أنشر إضافة مجانية على wordpress.org؟
ج: القواعد الأوروبية موجّهة إلى المنتجات التجارية بالأساس، لكن الملفات الستة نفسها تفيد أي مشروع مفتوح المصدر جدّي، لأن قيمتها في الإجابة السريعة وقت الحادثة لا في الامتثال وحده.
س: ما الفرق بين composer.json وقائمة المكونات (SBOM)؟
ج: الأول يوصف ما تنوي الاعتماد عليه في المستودع، والثاني جرد لما شُحن فعلًا داخل الملف المضغوط بإصداراته الدقيقة. وقت الحادثة، الجرد المفيد هو ما ثبّته العميل.
س: كم وقت يحتاج تجهيز هذا فعلًا؟
ج: يقدّره الكاتب بساعتين تقريبًا لأول إصدار، ومعظمه قابل للأتمتة بعد ذلك، أي دقائق لكل إصدار لاحق.
س: ماذا أكتب في مدة الدعم الأمني؟
ج: سطرًا محددًا بتاريخ صريح مثل “الإصدارات 4.3.x تستقبل إصلاحات أمنية حتى يونيو 2027″، وضعه في صفحة المنتج ومع الملف. العبارات المطاطة مثل “ندعم أحدث إصدار” هي ما تُحاول القواعد الجديدة إنهاءه.
س: أنا أبيع من مصر لعملاء أوروبيين، هل تنطبق عليّ؟
ج: المعيار هو السوق الذي تبيع فيه لا مكان إقامتك، ولذلك فالبيع لعملاء داخل الاتحاد الأوروبي يجعل الموضوع ذا صلة. وللحصول على موقف قانوني دقيق يخص حالتك، استشر محاميًا؛ ما في هذا المقال نظافة إصدار تتقاطع مع ما يطلبه التنظيم.
الخلاصة
الفجوات الخمس كلها من نوع واحد: قرار حدث فعلًا لكن لا يوجد ما يثبت وقته ومن اتخذه. وعلاجها ستة ملفات صغيرة إلى جانب كل إصدار، لا جهاز امتثال كامل.
ابدأ بالبناء الآلي وسجل استلام التقارير وسطر مدة الدعم، وأضف قائمة المكونات ومخرجات الفحص بعد ذلك.
اسأل نفسك السؤال الصعب: لو عميل بعتلك إيميل النهاردة يسألك عن محتوى نسخة مارس، هتجاوب في كام يوم؟ لو الرقم مش عاجبك، ابدأ بملف release.json الأسبوع ده.
مرجع المقال (بالإنجليزية): I tried to build a CRA evidence packet for a WordPress plugin release. Here’s what was missing.
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.



