حين يتحول الإصلاح التلقائي للذكاء الاصطناعي إلى ثغرة أمنية في منظومة ERP

في 23 يونيو، فتح باحث أمني تقريرَ خطأ على مستودع Snowflake العام في GitHub. كان عنوان التقرير يحتوي على صياغة shell. التقط سير عمل GitHub Actions هذا العنوان، وأدرجه دون تهريب (escaping) داخل سكريبت مضمّن بصلاحيات عالية، وفي غضون ثوانٍ انكشف رمز Jira API — مما أتاح صلاحية القراءة على مشاريع Snowflake الداخلية في الهندسة والامتثال الأمني ومكافآت اكتشاف الثغرات ^[1]. لم يلمس أحد لوحة مفاتيح على الجانب الهجومي. نفّذ الوكيل الأحمر المستقل Red Agent التابع لـ Wiz كل شيء، بعد خمسة أيام من دمج الكود الضعيف ^[4].

ما انتشر بسرعة على الإنترنت: أن ميزة Autofix في GitHub Copilot شاركت في طلب السحب (pull request)، ووفقاً لـ Wiz، لم تُشِر إلى الثغرة ^[1]. ما تراجع عنه الجميع في غضون ثماني ساعات: لم يُثبَت بشكل قاطع أن Copilot كتب السطر المعيب — سجل الالتزامات (commit history) غامض، وطعنت GitHub في هذه الرواية ^{[3] [4]}. وحدّثت Wiz تقريرها ليعكس هذه الضبابية.

ما لا خلاف عليه: مساعد برمجي يعمل بالذكاء الاصطناعي شارك في مراجعة تغيير حساس أمنياً في مسار CI/CD ولم يرصد ثغرة بالغة الخطورة. كان بإمكان أي مستخدم غير موثّق على الإنترنت العام تفعيلها. ولم تكتشفها الأدوات الأمنية الآلية لدى Snowflake أيضاً — بل اكتشفها وكيل ذكاء اصطناعي هجومي ^{[1] [4]}.

بالنسبة للشركات الخليجية التي تدمج مساعدي الذكاء الاصطناعي في سير عمل Odoo أو Dynamics أو SAP، فإن الغموض حول من كتب السطر المعيب يكاد لا يكون ذا صلة. إخفاق الحوكمة متطابق في كلتا الحالتين.

كيف بدا مسار الهجوم فعلياً

يستحق الفهم الدقيق لهذه الآلية عناءه، لأنها تنعكس مباشرة تقريباً على طريقة تركيب تكاملات ERP في منطقة الخليج.

سير العمل الضعيف كان يُطلَق كلما فتح أي شخص تقرير خطأ في GitHub. كان يأخذ عنوان التقرير ويدرجه في سكريبت shell مصمّم لإنشاء تذكرة Jira مقابلة. منطق التهريب كان بترتيب خاطئ: محرك قوالب GitHub يستبدل العنوان أولاً، وتعمل أوامر التعقيم بعد ذلك — مما يعني أن علامة اقتباس مفردة في العنوان تكسر سلسلة shell بالكامل ^[4].

شرط حراسة (guard condition) بدا وكأنه حماية. كان يقارن خاصية طلب سحب بأسم بوت معروف. لكن في أحداث تقارير الأخطاء، هذه الخاصية غير موجودة — يُقيّمها GitHub كـ null، وnull لا تساوي أبداً اسم البوت، فكان الشرط دائماً صحيحاً، ومرّ كل مستخدم على الإنترنت مباشرة ^[4].

المحاولة الأولى لـ Red Agent أسفرت عن خطأ في الصياغة. قرأ الوكيل الخطأ، واستنتج السبب، وأعاد كتابة الحمولة، وحاول مجدداً. تأكّد الوصول في ثوانٍ ^[4].

