هل Go أكثر أمانًا من Node.js في مواجهة هجمات سلسلة التوريد؟

معظم هجمات سلسلة التوريد الكبيرة في العامين الأخيرين عملت بالطريقة نفسها. شغّل مطور الأمر npm install، فنفّذت اعتمادية لم يخترها أصلًا كودًا على جهازه قبل أن يكتب سطرًا واحدًا. تسمح npm بذلك بحكم تصميمها، وهي الآن تتراجع عن هذا القرار. أما Go فلم تسمح به يومًا. يتناول هذا المقال حجم ما يفسره هذا الفرق الواحد، والمواضع التي تكون فيها Go أكثر أمانًا حقًا، والمواضع التي تواجه فيها المخاطر نفسها التي يواجهها Node. ولكل ادعاء في هذا المقال مصدر.

الخلاصة

أمن سلسلة التوريد: Go مقابل Node.js في نظرة سريعة

تتقدم Go في السلوك الافتراضي وفي مساحة الهجوم. لكن المهاجم المصمم الذي ينجح في تصيّد مشرف بشري يستطيع العبور في كلتا المنظومتين.

لماذا تتجنب Go الهجوم الذي يضرب npm أكثر من غيره؟

لا توجد في Go سكربتات تثبيت. عندما تشغّل npm install، يمكن لكل حزمة في شجرة الاعتماديات المتعدية أن تسجل خطافات دورة حياة (preinstall و install و postinstall). وتشغّلها npm تلقائيًا بصلاحيات مستخدمك، قبل أن تشغّل أو حتى تقرأ سطرًا واحدًا (توثيق سكربتات npm). وقد وصفت GitHub سكربتات التثبيت بأنها أكبر مساحة منفردة لتنفيذ الكود في منظومة npm (GitHub Security, 2025).

استبعدت Go هذا عن قصد. لا توجد فيها خطافات بناء. يجلب go get الكود المصدري ويتحقق منه، ويترجمه go build، ولا يشغّل أي منهما سكربتات تحددها الحزمة. تبقى الاعتمادية المسمومة في Go مجرد كود مصدري حتى يستوردها كودك و يستدعي الدالة الخبيثة. هذه نافذة أضيق بكثير وأسهل كشفًا من كود يعمل لدى الجميع مع كل تثبيت.

إليك ما يفعله كل أمر:

example.bashbash
# npm: the postinstall hook runs on every install, automatically
$ npm install left-pad
> [email protected] postinstall
> node ./scripts/setup.js   # <- arbitrary code, your privileges, right now

# go: nothing in the package gets to run during fetch or build
$ go get example.com/some/module
go: downloaded example.com/some/module v1.0.0   # source fetched, checksum verified, nothing executed

هذا الفرق هو سبب منع npm v12، الذي يصدر في يوليو 2026، لسكربتات التثبيت افتراضيًا، وسبب قيام pnpm بالشيء نفسه في الإصدار v10 (توثيق سكربتات npm). أدوات JavaScript تتجه نحو السلوك الذي كان في Go منذ إطلاقها.

ما حجم مشكلة سلسلة التوريد في npm بالأرقام؟

npm هي الهدف الأكبر بفارق كبير. حددت Sonatype 454,648 حزمة ضارة جديدة في 2025، ما رفع إجمالي ما حجبته تراكميًا إلى ما يتجاوز 1.23 مليون، بزيادة 75% على أساس سنوي. وكان أكثر من 99% من هذه البرمجيات الخبيثة في المصادر المفتوحة على npm (Sonatype 11th State of the Software Supply Chain, 2026). وقدّر مؤشرها للبرمجيات الخبيثة في الربع الرابع من 2025 النسبة بـ 99.8% من البرمجيات الخبيثة المحجوبة في ذلك الربع.

لا يوجد أي عدد منشور للوحدات الضارة في Go. لا تتابع Sonatype ولا OpenSSF ولا معظم المزودين Go كمنظومة مستقلة في مؤشرات البرمجيات الخبيثة، لأن الحوادث أقل من أن تُفهرس. وهذه الفجوة في البيانات تقول الكثير بحد ذاتها.

