نشرات AWS الأمنية لشهر أكتوبر تجعل أدوات التطوير الوكيلة جزءاً من الاستجابة للحوادث

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

خلال الأيام الماضية نشرت AWS أو حدّثت تنبيهات مهمة تخص Loom for AWS، وخادم security-agent-mcp-server مفتوح المصدر، وتوزيعة SageMaker في SageMaker Unified Studio، وبيئة Kiro IDE. وتشمل الإفصاحات تجاوز المصادقة، وكشف الرموز، والطلبات الصادرة غير الآمنة، وحقن الوسائط، وتنفيذ الأوامر، وعمليات كتابة وكيلية في الإعدادات العامة. وتحدد نشرات AWS إصدارات متأثرة ومسارات معالجة مختلفة، ولذلك لا تكفي تعليمات عامة من قبيل «حدّث أدوات AWS».

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

ما الذي أفصحت عنه AWS

تتعلق أحدث نشرة في هذه المجموعة بالثغرة CVE-2026-104019 في عملية بدء تشغيل SageMaker Spaces داخل SageMaker Unified Studio. تقول AWS إن برنامج بدء التشغيل يتحقق من اتصالات الشبكة المتاحة في المشروع. وفي ظروف معينة، قد يسمح عدم تنظيف تفاصيل الاتصال بصورة كافية بتنفيذ شيفرة داخل Space يخص عضواً آخر في المشروع. وفي المشاريع التي تستخدم Trusted Identity Propagation، قد يتمكن مساهم أو مستخدم ذو صلاحيات أعلى من الحصول على بيانات اعتماد دور التنفيذ المؤقتة الخاصة بعضو آخر، ثم استدعاء خدمات لاحقة بالنيابة عنه.

تقول AWS إن الإصلاح نُشر عالمياً ويُطبّق عند إعادة تشغيل Spaces المدعومة. وتسرد النشرة إصدارات مصححة من SageMaker Distribution، منها 2.14.12 و3.9.12 و4.0.11 و4.1.11 و4.2.8 و4.3.5 و4.4.3. ولا يتوفر إصلاح لبعض الفروع الثانوية الأقدم لأنها خرجت من نطاق الدعم. وتوصي AWS بإعادة تشغيل Spaces التي تعمل على إصدارات ثانوية متأثرة حتى تتلقى الصورة المصححة. ولا تذكر النشرة حلاً مؤقتاً. لذلك تصبح إعادة التشغيل والتحقق من الإصدار إجراءً تشغيلياً، لا مهمة يمكن تأجيلها تلقائياً إلى نافذة الصيانة التالية.

تختلف نشرة Loom for AWS، وهي ذات صلة خاصة بالفرق التي تختبر تنسيق الوكلاء. تصف AWS Loom بأنه منصة مفتوحة المصدر لتنسيق وكلاء الذكاء الاصطناعي، طورتها AWS Labs. وتؤثر ثلاث ثغرات CVE في الإصدارات السابقة لـ1.7.0. فقد تسمح مشكلة مصادقة في الإصدارات السابقة لـ1.6.1 لعميل شبكة غير موثق بالحصول على صلاحيات إدارية على مستوى التحكم بالوكيل عندما لا يكون موفر هوية مهيأً. وتقول AWS إن هذه الصلاحيات قد تشمل تسجيل خوادم الأدوات، وقراءة بيانات اعتماد التكامل المخزنة، وإعادة كتابة سياسات أدوار IAM المرتبطة بأدوار الوكلاء المُدارة.

وتتعلق المشكلة الثانية في الإصدارات السابقة لـ1.7.0 بالتعامل مع اكتشاف OAuth2. تقول AWS إن مستخدماً موثقاً يملك نطاق mcp:write أو a2a:write قد يضبط عنوان اكتشاف يؤدي إلى إرسال أسرار عميل OAuth2 أو رمز وصول مستخدم آخر إلى نقطة نهاية يسيطر عليها طرف ثالث. وقد منع الإصدار 1.6.1 الأسبق الوصول إلى العناوين الداخلية، لكنه لم يغلق مسار كشف الرموز بالكامل. أما المشكلة الثالثة فتمس اتصالات خوادم الأدوات والوكلاء البعيدين، وقد تتيح لمستخدم موثق توجيه الطلبات إلى مواقع عشوائية داخل الشبكة، بما فيها نقطة نهاية تزويد الحاوية بالاعتمادات.

