Composer Audit: اكتشاف اعتماديات PHP المعرضة للثغرات قبل وصولها إلى الإنتاج

يشغّل تطبيق Laravel أو Symfony أو دروبال أو ماجنتو المعتاد شيفرة من حزم Composer الخارجية تفوق بكثير ما كتبه فريقه بنفسه. ويستطيع Composer فحص هذه الحزم مقابل الإشعارات الأمنية المنشورة بأمر واحد هو composer audit، بل تذهب إصداراته الحديثة أبعد من ذلك فتمنع الإصدارات المعروفة بثغراتها والإصدارات الخبيثة أثناء التحديث. يشرح هذا الدليل ما يفحصه الأمر، وما الذي تغير في 2026، وكيف تجعله جزءًا من روتينك. وكل سلوك موصوف هنا مأخوذ من وثائق Composer الرسمية وسجل تغييراته.

أي إصدار من Composer لديك؟

تعتمد الميزات كثيرًا على الإصدار، وقد صدرت أحدث النسخ هذا الأسبوع: Composer 2.11.0 في 29 أكتوبر 2026 و2.11.1 في 30 أكتوبر 2026.

composer --version
command -v composer

• الإصدار 2.4 (2022) أضاف composer audit، مع فحص تلقائي بعد update وrequire يمكن تخطيه بالخيار --no-audit.
• الإصدار 2.9 (نوفمبر 2025) بدأ يمنع إصدارات الحزم التي لها إشعارات أمنية معروفة أثناء update وrequire، وهذا مفعّل افتراضيًا.
• الإصدار 2.10 (مايو 2026) قدّم كتلة الإعداد policy التي تحل محل أغلب إعدادات audit القديمة وتجعلها مهملة، وأضاف اكتشاف إصدارات الحزم الموسومة كبرمجيات خبيثة ومنعها (المنع عند install مفعّل افتراضيًا)، وبسّط رمز خروج الفحص إلى 0 عند عدم وجود مشكلات و1 عند فشل أي شيء.
• الإصدار 2.11 (أكتوبر 2026) أضاف سياسة فترة الانتظار cooldown والخيار --direct للفحص.

أما حزم التوزيعات فمتأخرة: تحزم ديبيان 13 ‏(trixie) الإصدار 2.8.8، وديبيان 12 ‏(bookworm) الإصدار 2.5.5، فلا يتضمن أي منهما منع الإصدارات المعرضة للثغرات ولا كتلة السياسات. وتذكر الوثائق أيضًا أن الأمر composer self-update غير متاح إذا ثُبّت Composer عبر مدير حزم نظام التشغيل. فإن أردت السلوك الحالي فثبّت Composer من getcomposer.org وحدّثه بالأمر composer self-update.

ماذا يفحص composer audit؟

يرسل الفحص افتراضيًا أسماء الحزم المثبتة إلى واجهة الإشعارات الأمنية في Packagist.org (أو إلى المستودعات الأخرى التي ضبطتها)، ثم يبلغ عن:

• الإشعارات الأمنية التي تمس الإصدارات المثبتة. يجمع Packagist الإشعارات من مصادر مثل قاعدة GitHub Advisory Database ومشروع FriendsOfPHP security-advisories، ويعيد معرّف CVE ودرجة الخطورة عند توفرهما.
• الحزم المهجورة التي توقف القائمون عليها عن تطويرها.
• الإصدارات الموسومة كبرمجيات خبيثة (في Composer 2.10 وما بعده).

composer audit                    # installed packages in vendor/
composer audit --locked           # composer.lock, even without vendor/
composer audit --no-dev           # skip require-dev packages
composer audit --format=json      # table (default), plain, json or summary
composer audit --abandoned=report # ignore, report or fail

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

إصلاح ما يكتشفه

تُعالج أغلب النتائج بتحديث الحزمة المتأثرة ضمن القيود التي يسمح بها مشروعك أصلًا:

composer update vendor/package --with-dependencies
composer audit
composer outdated

يحدّث الخيار --with-dependencies (-w) اعتماديات تلك الحزمة أيضًا، واستخدم --with-all-dependencies (-W) عندما يلزم تحريك الاعتماديات المشتركة كذلك. وإذا كان الإصدار المصحَّح يحتاج إلى إصدار رئيسي أحدث أو إلى PHP أحدث، فالأمر composer prohibits vendor/package 2.0 يشرح ما يمنعه. اعتمد ملف composer.lock المحدّث، وشغّل اختباراتك، وانشر بالأمر composer install من ملف القفل هذا بدل تشغيل update على الخادم.

