DevSecOps - متقدّم

1. DevOps مقابل DevSecOps

ما الذي تحتاج إلى معرفته

صومعة «الأمان» (Security Silo)

كما عُرِّف سابقًا في خارطة الطريق هذه، فإنّ «DevOps» مجموعة من الممارسات والأدوات والثقافة التي تجعل تسليم البرمجيات سريعًا وفعّالًا وموثوقًا. وبعبارة أخرى، هدف «DevOps» هو جعل تسليم البرمجيات أسرع وأكثر فعالية دون المساس بالموثوقية، التي تشمل أمورًا كثيرة مثل الوظائف (يجب ألّا تُعطّل الشيفرة الجديدة الوظائف القائمة)، والأداء، والأهم من ذلك «الأمان».
مع تصاعد تبنّي «DevOps»، أصبحت أدواته وعملياته أكثر نضجًا وقادرة على تغطية جوانب كثيرة من الموثوقية. فمثلًا، لضمان ألّا تُعطّل الشيفرة الجديدة الوظائف القائمة، تتيح لنا أدوات CI/CD تشغيل اختبارات الوحدة أو التكامل كجزء من خط الأنابيب، بل يمكننا حتى استخدام مقاييس مثل تغطية الشيفرة (code coverage) كمؤشّر على جودة الاختبار.
غير أنّ جانبًا واحدًا من الموثوقية لم ينضج بالوتيرة ذاتها، وهو «الأمان». وبعبارة أخرى، بينما كسرت DevOps الصومعة بين «Dev» و«Ops»، بقيت فرق «الأمان» في صومعتها الخاصة.

لماذا يتخلّف «الأمان»؟

توجد تحدّيات كثيرة تجعل من الصعب إدراج «الأمان» ضمن أدوات «DevOps» وعملياته. لنبدأ باستكشاف بعض هذه التحدّيات
1. الطبيعة البشرية: عند بناء الأشياء، تركّز أدمغتنا على «كيف ينبغي أن تعمل الأشياء» (المسار السعيد (happy path))، لا على «ما قد يخطئ»، ومن ثمّ يُغفَل «الأمان» عادةً.
2. طبيعة البرمجيات: تُبنى البرمجيات على طبقات وتجريدات وتبعيات كثيرة. ويمكن أن تنشأ مشكلات الأمان عن أحد هذه المكوّنات الكامنة (مثل تبعيات المصادر المفتوحة، أو إعداد السحابة، أو حتى خط أنابيب CI/CD ذاته). ومن ثمّ، لتأمين تطبيق ما، نحتاج إلى تفكيك كل هذه الطبقات والتجريدات والتأكّد من ضبطها بشكل صحيح. شكل توضيحي: طبقات التطبيق وتجريداته وتبعياته الكامنة التي قد تنشأ عنها مشكلات الأمان.
3. طبيعة مشكلات الأمان:
  - مشكلات الأمان أقلّ شيوعًا من أنواع الأخطاء الأخرى (مثل الاستقرار أو الأداء)، لكن أثرها عادةً أكبر.
  - يمكن أن تبقى مشكلات الأمان سنوات دون اكتشاف، وعند اكتشافها غالبًا لا يكون الشخص الذي يصلح المشكلة هو نفسه من أدخلها.
  - وهذا يُضعف عملية التعلّم المعتادة القائمة على «التجربة والخطأ»، ما يجعل التعلّم أبطأ بكثير.
4. طبيعة أدوات الأمان:
  - حتى وقت قريب، كانت أدوات أمان كثيرة مبنية للتركيز على الاستخدام اليدوي بدلًا من الأتمتة. وهذا يجعل إدراجها في خط أنابيب CI/CD أكثر صعوبة.
  - تُنتج معظم أدوات الأمان كثيرًا من الإيجابيات الكاذبة (false positives)، ما يجعل استخدامها لأتمتة القرارات (مثل إفشال خط أنابيب البناء) صعبًا دون قدر كبير من الضبط.
  - لا تغطّي معظم أدوات الأمان كثيرًا من مشكلات أمان منطق الأعمال (مثل التخويل)، ما يؤدّي إلى كثير من السلبيات الكاذبة (false negatives) إن اعتمدنا عليها وحدها.

إضافة «Sec» إلى «DevOps»

