كيف تكتشف وحدات Terraform الموثوقة وتتحقق منها قبل النشر في بيئة الإنتاج

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

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

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

لماذا الوحدة غير الموثوقة تهديد حقيقي لبنيتك التحتية

معظم فرق DevOps تستورد وحدات من Terraform Registry وتُشغّلها مباشرةً في بيئات الإنتاج دون إجراء أي مراجعة أمنية موثّقة. هذه الظاهرة ليست افتراضاً؛ فمنذ نوفمبر 2023 يتصاعد النقاش في مجتمع HashiCorp حول غياب عمليات منهجية لتدقيق الثغرات قبل استخدام الوحدات، وهو ما دفع HashiCorp لاحقاً إلى معالجة تحسينات أمان سلسلة توريد وحدات Registry في فبراير 2024، مما يُثبت أن المشكلة معترف بها على أعلى المستويات.

وحدة واحدة مُخترقة كافية

في سياق Infrastructure-as-Code، هجمات سلسلة التوريد تعني أن الوحدة نفسها هي ناقل الهجوم. وحدة مُخترقة يمكنها تضمين أذونات IAM مفتوحة بصمت، أو إنشاء موارد nat security مُعرَّضة للإنترنت دون تقييد، أو إدراج backdoors في إعدادات terraform aws تُمرَّر كأكواد مشروعة ضمن ملفات الإعداد. المستخدم لا يرى سوى وحدة تعمل وتُنتج بنية تحتية، بينما تنشر هذه الوحدة ثغرات خفية بالتوازي.

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

المسؤولية تقع على الفريق لا على المصدر

وجود وحدة في Terraform Registry العام لا يعني أنها آمنة، تماماً كما أن نشرها من مستودع GitHub مشهور لا يُقدّم أي ضمان تقني. الفرق العاملة على بيئات AWS الإنتاجية تتحمل مسؤولية التحقق بصرف النظر عن المصدر، لأن بيئة الإنتاج لا تُفرّق بين ثغرة كُتبت داخلياً وأخرى استُوردت من الخارج. حتى وحدة بسيطة مثل إدارة الأسرار، كهذه الوحدة الجاهزة لـ GCP Secret Manager، تحتاج إلى تحقق موثّق قبل الدمج في أي pipeline إنتاجي.

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

طبقات التحقق الأربع: إطار عمل متكامل

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

المنهجية لا الأداة

يقع كثير من الفرق في فخ الاعتقاد بأن تشغيل أداة مسح واحدة يُعادل "التحقق" من الوحدة. الواقع أن كل أداة تُغطي نطاقاً محدداً من المخاطر:

• الفحص الثابت (Static Analysis): يفحص كود Terraform بحثاً عن إعدادات خاطئة وموارد مكشوفة قبل أي تنفيذ.

• المسح الأمني العميق (Security Scanning): يكشف الأسرار المُضمّنة، وثغرات التبعيات، والصلاحيات المفرطة التي يتجاوزها الفحص الثابت.

• التحقق من التوقيع الرقمي (Signature Verification): يُثبت أن الوحدة لم تُعدَّل منذ نشرها، وأنها صادرة فعلاً من المصدر المُعلَن.

• حوكمة السياسات (Policy-as-Code): تُطبّق قواعد تنظيمية تحدد أي الوحدات مسموح باستخدامها ومن أي مصادر موثوقة.

هذه الطبقات تعمل بتكامل لا بتكرار؛ وحدة قد تجتاز الفحص الثابت لأن إعداداتها صحيحة، لكن المسح الأمني يكشف مفتاح API مُضمَّناً في أحد ملفاتها. كذلك قد تجتاز الطبقتين الأوليين، لكن التحقق من التوقيع يُظهر أنها عُدِّلت بعد نشرها الأصلي.

الترتيب يحكم الكفاءة

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

إطار يصلح لكل مصدر

ما يُميّز هذا الإطار هو قابليته للتطبيق بصرف النظر عن مصدر الوحدة. سواء جاءت من Terraform Registry العام، من مستودع GitHub، أو من مستودع داخلي خاص، الطبقات الأربع تُطبَّق بالتسلسل ذاته. تحسينات HashiCorp لأمان سلسلة التوريد في فبراير 2024 أضافت ضمانات على مستوى Registry، لكنها لا تُغني عن تحقق الفريق المستخدم من طرفه.

الأقسام التالية تُفصّل كل طبقة بأدواتها وأمثلتها العملية.

الطبقة الأولى: التحقق الثابت باستخدام أدوات تحليل الكود