الحل الذي تحدده AWS لـLoom هو الإصدار 1.7.0، مع معالجة مشكلة المصادقة المنفصلة أيضاً في 1.6.1. وتطلب النشرة صراحة تدوير أسرار عملاء OAuth2، وإبطال رموز الوصول التي كانت نشطة خلال الفترة المتأثرة وإصدار رموز جديدة، وتدوير بيانات اعتماد جلسات أدوار IAM إذا كان من المحتمل الوصول إلى بيانات اعتماد الحاوية. وهذا أوضح مثال في المجموعة على أن التحديث قد يكون ضرورياً لكنه غير كافٍ: فعندما تكون الأسرار قد عبرت حدود الثقة، تشمل المعالجة استعادة سلامة الهوية.

أما مشكلة security-agent-mcp-server فنطاقها المنتجـي أضيق، لكنها مهمة لأنها تمس الحد الفاصل بين مساعد ذكاء اصطناعي محلي ونظام ملفات المضيف. تصف AWS المشروع بأنه خادم MCP مفتوح المصدر في مستودع awslabs/mcp، تستخدمه المساعدات لتشغيل عمليات فحص أمنية محلية، ومنها الفحوص التفاضلية. وأثرت CVE-2026-97662 في الإصدارات من 0.1.1 وحتى ما قبل 0.2.0. فقد تُفسَّر قيمة مرجعية مصاغة خصيصاً يمررها المستخدم إلى فحص الفرق على أنها خيار لسطر الأوامر لا مراجعة برمجية. وتقول AWS إن النتيجة قد تكون إنشاء ملفات عشوائية أو الكتابة فوقها أو اقتطاعها خارج مساحة العمل المقصودة، متجاوزةً آلية حصر الخادم داخل مساحة العمل.

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

يوضح Kiro IDE نسخة أخرى من المشكلة نفسها. تقول نشرة AWS الخاصة بالثغرة CVE-2026-95985 إن إصدارات Kiro السابقة لـ1.0.242 قد تسمح لمهاجم بعيد غير موثق بتنفيذ أوامر عشوائية وحقن تعليمات مصاغة في سياق الوكيل عندما يشغّل المستخدم الوكيل داخل مستودع مصاغ كمساحة عمل غير موثوقة. وتقول AWS إن المهاجم لم يكن يحتاج إلا إلى إرسال رسالة حتى تُجرى تعديلات الوكيل تلقائياً على مسارات إعدادات عامة تُحمّل تلقائياً.

إصدار Kiro المصحح هو 1.0.242. وتقول AWS إنه لا يوجد حل مؤقت، وتطلب من المستخدمين الذين شغّلوا الوكيل داخل مساحة عمل غير موثوقة على إصدار أقدم فحص مجلد إعدادات Kiro العام بحثاً عن إدخالات لم ينشئوها. والمسارات المذكورة هي ~/.kiro على macOS وLinux، و%USERPROFILE%\.kiro على Windows. والتفصيل التشغيلي المهم هو أن المستودع قد يكون غير موثوق حتى عندما يكون الشخص الذي يفتحه موثوقاً. فالقرار المتعلق بالثقة يخص المحتوى الذي يفسره الوكيل والأدوات التي يستطيع استدعاءها، لا هوية المطور الجالس أمام لوحة المفاتيح فحسب.

القاسم المشترك ليس أن الذكاء الاصطناعي غير آمن

من السهل اختزال هذه التنبيهات في تحذير عام من برمجيات الذكاء الاصطناعي، لكن ذلك لا يرشد الاستجابة. القاسم المشترك المفيد هو تركّز الامتيازات. فكل منتج يجمع مكونات برمجية عادية مع قدرة يمكنها عبور حد أمني: كاتب ملفات محلي، أو موصل MCP أو A2A، أو عميل OAuth2، أو دور تنفيذ مؤقت، أو برنامج بدء تشغيل، أو سياق وكيل يؤثر في الإجراءات اللاحقة.

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

لهذا السبب لا تتمثل وحدة المراجعة الصحيحة في الحزمة أو بيئة التطوير وحدهما، بل في الحزمة مع هوية التنفيذ ونطاق نظام الملفات المحلي والاتصالات الصادرة والأدوات المرتبطة والصلاحيات السحابية. قد يقلل فريق يحدّث Kiro من عيب معروف، لكنه يبقي نطاق تأثير كبيراً غير مضبوط إذا ترك كل وكيل لدى المطورين معتمداً إدارياً. وقد يغلق فريق يرقع Loom مسار الشيفرة، لكنه لا يغلق الحادث إذا لم يدوّر الرموز بعد احتمال كشفها.

توصي إرشادات AWS الخاصة بـIAM باستخدام بيانات اعتماد مؤقتة لأحمال العمل، وصلاحيات بأقل امتياز، ومراجعة دورية للصلاحيات غير المستخدمة، وشروط تضيق السياسات، وحواجز للصلاحيات عبر الحسابات. كما توصي AWS باستخدام نشاط CloudTrail وIAM Access Analyzer لتحسين السياسات. وهذه ضوابط عامة، لكن هذه النشرات توضح موضع تطبيقها: على الهويات والتكاملات التي تستخدمها الأدوات الوكيلة، وليس على خدمات الإنتاج وحدها.

