ما المقصود بالسياسة بوصفها تعليمات برمجية (PaC)؟

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

وتنقل هذه العملية ممارسات إدارة السياسات من المستندات الثابتة إلى طبقة تحكم ديناميكية تُطبَّق باستمرار وتكون مضمّنة في مسار تسليم البرمجيات.

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

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

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

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

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

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

ومن الناحية التقنية، تتبع معظم إعدادات PaC الخطوات الأساسية نفسها:

• يكتب المطورون السياسات في صورة ملفات تعليمات برمجية. ويمكنهم استخدام مجموعة من لغات البرمجة الأمرية والتصريحية عالية المستوى، بما في ذلك Python وYAML وJavaScript Object Notation (JSON) وRego، التي تُستخدم عادةً مع Open Policy Agent (OPA)، وهو محرك سياسات مفتوح المصدر. ويحدّد كل ملف سياسة المدخلات ذات الصلة به، مثل "resource.kind" و"metadata.labels"، ويشفّر الشروط، التي تُسمى أيضًا "المسندات"، إلى جانب النتائج، مثل السماح أو الرفض ومستوى الخطورة والرسائل.

• تُودَع التعليمات البرمجية في نظام للتحكم في الإصدارات، مثل Git أو GitHub، وتمر بمهام سير العمل نفسها التي تتبعها التعليمات البرمجية للتطبيقات، بما في ذلك طلبات السحب، ومراجعة التعليمات البرمجية، والاختبارات الصارمة لبناء الجملة البرمجية.

• يقرأ محرك السياسات ملف التعليمات البرمجية ويحلله، ثم يحوّله إلى هياكل بيانات وتعليمات يمكنه استيعابها داخليًا. وبعد ذلك، تُحوَّل هذه الهياكل والتعليمات إلى تنسيق مضغوط من التعليمات منخفضة المستوى (bytecode) لتسريع عملية التقييم.

• ويتولى المستدعي، وهو الجزء من التعليمات البرمجية الذي يطلب قرارًا من محرك السياسات، توحيد مدخلات البيانات. ويعالج المستدعي تنسيقات مختلفة للمدخلات، بما في ذلك ملفات HashiCorp Configuration Language (HCL) وقوالب JSON الواردة من أدوات IaC، وبيانات YAML التعريفية الواردة من Kubernetes والمنصات السحابية، وطلبات HTTP الناتجة عن استدعاءات واجهات برمجة التطبيقات، إلى جانب بيانات التطبيقات وبيانات القياس عن بُعد الواردة من بيئات وقت التشغيل والإنتاج. ينظّف المستدعي المدخلات غير المنسقة ويعيد تشكيلها في بنية قياسية موحّدة، بحيث تتمكن السياسات من قراءة المدخلات بطريقة متسقة.

• ثم يعيد المستدعي البيانات الموحّدة إلى محرك السياسات، الذي يبدأ في تشغيل التعليمات البرمجية للسياسات على مدخلات البيانات.

• ويستعرض محرك السياسات القواعد، ويتحقق من مسندات كل قاعدة مقارنةً بالمدخلات لتحديد المسندات المنطبقة. ويمكن النظر إلى محرك السياسات كما لو كان يطرح السؤال: "ماذا تنص هذه القاعدة بشأن هذه المدخلات؟"

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

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

يمكن إجراء فحوصات السياسات في أي مرحلة من دورة حياة تطوير البرمجيات (SDLC)، بدءًا من تكامل التعليمات البرمجية وصولًا إلى بيئة الإنتاج الفعلية والمراقبة.

ولأن السياسات مكتوبة في صورة تعليمات برمجية، يمكن التعامل معها مثل أي عنصر برمجي آخر.

ويمكن لفرق التطوير كتابة اختبارات مؤتمتة تمرر مدخلات نموذجية إلى السياسات وتتحقق من القرارات التي تعيدها، لتسريع دورات التعليقات عند تغيير السياسات.

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

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

وتمكّن هذه القدرات الفِرق من تطبيق ممارسات هندسة البرمجيات المعتمدة على منطق الحوكمة، مما يساعدها على الحفاظ على متطلبات الأمن والامتثال مع توسُّع البنى المعمارية لتكنولوجيا المعلومات وتطوّرها.

لنفترض أن الشركة X تريد تطبيق سياسة "HTTPS فقط"، التي تشترط استخدام كل خدمة ويب بروتوكول HTTPS بدلًا من بروتوكول HTTP العادي. ولصياغة السياسة في صورة تعليمات برمجية، يكتب مهندس المنصة قاعدة بسيطة تنص على ما يلي:

• إذا كان بروتوكول الخدمة هو HTTP، فيجب رفض التغيير.
• إذا كان بروتوكول الخدمة هو HTTPS، فيُسمح بالتغيير.

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