تبدأ الطبقة الأولى بالأسرع تنفيذاً والأقل تكلفةً حسابياً: تحليل الكود ثابتاً قبل أي تنفيذ فعلي.

من tfsec إلى Trivy: تحول إلزامي

tfsec كان لسنوات الأداة المرجعية لفحص security code في Terraform، لكنه أُهمل رسمياً وتوقف تطويره. مجتمع HashiCorp بات ينصح بالانتقال إلى Trivy من Aqua Security بوصفه البديل النشط المُصان.

ما يميز Trivy عملياً هو قدرته على دمج فحصين في أمر واحد: اكتشاف الإعدادات الخاطئة (misconfigurations) في ملفات Terraform، وفحص ثغرات CVE في التبعيات المرتبطة بالوحدة. لا حاجة لأداتين منفصلتين أو خطوتين مستقلتين في الـ pipeline. حقق Trivy أكثر من 31,000 نجمة على GitHub مما يعكس اعتماداً واسعاً من فرق DevSecOps حول العالم.

trivy config ./modules/vpc-module/

هذا الأمر يفحص مجلد الوحدة ويُخرج قائمة بالإعدادات الخاطئة مصنفةً حسب درجة الخطورة.

Checkov: قواعد مدمجة لبيئات الإنتاج

Checkov خيار موازٍ يتميز بمكتبة قواعد ضخمة موجهة تحديداً لأفضل ممارسات terraform aws وبيئات السحابة الإنتاجية. يغطي معايير CIS Benchmarks لـ AWS مباشرةً دون إعداد إضافي، مما يجعله مناسباً للفرق التي تحتاج امتثالاً لمعايير محددة.

ما يكشفه الفحص الثابت فعلياً

الفحص الثابت ليس نظرياً؛ هو يرصد حالات عملية خطرة:

• موارد مكشوفة للإنترنت كـ S3 buckets ذات صلاحيات عامة

• Security Groups مفتوحة تسمح بالوصول من 0.0.0.0/0 على منافذ حساسة

• إعدادات nat security غير مقيدة تُتيح مرور حركة مرور غير مصرح بها

• تشفير معطل على قواعد البيانات أو أحجام التخزين

كل بند من هذه البنود قد يُعرّض بيئة الإنتاج بالكامل للاختراق إذا تسللت الوحدة دون فحص. يمكن الاطلاع على قائمة الموفرين المدعومين والوحدات المتاحة عبر https://www.iac-bazaar.com/providers لفهم نطاق التغطية الممكنة.

دمج الفحص في CI/CD كبوابة إلزامية

الفحص الثابت لا قيمة له إن ظل اختيارياً. الممارسة الصحيحة هي تعريف عتبة خطورة مسبقاً في الـ pipeline، بحيث تفشل أي وحدة تحمل مخاطر تتجاوزها:

- name: Scan Terraform Module
 run: trivy config --exit-code 1 --severity HIGH,CRITICAL ./modules/

الخيار --exit-code 1 يوقف الـ pipeline فوراً عند اكتشاف ثغرة عالية أو حرجة. هذا ما يصفه سلم التحقق المتكامل كخطوة أولى لا تُتجاوز قبل الانتقال لطبقات التحقق الأعمق.

تجدر الإشارة إلى ضرورة تثبيت إصدار Trivy المستخدم في الـ pipeline صراحةً، إذ رُصدت حادثة أمنية في إصدار v0.69.4 تضمنت نشراً ضاراً عبر بيانات اعتماد مخترقة، مما يُثبت أن أدوات الفحص نفسها تحتاج تحققاً من إصداراتها.

الطبقة الثانية: المسح الأمني العميق والكشف عن الأسرار المُضمَّنة

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

ما الذي يكشفه المسح العميق

المسح الأمني العميق يعمل على ثلاثة محاور متوازية:

• كشف الأسرار المُضمَّنة: أداة مثل GitLeaks تفحص كل سطر بحثاً عن أنماط المفاتيح والرموز المعروفة، سواء كانت مفاتيح AWS أو رموز GitHub أو بيانات اعتماد قواعد البيانات.

• فحص الاعتمادية: يتتبع الحزم والموفرين المرتبطين بالوحدة ويتحقق من وجود ثغرات CVE معروفة فيها.

• تحليل الصلاحيات: يرصد موارد تمنح صلاحيات IAM مفتوحة أو سياسات * غير مقيدة تتجاوز ما تعلنه الوحدة عن نفسها.

التبعيات المتداخلة: مصدر الخطر غير المرئي

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