أضاف موضوع Hacker News ملاحظة هيكلية مهمة: GitHub Actions فريد تقريباً في جمعه بين لغة يصعب تدقيقها وبيئة تنفيذ عن بُعد بصلاحيات عالية، وأُطلقت المنصة دون حل فعّال لفحص الأمان، تاركةً ذلك للمجتمع ^[2]. ونماذج الذكاء الاصطناعي مدرَّبة على المجموعة القائمة من أمثلة Actions — التي تحتوي على نسبة كبيرة من الأنماط غير الآمنة ^[2].

لماذا تواجه بيئات ERP وسير العمل الانكشاف ذاته

استبدل "سير عمل GitHub Actions" بـ "مهمة Zapier zap" أو "تدفق Power Automate" أو "إجراء خادم Odoo"، وستجد بنية المخاطرة متطابقة. هذه كلها سكريبتات مُفعَّلة بأحداث تتلقى مدخلات خارجية، وتمررها إلى عمليات ذات صلاحيات عالية، وغالباً ما تخزّن بيانات اعتماد API أو تشير إليها بشكل مضمّن.

في بيئة العمليات الخليجية تحديداً، يتضاعف الانكشاف بسبب ثلاثة أنماط نراها بشكل متكرر:

1. WhatsApp كطبقة تشغيل. تصل رسالة عميل أو تحديث مستودع عبر WhatsApp ويوجّهها سكريبت إلى ERP. كُتب السكريبت بسرعة، ربما بمساعدة ذكاء اصطناعي، والمدخلات لا تخضع لأي تعقيم [انظر أيضاً: فجوة WhatsApp إلى ERP].
2. رموز API في إعدادات الأتمتة. ربط Odoo بمزود خدمات لوجستية أو بوابة دفع يعني تخزين بيانات الاعتماد في مكان ما. وذلك المكان غالباً ملف إعداد سير العمل، لا مدير أسرار (secrets manager).
3. سلاسل موافقة تتخطى المراجعة. كثيراً ما تدخل سكريبتات الأتمتة في الشركات الخليجية مرحلة التشغيل الفعلي بعد اختبار وظيفي — هل تتحرك البيانات؟ — دون مراجعة أمنية — من يمكنه أيضاً تحريك البيانات، وماذا يمكنه أن ينفّذ بها؟

حادثة Snowflake هي خبر يتعلق بشركة برمجيات. بالنسبة لمشغّل يدير شركة تصنيع أو تجارة في جبل علي أو الخبر، السيناريو المقابل هو أتمتة بمساعدة ذكاء اصطناعي توجّه فواتير الموردين، وتحمل رمز مسؤول ERP، وتنطلق عند أي بريد إلكتروني وارد يطابق نمطاً بسيطاً. نطاق الضرر ليس Jira. إنه دفتر مشترياتك.

حدود الثقة الثلاثة التي يجب على فريقك رسمها قبل نشر أي مساعد ذكاء اصطناعي

يلخّص باحثو الأمن المشكلة الجوهرية بوضوح: يمكن أن يحتوي الكود الذي يولّده الذكاء الاصطناعي على إعدادات افتراضية غير آمنة، ومعالجة هشّة للأخطاء، ومنطق يبدو آمناً فقط في سياق مراجعة ضيّق — وإذا لم تفحص الفرق هذا الكود وتراجعه كأي مدخل خارجي آخر، فإنها تفتح مساراً لمنطق غير آمن يدخل الإنتاج دون الضوابط المعتادة ^[5].

ثلاثة حدود تجعل ذلك ملموساً:

الحد الأول — وسم مصدر الكود. أي كود كتبه مساعد ذكاء اصطناعي أو عدّله يجب أن يُوسَم بذلك في الالتزام (commit) وفي وصف طلب السحب. هذا ليس آلية إلقاء مسؤولية. هو آلية فرز: يخبر المراجعين بمعاملة التغيير كما يعاملون مساهمة من مطوّر خارجي مجهول، لا زميل موثوق. الكود الذي يشارك فيه Copilot ويُشحن دون هذا الوسم لا يمكن تمييزه عن الكود المراجَع بشرياً في سجل التدقيق. بعد أي حادثة، يهمّ ذلك كثيراً.