في مسار التكامل المستمر (CI)، تُحمَّل جميع ملفات السياسات من مجلد "السياسات" إلى محرك السياسات. ويقرأ محرك السياسات السياسة ويحوّلها إلى تمثيل داخلي، ثم يترجمها إلى صيغة مضغوطة منخفضة المستوى. وتتيح هذه الصيغة المضغوطة للمحرك الإجابة بسرعة عن سؤال "السماح أم الرفض؟" لكل خدمة يفحصها المسار.

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

ويطلب المستدعي قرارًا من محرك السياسات بإرسال الوصف الموحّد للخدمة بوصفه أحد المدخلات، مع تحديد ضرورة تطبيق حزمة السياسة الخاصة ببروتوكول "HTTPS فقط".

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

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

وأخيرًا، تطبّق أدوات التكامل المستمر (CI) القرار. فإذا كان القرار هو "الرفض"، لا يُسمح بدمج التغيير في الفرع الرئيسي للتعليمات البرمجية. ويرى المهندس رسالة خطأ توضّح أن الخدمة يجب أن تستخدم HTTPS، وتحدّد التعديلات المطلوبة. أما إذا كان القرار هو "السماح"، فيُحزَّم ناتج البناء ويُنشر، ويواصل مسار التكامل المستمر (CI) عمله كالمعتاد.

نشأت السياسة بوصفها تعليمات برمجية ضمن التوجه الأوسع نحو "كل شيء بوصفه تعليمات برمجية" في ممارسات DevOps وهندسة السحابة الحديثة.

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

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

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

وتُعد السياسة بوصفها تعليمات برمجية (PaC)، في جوهرها، تطبيقًا لهذه الفلسفة على القواعد والحوكمة والامتثال. تقليديًا، كانت السياسات تُدوَّن في ملفات PDF أو صفحات الويكي، أو تقررها اللجان، ويتولى العنصر البشري إنفاذها. وقد نجحت هذه العملية عندما كانت دورات الإصدار بطيئة والبنية التحتية ثابتة نسبيًا.

ولكن مع انتشار البنى القائمة على بنية سحابية أصلية وبنى الخدمات المُصغَّرة، وبدء الفِرق في نشر التعليمات البرمجية مرات عدة يوميًا، لم تعد العمليات اليدوية قادرة على مواكبة هذا الإيقاع. وعالجت السياسة بوصفها تعليمات برمجية هذا التحدي من خلال صياغة السياسات بتنسيقات قابلة للقراءة آليًا، بحيث يمكن إخضاعها للتحكم في الإصدارات باستخدام Git، ومراجعتها مثل ملفات التعليمات البرمجية، واختبارها ضمن التكامل المستمر (CI)، وإنفاذها تلقائيًا في المسارات أو في وقت التشغيل.

السياسة بوصفها تعليمات برمجية هي ممارسة لإدارة سياسات تكنولوجيا المعلومات بالطريقة نفسها التي تُدار بها التعليمات البرمجية للبرمجيات. وتتشابه معها البنية التحتية بوصفها تعليمات برمجية (IaC)، لكنها تركز على جانب مختلف. فهي تمكّن فرق الهندسة من تعريف البنية التحتية لتكنولوجيا المعلومات وإدارتها باستخدام التعليمات البرمجية للتطبيقات.

وبدلًا من إنشاء أصول الشبكة وتهيئتها يدويًا، مثل الأجهزة الافتراضية (VMs) وموازنات الأحمال، تمكّن البنية التحتية بوصفها تعليمات برمجية المطورين من كتابة تعليمات برمجية تصف الحالة المطلوبة لهذه الموارد. تأخذ أداة البنية التحتية بوصفها تعليمات برمجية (IaC) هذه التعليمات البرمجية، ثم تنشئ الموارد المحددة أو تعدّلها.

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

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

وفي كثير من البنى المعمارية الحديثة لتكنولوجيا المعلومات وإعدادات CI/CD، توفر IaC وPaC مزايا متكاملة. فبينما تؤتمت IaC توفير الموارد، تضيف PaC طبقة من الحوكمة المؤتمتة.

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

يركز نهج التطوير والأمن والعمليات (DevSecOps) على تضمين الأمن والامتثال في دورة حياة DevOps، بدلًا من إضافتهما في نهاية العملية. وهو نهج تطويري يعطي الأولوية للعمليات الأمنية وينفذها في كل مرحلة من مراحل دورة حياة تطوير البرمجيات.

وتدعم PaC ممارسات التطوير والأمن والعمليات من خلال ما يلي:

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

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

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

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

للسياسة بوصفها تعليمات برمجية مجموعة واسعة من الاستخدامات في البنى المعمارية لتكنولوجيا المعلومات في المؤسسات.

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

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

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

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

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

• الكفاءة. عند صياغة السياسات في صورة تعليمات برمجية، يمكن إنفاذها تلقائيًا في مسارات CI/CD أو وقت النشر، مما يلغي الحاجة إلى الفحوصات والموافقات اليدوية.

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

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

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

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