أين كانت البرمجيات الخبيثة في المصادر المفتوحة عام 2025 (نصيب كل منظومة من الحزم الضارة الجديدة):

*حُددت 454,648 حزمة ضارة جديدة في 2025. ولا تُتابع Go كمنظومة مستقلة، لأن حوادثها أقل من أن تُفهرس. المصدر: Sonatype 11th State of the Software Supply Chain, 2026.

ما الذي حدث فعلًا في موجة ديدان npm خلال 2025 و2026؟

سلسلة من الديدان ذاتية الانتشار حولت خطرًا معروفًا إلى حالة طوارئ دائمة، وكل واحدة منها استخدمت سكربتات التثبيت. عرفت npm حوادث بارزة منذ سنوات. في 2018، أخفى event-stream سارق محافظ Bitcoin داخل اعتمادية نُزّلت نحو 8 ملايين مرة. وفي 2021، شحن ua-parser-js برمجيات تعدين خفية بعد الاستيلاء على حساب. لكن 2025 هو العام الذي بدأت فيه الحوادث تتوالى واحدة تلو الأخرى.

بدأ اختراق qix في سبتمبر 2025 برسالة مقنعة لإعادة تعيين المصادقة الثنائية من النطاق المنتحل npmjs.help. استولى المهاجم على حساب المشرف Josh Junon ونشر إصدارات خبيثة من 18 حزمة. ومن بينها chalk (نحو 300 مليون تنزيل أسبوعيًا) و debug (نحو 358 مليونًا)، أي تعرّض مجتمع يتجاوز 2.6 مليار تنزيل أسبوعيًا. وكانت الحِمولة أداة crypto-clipper تعمل في جانب المتصفح، وبقيت نشطة نحو ساعتين.

وبعد أيام جاءت Shai-Hulud، أول دودة حقيقية في npm. عند التثبيت، جمع ملف bundle.js الخاص بها بيانات اعتماد npm و GitHub و AWS و GCP، وشغّل TruffleHog لاستخراج الأسرار. ثم استخدم رموز npm المسروقة ليحقن نفسه في ما يصل إلى نحو 100 حزمة إضافية يملكها كل ضحية. وأصدرت CISA تنبيهًا بشأنها (CISA, 2025). وتنسب Sonatype 171,740 حزمة ضارة إلى حملات npm ذاتية التكرار خلال بضعة أشهر.

نقلت Shai-Hulud 2.0 (24 نوفمبر 2025) التنفيذ إلى preinstall للوصول إلى أجهزة أكثر. وثبّتت بيئة تشغيل Bun للالتفاف على المراقبة المعتمدة على Node، وأضافت مسارًا بديلًا مدمرًا قادرًا على محو مجلد المستخدم. ووجدت Wiz حزمًا مصابة في نحو 27% من بيئات السحابة التي فحصتها (Wiz, 2025).

في 2026 اتضح أن منع سكربتات التثبيت لن يكفي وحده. لم يبدأ اختراق axios (31 مارس 2026) بكلمة مرور مسروقة بالتصيّد. استهدفت جهات مرتبطة بكوريا الشمالية (تُتابع باسم UNC1069 / Sapphire Sleet) المشرف الرئيسي عبر شركة وهمية، ومساحة عمل Slack تحمل هوية بصرية، ومكالمة Teams زرعت RAT على جهاز المشرف. ثم نشروا إصدارات خبيثة من axios (أكثر من 100 مليون تنزيل أسبوعيًا) تحمل RAT في postinstall. ورصدت StepSecurity اتصال C2 غير طبيعي في أكثر من 12,000 مشروع (StepSecurity, 2026). ثم التفت Miasma (يونيو 2026) على منع npm القادم لسكربتات التثبيت بتقنية «Phantom Gyp». تشحن الحزمة ملف binding.gyp، فتشغّل إعادة البناء الضمنية عبر node-gyp في npm الحِمولة دون أي سكربت معلن.

هل Go حل سحري إذن؟ ليس تمامًا