ولهذا كانت الحاجة إلى «DevSecOps» للتركيز على تجاوز التحدّيات أعلاه وإدراج «الأمان» ضمن أدوات «DevOps» وعملياته. وبعبارة أخرى، هدف «DevSecOps» هو دمج «الأمان» في جميع مراحل دورة حياة تطوير البرمجيات (SDLC) دون المساس بالسرعة والكفاءة (وهما الهدفان الرئيسان لـ DevOps).

2. التعريف: تحديد التهديدات

ما الذي تحتاج إلى معرفته

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

شكل توضيحي: تعريف الأمان عبر تحديد التهديدات الرئيسة التي قد تصيب التطبيق وضوابط الأمان المقابلة للتخفيف منها.

وبعبارة أخرى، لتعريف «الأمان» نحتاج إلى تحديد التهديدات الأمنية الرئيسة التي قد تؤثّر في التطبيق، وتحديد ضوابط الأمان (security controls) التي يلزم تنفيذها للتخفيف من هذه التهديدات.
تُسمّى عملية تحديد التهديدات الرئيسة وضوابط الأمان المقابلة لها «نمذجة التهديدات» (Threat Modeling)، وسنناقشها بمزيد من التفصيل قريبًا.

متى تبدأ التخطيط للأمان؟

من الناحية المثالية، ينبغي أن نبدأ التخطيط للأمان خلال مرحلة «التصميم». وكلّما كان ذلك أبكر كان أفضل، إذ كلّما اكتُشفت مشكلة أمان متأخّرة ارتفعت كلفة إصلاحها، ويشمل ذلك الوقت والجهد والإيرادات المفقودة ... إلخ.

نمذجة التهديدات

كما ذُكر أعلاه، «نمذجة التهديدات» هي كيفية تعريفنا لما يعنيه «آمن» بالنسبة لتطبيقنا عبر تحديد التهديدات الرئيسة والتخفيفات المقابلة لها (ضوابط الأمان)، ومن ثمّ فهي الجانب الأكثر أهمية في «DevSecOps». وهدف «نموذج التهديد» (Threat Model) هو الإجابة عن الأسئلة التالية:
1. على ماذا نعمل؟ -> النطاق
2. ما الذي قد يخطئ؟ -> التهديدات
3. ما الذي سنفعله حيال ذلك؟ -> التخفيفات
4. هل قمنا بعمل جيد؟
ينبغي إجراء نمذجة التهديدات خلال مرحلة التصميم حالما يتحدّد النطاق التقني للتطبيق، ويلزم القيام بها في اجتماعات تضمّ أصحاب المصلحة من فريق هندسة البرمجيات وفريق الأمان وأي فرق أخرى مشاركة في التصميم (مثل فريق المنصّات إن كنّا نستخدم خدمة سحابية).
ناتج نمذجة التهديدات قائمة بالتهديدات والتخفيفات المقابلة لها. مثال:

التهديد: قد يؤدّي الوصول غير المصرّح به إلى واجهتنا البرمجية (API) إلى كشف بيانات العملاء أو العبث بها.

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

مصادر

3. التحقّق: عمليات وأدوات DevSecOps

ما الذي تحتاج إلى معرفته

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

3.1 اختبارات الوحدة والتكامل

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

على سبيل المثال، كاختبار تكامل، اختبار المصادقة لتطبيق Django.

from django.test import TestCase, Client

class ShareAPIViewTestCase(TestCase):
    def setUp(self):
        self.client = Client()

    def test_missing_session_cookie(self):
        """Test that a 401 response is returned when the session cookie is missing"""
        response = self.client.get('/api/share/')
        self.assertEqual(response.status_code, 401)

    def test_valid_cookie_different_user_file(self):
        """Test that a 403 response is returned when a valid cookie for user 1 is provided and the file_id input
        parameter is a valid id of a file owned by a different user"""
        # Assuming you have a function or method to generate a valid session for a user
        self.client.login(username='user1', password='password1')

        # Assuming you have a function or method to create a file owned by a different user
        file_id = create_file_for_different_user()

        response = self.client.get('/api/share/', {'file_id': file_id})
        self.assertEqual(response.status_code, 403)

يمكنك العثور على مزيد من التفاصيل حول كتابة اختبارات الوحدة والتكامل في خارطة الطريق هذه:
- 3.4 البرمجة - كتابة اختبارات الوحدة
- 5.3 البرمجة - كتابة اختبارات التكامل