تجاهل إشعار، مع ذكر السبب

أحيانًا لا ينطبق الإشعار عليك، كأن يمس ميزة لا تستدعيها أبدًا. وابتداءً من Composer 2.10 يمكنك تسجيل هذا القرار في composer.json مع سببه، وتحديد هل يسري على المنع أو الفحص أو كليهما:

{
    "config": {
        "policy": {
            "advisories": {
                "ignore-id": {
                    "GHSA-xxxx-xxxx-xxxx": "Not affected: feature X is disabled. Review by 2027-01-31."
                }
            },
            "abandoned": {
                "audit": "report"
            }
        }
    }
}

يمكن أن تكون معرّفات الإشعارات من نوع CVE أو GHSA أو معرّفات Packagist ‏(PKSA). اجعل كل استثناء ضيقًا، ودوّن سببه، وراجع القائمة بانتظام، فقائمة الاستثناءات التي لا تكف عن النمو ليست إلا تراكمًا لمخاطر غير مرقّعة. وما زالت مفاتيح config.audit القديمة تعمل احتياطًا، لكن فقط عند غياب قسم policy المقابل، فانقلها كلها دفعة واحدة ولا تخلط بين الطريقتين.

سياسة فترة الانتظار: مقايضة

يستطيع Composer 2.11 حجب الإصدارات المنشورة حديثًا لمدة تختارها، مثل "policy": {"cooldown": {"period": "7 days"}}. وتعلل الوثائق ذلك بأن كثيرًا من الإصدارات الخبيثة تُكتشف وتُزال خلال ساعات أو أيام من نشرها. والثمن أن إصلاحًا أمنيًا حقيقيًا يُحجب أيضًا طوال تلك المدة، ما لم تُدرج الحزمة تحت المفتاح ignore الخاص بفترة الانتظار أو تمرر --no-cooldown في تشغيل واحد. فإن فعّلتها فحدد مسبقًا كيف ستطبق الإصلاحات العاجلة.

اجعله تلقائيًا

• في CI: أضف خطوة تشغّل composer audit --locked. ومع Composer 2.10 وما بعده يخرج الأمر بالرمز 1 عند فشل أي فحص فيتوقف خط التكامل. وراجع السكربتات المكتوبة لإصدارات أقدم إذا كانت تختبر رموز خروج محددة.
• وفق جدول زمني: تُنشر إشعارات جديدة لشيفرة نشرتها بالفعل، ومهمة CI أسبوعية مجدولة، أو مهمة cron على خادم البناء، تشغّل الفحص على ملف القفل الحالي تلتقطها بين الإصدارات.
• على الخوادم: شغّل composer audit --locked في كل مشروع منشور ضمن فحص الترقيع الشهري، بإصدار PHP نفسه الذي يستخدمه الموقع.

أخطاء شائعة

• استخدام Composer قديم من حزم التوزيعة مع افتراض أنه يمنع الإصدارات المعرضة للثغرات.
• تشغيل composer update مباشرة على الإنتاج، فتتغير شيفرة لم يختبرها أحد.
• تجاهل الإشعارات دون سبب أو موعد مراجعة.
• اعتبار نتيجة الفحص النظيفة شهادة سلامة كاملة، فهو لا يعرف إلا الإشعارات المنشورة لحزم Composer.

ما الذي ينبغي فعله

1. افحص composer --version على أجهزة المطورين وفي CI وعلى الخوادم، وانتقل إلى إصدار 2.x حديث حيثما أمكن.
2. شغّل composer audit الآن على كل مشروع، وأصلح كل نتيجة أو وثّقها.
3. أضف composer audit --locked إلى CI وإلى مهمة أسبوعية مجدولة.
4. سجّل أي إشعار متجاهَل تحت config.policy مع سببه وموعد مراجعته.
5. واصل ترقيع PHP ونظام التشغيل بشكل منفصل، فـ Composer لا يغطيهما.

المصادر

• getcomposer.org/doc/03-cli.md#audit
• getcomposer.org/doc/03-cli.md#self-update-selfupdate
• getcomposer.org/doc/03-cli.md#update-u-upgrade
• getcomposer.org/doc/03-cli.md#prohibits-why-not
• getcomposer.org/doc/06-config.md#policy
• getcomposer.org/doc/06-config.md#cooldown
• getcomposer.org/doc/06-config.md#audit
• github.com/composer/composer/blob/main/CHANGELOG.md
• getcomposer.org/download
• packagist.org/apidoc
• qa.debian.org/madison.php?package=composer