توقف إعدادات Go الافتراضية صنفًا كاملًا من الهجمات، لكن المهاجمين استهدفوا Go في بضع مرات رغم ذلك. عدد وحدات Go الضارة الموثقة في 2025 لا يتجاوز عشرات قليلة موزعة على حملات معدودة. وهذا رقم ضئيل مقابل مئات الآلاف في npm. والحالة الأبرز تستحق أن نمر عليها، لأنها تبين حجم العمل الذي يلزم المهاجم ليتجاوز تصميم Go.

كُشف الباب الخلفي في boltdb-go/bolt في فبراير 2025، لكنه زُرع في نوفمبر 2021. انتحل اسمًا مشابهًا لوحدة BoltDB الشهيرة (github.com/boltdb/bolt)، التي تعتمد عليها آلاف الحزم واستُخدمت في Shopify و Heroku، وحمل بابًا خلفيًا للتحكم والسيطرة. نشر المهاجم الإصدار الخبيث v1.3.1، وترك Go Module Mirror يخزنه، ثم أعاد كتابة وسم Git ليشير إلى كود نظيف. فمن راجع المستودع على GitHub رأى كودًا نظيفًا، بينما استمر الوسيط في تقديم الباب الخلفي. نجح الأمر، لكن فقط باستغلال حالة حدّية في نظام التخزين المؤقت. أما في npm فكان خطاف وقت التثبيت سيؤدي المهمة دون أي جهد من هذا النوع (Socket, 2025).

وظهرت حملات أخرى قليلة في 2025. في مارس جاءت موجة من انتحالات أسماء hypert و layout تحمل برمجيات محمّلة موجهة إلى مطوري القطاع المالي. وظهرت أيضًا بعض الوحدات الماسحة للأقراص وسارق لبيانات اعتماد SSH. كانت كلها معزولة، واحتاجت كل واحدة منها إلى مطور يكتب مسار استيراد خاطئ. ولم يعمل أي منها تلقائيًا.

عند الإبلاغ عن وحدة ضارة، يزيلها فريق أمن Go من الوسيط، الذي يعيد بعدها 403 SECURITY ERROR، ويضيفها إلى قاعدة بيانات ثغرات Go. في حالة boltdb-go، أزالت Google الوحدة من الوسيط ومن GitHub، وسجلتها في قاعدة بيانات الثغرات. وأشارت أيضًا إلى عمل جار على تحليل القدرات عبر Capslock وعلى المقارنات مع deps.dev. تجعل دفاعات Go الهجمات أعلى كلفة بكثير، لكنها لا تضمن الأمان، ولا تضمنه دفاعات أي منظومة أخرى.

ما الذي يجعل Go أكثر أمانًا من حيث البنية؟

إلى جانب غياب سكربتات التثبيت، تتخذ Go أربعة قرارات تصميمية أخرى تزيد هذه الأفضلية.

قاعدة بيانات المجاميع الاختبارية في Go قوية على نحو غير معتاد. يسجل ملف go.sum تجزئات SHA-256 لكل اعتمادية. و sum.golang.org سجل شفافية مبني على شجرة Merkle على طريقة Certificate Transparency. يسجل تجزئة كل إصدار وحدة في أول مرة يجلبها فيها أي شخص، ويحفظها إلى الأبد (مرجع وحدات Go). ويتحقق الأمر go من أدلة الإدراج والاتساق قبل أن يثق بأي كود، لذلك يفشل بصوت مسموع أي وسم Git مدفوع بالقوة أو أي وسيط يتلاعب بالكود. ويرى عالم التشفير Filippo Valsorda، الذي قاد فريق أمن Go في Google، أن Go تملك أفضل سجل لسلامة الحزم بين منظومات اللغات كلها، لأن كل عميل في العالم يحوّل إصدار وحدة معينًا إلى البايتات نفسها، إلى الأبد (Filippo Valsorda). وللسجل حد واحد. فهو يثبت الاتساق لا أن الكود سليم، ولا يفيد إلا إذا راقبه أحد.

