هجوم سلسلة توريد البرمجيات Software Supply Chain Attack لا يحتاج إلى اختراق كل شركة مستهدفة على حدة. يكفي أحيانًا اختراق مكوّن واحد تثق به آلاف المشاريع: حزمة npm، حساب Maintainer، إضافة IDE، GitHub Action، نظام Build أوبيانات اعتماد تستخدمها عملية النشر.
الخطر الحقيقي هو انتقال هذه الثقة. قد يبدأ الحادث من حساب مطور واحد، ثم يصل إلى Package موثوقة، ومنها إلى CI/CD، ثم إلى Credentials أوArtifacts تُنشر في بيئة الإنتاج. ولهذا لا يمكن اختزال Software Supply Chain Security في فحص Dependencies بحثًا عن CVEs فقط.
أحداث 2025 و2026 أكدت ذلك عمليًا. فقد شهدت منظومة GitHub Actions حادثة tj-actions/changed-files، ثم تعرض npm لحملة واسعة مرتبطة بـShai-Hulud، وفي مايو 2026 حذرت CISA من موجة جديدة استهدفت Nx Console ومستودعات GitHub وبيئات التطوير وCI/CD. وفي المقابل، بدأت npm وGitHub خلال 2026 بإضافة ضوابط جديدة تستهدف نقاطًا محددة في سلسلة الهجوم.
ما المقصود بسلسلة توريد البرمجيات؟
البرنامج الذي يصل إلى المستخدم النهائي لا يتكون من الكود الذي كتبه فريقك فقط. بين Source Code وProduction توجد طبقات كثيرة من المكونات والأنظمة والثقة.
- Open-source libraries وDependencies.
- npm وPyPI وغيرها من Package Registries.
- Container images والصور الأساسية.
- GitHub Actions وReusable Workflows.
- Build tools وCompilers.
- CI/CD runners.
- IDE extensions وأدوات المطورين.
- Artifact repositories.
- حسابات Maintainers والمطورين.
- Signing keys وPublishing credentials.
- Cloud deployment identities.
كل نقطة من هذه النقاط تمثل Trust Boundary. عندما تقول عملية البناء: «استخدم هذه الحزمة» أو«نفّذ هذا الـAction» أو«اقبل هذا الـArtifact لأنه موقّع»، فهي تتخذ قرار ثقة يمكن أن يصبح مسارًا للهجوم إذا تعرض المصدر الموثوق نفسه للاختراق.
هجوم Supply Chain ليس هو نفسه وجود Vulnerability في Dependency
من المهم الفصل بين المفهومين. قد تحتوي مكتبة شرعية على ثغرة أمنية بسبب خطأ برمجي، وهذا لا يعني تلقائيًا أن سلسلة التوريد تعرضت للاختراق.
في Supply Chain compromise يحدث تلاعب أوإساءة استخدام لمسار التطوير أوالبناء أوالتوزيع نفسه؛ مثل السيطرة على حساب Maintainer ونشر إصدار خبيث، أوتعديل GitHub Action موثوقة، أوالوصول إلى Signing Key، أوإدخال كود ضار في Artifact قبل توزيعه.
يمكن أن ينتج النوعان خطرًا على التطبيقات downstream، لكن طريقة الكشف والاستجابة مختلفة. معالجة CVE قد تتطلب تحديث Dependency، بينما حادث Supply Chain قد يستلزم التحقيق في Builds السابقة وتدوير Credentials وفحص Artifacts نُشرت بالفعل.
كيف تنتقل الثقة المخترقة إلى الإنتاج؟
1. حزمة خبيثة أوإصدار تم اختراقه
أبسط سيناريو هو نشر Package خبيثة باسم جديد أوباسم يشبه مكتبة معروفة عبر Typosquatting. لكن السيناريو الأكثر خطورة هو اختراق الحزمة الأصلية نفسها.
إذا استطاع المهاجم السيطرة على حساب يملك صلاحية Publish، فقد يظهر الإصدار الخبيث للمطورين وكأنه Release طبيعي من المشروع الذي يستخدمونه منذ سنوات.
وعندما تعتمد المشاريع على تحديثات تلقائية أوVersion ranges واسعة، يمكن أن ينتقل الإصدار الجديد بسرعة إلى عدد كبير من البيئات قبل اكتشاف المشكلة.
2. اختراق حساب Maintainer
حساب Maintainer قد يكون أهم من خادم التطبيق نفسه؛ لأنه يملك أحيانًا القدرة على تعديل المستودع، إنشاء Releases، إدارة Secrets أوالنشر إلى Package Registry.
لهذا تبدأ بعض الحملات بالتصيد أوالاستيلاء على Sessions وCredentials بدل البحث عن ثغرة تقنية في البرنامج. وبعد السيطرة على هوية موثوقة، تصبح الأنشطة الضارة أقرب في شكلها إلى العمليات الطبيعية للمشروع.
3. GitHub Actions وCI/CD
بيئة CI/CD حساسة لأنها تجمع الكود مع الأتمتة والصلاحيات. وقد تحتوي Workflow واحدة على إمكانية الوصول إلى:
- Repository tokens.
- Cloud credentials.
- Package publishing permissions.
- Container registries.
- Signing systems.
- Deployment environments.
إذا نفذت Pipeline مكوّنًا خارجيًا مخترقًا في سياق يملك هذه الصلاحيات، قد يتحول اختراق Dependency صغيرة إلى تسريب Secrets أوتعديل Artifact أوالوصول إلى مرحلة النشر.
ماذا علمتنا حادثة tj-actions/changed-files؟
في مارس 2025 أصدرت CISA تنبيهًا عن اختراق tj-actions/changed-files، وهي GitHub Action كانت مستخدمة داخل عدد كبير من Workflows.
تكمن أهمية الحادثة في أن Action خارجية لا تعمل بمعزل عن المشروع. إنها تعمل داخل Runner، وبالتالي يتحدد أثر اختراقها بما يستطيع ذلك Workflow الوصول إليه.
الدرس ليس «تجنب GitHub Actions»، بل التعامل مع الكود الذي تنفذه داخل Pipeline باعتباره جزءًا من Trusted Computing Base الخاص بعملية البناء.
Shai-Hulud وهجمات npm في سبتمبر 2025
في سبتمبر 2025 نشرت CISA تنبيهًا عن Supply Chain compromise واسعة داخل npm ecosystem مرتبطة بحملة Shai-Hulud.
الحملة أبرزت خصوصًا قيمة Credentials الخاصة بالمطورين والنشر. فالوصول إلى Package واحدة لا يكون دائمًا الهدف النهائي؛ يمكن استخدام البيانات المسروقة لمحاولة الوصول إلى مشاريع وحسابات وحزم أخرى، ما يسمح للهجوم بالانتشار عبر علاقات الثقة الموجودة أصلًا في المنظومة.
لماذا بقي الخطر حاضرًا في 2026؟
في 28 مايو 2026 حذرت CISA من عدة حملات Supply Chain استهدفت Nx Console ومستودعات GitHub وبيئات المطورين وCI/CD.
ومن أبرز الحالات إصدار Nx Console الخبيث 18.95.0 الذي نُشر في مايو 2026، والمسجل باسم CVE-2026-48027 لدى NVD.
هذه الحالات توسّع مفهوم Software Supply Chain. لم تعد Package Registry هي النقطة الوحيدة التي يجب مراقبتها؛ إضافة VS Code، جهاز المطور، Workflow، حساب GitHub أوأداة Build يمكن أن يصبح نقطة البداية.
ما الذي تغير في npm وGitHub خلال 2026؟
بعد سلسلة الحملات التي استهدفت المنظومة، نشرت GitHub في يوليو 2026 تفصيلًا للضوابط الجديدة المضافة إلى npm وGitHub Actions. الأهم أن هذه التغييرات لا تعتمد على آلية دفاع واحدة، بل تحاول قطع سلسلة الهجوم في مراحل مختلفة.
فترة انتظار لتحديثات Dependabot
منذ يوليو 2026 أصبحت Version Updates في Dependabot تخضع افتراضيًا لفترة Cooldown مدتها ثلاثة أيام قبل فتح Pull Request للإصدار الجديد. الهدف هو تقليل احتمال وصول Release خبيثة فور صدورها إلى المشاريع downstream قبل ظهور إشارات تحذيرية عنها.
هذا التأخير لا يطبق على Security Updates؛ إذ تستمر تحديثات الإصلاح الأمني في الوصول مباشرة.
Staged Publishing في npm
أضاف npm أيضًا Staged Publishing، حيث يمكن لعملية CI تجهيز Release دون جعلها عامة فورًا، ثم يحتاج Maintainer إلى مراجعتها والموافقة عليها باستخدام 2FA.
الفكرة المهمة هنا هي فصل القدرة على تشغيل Automation عن القدرة النهائية على نشر Package للعالم.
تقليل مخاطر Install Scripts
أعلنت GitHub كذلك أن npm v12 يتجه إلى تعطيل Install Scripts افتراضيًا مع إمكانية السماح بها بصورة صريحة عند الحاجة. Install-time execution كان مفيدًا للمهاجمين لأنه يسمح بتنفيذ الكود أثناء تثبيت Dependency بدل انتظار استخدام التطبيق للحزمة لاحقًا.
لكن هذا التغيير لا يعني أن كل Install Script ضارة؛ فكثير من المشاريع الشرعية تعتمد عليها. الهدف هو الانتقال من التنفيذ الضمني إلى قرار أكثر وضوحًا بشأن ما يسمح له بالتنفيذ أثناء التثبيت.
Dependency Pinning: مهم لكنه ليس دفاعًا كاملًا
Lock files وPinned versions تجعل عملية البناء أكثر قابلية للتكرار والتدقيق، وتقلل احتمال أن يتغير Dependency دون أن يتغير الكود الموجود في Repository.
لكن Pinning لا يثبت أن الإصدار نفسه آمن. إذا ثبّت المشروع Version ثم اتضح أن هذه النسخة كانت مخترقة، سيواصل Pinning استخدام الإصدار السيئ إلى أن يتم تغييره.
لذلك يجب أن يعمل Pinning مع Dependency Review وVulnerability Intelligence ومراجعة التحديثات وليس بدلًا منها.
GitHub Actions تحتاج Pinning أكثر صرامة
توصي وثائق GitHub الأمنية بتثبيت Third-party Actions إلى full-length commit SHA. وتصف GitHub هذه الطريقة بأنها الوسيلة الحالية لاستخدام Action كمرجع Release غير قابل للتغيير.
الاعتماد على Tag مثل @v4 أكثر راحة، لكنه يعني أن المشروع يثق أيضًا في قدرة الجهة المالكة للمستودع على إدارة ذلك Tag بأمان.
أخرج Long-lived Secrets من CI/CD قدر الإمكان
وجود Cloud Key ثابت أوnpm token طويل العمر داخل CI يجعل سرقته ذات قيمة كبيرة حتى بعد انتهاء Workflow التي سربته.
عندما يدعم مزود الخدمة Federation، يمكن استخدام OIDC للحصول على Credentials قصيرة العمر ومقيدة بسياق محدد بدل تخزين مفتاح ثابت.
توضح وثائق GitHub الخاصة بـOIDC أن GitHub Actions يمكنها تبادل هوية Workflow مع Cloud Provider للحصول على Access Token قصير العمر دون الاحتفاظ بـCloud credentials طويلة العمر كـGitHub Secrets.
وينطبق المبدأ نفسه على نشر Packages. توفر npm Trusted Publishing علاقة ثقة تعتمد على OIDC بين Package وCI/CD Provider، فتستطيع عملية النشر الحصول على Credential مؤقت بدل الاحتفاظ بـnpm publishing token ثابت داخل Pipeline.
اعتبارًا من 2026 تدعم npm Trusted Publishing مع GitHub Actions وGitLab CI/CD وCircleCI وفق التوثيق الرسمي، مع وجود قيود تختلف حسب نوع Runner وطريقة النشر.
Least Privilege داخل Workflow
إزالة Secrets طويلة العمر لا تكفي إذا كانت Workflow نفسها تملك صلاحيات أوسع من مهمتها.
ينبغي مراجعة كل Job وسؤال بسيط:
- هل يحتاج فعلًا إلى
contents: write؟ - هل يحتاج الوصول إلى Production environment؟
- هل يحتاج Publishing permission؟
- هل يحتاج
id-token: write؟ - هل يجب أن تصل إليه جميع Repository Secrets؟
Workflow تبني Documentation لا تحتاج عادة صلاحيات نشر Production. كل Permission تتم إزالتها تقلل ما يستطيع المهاجم فعله حتى لو نجح في تنفيذ كود داخل Runner.
SBOM: اعرف ماذا يوجد داخل البرنامج
Software Bill of Materials هي قائمة منظمة بالمكونات التي يتكون منها البرنامج وعلاقاتها. فائدتها الأساسية هي الرؤية: إذا ظهر خطر في Component محددة، تستطيع المؤسسة تحديد المنتجات والـBuilds التي تحتوي عليها بدل البحث اليدوي في عشرات المشاريع.
في 29 يوليو 2026 أصدرت CISA وNSA وFBI وشركاء دوليون نسخة محدثة من Minimum Elements for a Software Bill of Materials لعام 2026، لتحل محل خط الأساس الذي نشرته NTIA في 2021.
التحديث أضاف ووسع معلومات تساعد على تقييم أصل SBOM والمكونات، بما في ذلك بيانات مثل SBOM Author Signature وSBOM Version وComponent Hash Value.
لكن SBOM لا تمنع الهجوم
SBOM لا تمنع التصيد ضد Maintainer، ولا توقف Credential theft، ولا تثبت أن Release سليمة. هي أداة Visibility وإدارة مخاطر.
قيمتها تظهر عندما تندمج مع سياسات Dependency، والفحص، والمراقبة، وProvenance، والتحكم في عمليات Build والنشر.
ما الفرق بين Signing وProvenance؟
التوقيع الرقمي يمكن أن يساعدك على التحقق من أن Artifact جاءت من المفتاح المتوقع ولم تتغير بعد توقيعها وفق نموذج التحقق المستخدم. لكنه لا يثبت تلقائيًا أن محتوى Artifact حميد.
إذا أدخل المهاجم كودًا ضارًا قبل مرحلة Signing، يمكن أن يتم توقيع Artifact الخبيثة بالطريقة الطبيعية. وإذا سُرق Signing Key نفسه، تنهار الثقة الموضوعة في ذلك المفتاح.
أما Provenance فتركز على تقديم معلومات قابلة للتحقق عن كيفية إنتاج Artifact ومصدرها وBuild process المرتبطة بها.
يعرّف SLSA 1.2 مستويات متدرجة لحماية Build Provenance وعملية البناء، بدءًا من وجود Provenance وصولًا إلى Build platforms أكثر صلابة وعزلًا.
وتحذر وثائق npm نفسها من اعتبار Provenance ضمانًا بأن Package خالية من الكود الخبيث. فائدتها أنها تجعل أصل الحزمة وعملية بنائها أكثر قابلية للتحقق والتدقيق.
Developer Workstations جزء من Supply Chain
المطور الذي يستطيع تعديل Source أوPublish Package أوالوصول إلى Production هو جزء من سلسلة التوريد حتى لو لم يكن جهازه Server.
إذا سُرقت Session من Browser أواخترقت IDE extension أوجهاز يمتلك SSH keys وPackage credentials، يستطيع المهاجم تجاوز بعض الضوابط الموجودة في الأنظمة المركزية.
لذلك يجب أن تشمل الحماية:
- Phishing-resistant MFA أوPasskeys للحسابات الحساسة.
- Endpoint Detection and Response عند ملاءمته للبيئة.
- تحديث IDE وExtensions ومراجعة مصادرها.
- Password manager وحماية Sessions.
- فصل حسابات الإدارة والنشر عن الاستخدام اليومي.
- تقليل عدد الأشخاص الذين يملكون Publish وRelease permissions.
هذه الضوابط جزء من مبدأ الدفاع متعدد الطبقات وأفضل ممارسات الأمن السيبراني، لكن أهميتها في Supply Chain ترتفع لأن هوية المطور قد تمنح وصولًا مباشرًا إلى قنوات التوزيع.
كيف تراقب Software Supply Chain؟
لا توجد إشارة واحدة تكشف جميع الهجمات. الأفضل بناء Baseline للسلوك الطبيعي ثم مراقبة الانحرافات في Source وBuild وRelease.
- إضافة Dependency جديدة دون Review متوقع.
- تغيير غير معتاد في Maintainers أوPublishing permissions.
- Release صدر في توقيت أوطريقة غير مألوفة.
- GitHub Action جديدة أوتغيير مرجع Action مستخدمة.
- توسيع Workflow permissions دون حاجة واضحة.
- اتصالات Network غير متوقعة أثناء Build أوInstall.
- ظهور Secrets أوTokens داخل Logs.
- تعديل ملفات Workflow خارج عملية المراجعة المعتادة.
- Package أوArtifact لا تتطابق Digest الخاصة بها مع القيمة المتوقعة.
- تغيير في Signing أوProvenance metadata.
ماذا تفعل إذا اكتشفت Dependency أوBuild مخترقة؟
حذف Package من package.json أوالرجوع إلى إصدار سابق خطوة احتواء فقط، وليست نهاية التحقيق.
- حدد أول ظهور: متى دخل المكوّن أوالتغيير الخبيث إلى Repository أوPipeline؟
- حدد Builds المتأثرة: لا تفترض أن آخر Build هي الوحيدة التي استخدمته.
- حدد Execution Context: ما الصلاحيات وSecrets التي كانت متاحة وقت التنفيذ؟
- راجع Logs: ابحث عن اتصالات خارجية أوأوامر أوعمليات نشر غير معتادة.
- ألغِ Credentials المعرّضة: لا تنتظر إثبات استخدامها إذا كان لديك دليل أنها أصبحت مكشوفة.
- افحص Artifacts: هل تم نشر Binary أوContainer أوPackage بنيت خلال فترة الاختراق؟
- حدد الوصول downstream: هل وصلت Artifacts إلى Production أوالعملاء؟
- أعد البناء من بيئة موثوقة: بعد تنظيف Source وDependencies وPipeline.
- احتفظ بالأدلة: Logs وCommit history وArtifacts مهمة لفهم Root Cause ونطاق الحادث.
طبقات الدفاع الأكثر أهمية
| الطبقة | الخطر الذي تقلله | أمثلة للضوابط |
|---|---|---|
| Dependencies | Release خبيثة أوتغيير غير متوقع | Lock files، Review، Cooldown، Allowlisting |
| Maintainer Identity | Account takeover | Passkeys، MFA، تقليل Publish permissions |
| GitHub Actions | Third-party workflow compromise | Full commit SHA، Least Privilege، مراجعة الكود |
| CI/CD Credentials | سرقة Tokens طويلة العمر | OIDC، Short-lived credentials، Secret minimization |
| Publishing | استخدام Credential مسروقة لنشر Release | Trusted Publishing، Staged Publishing، 2FA |
| Build Integrity | تعديل Artifact أثناء عملية البناء | Isolated builds، Provenance، SLSA |
| Inventory | عدم معرفة المنتجات المتأثرة | SBOM وAsset inventory |
| Developer Endpoint | سرقة Sessions ومفاتيح النشر | EDR، تحديثات، MFA، Least Privilege |
ابدأ من NIST SSDF بدل جمع أدوات منفصلة
المؤسسة التي تريد بناء برنامج Software Supply Chain Security مستدام تحتاج إلى إدخال الضوابط في دورة تطوير البرمجيات نفسها بدل شراء Scanner لكل مشكلة.
يوفر NIST Secure Software Development Framework — SP 800-218 مجموعة ممارسات يمكن دمجها في SDLC لتقليل الثغرات ومعالجة أسبابها وتحسين طريقة تطوير البرمجيات وتأمينها.
عمليًا، يمكن الجمع بين SSDF كإطار للعمل، وSLSA لسلامة Build وProvenance، وSBOM للرؤية، وضوابط المنصة مثل OIDC وPinning وStaged Publishing. لا يحل أي واحد منها محل الآخرين.
الخلاصة
هجمات سلسلة توريد البرمجيات خطيرة لأنها تستغل الثقة القابلة للانتقال. Package يثق بها المطور تدخل إلى Build؛ والـBuild يملك Credentials؛ وهذه Credentials تستطيع النشر؛ والـArtifact الناتجة يثق بها Production أوالعملاء.
الحماية الفعالة تعني كسر هذه السلسلة في أكثر من نقطة: اعرف Dependencies التي تستخدمها، ثبّت المراجع الحساسة، راجع GitHub Actions، أزل Long-lived credentials من CI/CD، استخدم OIDC وTrusted Publishing حيثما أمكن، طبّق Least Privilege، احتفظ بـSBOM، تحقق من Provenance، واحمِ حسابات وأجهزة الأشخاص الذين يستطيعون تغيير ما يصل إلى المستخدم النهائي.
والقاعدة الأهم: Artifact الموقعة ليست بالضرورة آمنة، وPackage ذات Provenance ليست بالضرورة حميدة، وDependency المثبتة ليست بالضرورة سليمة. هذه التقنيات تزيد القدرة على التحقق والمراقبة، لكن Software Supply Chain Security تظل منظومة دفاع متعددة الطبقات من Source إلى Production.