نموذج وحدة opendevsecops/scanner على Terraform Registry يُقدّم مثالاً تطبيقياً على هذا النهج، إذ يدمج أدوات متعددة كـ Nmap وGitLeaks وNikto معاً عبر CloudWatch jobs في بيئة terraform aws، مما يُنشئ منظومة مسح موحدة تعمل بصورة مجدولة داخل البنية التحتية ذاتها.

المسح الدوري ليس خياراً

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

الحل: جدولة مسح أسبوعي على الأقل لجميع الوحدات النشطة في الإنتاج، وربط نتائجه بنظام تنبيه يُخطر الفريق فور ظهور CVE بدرجة خطورة عالية في أي مكون مُستخدم.

الطبقة الثالثة: التحقق من التوقيع الرقمي عبر cosign

المسح الأمني يكشف ما تحتويه الوحدة من ثغرات وأسرار، لكنه لا يُجيب على سؤال أعمق: هل هذه الوحدة وصلتك كما نشرها صاحبها الأصلي؟ هذا هو السؤال الذي يعالجه التوقيع الرقمي تحديداً.

ما الفرق الجوهري؟

هجمات استبدال الوحدة (module substitution attacks) لا تُعدّل الكود داخلها بالضرورة، بل تستبدل الوحدة كاملاً بنسخة خبيثة تحمل الاسم ذاته. أدوات الفحص الثابت والمسح الأمني لن ترصد هذا النوع من الهجوم لأنها تفحص ما أمامها فعلاً، دون أن تتحقق من مصدره.

cosign وSigstore: المعيار الناشئ

Cosign هي أداة من مشروع Sigstore مفتوح المصدر، طُوِّرت أصلاً لتوقيع صور الحاويات في بيئات Kubernetes ثم امتد استخدامها ليشمل أي artifact برمجي، بما في ذلك وحدات IaC. يستخدم Sigstore أيضاً أداة Rekor، وهي دفتر أستاذ شفاف وغير قابل للتلاعب يسجّل كل توقيع وبياناته الوصفية، مما يجعل التحقق اللاحق ممكناً وقابلاً للتدقيق.

آلية العمل عملياً

العملية مباشرة:

1. الناشر يوقّع الوحدة بمفتاحه الخاص بعد اكتمال البناء مباشرةً.

2. المفتاح العام يُنشر مع الوحدة أو يُخزَّن في مكان موثوق.

3. المستخدم يُشغّل أمر التحقق قبل أي terraform init للوحدة الخارجية.

cosign verify-blob \
 --key cosign.pub \
 --signature module.sig \
 module.zip

إذا أخفق التحقق، يعني ذلك أن الوحدة عُدِّلت بعد التوقيع أو لم تصدر عن الجهة المدّعاة. يدعم Sigstore كذلك الشهادات قصيرة الأجل (ephemeral keys) لتخفيف مخاطر تسريب المفاتيح.

إلزامية التحقق في الـ Pipeline

التحقق من التوقيع لا يُجدي إن بقي اختيارياً. يجب إدراجه كخطوة blocking في pipeline التحقق، تسبق terraform init وتُوقف التنفيذ عند الإخفاق. فريق يتجاوز هذه الخطوة يُعيد الثغرة التي يحاول إغلاقها.

الوحدات الموقَّعة مسبقاً: تخلّص من العبء

بناء منظومة توقيع داخلية يستلزم إدارة مفاتيح، وضبط pipeline، وتحديث عمليات التحقق مع كل إصدار. المنصات التي توفر وحداتها موقَّعة بـ cosign مسبقاً تُلغي هذا العبء كلياً؛ يمكنك التحقق من التوقيع بنفسك قبل الاستخدام دون الحاجة لإعداد أي بنية تحتية للتوقيع، مما يُبقي ضماناً موثوقاً للسلامة مع الحفاظ على سرعة التطوير.

الطبقة الرابعة: حوكمة الوحدات بسياسات Policy-as-Code

التحقق من التوقيع يُثبت أن الوحدة لم تُعدَّل، لكنه لا يمنع المطوّر من استيراد وحدة موقَّعة من مصدر غير موثوق أصلاً. هنا يأتي دور الطبقة الرابعة: تعريف ما يُسمح باستخدامه كسياسة قابلة للتطبيق الآلي.

سياسات Rego وقوائم المصادر الموثوقة