اختيار أدنى إصدار يبطئ انتشار الإصدارات السيئة. تستخدم عمليات البناء في Go أدنى إصدار يلبي جميع المتطلبات، والترقيات صريحة (مرجع Minimal Version Selection). ومع نطاقات ^ و ~ في npm، قد ينتهي ترقيع خبيث نُشر قبل قليل داخل عملية بناء تلقائيًا. في Go، لا ينتشر إصدار جديد سيئ إلى المشاريع التابعة حتى يرفع شخص المتطلب بشكل متعمد. وقد اعتمدت دودتا qix و Shai-Hulud على سلوك الترقية التلقائية نفسه الذي لا يقوم به Minimal Version Selection.

يستخدم govulncheck تحليل قابلية الوصول ليقلل الإنذارات الكاذبة. يفحص الماسح الرسمي في Go قاعدة بيانات الثغرات المنسقة على vuln.go.dev ولا ينبهك إلا عندما يستدعي كودك فعلًا الرمز المصاب بالثغرة (govulncheck، مدونة Go). أما npm audit فيرفع علمًا على كل إصدار مصاب في أي موضع من الشجرة، سواء وصلت إليه أم لا، فيتعلم المطورون تجاهله.

لا يوجد حساب مركزي يكشف الاستيلاء عليه محفظة حزم كاملة. تُعرّف وحدات Go بعنوان URL لمصدرها، لذلك تعتمد على أمان الحسابات في GitHub (أو GitLab). أما في npm، فحساب واحد مُستولى عليه يكشف كل ما يملكه ذلك المشرف. وهذا الفرق جزء من سبب انتشار ديدان npm بالطريقة التي تنتشر بها، بينما تبقى حوادث Go محصورة.

وتساعد المكتبة القياسية الأكبر أيضًا. تأتي HTTP و JSON والتشفير والقوالب كلها مع Go، لذلك يملك المشروع النموذجي اعتماديات مباشرة أقل ومشرفين أقل عليه أن يثق بهم. صحيح أن دراسة من 2025 وجدت أن معامل تضخيم الاعتماديات في Go (نحو 4.48 ضعفًا) قريب من نظيره في npm (نحو 4.32 ضعفًا)، أي أن حزمة Go الواحدة لا تجلب اعتماديات متعدية أقل من حزمة npm. لكن Go تتقدم لأن المشاريع تبدأ باعتماديات مباشرة أقل، فتبقى مجموعة الأشخاص الذين تثق بهم أصغر.

ما لا تغطيه إعدادات Go الافتراضية

تغلق Go أكبر الأبواب تلقائيًا. أما المخاطر التالية فتنطبق على كل منظومة، ومنها Go، لذلك عليك أن تغطيها بنفسك.

• المشرف المُتصيَّد يستطيع تجاوز دفاعات أي منظومة. إذا استُولي على حساب GitHub لمشرف، يستطيع المهاجم وسم إصدار خبيث، وستسجله قاعدة بيانات المجاميع الاختبارية بأمانة لأنها لا تميز الكود الجيد من السيئ. والهجوم على طريقة axios ينجح ضد كل منظومة، ولهذا تتجه الصناعة إلى المفاتيح العتادية والنشر الموثوق.
• ما زلت تختار اعتمادياتك بالاسم. يمنع التحقق من المجاميع الاختبارية في Go التلاعب بوحدة اخترتها، لكنه لا يمنعك من اختيار اسم منتحل. تحقق من مسار الاستيراد مقابل المستودع الرسمي قبل أن تضيف أي اعتمادية.
• ثبات الوسيط ميزة في معظم الأحوال. التخزين المؤقت الذي يضمن حصول كل عملية بناء على البايتات ذاتها هو أيضًا ما أبقى الباب الخلفي في boltdb-go قابلًا للوصول بعد تنظيف وسم Git. كانت تلك حالة نادرة، ويغطيها إجراء الإزالة عند فريق Go وقاعدة بيانات الثغرات.
• الإعدادات الافتراضية تحمي وقت التثبيت لا وقت التشغيل. أفضلية Go أنه لا يعمل شيء أثناء الجلب أو البناء. لكن بمجرد أن تستورد اعتمادية وتستدعيها، فإنها تعمل بصلاحياتك كما في أي لغة أخرى. وعزل الكود غير الموثوق وقت التشغيل مشكلة منفصلة في كل منظومة.
• أبقِ الحماية مفعّلة. الخطأ الوحيد الذي يصنعه المطور بنفسه هو ضبط GOSUMDB=off على نطاق واسع، فهذا يعطل التحقق من المجاميع الاختبارية الموصوف أعلاه. اتركه مفعّلًا، واقصر GOPRIVATE على المسارات الداخلية الحقيقية فقط.