من ينبغي أن يتحرك أولاً

المجموعة الأولى هي كل فريق نشر Loom for AWS خارج جهاز مطور يعمل على عنوان loopback المحلي، ولا سيما إذا لم يكن موفر هوية مهيأً قبل إتاحة التطبيق عبر شبكة. والمجموعة الثانية هي أي فريق منح نطاقات تكامل إدارية في Loom، مثل mcp:write أو a2a:write، لعدد أكبر من مجموعة صغيرة من المسؤولين. أما المجموعة الثالثة فتشمل الفرق التي تستخدم Loom مع تكاملات OAuth2 أو وكلاء بعيدين أو خوادم أدوات تحمل بيانات اعتماد.

وتأتي بعدها فرق البيانات والذكاء الاصطناعي التي تستخدم Spaces في SageMaker Unified Studio مع Trusted Identity Propagation. يعتمد الخطر على إعداد المشروع وخط التوزيعة، لكن المعالجة محددة: حدّد Spaces التي تعمل على إصدارات متأثرة، وأعد تشغيلها بعد إتاحة الصور المصححة، وتحقق من أن الفروع الثانوية القديمة غير المدعومة ليست ما تزال قيد الخدمة. ينبغي تسجيل إعادة التشغيل كتغيير له مالك ودليل، لا افتراض حدوثها لمجرد أن المنصة مُدارة.

وينبغي لفرق منصات التطوير وأمن التطبيقات البحث عن security-agent-mcp-server الخاص بـAWS في بيانات أدوات التطوير المحلية، وتكاملات المحررات، وصور مساعدات CI، وحاويات التطوير المشتركة. فقد تكون الحزمة مثبتة باسم لا يظهر بوضوح في جرد خدمات AWS. ابحث في مستودعات المصدر وإعدادات إقلاع المطورين التي تعرّف خوادم MCP، ثم اربط كل تثبيت بإصدار وحساب تنفيذ.

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

تسلسل عملي للاستجابة

1. أنشئ جرداً للقدرات

ابدأ بالقدرات لا بأسماء الموردين. اذكر كل أداة تطوير أو بيانات تستطيع القيام بواحد أو أكثر من الآتي: الكتابة خارج مجلد المشروع، تنفيذ أوامر محلية، استدعاء خوادم MCP أو A2A، الوصول إلى اعتمادات سحابية، حل عناوين الشبكة، إنشاء أدوار IAM أو تعديلها، أو قراءة أسرار التكامل. وأدرج امتدادات بيئات التطوير، والخدمات المحلية، والحاويات المشتركة، ومشغلات CI، وصور دفاتر الملاحظات، والطبقات الداخلية التي تغلف مشاريع مفتوحة المصدر.

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

2. طبّق التحديث وفق حدود المنتج الفعلية

بالنسبة إلى Loom، حدّث إلى الإصدار 1.7.0 وافحص التفرعات أو الشيفرة المشتقة. توضح AWS صراحة أن المشتقات تحتاج إلى دمج الإصلاحات، ولذلك لا يغطي الإصدار الأعلى مستودعاً نسخ شيفرة المنبع لمجرد أن الإصدار الأصلي أصبح حديثاً. وبالنسبة إلى خادم MCP، حدّث إلى 0.2.0 وتأكد من أن الصور المشتركة ونصوص إقلاع المطورين لم تعد تثبت نطاقاً أقدم. وبالنسبة إلى Kiro، انتقل إلى 1.0.242 أو أحدث وراجع الإعدادات العامة إذا استُخدم إصدار متأثر مع مساحة عمل غير موثوقة.

أما في SageMaker Unified Studio، فحدّد الفرع الثانوي للتوزيعة وأعد تشغيل Spaces المتأثرة حتى يُطبّق الإصلاح المنشور عالمياً. وتهم قائمة الإصدارات التي تذكرها AWS لأن بعض الفروع القديمة غير مدعومة وليست مصححة. قد تزيل الخدمة المُدارة جزءاً من عبء التحديث، لكنها لا تلغي الحاجة إلى تأكيد بيئة التشغيل المستخدمة فعلياً أو التحقق من أن Space أعيد تشغيلها.

3. استعد مواد الهوية عندما يكون الانكشاف محتملاً