الحد الثاني — الأسرار خارج إعدادات الأتمتة، دائماً. لا يسكن أي رمز API أو كلمة سر قاعدة بيانات أو سر webhook داخل ملف سير عمل أو سكريبت أتمتة أو إعداد منصة كود منخفض. استخدم مدير أسرار — Azure Key Vault أو AWS Secrets Manager أو HashiCorp Vault أو ما يوفره مزود الحوسحة السحابية لديك. أشر إلى السر باسمه وقت التشغيل. هذه ليست نصيحة جديدة؛ حادثة Snowflake تذكير بأن التطوير بمساعدة الذكاء الاصطناعي لا يطبّقها تلقائياً.

الحد الثالث — بوابة تحليل ثابت (static analysis) في CI قبل أي دمج. الأداة المجتمعية التي أُشير إليها في نقاش Hacker News عقب الحادثة، zizmor، كانت ستُصنّف نمط template injection في سير عمل Snowflake كنتيجة بثقة عالية ^[2]. التحليل الثابت لأمن CI/CD ليس أمراً استثنائياً. هو خانة اختيار لم تكن موجودة في سير عمل Snowflake. بالنسبة لفرق أتمتة ERP، ما يقابل ذلك هو تشغيل فاحص أو أداة مسح أمني على أي سكريبت أتمتة قبل ترقيته إلى تكامل إنتاجي — بصرف النظر عن مساهمة الذكاء الاصطناعي في كتابته.

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

كيف تقيّم الوضع الأمني لأي مورّد أتمتة ذكاء اصطناعي

حين يعرض مورّد مساعد ذكاء اصطناعي أو منصة أتمتة أو أداة سير عمل وكيل (agentic) لبيئة ERP لديك، يجب أن تتضمن محادثة الشراء هذه الأسئلة — لا كأسئلة إيقاع، بل كمرشّح تقييم:

1. أين تخزّن الأداة بيانات الاعتماد التي تحتاجها للعمل؟ إذا كانت الإجابة "في إعداد التكامل" أو "في منصتنا"، اطلب البنية التقنية لهذا التخزين. الإشارة إلى مدير أسرار مقبولة. سلسلة مشفّرة مضمّنة غير مقبولة.
2. هل تولّد الأداة أو تعدّل كوداً يُطبَّق تلقائياً على الإنتاج؟ إذا نعم، ما بوابة المراجعة البشرية؟ التطبيق التلقائي على بيئة تجريبية مع خطوة موافقة بشرية إلزامية قبل ترقية الإنتاج مقبول. التطبيق التلقائي على الإنتاج غير مقبول، لأي نظام يتعامل مع بيانات مالية أو هوية أو مخزون.
3. ما التحليل الثابت أو الفحص الأمني الذي يجري على الكود الذي يولّده الذكاء الاصطناعي قبل تنفيذه؟ إذا لم يستطع المورّد تسمية الأداة، فالإجابة على الأرجح لا شيء.
4. ما نطاق الضرر إذا تعرّضت بيانات اعتماد الأداة للاختراق؟ هذا هو السؤال الذي تجيب عليه حادثة Snowflake بأوضح صورة. رمز Jira أتاح صلاحية القراءة على مشاريع الهندسة والأمن ومكافآت اكتشاف الثغرات ^[1]. ماذا سيتيح رمز مكافئ من تكامل ERP الخاص بك؟ ارسم الصورة قبل التوقيع.
5. هل خضع المورّد لتدقيق أمني من طرف ثالث على مكوّنات الذكاء الاصطناعي تحديداً؟ الامتثال العام لـ SOC 2 لا يغطي ملف المخاطر الخاص بتوليد الكود بمساعدة الذكاء الاصطناعي وتطبيقه التلقائي.