كيف تتقارب المنظومتان نحو الحلول نفسها؟

تتبنى المنظومتان الدفاعات نفسها، لأن نقطة الضعف في كلتيهما هي الناس. بعد موجة 2025، أعلنت GitHub مصادقة ثنائية إلزامية عبر FIDO/WebAuthn، ورموزًا دقيقة الصلاحيات قصيرة العمر، وإيقاف الرموز الكلاسيكية القديمة. وهي تدفع أيضًا نحو النشر الموثوق عبر OIDC لإثبات منشأ البناء تشفيريًا (GitHub Security, 2025). ويمنع الإصدار npm v12 (يوليو 2026) سكربتات التثبيت افتراضيًا ويضيف فترة تهدئة min-release-age، فلا تصلك حزمة بقيت نشطة ساعتين فقط.

هذه التغييرات تساعد. لكن axios أظهرت أين تتوقف عن العمل. لا توجد سياسة رموز توقف مشرفًا يعمل على حاسبه المحمول RAT. وحدها مفاتيح FIDO2 العتادية مع تثبيت مُتحقق من منشئه ومقيد بفترة تهدئة كانت ستوقف ذلك. ويتعلم المجتمعان أن المهاجمين يستهدفون المشرف أكثر من الأدوات. وما زالت Go تتقدم هنا. فحتى عندما يُخترق مشرف، يكون الضرر أقل، لأن لا شيء يعمل عند التثبيت.

ما الذي يجب أن تفعله الآن؟

تعتمد الخطوات على المنظومة التقنية التي تعمل بها.

إذا كنت تكتب Go:

1. لا تضبط GOSUMDB=off ولا GONOSUMCHECK على نطاق واسع أبدًا. واقصر GOPRIVATE بدقة على المسارات الداخلية الحقيقية.
2. أضف go.sum إلى المستودع وابنِ باستخدام -mod=readonly.
3. شغّل govulncheck ./... في CI كبوابة تراعي قابلية الوصول.
4. افحص الاعتماديات الجديدة بحثًا عن أسماء منتحلة. وتحقق من مسارات الاستيراد مقابل المستودع الرسمي قبل إضافتها.
5. راقب الإصدارات الجديدة لاعتمادياتك الحرجة باستخدام Socket أو deps.dev.

إذا كنت تكتب Node:

1. حدّث إلى npm 11.16.0 أو أحدث واضبط ignore-scripts=true، مع قائمة سماح (مثل @lavamoat/allow-scripts) للحزم القليلة التي تحتاج السكربتات فعلًا.
2. استخدم npm ci مع lockfile مجمّد، وثبّت الإصدارات بدقة، واضبط فترة تهدئة min-release-age من 3 إلى 7 أيام حتى لا تصلك اختراقات تعيش ساعتين.
3. اعتمد النشر الموثوق (OIDC) ومفاتيح FIDO2 العتادية. ولا تعتمد على TOTP في النشر.
4. شغّل تحليلًا حقيقيًا لمكونات البرمجيات (Socket و Snyk) مع كشف سلوكي، لا npm audit وحده.
5. سجّل أسماء حزمك الداخلية علنًا بشكل وقائي لتسد باب التشويش على الاعتماديات.

الأسئلة الشائعة

هل Go أكثر أمانًا فعلًا من Node.js في أمن سلسلة التوريد؟

نعم، على مستوى البنية. السبب الرئيسي أن go get و go build لا يشغّلان أي سكربتات وقت التثبيت، وهذا يزيل ناقل preinstall/postinstall الذي يقف خلف كل دودة npm كبرى تقريبًا في 2025 و2026. وقد ظهر أكثر من 99% من البرمجيات الخبيثة في المصادر المفتوحة عام 2025 على npm (Sonatype, 2026). Go أكثر أمانًا، لكنها ليست محصّنة.