لا تنتظر دليلاً على استخدام الرمز. توصي نشرة Loom الصادرة عن AWS بتدوير أسرار عملاء OAuth2، وإبطال رموز الوصول النشطة وإصدار رموز جديدة عندما يمكن أن تشملها الفترة المتأثرة. وإذا كان من المحتمل الوصول إلى بيانات اعتماد دور الحاوية، فدوّر بيانات اعتماد الجلسة وراجع CloudTrail بحثاً عن استخدام غير مقصود. وينبغي أن يتبع التسلسل الدقيق إجراءات الحوادث المعتمدة في المؤسسة وقدرات موفر الهوية.

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

4. راجع نشاط السحابة حول فترة الانكشاف

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

لا يكمن الهدف في البحث عن اسم حدث سحري واحد. ابنِ خطاً زمنياً يبدأ من المكوّن الضعيف وهويته وخدماته المرتبطة. قد تظهر حالة كشف رمز على هيئة وصول من عنوان غير متوقع. وقد يظهر تعديل سياسة دور على هيئة تغيير في IAM يتبعه وصول من أصل جديد. أما Space متضررة في بيئة تطوير بيانات فقد تنتج نشاطاً تحت دور مؤقت شرعي، ولهذا يجب النظر إلى الوقت والمصدر ونشاط المشروع المتوقع معاً.

5. خفّض الصلاحيات قبل العودة إلى الوضع المعتاد

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

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

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

ما الذي لا ينبغي استنتاجه من هذه النشرات

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

كما لا تبرر هذه الإفصاحات حظر أدوات الوكلاء مفتوحة المصدر كفئة كاملة. فتنبها Loom وsecurity-agent-mcp-server يوضحان حاجة الفرق إلى تتبع التفرعات والإصدارات المثبتة والأغلفة المحلية. قد يجعل المصدر المفتوح الإصلاحات مرئية وقابلة للتدقيق، لكنه يعني أيضاً أن مستودعاً منسوخاً أو تصحيحاً داخلياً أو صورة حاوية قد يستمر في حمل الثغرة بعد إصدار المنبع إصلاحاً. الضابط المطلوب هو الانضباط في الإصدار والمنشأ، لا تصنيف مبسط.

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

الدرس المستدام لفرق المنصات

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

تقدم تنبيهات AWS الحالية اختباراً مفيداً لنضج المؤسسة. هل يستطيع الفريق تحديد المطورين الذين يستخدمون Kiro، والمستودعات التي تحتوي خادم MCP، ونشرات Loom التي يمكن الوصول إليها، وSpaces التي تعمل على توزيعات متأثرة، والأدوار التي تستطيع تلك الأنظمة افتراضها؟ هل يستطيع تدوير سر تكامل من دون إعادة بناء منصة كاملة؟ وهل يستطيع التمييز بين استدعاء عادي لدور مؤقت واستدعاء مريب؟ إذا كانت الإجابة لا، فالمفقود ليس وثيقة أخرى عن سياسات الذكاء الاصطناعي، بل مسار عمل للأصول والهوية والتدقيق يخص أتمتة التطوير.

في الوقت الراهن، التسلسل العملي مختصر: حدّد التعرض، وطبّق إصلاحات المورد، وأعد تشغيل Spaces المُدارة حيث يلزم، ودوّر المواد التي يحتمل انكشافها، وراجع CloudTrail، وضيّق الصلاحيات قبل إعادة تفعيل الوصول الواسع. تتناول نشرات AWS منتجات وإصدارات محددة، لكن رسالتها التشغيلية أوسع. فعندما يستطيع برنامج تفسير مستودع، واستدعاء أداة، والعمل تحت هوية سحابية، فإن تصحيحه الأمني ينتمي إلى قائمة الاستجابة للحوادث بقدر ما ينتمي إلى قائمة تحديث أدوات المطورين.

المصادر والنطاق

يركز هذا المقال على نشرات AWS الأمنية المنشورة بين 24 سبتمبر و2 أكتوبر 2026، مع التركيز على الإجراءات التشغيلية التي ذكرتها AWS. ولا يدعي وقوع استغلال في أي من عمليات النشر المتأثرة. وقد حُذفت خطوات الاستغلال التقنية عمداً؛ وعلى الفرق استخدام تنبيهات المورد وإجراءات الحوادث الداخلية للتحقيق.

الإفصاحات الأساسية هي نشرة AWS 2026-125 الخاصة بالثغرة CVE-2026-104019 في SageMaker Distribution، ونشرة AWS 2026-124 الخاصة بثغرات Loom for AWS الثلاث، ونشرة AWS 2026-121 الخاصة بالثغرة CVE-2026-97662 في security-agent-mcp-server، ونشرة AWS 2026-117 الخاصة بالثغرة CVE-2026-95985 في Kiro IDE. وتستند توصيات الصلاحيات والتدقيق إلى أفضل ممارسات IAM الأمنية لدى AWS، وإرشادات أقل امتياز، وتوثيق CloudTrail لواجهات برمجة التطبيقات.