Open Policy Agent (OPA) يُتيح كتابة سياسات بلغة Rego تُحدد قائمة بيضاء للوحدات المقبولة بناءً على ثلاثة معايير: منظمة GitHub المصدر، اسم الوحدة، أو عنوان السجل. المثال التالي يرفض أي وحدة خارج المصادر المعتمدة ويُصدر مخالفة واضحة:

package terraform.module_allowlist

allowed_sources := {
 "registry.terraform.io/hashicorp/",
 "github.com/my-org/"
}

deny[msg] {
 module := input.configuration.module_calls[_]
 source := module.source
 not any_allowed(source)
 msg := sprintf("وحدة غير مسموح بها: %v - أبلغ فريق الأمن", [source])
}

any_allowed(source) {
 allowed := allowed_sources[_]
 startswith(source, allowed)
}

السياسة تُفحص كل module_calls في خطة Terraform وترفض أي مصدر لا يبدأ بأحد المسارات المعتمدة، مع رسالة تنبيه مُضمَّنة.

تطبيق السياسات محلياً عبر Conftest

Conftest هو الأداة التي تُشغّل سياسات Rego مباشرةً على ملفات Terraform قبل أن تصل إلى CI/CD. يُنفَّذ بأمر واحد:

conftest test main.tf --policy ./policies/

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

Sentinel لمستخدمي Terraform Enterprise

فرق تعمل على Terraform Enterprise أو HCP Terraform تجد في Sentinel بديلاً أعمق تكاملاً. Sentinel مدمج في دورة حياة Terraform نفسها، ويُطبَّق تلقائياً في مراحل plan وapply دون إعداد خارجي. يُوفّر مستويات تطبيق مختلفة (advisory, soft-mandatory, hard-mandatory) تمنح المرونة في تدرّج الإلزام. كلا الأداتين تُحقّقان الهدف ذاته؛ الاختيار بينهما يعتمد على البنية التحتية الحالية للفريق.

السياسات تُكمل المسح ولا تُغني عنه

نقطة جوهرية: حوكمة السياسات تتحكم في المصدر، أما المسح الأمني فيتحقق من المحتوى. وحدة من مصدر موثوق قد تحتوي على ثغرة CVE في إعدادات terraform aws أو تكوين nat security مفتوح، وهو ما تكشفه أدوات كـ Trivy لا سياسات Rego. للاطلاع على مثال تطبيقي لوحدة موثّقة تجمع هذه الطبقات، راجع توثيق وحدة GCP Service Accounts IAM.

الطبقتان معاً تُغلقان مسارَين مختلفَين للمخاطر: مصدر لا ينبغي الثقة به، ومحتوى لا ينبغي نشره.

ممارسات تكميلية: تثبيت الإصدار والاستضافة المحلية

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

تثبيت الإصدار: الحاجز الأول أمام التغييرات غير المراجعة

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

module "vpc" {
 source = "terraform-aws-modules/vpc/aws"
 version = "~> 5.0"
}

هذا التعريف يسمح بتحديثات الترقيع 5.0.x تلقائياً، لكنه يمنع القفز إلى 6.0 الذي قد يُعيد هيكلة واجهة برمجية كاملة. في بيئات SOC 2 وISO 27001، يُطالب المدققون بإثبات أن الإصدار المنشور على البيئة المرحلية مطابق لما رُقِّي إلى الإنتاج، وهذا مستحيل دون تثبيت دقيق.

مراجعة CHANGELOG: خطوة غير قابلة للتجاوز

قبل رفع رقم الإصدار في أي كود terraform aws، افتح سجل التغييرات واقرأ كل تعديل منذ إصدارك الحالي. ابحث تحديداً عن: تغييرات في الصلاحيات الممنوحة للموارد، تعديلات على قواعد Security Groups، أو إضافة متغيرات جديدة لها قيم افتراضية غير آمنة. الاختبار في بيئة غير إنتاجية أولاً قاعدة ثابتة، لكنها لا تُغني عن القراءة التحليلية للـ CHANGELOG قبل الترقية. للاطلاع على كيفية بناء سياسة ترقية آمنة، يُقدّم دليل نشر وحدة Terraform جاهزة للإنتاج وفق مبدأ أقل صلاحية نموذجاً عملياً لهذه الدورة.

Vendoring والمستودع الخاص: طبقتا العزل في المؤسسات الكبيرة

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

المستودع الخاص (Private Registry) يُضيف طبقة حوكمة فوق Vendoring: لا تُنشر وحدة داخلياً إلا بعد اجتياز pipeline المراجعة الأمنية المُعرَّف مسبقاً. هذا يحوّل المراجعة من ممارسة اختيارية إلى شرط تقني إلزامي مُدمج في سير العمل.