ما أكبر فرق واحد بين أمن Go وأمن npm؟

تنفيذ الكود وقت التثبيت. عند npm install، تشغّل npm تلقائيًا سكربتات حزم عشوائية بصلاحياتك، لكل حزمة في الشجرة. أما Go فلا تملك خطافات بناء على الإطلاق، لذلك لا تفعل الاعتمادية الخبيثة شيئًا حتى يستوردها كودك ويستدعيها. ولهذا يمنع npm v12 الآن سكربتات التثبيت افتراضيًا، وهكذا تتصرف Go دائمًا.

هل تعرضت Go لهجوم على سلسلة التوريد من قبل؟

نعم. انتحل الباب الخلفي في boltdb-go اسمًا مشابهًا لـ BoltDB وقدّم بابًا خلفيًا للوصول عن بعد من مخزن وحدات Go مدة ثلاث سنوات (Socket, 2025). وشحنت حملة hypert/layout في 2025 سبعة أسماء منتحلة على الأقل مع برمجيات محمّلة. هذه الحوادث حقيقية لكنها نادرة، وتُزال الوحدات الضارة من الوسيط بمجرد الإبلاغ عنها.

ما هي قاعدة بيانات المجاميع الاختبارية في Go ولماذا تهم؟

sum.golang.org سجل شفافية مبني على شجرة Merkle. يسجل بشكل دائم تجزئة كل إصدار وحدة في أول مرة يُرى فيها ذلك الإصدار. ويتحقق الأمر go من هذه الأدلة قبل أن يثق بالكود، لذلك يفشل أي تلاعب أو أي وسم Git معاد كتابته بصوت مسموع (مرجع وحدات Go). ويحصل كل عميل على البايتات ذاتها لإصدار معين، وهذا أقوى ضمان سلامة في إدارة الحزم السائدة.

هل يحل منع سكربتات التثبيت في npm المشكلة؟

يساعد كثيرًا، لكنه لا يحل كل شيء. استخدم هجوم axios قناة RAT في postinstall بعد الهندسة الاجتماعية مع المشرف، والتفت حملة Miasma على منع السكربتات عبر إعادة بناء ضمنية بـ node-gyp. منع السكربتات مع مفاتيح FIDO2 العتادية وفترة تهدئة للإصدارات والتحقق من المنشأ يغلق معًا معظم الفجوة. ومع ذلك، ما زال المشرف المُتصيَّد قادرًا على تجاوز أي إجراء منفرد.

هل يجب أن أنتقل من Node إلى Go لأجل الأمن وحده؟

الأمن يُحسب لصالح Go، لكن معظم الفرق تختار اللغة لكل ما تقدمه: التزامن (concurrency)، والتوظيف، والمنظومة، وسرعة الإطلاق. و Go لغة واجهة خلفية (backend) قوية، وهي أيضًا الأكثر أمانًا بنيويًا في مواجهة هجمات سلسلة التوريد. وإذا كنت تفكر فيها بالفعل، فالإعدادات الافتراضية الأكثر أمانًا سبب إضافي لتعلمها.

المصادر

المصادر الأساسية المذكورة في هذا المقال (آخر تحقق في 29 يونيو 2026):

• Sonatype: State of the Software Supply Chain
• Socket: وحدة Go ضارة تستغل التخزين المؤقت للوسيط لتحقيق الاستمرارية (boltdb-go)
• GitHub Security: خطتنا لسلسلة توريد npm أكثر أمانًا
• مرجع وحدات Go: قاعدة بيانات المجاميع الاختبارية
• مرجع وحدات Go: Minimal Version Selection
• مدونة Go: govulncheck
• Go: إدارة الثغرات في Go
• توثيق npm: السكربتات وخطافات دورة الحياة
• Alex Birsan: Dependency Confusion
• CISA: التنبيهات الأمنية
• Wiz: مدونة البحوث
• StepSecurity: المدونة
• Filippo Valsorda: words.filippo.io