# حزم AsyncAPI الخبيثة على npm حملت توقيع provenance سليمًا من خط النشر الرسمي

> **المغزى:** توقيع provenance يثبت أين بُنيت الحزمة وكيف، لا أنها آمنة، والخلط بين السؤالين يجعل التوقيع إشارة ثقة لا يستحقها.

- المصدر: المغزى (https://almaghza.com/a/2026-07-21-asyncapi-npm-signed-malware/)
- التاريخ: 7 صفر - 21 يوليو 2026 (2026-07-21)
- القسم: أمن سيبراني
- الوسوم: npm، هجمات سلسلة التوريد، GitHub، CI/CD، الأمن السيبراني

تعرضت 4 حزم تابعة لمشروع AsyncAPI على npm، في 5 إصدارات، لاختراق في سلسلة التوريد يوم 14 يوليو 2026، بحسب تحليل نشرته Microsoft Security. وتُحمّل هذه الحزم ملايين المرات أسبوعيًا.

والمفاجأة في هذه الحادثة أن النسخ الخبيثة كانت تحمل توقيع provenance سليمًا عبر GitHub OIDC. أي أنها وُقّعت من خط النشر (pipeline) الحقيقي للمشروع، لا من جهة مزورة.

ولم يسرق المهاجم مفتاح توقيع ولم يزوّر توقيعًا. بل استغل إعدادًا في GitHub Actions اسمه pull_request_target، يسمح بتشغيل مهام مرتبطة بطلبات دمج (pull requests) قادمة من خارج المشروع بصلاحيات المشروع الأصلي. ومن خلال ذلك تسرب token خاص بحساب البوت التابع للمشروع.

وبهذا الـ token تمكن المهاجم من إدخال كود خبيث إلى فرع الإصدار. ثم تولى خط النشر الرسمي للمشروع بناء الحزمة ونشرها وتوقيعها بتوقيعه الحقيقي. فكانت النتيجة توقيعًا صحيحًا تمامًا على حزمة خبيثة تمامًا.

ويكشف ذلك الفرق بين سؤالين طالما عومل أحدهما كأنه جواب عن الآخر. فالـ provenance يجيب عن سؤال: أين بُنيت هذه الحزمة وكيف. ولا يجيب عن سؤال: هل هي آمنة. فالتوقيع يثبت مكان البناء، ولا يقول شيئًا عن نية من أدخل الكود قبل البناء.

وبالنسبة للفرق التي تسحب حزم npm يوميًا وتعتمد على التوقيع بوصفه علامة ثقة، تعني الحادثة أن التوقيع دليل على المصدر فقط. أما أمان خط النشر نفسه، بما فيه إعدادات GitHub Actions والصلاحيات الممنوحة للطلبات الخارجية، فيبقى جزءًا من سلسلة الثقة لا يغطيه التوقيع.

## المصادر

- [تحليل Microsoft Security لاختراق AsyncAPI على npm](https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/)