الموازنة بين الأمان والسرعة

الصرامة الكاملة، بناء Vendoring وصيانة private registry وإجراء مراجعات CHANGELOG لكل تحديث، تستهلك موارد هندسية حقيقية. الفرق التي تعتمد وحدات موثّقة مسبقاً، اجتازت الفحص الثابت والمسح الأمني والتوقيع الرقمي قبل وصولها إليها، تتجنب هذه المقايضة دون التنازل عن أي ضمان أمني.

البديل الجاهز: استخدام وحدات موثوقة من منصات متخصصة

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

IaC Bazaar سوق متخصص يوفر وحدات Terraform وOpenTofu وAnsible اجتازت ثلاث طبقات تحقق قبل النشر: الفحص الثابت للكود، والمسح الأمني الشامل، والتوقيع الرقمي عبر cosign. بمعنى آخر، ضمانات السلسلة التي تستغرق بناؤها أسابيع هندسية تأتي مدمجة في كل وحدة.

تغطية بيئات الإنتاج المستهدفة

الوحدات في المنصة مصممة للبيئات الأكثر شيوعاً في فرق DevOps: AWS وEKS وGKE. كل وحدة مُختبرة للجاهزية الإنتاجية، مما يعني أن الفريق لا يحتاج إلى إعداد pipeline تحقق مستقل أو اختبار توافق مع البيئة المستهدفة قبل النشر.

Vizier: تنسيق مبني على كتالوج موثّق

Vizier هو orchestrator يعمل فوق كتالوج وحدات المنصة الموثّقة. يُمكّن الفرق من بناء stacks كاملة، تجمع وحدات متعددة في بنية متماسكة، دون الخروج من بيئة الوحدات التي خضعت للفحص مسبقاً. الفائدة العملية: لا توجد وحدة خارجية غير خاضعة للمراجعة تتسرب إلى تكوين الإنتاج.

نموذج دفع يناسب الاحتياجات الفعلية

تعمل المنصة وفق نموذج دفع لكل وحدة يبدأ من 29 دولاراً، بدون اشتراك شهري. هذا يناسب الفرق التي تبحث عن وحدة محددة لمشروع محدد، وتريد ضمان أمانها دون الالتزام بمنصة شاملة. يمكن مقارنة خيارات المنصات المتاحة في Platforms that run your IaC لتحديد النموذج الأنسب لحجم الفريق وطبيعة المشاريع.

خلاصة: منهجيتك للتحقق قبل كل نشر

سواء اخترت بناء منظومة التحقق داخلياً أو الاعتماد على وحدات موثّقة مسبقاً، فالمبدأ الجوهري واحد: التحقق عملية منهجية لا إجراء لمرة واحدة.

إطار الطبقات الأربع هو نقطة البداية الصحيحة. ابدأ بالفحص الثابت عبر Trivy أو Checkov لرصد الإعدادات الخاطئة وثغرات التبعيات في الكود مباشرةً. انتقل بعدها إلى المسح الأمني العميق لاكتشاف الأسرار المُضمَّنة والصلاحيات المفرطة التي يتجاوزها الفحص الثابت. تحقق من توقيع cosign قبل كل terraform init لوحدة خارجية لضمان سلامة المصدر. أغلق الدورة بسياسات Rego التي تُطبّق allowlist على مستوى المصدر وتمنع الوحدات غير المعتمدة من الوصول إلى pipeline الإنتاج أصلاً.

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

تثبيت الإصدار ومراجعة CHANGELOG ليسا اختياريَّين. استخدم دائماً صيغة تثبيت كاملة في كود Terraform:

module "vpc" {
 source = "registry.terraform.io/org/vpc/aws"
 version = "3.14.0"
}

قبل رفع رقم الإصدار في بيئة الإنتاج، راجع CHANGELOG بحثاً عن أي تغيير في الأذونات أو الموارد المُضافة، لأن تحديثاً واحداً قد يُعيد تشكيل سلوك موارد nat security أو IAM roles دون إشعار واضح.

إذا كانت مواردك الهندسية محدودة، لا تبنِ المنظومة من الصفر. الوقت الذي تستثمره في إعداد pipelines الفحص وصيانتها قد يفوق قيمته. الوحدات التي تأتي مكتملة التحقق، فحصاً ثابتاً ومسحاً أمنياً وتوقيعاً رقمياً، تُتيح للفرق الصغيرة مستوى أمان يستغرق عادةً أشهراً لبنائه.

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