3.2 SAST (اختبار أمان التطبيق الساكن)

فئة مفيدة أخرى من أدوات الأمان هي SAST، التي تفحص الشيفرة بحثًا عن أنماط شائعة قد تؤدّي إلى مشكلات أمان. وتكون مفيدة عادةً في تحديد الدوال الخطرة مثل:
- استعلام SQL خام يُعرَّف باستخدام مدخلات المستخدم قد يؤدّي إلى حقن SQL.
- أمر يُعرَّف باستخدام مدخلات المستخدم قد يؤدّي إلى حقن الأوامر.

على سبيل المثال، يحتوي المسار أدناه على ثغرة إعادة التوجيه المفتوح لأنّه يمرّر مدخلات المستخدم (معامل الاستعلام url) إلى الدالة الخطرة res.redirect.

app.get('/users/:id', (req, res) => {
    const userId = Number(req.params.id);
    const user = users.find((user) => user.id === userId);
    console.log(req.query)
    if (!user) {
        if (req.query.url) {
            res.redirect(req.query.url);
        } else {
            res.redirect('https://www.example.com');
        }
    } else {
        res.json(user);
    }
});

ويُنتج فحص SAST (Semgrep في هذا المثال) لهذا الأمر النتيجة التالية:

$ semgrep scan

┌──── ○○○ ────┐
│ Semgrep CLI │
└─────────────┘
[...]
    ❯❱ javascript.express.security.audit.express-open-redirect.express-open-redirect
        The application redirects to a URL specified by user-supplied input `req` that is not validated.
        This could redirect users to malicious locations. Consider using an allow-list approach to validate
        URLs, or warn users they are being redirected to a third-party website.
        Details: https://sg.run/EpoP

        29┆ res.redirect(req.query.url);

غير أنّه من الضروري ملاحظة أنّ أدوات SAST تولّد عادةً كثيرًا من الإيجابيات الكاذبة، لذا لا يُنصح بإيقاف خط أنابيب CI/CD بسبب نتائج SAST، لأنّ ذلك قد يصبح مصدر ضجيج كبير.
فيما يلي المقاربة الموصى بها:
- فحص SAST يومي كامل للمستودع، مع فريق محدّد مسؤول عن فرز النتائج الجديدة الناتجة عن هذا الفحص وإصلاحها.
- فحص تزايدي لطلبات السحب/الدمج (PR/MR) يفحص الشيفرة الجديدة بحثًا عن نتائج مُدخَلة حديثًا، ويضيف النتائج كتعليقات على طلب السحب/الدمج.
- في خط أنابيب CI/CD، يُقتصر الحجب على النتائج المتعلّقة بالتخفيفات عالية الأثر المحدّدة في نموذج التهديد. مثلًا، فقط للقواعد المتعلّقة بنتائج حقن SQL التي اختُبرت وتُحقّق من أنّها لا تولّد إيجابيات كاذبة.
فيما يلي بعض أدوات SAST للاستكشاف:
- Semgrep: يتيح كتابة قواعد مخصّصة، وتخصيص القواعد التي تُشغَّل، ما يجعله مرنًا وسهل التكيّف مع تخفيفات نموذج التهديد لديك. وله إصدار مجتمعي مجاني، لكن معظم الإصدارات (مثل التحليل عبر الملفات، وعمليات فحص طلبات السحب، والمساعد الذكي (AI Assistant) للفرز والإصلاح التلقائيين) متاحة في الإصدار المدفوع.
- OpenGrep: تفرّع مفتوح المصدر من الإصدار المجتمعي لـ Semgrep.
- QwietAI: يستخدم رسمًا بيانيًّا لخصائص الشيفرة (code property graph) لتحديد الثغرات، ما يجعله نظريًّا قادرًا على تقليل الإيجابيات الكاذبة وتحديد ثغرات أكثر تعقيدًا (مثل الثغرات عبر الملفات).
- Corgea: إلى جانب استخدام الذكاء الاصطناعي لفرز نتائج SAST لأدوات أخرى وإصلاحها، فإنّه يستخدم الذكاء الاصطناعي لفحص الشيفرة، ما يجعله قادرًا على تحديد مشكلات منطق الأعمال عبر (BLAST).
فيما يلي مزيد من المصادر حول SAST:
- كيف «تُنقل عمليات فحص SAST إلى اليسار» (Shift-Left) (Semgrep كمثال) | بقلم Mohamed AboElKheir | AppSec Untangled | Medium
- كيف يخرق فحص الشيفرة بالذكاء الاصطناعي حدود SAST - Corgea كمثال | بقلم Mohamed AboElKheir | AppSec Untangled | Medium