لطريقة منظّمة لإجراء هذا التقييم داخلياً قبل التواصل مع أي مورّد، يتناول تدقيق جاهزية ERP للذكاء الاصطناعي الأسئلة التشغيلية والأمنية بالتسلسل.

رأي تارسين: مساعدو الذكاء الاصطناعي لسير العمل غير الحرجة، لا لأنظمة السجلات — في الوقت الراهن

الصورة الصادقة لهذا الوضع أن حادثة Snowflake أكثر تحديداً وأكثر عمومية في آنٍ واحد مما أوحت به العناوين. أكثر تحديداً: الإسناد إلى Copilot Autofix غير موثوق فعلاً، وصحّحت Snowflake الثغرة بسرعة ^{[3] [4]}. أكثر عمومية: الظروف الهيكلية التي أتاحت نافذة خمسة أيام للاستغلال — مشاركة ذكاء اصطناعي دون بوابة أمنية، وشرط حراسة فشل بالانفتاح، وبيانات اعتماد يصل إليها منطق سير العمل — موجودة في مشاريع أتمتة ERP عبر الخليج الآن.

لسنا نقول إن مساعدي الذكاء الاصطناعي خطرون جداً للاستخدام. نستخدمهم نحن أيضاً. لكن لدينا مبدأ عمل: الكود الذي يساعد فيه الذكاء الاصطناعي مسوّدة، لا قرار. يستحق الفحص ذاته الذي يستحقه أي مساهمة خارجية. لا يلمس الأسرار. لا يُطبَّق تلقائياً على التكاملات الإنتاجية.

للمشغّلين الخليجيين، الخط العملي هو: مساعدو الذكاء الاصطناعي جاهزون لتسريع أتمتة سير العمل غير الحرجة — توليد التقارير، وتوجيه الإشعارات، وتحويل البيانات بين أنظمة غير مميّزة. ليسوا جاهزين ليكونوا المؤلفين غير المراجَعين لسكريبتات تحمل رموز مسؤولي ERP، أو تلمس الدفاتر المالية، أو تنطلق على مدخلات خارجية غير مُتحقَّق منها. هذا الخط ليس دائماً. هو أين تقف الأدوات وممارسات الحوكمة اليوم.

قبل شراء أي طبقة أتمتة ذكاء اصطناعي لعملياتك، أجرِ التدقيق أولاً. ليس لأن التقنية سيئة، بل لأن الحوكمة المحيطة بها شبه دائماً غير ناضجة — وكما تُظهر حادثة Snowflake، الفجوة بين "الذكاء الاصطناعي راجع هذا" و"هذا آمن" قابلة للاستغلال في خمسة أيام بأداة تقرأ رسائل الخطأ الخاصة بها.

ابدأ بتدقيق العمليات لدينا قبل أن يلمس أي مساعد ذكاء اصطناعي تكاملاً إنتاجياً. الأسئلة الخمسة أعلاه تستغرق أقل من يوم للإجابة عنها داخلياً. حادثة Snowflake استغرق استغلالها خمسة أيام وكان يمكن أن يستغرق اكتشافها وقتاً أطول بكثير لولا اختبار هجومي مستقل على الجانب الآخر.

إذا أردت إطاراً أشمل حول أين تُجدي أتمتة الذكاء الاصطناعي فعلاً مقابل أين تخلق فوضى منظّمة، تتناول مقالتنا عن وكلاء الذكاء الاصطناعي للعمليات الخليجية تفصيل حالات الاستخدام المحددة. وإذا كنت تقيّم ما إذا كان أي إنفاق على الذكاء الاصطناعي مبرراً قبل ترتيب الأساسيات، فإن التدقيق الذي يحسم القرار هو نقطة البداية الصحيحة.

اضرب الفوضى في الذكاء تحصل على فوضى بليغة. حادثة Snowflake عرض تطبيقي لهذا المبدأ في بيئة إنتاجية.