3.3 DAST (اختبار أمان التطبيق الديناميكي)

يحلّل DAST التطبيق بمحاكاة الهجمات ومراقبة كيفية استجابة التطبيق للعثور على ثغرات محتملة. وخلافًا لـ SAST، لا يحتاج هذا إلى الوصول إلى شيفرة التطبيق.
يُعدّ Burp Suite وOWASP ZAP أشهر أدوات DAST. غير أنّهما لا يعملان جيدًا مع التطبيقات الحديثة (مثل تطبيقات الصفحة الواحدة (SPA) كـ React) وليسا مُحسَّنين للعمل ضمن خطوط أنابيب CI/CD، لأنّهما عادةً مستهلكان للوقت ومصدران للضجيج.
توجد بعض أدوات DAST الأحدث التي تستحقّ الاستكشاف، مثل Escape وAkto API Security، وهي أكثر تجهيزًا للتعامل مع التطبيقات والواجهات البرمجية الحديثة، لكن يُنصح عمومًا بتشغيل DAST كمهمة مجدولة منفصلة بدلًا من تشغيله ضمن خط أنابيب CI/CD.

3.4 IAST (اختبار أمان التطبيق التفاعلي)

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

تلميح

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

3.5 فحص الأسرار

ثمة تهديد مهم آخر هو بيانات الاعتماد/الأسرار المُضمَّنة مباشرةً في شيفرتك (hard-coded)، ما قد يكشف هذه البيانات وأيّ بيانات تملك صلاحية الوصول إليها. وهذا خطير بشكل خاص في المستودعات مفتوحة المصدر. ومن ثمّ، يُنصح باستخدام أداة تفحص مستودعاتك بحثًا عن الأسرار.

TruffleHog أداة مفتوحة المصدر يمكن استخدامها لفحص الأسرار، وهناك أيضًا بعض الحلول المدفوعة، مثل GitGuardian وSemgrep Secrets.

3.6 SCA (تحليل تكوين البرمجيات)

كما ذُكر سابقًا، لا يعتمد أمان التطبيق على شيفرة التطبيق وحدها، بل أيضًا على جميع الطبقات والتجريدات الكامنة. وإحدى هذه الطبقات التي تحتاج إلى تأمين هي حزم المصادر المفتوحة (npm و pip و maven وغيرها) التي يستخدمها التطبيق كتبعات مباشرة أو غير مباشرة، إذ إنّ الثغرات التي تصيب أيًّا من هذه الحزم قد تُستخدم أيضًا لمهاجمة التطبيق الذي يستخدمها.
ومن ثمّ، يُنصح باستخدام أدوات SCA لفحص تطبيقك للحصول على قائمة تبعيات المصادر المفتوحة، وإصداراتها الحالية، وأيّ ثغرات معروفة تؤثّر في هذه الإصدارات.
ولهذا يمكننا استخدام أدوات مثل Dependabot أو Snyk، لكن بما أنّ معظم أدوات SCA تولّد عددًا هائلًا من التنبيهات، يُنصح باستكشاف أدوات تُجري «تحليل قابلية الوصول» (Reachability Analysis) مثل Coana (استحوذت عليها حديثًا Socket.dev) أو Endor Labs.
تحليل قابلية الوصول هو التحليل المؤتمت للشيفرة وتبعياتها لتحديد ما إذا كانت الأجزاء المعرّضة للثغرة من الشيفرة (مثل الدالة المعرّضة للثغرة) في الحزمة ذات الثغرة المعروفة يمكن الوصول إليها من شيفرة التطبيق. وهذا يتيح لنا استبعاد 70-90٪ من التنبيهات، لأنّه في حالات كثيرة لا تكون الثغرة في التبعية قابلة للوصول. ولمزيد من التفاصيل حول «تحليل قابلية الوصول»، يمكنك الاطّلاع على هذا المنشور.

3.7 فحص ثغرات الحاويات

ثمة طبقة أخرى تحتاج أيضًا إلى تأمين، وهي صور الحاويات المستخدمة، إذ إنّه على غرار حزم المصادر المفتوحة، قد تؤثّر ثغرات حزم صور الحاويات (مثل حزم deb أو apk) في أمان التطبيق.
ومن التدابير الوقائية استخدام صور حاويات بلا توزيعة (distroless) لا تحتوي على حزم غير ضرورية، ويُرقَّع عليها دوريًّا لتقليل الحزم ذات الثغرات، مثل Chainguard Images.
وإلى جانب ذلك، توجد أدوات يمكن استخدامها لفحص صور حاوياتك بحثًا عن الثغرات، مثل Trivy وGrype أو Docker Scout.
يُنصح باستخدام أدوات الفحص هذه كجزء من خط أنابيب بناء صورة الحاوية، وكذلك كمهمة مجدولة لتغطية الثغرات المكتشفة حديثًا.

3.8 فحص إعداد السحابة

وعلى نحو مشابه، إن كنت تنشر تطبيقك على مزوّد سحابي (مثل AWS أو GCP أو Azure)، فقد يؤثّر سوء ضبط الخدمات السحابية في أمان تطبيقك (مثل جعل حاوية S3 تحتوي على بيانات حسّاسة عامة، ما قد يكشف هذه البيانات الحسّاسة).
ومن ثمّ، يُنصح بفحص إعداد خدمتك السحابية دوريًّا بحثًا عن أخطاء الضبط، ولهذا يمكنك استخدام أدوات مثل checkov وcloudsploit أو Scout Suite

3.9 فحص إعداد SCM و CI/CD

ثمة طبقة أخرى قد تدخل الثغرات، وهي أدوات إدارة شيفرة المصدر (SCM) (مثل GitHub) أو أدوات CI/CD (مثل GitHub Actions أو CircleCI). مثل:
- غياب حماية الفروع (branch protection) قد يتيح لمهاجم إضافة شيفرة خبيثة إلى مستودعك.
- اختراق حزمة GitHub Actions (مثل اختراق الحزمة tj-actions/changed-files) قد يكشف أسرارك أو بيانات اعتمادك في الإنتاج.
ومن ثمّ، يُنصح بفحص إعداد أدوات SCM و CI/CD لديك، ولهذا يمكنك استخدام أدوات مثل legitify.

تلميح

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

الملخّص

للتذكير، هدف «DevSecOps» هو جعل الأمان يتحرّك بالوتيرة ذاتها التي تتحرّك بها DevOps، ولكي يحدث ذلك نحتاج إلى تعريف واضح لما يجب أن يكون تطبيقنا (تطبيقاتنا) آمنًا منه (التهديدات)، والضوابط التي نحتاج إلى تنفيذها للحماية منها (التخفيفات). ثم نحتاج إلى اختيار الأدوات والعمليات الصحيحة التي تساعدنا على التحقّق من أنّ هذه الضوابط تعمل كما هو متوقّع عبر جميع طبقات التطبيق.
أخيرًا، إليك رسم توضيحي يلخّص أدوات وعمليات DevSecOps المذكورة أعلاه، ومواءمتها مع طبقات التطبيق المختلفة.

شكل توضيحي: مواءمة أدوات وعمليات DevSecOps مع طبقات التطبيق المختلفة.

مصادر

دورة Certified DevSecOps Professional (CDP): دورة شهادة DevSecOps عملية تعتمد أساسًا على المختبرات.
استخدام نمذجة التهديدات لإنشاء خطّة DevSecOps: محاضرة حول استخدام نمذجة التهديدات لإنشاء خطّة DevSecOps.
مكتبة DevSecOps الشاملة: مكتبة تحتوي على قائمة بالأدوات والمنهجيات مصحوبة بمصادر.
Awesome DevSecOps: قائمة موثوقة بأدوات DevSecOps الرائعة بمساعدة تجارب المجتمع ومساهماته.
جامعة DevSecOps: مجموعة شاملة من موارد تعلّم DevSecOps مثل الكتب والدروس والإنفوجرافيك والأدوات وغيرها الكثير.

السابق DevOps - متقدّم التالي هندسة المنصّات - متقدّم