1. قبل البدء
مرحبًا بك في الدرس التطبيقي العملي حول الترميز بعنوان تأمين مسار CI/CD باستخدام CodeMender.
في عملية تسليم البرامج الحديثة، تُعدّ أدوات التحليل الثابت (مثل CodeQL) ضرورية لرصد الأنماط النحوية المعروفة، ولكنّها غالبًا ما تفوتها الثغرات الأمنية الدقيقة المخفية في عمق منطق النشاط التجاري وتُنشئ تنبيهات مزعجة وغير مؤكّدة.
تعمل أداة CodeMender (الملف التنفيذي لـ CLI: cm) على تحسين مسارَي التعلّم "الدمج المستمر" (CI) أو "النشر المستمر" (CD)، وذلك من خلال العمل جنبًا إلى جنب مع أدوات SAST الحالية، من خلال نشر وكلاء الاستدلال الأمني المستنِدين إلى Gemini من Google من أجل:
الكشف عن العيوب المعقّدة في منطق العمل: يمكنك تحليل سياق التطبيق وتدفّقات البيانات المعمارية بما يتجاوز قواعد الأنماط الثابتة الصارمة.
تقليل النتائج الموجبة الخاطئة بشكل كبير من خلال التحقّق من الاستغلال الذاتي: يمكنك إثبات قابلية الاستغلال ديناميكيًا في بيئات وضع الحماية قبل تنبيه المطوّرين.
معالجة النتائج التي تم التحقّق منها بشكل مستقل: يمكنك إنشاء رموز برمجية تصحيحية والتحقّق من صحتها من خلال حزم اختبارية لمنع حدوث تراجعات، وإرسال طلبات سحب جاهزة للمراجعة.
في هذا الدرس التطبيقي حول الترميز، ستدمج CodeMender في مستودع OWASP Juice Shop باستخدام GitHub Actions وخدمة Google Cloud Workload Identity Federation (WIF) بدون مفتاح.
المتطلبات الأساسية
- يُنصح بالإلمام الأساسي بمفاهيم CodeMender (المشمولة في دورة تأمين تطبيقك باستخدام CodeMender)
- فهم أساسي لمهام سير عمل GitHub Actions والمشغّلات وبنية YAML
- معرفة أساسية بأوامر Git وسير عمل مراجعة طلبات السحب
- معرفة أساسية بمفاهيم Google Cloud IAM (حسابات الخدمة والأدوار وواجهات برمجة التطبيقات)
- الإلمام بالثغرات الأمنية الشائعة في تطبيقات الويب (مثل SQL Injection وXSS)
ما ستتعلّمه
- كيفية ضبط المصادقة بدون مفتاح المستندة إلى نهج الثقة المعدومة بين GitHub Actions وGoogle Cloud من خلال Workload Identity Federation (WIF)
- كيفية إنشاء سير عمل آلي لفحص الثغرات الأمنية باستخدام CodeMender و
gemini-3.8-flash - كيفية نشر تقارير أمان قابلة للتنفيذ باستخدام OASIS SARIF v2.1.0 وملخّصات مهام GitHub Actions الأصلية
- كيفية إنشاء سير عمل إصلاح مستقل يُنشئ رموزًا برمجية تصحيحية تم التحقّق منها من خلال الاختبارات ويفتح طلبات سحب لمراجعتها من قِبل فريق
- كيفية فرض قيود صارمة على الجودة المبرمَجة (
--fail-on) وتخزين المسارات مؤقتًا لتوفير أمان مستمر عالي السرعة
المتطلبات
- مشروع على Google Cloud مع تفعيل الفوترة وأذونات مالك/محرِّر المشروع
- حساب على GitHub يملك أذونات لإنشاء مستودعات وضبط Secrets وإدارة Actions (يمكنك إنشاء نسخة من مستودع OWASP Juice Shop على GitHub في الخطوة 3 باستخدام واجهة سطر الأوامر في GitHub).
2. فهم بنية التكامل المستمر/التسليم المستمر في CodeMender
في عمليات DevSecOps الحديثة للمؤسسات، لا يمكن أن يكون الأمان المستند إلى الذكاء الاصطناعي مجرد أداة يدوية على الكمبيوتر المكتبي. يجب أن تعمل كـ حارس تلقائي (يحظر طلبات السحب غير الآمنة) ومطوّر مشارك مستقل (يقترح تصحيحات تم التحقّق منها مباشرةً في Git).
لتحقيق ذلك، عليك تنفيذ بنية سير عمل مزدوجة مستندة إلى Google Cloud Workload Identity Federation (WIF) ونماذج الاستدلال في Gemini Enterprise.
بنية سير العمل المزدوج
بدلاً من حشر عمليات الرصد والمعالجة في نص برمجي واحد ضخم، يفصل المسار الأمان إلى سيرَي عمل منفصلَين ومخصّصَين:
Workflow | المشغّل الأساسي | المسؤولية الأساسية | Quality Hard Gate |
1. برنامج كشف الثغرات( | طلبات السحب، وعمليات الدفع الرئيسية، وCron الأسبوعي، والإرسال اليدوي | • يُجري عمليات مسح AST تفاضلية سريعة على طلبات السحب (حوالي 15 ثانية)، وعمليات مسح أساسية سريعة على عمليات الدفع ( | حظر دمج طلبات الدمج في حال رصد ثغرات أمنية جديدة عالية الخطورة أو حرجة ( |
2. Autonomous Remediator( | التشغيل اليدوي ( | • يستأنف العمل من حيث توقّف استنادًا إلى بيانات الفحص ( | ضمان الحصول على اختلافات واضحة في الإنتاج قبل فتح طلب دمج |
المبادئ الثلاثة الأساسية لتصميم المؤسسات
أثناء إنشاء مهام سير العمل هذه في الأقسام القادمة، ضع في اعتبارك هذه الركائز المعمارية الأساسية الثلاث:
🔑 المصادقة بدون مفتاح والتحقّق من صحة البيانات قبل الإرسال وفقًا لنموذج "الثقة المعدومة":
لا يتم تخزين أي مفاتيح JSON طويلة الأمد لحسابات خدمة Google Cloud في GitHub Secrets. ينشئ المشغّل رمز OIDC مميزًا قصير الأجل يتم تبادله عبر Google Cloud STS للحصول على بيانات اعتماد مؤقتة لمدة ساعة واحدة، ويضبط persist-credentials: false على عمليات سحب Git، ويشغّل cm health --strict للتحقّق من بيانات الاعتماد وإمكانية الوصول إلى الشبكة وأذونات "إدارة الهوية وإمكانية الوصول" قبل استخدام حصة النموذج.
⚡ توجيه المسح التكيُّفي وكتم الضوضاء القديم:
بدلاً من إجراء عمليات تدقيق بطيئة للمستودع بالكامل في كل طلب سحب، يوجّه CodeMender كل حدث CI إلى وضع الفحص الأمثل: تؤدي طلبات السحب إلى تشغيل تحليل AST التفاضلي (--diff="origin/$BASE_REF") على الملفات المعدَّلة والمتصلين بخطوة واحدة في أقل من 15 ثانية، وتؤدي عمليات الدفع في الفرع الرئيسي إلى إجراء عمليات فحص أساسية سريعة لجلسة واحدة (--quick)، وتؤدي الجداول الأسبوعية إلى إجراء عمليات تدقيق متزامنة للملفات بعمق (الإعداد التلقائي cm find .). يتم تصنيف الثغرات الأمنية الموجودة مسبقًا في قاعدة الرموز البرمجية والتي لم يتم لمسها بواسطة طلب سحب على أنّها [LEGACY / UNTOUCHED]، وتظهر في تقارير SARIF لضمان وضوحها، ولكنّها لا تحظر بوابة دمج طلبات السحب ولا تؤدي إلى تشغيل الإصلاح التلقائي.
🛡️ إمكانية تتبّع البيانات الأمنية المرنة وغير المحظورة:
حتى عندما يخرج --fail-on بالرمز 1 لحظر طلب دمج غير آمن، فإنّ حماية خطوات تصدير التقارير وتحميل SARIF باستخدام steps.scan.outputs.completed == 'true' وhashFiles('results.sarif') != '' يضمن استمرار نشر تنبيهات OASIS SARIF وملخّصات المهام، مع تخطّي التصدير والتحميل بشكل نظيف في حال إلغاء عملية تشغيل أو إيقافها بسبب خطأ في الإعداد أو السعة (10–60).
3- المصادقة على المستودع المستهدَف وإعداده في Cloud Shell
لإعداد المصادقة بدون مفتاح وتشغيل مسارات الأمان المبرمَجة، تحتاج إلى مستودع GitHub مستهدَف يمكنك الوصول إليه وتملكه. في هذا الدرس التطبيقي حول الترميز، ستستخدم OWASP Juice Shop، وهو تطبيق ويب Node.js يتضمّن ثغرات أمنية بشكل متعمّد، كبيئة اختبار أمان جاهزة للاستخدام.
ستستخدم واجهة سطر الأوامر في GitHub (gh)، المثبّتة مسبقًا في Google Cloud Shell، للمصادقة مع GitHub، والحصول على تفاصيل المستخدم تلقائيًا، وإعداد المستودع في عملية واحدة سلسة.
الخطوة 1: فتح Cloud Shell ومصادقة GitHub CLI
افتح Google Cloud Console وفعِّل Cloud Shell (الرمز >_ في شريط التنقّل العلوي).
مصادقة GitHub CLI (gh) لضبط إدارة بيانات اعتماد Git:
gh auth login --hostname github.com --git-protocol https --web
اتّبِع التعليمات الظاهرة على الشاشة:
انسخ الرمز المكوّن من 8 أحرف والمطبوع في Cloud Shell (مثلاً، 1234-ABCD).
اضغط على Enter لفتح "https://github.com/login/device" في المتصفّح.
ألصِق الرمز وانقر على تفويض GitHub.
الخطوة 2: تصدير المتغيّرات ديناميكيًا وإنشاء نسخة من OWASP Juice Shop
نفِّذ الأوامر التالية في Cloud Shell لتسجيل اسم مستخدم GitHub تلقائيًا وإعداد المستودع:
# 1. Automatically capture your GitHub username (customize GITHUB_REPO if desired)
export GITHUB_ORG=$(gh api user -q .login)
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_ORG:+${GITHUB_ORG}/${GITHUB_REPO}}"
echo "Authenticated as: ${GITHUB_REPOSITORY}"
# 2. Fork on GitHub server using GITHUB_REPO as the fork name
gh repo fork juice-shop/juice-shop --fork-name "${GITHUB_REPO}" --default-branch-only --clone=false 2>/dev/null || true
# 3. Shallow clone your fork (downloads only ~15 MB in 3-5 seconds, skipping heavy upstream git history)
[ -d ~/"${GITHUB_REPO}" ] || git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}" || \
(sleep 2 && git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}")
cd ~/"${GITHUB_REPO}"
# 4. Confirm you are in the repository directory
git status
4. ضبط اتحاد Workload Identity في Google Cloud من خلال gcloud
في هذه الخطوة، ستستخدم واجهة سطر الأوامر (CLI) في gcloud في Google Cloud Shell لتفعيل واجهات برمجة التطبيقات المطلوبة، وإنشاء حساب خدمة مخصّص لعمليات التكامل والنشر المتواصلَين (CI/CD)، وإعداد مجموعة Workload Identity، وإنشاء علاقة ثقة مع OIDC في مستودع GitHub (${GITHUB_REPOSITORY}).
الخطوة 1: ضبط متغيّرات بيئة Google Cloud
في وحدة Terminal في Cloud Shell (داخل مساحة عمل المستودع المستنسَخ)، سجِّل رقم تعريف مشروع على السحابة الإلكترونية النشط في Google Cloud، وتحقَّق من متغيّر مستودع GitHub، وحدِّد أسماء موارد WIF:
# Capture active Google Cloud Project ID and verify GitHub repository
export PROJECT_ID=$(gcloud config get-value project)
export GITHUB_USER=$(gh api user -q ".login")
export GITHUB_REPO="${GITHUB_REPO:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*/##; s#\.git$##')}"
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_USER:+${GITHUB_USER}/${GITHUB_REPO}}"
# Define WIF and Service Account resource names
export WORKLOAD_IDENTITY_POOL="codemender-github-pool"
export WORKLOAD_IDENTITY_PROVIDER="codemender-github-provider"
export SERVICE_ACCOUNT_NAME="codemender-ci-runner"
if [ -z "${PROJECT_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: PROJECT_ID ('${PROJECT_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Check 'gcloud config get-value project' and 'gh auth status'."
else
echo "Project ID: ${PROJECT_ID}"
echo "GitHub Repository: ${GITHUB_REPOSITORY}"
fi
الخطوة 2: تفعيل واجهات Google Cloud API المطلوبة
فعِّل واجهات برمجة التطبيقات التالية: IAM API وSecurity Token Service API وIAM Credentials API وAgent Platform API وResource Manager API:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
الخطوة 3: إنشاء حساب خدمة مخصّص للتكامل المستمر والنشر المستمر
أنشئ حساب خدمة Google Cloud بأقل امتيازات مخصّص لتنفيذ مسار CI/CD (مع إعادة استخدامه بأمان إذا كان متوفّرًا):
export SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts describe "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" >/dev/null 2>&1 || \
gcloud iam service-accounts create "${SERVICE_ACCOUNT_NAME}" \
--display-name="CodeMender CI/CD Pipeline Runner" \
--project="${PROJECT_ID}"
echo "Service Account Email: ${SERVICE_ACCOUNT_EMAIL}"
الخطوة 4: منح أذونات "إدارة الهوية وإمكانية الوصول" (IAM) في Agent Platform
امنح دور roles/aiplatform.user (مستخدم Agent Platform) لحساب الخدمة ليتمكّن من التواصل مع Gemini Enterprise Agent Platform:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
الخطوة 5: إنشاء مجموعة Workload Identity
أنشئ مجموعة Workload Identity لإدارة تأكيدات هوية GitHub Actions (أو استعِدها وفعِّلها تلقائيًا إذا كانت متوفّرة في مشروعك):
POOL_STATE=$(gcloud iam workload-identity-pools list \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_POOL}$" \
--format="value(state)")
if [ -z "${POOL_STATE}" ]; then
gcloud iam workload-identity-pools create "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Pool" \
--project="${PROJECT_ID}"
else
[ "${POOL_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools undelete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools update "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--no-disabled \
--project="${PROJECT_ID}"
fi
الخطوة 6: إنشاء موفِّر Workload Identity باستخدام GitHub OIDC
أنشِئ (أو عدِّل) موفِّر OIDC داخل المجمّع، واربط عنوان URL لجهة الإصدار https://token.actions.githubusercontent.com واربط تأكيدات رمز GitHub المميّز بسمات Google STS:
PROVIDER_STATE=$(gcloud iam workload-identity-pools providers list \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_PROVIDER}$" \
--format="value(state)")
if [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: GITHUB_REPOSITORY is empty. Re-run Step 1 before configuring the OIDC provider."
elif [ -z "${PROVIDER_STATE}" ]; then
gcloud iam workload-identity-pools providers create-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Provider" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--project="${PROJECT_ID}"
else
[ "${PROVIDER_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools providers undelete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--no-disabled \
--project="${PROJECT_ID}"
fi
الخطوة 7: السماح لمستودع GitHub بانتحال هوية حساب الخدمة
اربط دور roles/iam.workloadIdentityUser للسماح للرموز المميّزة الصادرة من مستودعك بانتحال هوية حساب خدمة مشغّل CI، وتحقَّق من ربط السياسة:
# Retrieve the canonical Workload Identity Pool resource ID
export POOL_ID=$(gcloud iam workload-identity-pools describe "${WORKLOAD_IDENTITY_POOL}" \
--project="${PROJECT_ID}" \
--location="global" \
--format="value(name)")
if [ -z "${POOL_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: POOL_ID ('${POOL_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Re-run Step 1 and Step 5."
else
# Bind Workload Identity User role to the principalSet of your repository
gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/${POOL_ID}/attribute.repository/${GITHUB_REPOSITORY}"
# Verify the principalSet binding on the Service Account
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}"
fi
الخطوة 8: استرداد قيم الإعدادات لرموز GitHub السرية
استرِدّ اسم المورد الكامل لموفّر هوية أعباء العمل Workload Identity Provider وخزِّنه في متغيّر بيئة للتسجيل الآلي في الخطوة التالية:
# Retrieve full Workload Identity Provider name
export WORKLOAD_PROVIDER_NAME=$(gcloud iam workload-identity-pools providers describe ${WORKLOAD_IDENTITY_PROVIDER} \
--workload-identity-pool=${WORKLOAD_IDENTITY_POOL} \
--location="global" \
--project=${PROJECT_ID} \
--format="value(name)")
echo "=========================================================="
echo "WIF CONFIGURATION READY:"
echo "=========================================================="
echo "GCP_WORKLOAD_IDENTITY_PROVIDER: ${WORKLOAD_PROVIDER_NAME}"
echo "GCP_SERVICE_ACCOUNT: ${SERVICE_ACCOUNT_EMAIL}"
echo "=========================================================="
5- ضبط أسرار مستودع GitHub وأذونات سير العمل
بعد إعداد Google Cloud WIF، عليك ضبط GitHub Repository Secrets ومنح أذونات سير العمل اللازمة لإجراء عمليات فحص الأمان المبرمَجة وطلبات السحب الخاصة بالمعالجة التلقائية.
يمكنك ضبط هذه الإعدادات مباشرةً من Cloud Shell باستخدام GitHub CLI (gh)، ما يغنيك تمامًا عن نسخ أسماء الموارد الطويلة ولصقها يدويًا.
الخطوة 1: ضبط أسرار المستودع باستخدام GitHub CLI
في وحدة Cloud Shell الطرفية، نفِّذ الأوامر التالية لضبط سرَّي المستودع المطلوبَين بأمان باستخدام متغيّرات البيئة النشطة:
# 1. Set the Workload Identity Provider resource name
gh secret set GCP_WORKLOAD_IDENTITY_PROVIDER \
--body "${WORKLOAD_PROVIDER_NAME}" \
--repo "${GITHUB_REPOSITORY}"
# 2. Set the CI/CD Service Account email
gh secret set GCP_SERVICE_ACCOUNT \
--body "${SERVICE_ACCOUNT_EMAIL}" \
--repo "${GITHUB_REPOSITORY}"
# 3. Verify the secrets are registered
gh secret list --repo "${GITHUB_REPOSITORY}"
الخطوة 2: منح أذونات سير العمل لطلبات المراجعة الآلية
بشكل تلقائي، يتم تشغيل مهام سير عمل GitHub Actions بأذونات القراءة فقط ولا يمكنها إنشاء طلبات سحب. في الخطوة 9، سينشئ CodeMender طلبات سحب تم التحقّق منها لإصلاح الثغرات الأمنية ويرسلها بشكل مستقل.
امنح إذن تعديل وفعِّل إنشاء طلبات السحب مباشرةً من خلال GitHub API:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
/repos/${GITHUB_REPOSITORY}/actions/permissions/workflow \
-f default_workflow_permissions="write" \
-F can_approve_pull_request_reviews=true
الخطوة 3: إيقاف سير عمل Juice Shop الموروث من المصدر
يؤدي تفريع OWASP Juice Shop إلى نقل أكثر من 16 سير عمل للتكامل المستمر (CI) في المصدر (مثل PR Compliance Check وCI/CD Pipeline وCodeQL Scan) بالإضافة إلى نموذج طلب دمج (PR) للمساهمين في المصدر يغلق تلقائيًا طلبات الدمج التي تستهدف master. أوقِف جميع مهام سير العمل غير المتعلّقة بـ CodeMender من خلال GitHub CLI وأزِل ملفات المصدر على جهازك لكي يشغّل الفرع مهام سير عمل CodeMender فقط:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
# 1. Disable all inherited non-CodeMender workflows in GitHub Actions (and CodeQL default setup if active)
for WF_ID in $(gh workflow list --all --limit 100 --repo "${GITHUB_REPOSITORY}" --json id,path \
-q '.[] | select((.path | startswith(".github/workflows/")) and (.path | test("codemender-") | not)) | .id'); do
gh workflow disable "${WF_ID}" --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
done
gh api -X PATCH "/repos/${GITHUB_REPOSITORY}/code-scanning/default-setup" \
-f state=not-configured >/dev/null 2>&1 || true
# 2. Remove upstream workflow files and PR template from the local workspace
for f in .github/workflows/*; do
case "$f" in *codemender-*) ;; *) rm -f "$f" ;; esac
done
rm -f .github/PULL_REQUEST_TEMPLATE.md
6. إنشاء سير عمل مبرمَج لكشف الثغرات باستخدام SARIF
في هذه الخطوة، ستنشئ سير العمل الأساسي للفحص الأمني المستمر (.github/workflows/codemender-scan.yml) الذي يُجري عمليات فحص أساسية على عمليات الدفع في الفروع، وبوابات التفاضل في طلبات السحب، وعمليات تصدير SARIF إلى ميزة "فحص الرموز البرمجية" في GitHub.
الخطوة 1: تنزيل سير عمل الفحص في CodeMender
نزِّل codemender-scan.yml من مستودع المبتدئين إلى .github/workflows/:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-scan.yml \
-o .github/workflows/codemender-scan.yml
الخطوة 2: تنفيذ التغييرات وإرسالها وتشغيل فحص CI
احفظ التغييرات في سير العمل وانشرها مباشرةً في الفرع الأساسي للمستودع (master لـ Juice Shop أو main):
# Stage workflow changes, commit, and push to primary branch
git add -A .github
git commit -m "ci: add CodeMender SARIF security scanning workflow"
git push origin $(git branch --show-current)
في المتصفّح:
انتقِل إلى مستودع GitHub الذي تم نسخه: https://github.com/YOUR_GITHUB_USER/juice-shop (مثلاً، https://github.com/octocat/juice-shop).
انقر على علامة التبويب الإجراءات في شريط التنقّل العلوي.
في الشريط الجانبي الأيمن ضِمن Workflows (مهام سير العمل)، اختَر CodeMender Security Scan & SARIF Export (فحص الأمان وتصدير SARIF في CodeMender).
شغِّل تنفيذ سير العمل أو اعرضه:
التشغيل التلقائي: إذا تم إدراج عملية تشغيل تلقائية ناتجة عن عملية الدفع، انقر عليها مباشرةً لمراقبة التنفيذ المباشر.
التشغيل اليدوي عند الطلب (workflow_dispatch): إذا لم يبدأ أي تشغيل بعد، انقر على الزر Run workflow ▾ (تشغيل سير العمل ▾) على يسار الصفحة، وتأكَّد من اختيار Branch: master (اترك مربّع الاختيار deep_scan فارغًا حتى يتم تشغيل الفحص الأساسي السريع لـ --quick)، ثم انقر على الزر الأخضر Run workflow (تشغيل سير العمل).
انقر على عملية التنفيذ واختَر فحص ثغرات الرموز البرمجية المستقل لمشاهدة سير العمل في الوقت الفعلي.
داخل ملف codemender-scan.yml: توجيه عمليات الفحص المستندة إلى الأحداث
أثناء تشغيل فحص --quick الأساسي في السحابة الإلكترونية (يستغرق من 3 إلى 5 دقائق تقريبًا)، يمكنك الاطّلاع على كيفية توجيه codemender-scan.yml (الأسطر 118-155) لكل حدث في GitHub إلى وضع الفحص المخصّص له داخل المشغّل:
# Excerpt from .github/workflows/codemender-scan.yml
if [ "${{ github.event_name }}" = "pull_request" ]; then
cm find . \
--diff="origin/${{ github.base_ref }}" \
--diff-workers=16 \
--fail-on="CRITICAL,HIGH" \
--sandbox=false --yes --bypass-warning || status=$?
elif [ "${{ github.event_name }}" = "schedule" ] || [ "${{ github.event.inputs.deep_scan }}" = "true" ]; then
cm find . \
--deep-workers=8 \
--sandbox=false --yes --bypass-warning || status=$?
else
cm find . \
--quick \
--sandbox=false --yes --bypass-warning || status=$?
fi
إعداد Runner المحصَّن ( الأسطر من 27 إلى 117): يتخطّى طلبات التفريع والدمج الخارجية غير الموثوق بها من dependabot[bot]، ويتحقّق من persist-credentials: false، ويخزّن ~/.local/bin/cm و~/.codemender/state.db مؤقتًا، ويشغّل cm health --strict قبل استهلاك حصة النموذج.
حدود وضع الحماية بدون واجهة مستخدم رسومية (--sandbox=false --yes --bypass-warning): يوقف هذا الإعداد عزل مساحة أسماء مستخدمي Linux (المحصورة داخل حاويات GitHub Actions غير المميّزة) مع الإبقاء على حدود مسار مساحة العمل (project_paths) وcommand_policy.yaml مفروضة.
تصدير SARIF والملفات المحفوظة المحمية برمز الخروج ( الأسطر 147–194): يتم ضبط steps.scan.outputs.completed=true بدقة عندما يخرج cm find مع 0 (نظيف) أو 1 (تم استيفاء الحد الأدنى لـ --fail-on). يضمن ذلك استمرار نشر تقارير SARIF (cm report -f sarif مع درجات خطورة CVSS) وجداول $GITHUB_STEP_SUMMARY (cm report -f md) وملفات codemender-findings.json عندما يحظر --fail-on طلب دمج، مع تخطّي التصدير في حال حدوث أخطاء في الإعداد أو السعة (10–60) كي لا تؤدي ملفات SARIF الفارغة إلى إغلاق التنبيهات الحالية.
7. فحص تنبيهات GitHub Code Scanning ولوحة بيانات الأمان
بعد انتهاء سير عمل الإرسال الأساسي، يعالج GitHub ملف SARIF الذي تم تحميله ويملأ كلاً من ملخّص تشغيل الإجراءات وعلامة التبويب "الأمان" (Security) في المستودع.
الخطوة 1: فحص ملخّص المهمة الأصلي في GitHub Actions
يُضيف كل سير عمل جدول ملخّص Markdown (cm report -f md) مباشرةً إلى نظرة عامة على سير عمل GitHub Actions:
في مستودع GitHub، انقر على علامة التبويب الإجراءات (Actions).
اختَر عملية التشغيل المكتملة CodeMender Security Scan & SARIF Export (تنتهي عمليات تدقيق عمليات الدفع في الفرع الأساسي بعلامة اختيار خضراء ✅ بعد نشر نتائج SARIF).
انتقِل للأسفل إلى قسم 🛡️ ملخّص فحص الأمان في CodeMender للاطّلاع على تفاصيل النتائج:
🔒 تقرير الأمان من CodeMender
ملخّص
إجمالي النتائج: 28
درجة الفداحة | العدد |
🔴 خطيرة | 6 |
🟠 مرتفع | 16 |
🟡 متوسط | 6 |
الحالة | العدد |
🔴 مفتوح | 28 |
النتائج
المعرّف | درجة الفداحة | الثقة | الحالة | إصلاح | ملفّ | اللقب |
| 🔴 خطيرة | 100% | مفتوح | — |
| تنفيذ الرموز البرمجية عن بُعد من خلال إضافة الرموز البرمجية من جهة الخادم في ملف المستخدم الشخصي |
| 🔴 خطيرة | 100% | مفتوح | — |
| هجوم حقن SQL في مسار مصادقة المستخدم |
| 🔴 خطيرة | 100% | مفتوح | — |
| Remote Code Execution via Sandbox Escape in B2B Order Processing |
الخطوة 2: استكشاف لوحة البيانات المركزية لميزة "فحص الرموز"
في شريط التنقّل العلوي في مستودع GitHub، انقر على علامة التبويب الأمان والجودة (Security and quality) (أو الأمان (Security)).
في الشريط الجانبي الأيمن ضمن النتائج (Findings)، اختَر فحص الرمز البرمجي (Code scanning).
إذا كانت هناك أدوات متعددة نشطة، يمكنك فلترة الأداة إلى CodeMender (is:open branch:master tool:CodeMender) لفحص التنبيهات التي تم ربطها بشارات خطورة CVSS الأصلية:
شارة الخطورة | Vulnerability Headline | الموقع الجغرافي الذي تم رصده | Branch |
🔴 مهمة | تنفيذ الرموز البرمجية عن بُعد من خلال إضافة الرموز البرمجية من جهة الخادم في ملف المستخدم الشخصي |
|
|
🔴 خطيرة | هجوم حقن SQL في مسار مصادقة المستخدم |
|
|
🔴 مهمة | Remote Code Execution via Sandbox Escape in B2B Order Processing |
|
|
انقر على حقن SQL في مسار مصادقة المستخدم (routes/login.ts:34) لمراجعة تدفق البيانات الملوّثة وتحليل السبب الأساسي الذي أنشأه Gemini.
8. حظر طلب سحب غير آمن باستخدام الفحص التفاضلي
كشف الفحص الأساسي عن 28 ثغرة أمنية موجودة مسبقًا في OWASP Juice Shop. باستخدام أدوات التحليل الثابتة التقليدية، ستؤدي هذه النتائج الـ 28 القديمة إلى فشل كل طلب سحب مستقبلي إلى أن يتم إصلاح جميع المشاكل المتراكمة، ما يجبر الفِرق على إيقاف ميزة حظر الدمج.
والآن، ستختبرون PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") في CodeMender: افتحوا طلب دمج يتضمّن ثغرة أمنية جديدة وراقبوا كيف يعزل CodeMender التغييرات، ويحظر الدمج في غضون 15 إلى 25 ثانية تقريبًا، ويضيف تعليقات توضيحية إلى الأسطر التي تتضمّن الثغرة.
الخطوة 1: فتح طلب سحب يتضمّن ثغرة حقن الأوامر
في Cloud Shell (داخل مساحة عمل المستودع المستنسَخ)، أنشئ فرعًا للميزة، وأضِف مسار Express جديدًا يحتوي على ثغرة أمنية من نوع "حقن أوامر نظام التشغيل"، وافتح طلب دمج في المستودع الفرعي:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
# Reset any previous demo PR/branch so this step can be re-run cleanly
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch 2>/dev/null || true
git checkout "${PRIMARY_BRANCH}"
git checkout -B feat/diagnostics
# Introduce an Express endpoint vulnerable to OS Command Injection (CWE-78)
cat << 'EOF' > routes/diagnostics.ts
import { execSync } from 'node:child_process'
import { type Request, type Response } from 'express'
export function systemDiagnostics () {
return (req: Request, res: Response) => {
const host = String(req.query.host ?? '127.0.0.1')
const output = execSync(`ping -c 1 ${host}`).toString()
res.status(200).json({ status: 'ok', output })
}
}
EOF
git add routes/diagnostics.ts
git commit -m "feat: add network diagnostics endpoint"
git push -f -u origin feat/diagnostics
gh pr create \
--repo "${GITHUB_REPOSITORY}" \
--base "${PRIMARY_BRANCH}" \
--head feat/diagnostics \
--title "feat: add network diagnostics endpoint" \
--body "Adds a ping diagnostics handler."
الخطوة 2: التحقّق من بوابة الدمج التفاضلي والتعليقات التوضيحية المضمّنة لطلبات المراجعة
افتح عنوان URL الخاص بطلب السحب المطبوع في نهاية مخرجات الوحدة الطرفية.
انتقِل إلى مربّع Checks (عمليات التحقّق) في أسفل صفحة محادثة طلب السحب وشاهِد Autonomous Code Vulnerability Scan (فحص ثغرات الرموز البرمجية المستقل):
سرعة Delta: بدلاً من فحص جميع الملفات التي يزيد عددها عن 680 ملفًا في المستودع (يستغرق ذلك من 3 إلى 5 دقائق تقريبًا)، يحصر cm find . --diff="origin/${PRIMARY_BRANCH}" التحليل بدقة في routes/diagnostics.ts (وأي متصلين من قفزة واحدة)، ويكمل الفحص في من 15 إلى 25 ثانية تقريبًا.
عزل الديون القديمة وحظر الدمج: لا تفشل أي من الثغرات الأمنية القديمة الـ 28 التي لم يتم لمسها في Juice Shop في عملية التحقّق، بل إنّ ثغرة CRITICAL حقن الأوامر التي تم تقديمها حديثًا هي فقط التي تؤدي إلى تشغيل --fail-on="CRITICAL,HIGH"، والخروج برمز الحالة 1 (علامة ❌ حمراء) لحظر دمج طلبات الدمج.
انقر فوق علامة التبويب Files changed (الملفات التي تم تغييرها) في الجزء العلوي من طلب السحب:
بما أنّ حارس رمز الخروج (steps.scan.outputs.completed == 'true') في سير العمل لا يزال يصدّر results.sarif ويحمّله عندما يخرج --fail-on بالرمز 1، فإنّ ميزة GitHub Code Scanning تعرض تعليقًا توضيحيًا مضمّنًا للأمان بعنوان CodeMender — Critical تحت execSync مباشرةً في routes/diagnostics.ts.
الخطوة 3: تنظيف طلب المراجعة التجريبي والعودة إلى الفرع الأساسي
يُرجى تبديل مساحة عمل Cloud Shell إلى الفرع الأساسي وإغلاق طلب الدمج الاختباري غير الآمن قبل المتابعة إلى الإصلاح الذاتي:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
git checkout "${PRIMARY_BRANCH}"
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch
git branch -D feat/diagnostics 2>/dev/null || true
9. إنشاء سير عمل الإصلاح الذاتي وطلبات السحب التلقائية
بعد أن يمنع حاجز طلبات السحب دخول ثغرات أمنية جديدة إلى قاعدة الرموز البرمجية، ستنشر المعالجة الذاتية (.github/workflows/codemender-remediate.yml) لإصلاح الثغرات الأمنية الحالية بشكل نشط وفتح طلبات سحب جاهزة للمراجعة.
الخطوة 1: تنزيل ملف سير عمل المعالجة
يوفّر CodeMender نموذجين للمعالجة استنادًا إلى مستوى ظهور المستودع:
المستودعات العامة/المفتوحة المصدر (codemender-remediate.yml): وضع الإفصاح المسؤول: يربط بتنبيهات SARIF الخاصة بفحص الرموز البرمجية في GitHub بدون الكشف عن متجهات الاستغلال الأولية بشكل علني.
المستودعات الخاصة / مستودعات المؤسسات (codemender-remediate-private-repo.yml): وضع أدلة التدقيق الداخلي: يضمّن عناصر التحقّق (PLAN.md وREPORT.md وexploit.sh) داخل أقسام طلبات الدمج القابلة للتصغير مع استبعادها من عمليات الإرسال في Git.
نزِّل سير عمل المعالجة الآمن للجميع في المستودع:
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate.yml \
-o .github/workflows/codemender-remediate.yml
الخطوة 2: تنفيذ سير عمل المعالجة الذاتية وتفعيله
نفِّذ سير عمل المعالجة وادفع به إلى الفرع الأساسي:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
في المتصفّح، انتقِل إلى علامة التبويب الإجراءات (Actions) في مستودع GitHub.
في الشريط الجانبي الأيمن ضمن Workflows (مهام سير العمل)، اختَر CodeMender Autonomous Security Remediation & Auto-PR (المعالجة الأمنية المستقلة وطلب الدمج التلقائي في CodeMender).
انقر على القائمة المنسدلة Run workflow (تشغيل سير العمل) الخضراء على يسار الصفحة:
Use workflow from (استخدام سير العمل من): تأكَّد من اختيار الفرع التلقائي (master).
رقم تعريف النتيجة المحدّدة أو البادئة المطلوب إصلاحها: أدخِل البادئة المكوّنة من 8 أحرف لـ routes/login.ts المذكورة في الخطوة 7 (على سبيل المثال، cd47b38a). يؤدي ترك هذا الحقل فارغًا إلى تنفيذ عملية المعالجة المجمّعة لجميع النتائج المفتوحة ذات الأهمية "حرجة" و"عالية" (تستغرق من 10 إلى 15 دقيقة تقريبًا)، بينما يكتمل استهداف رقم تعريف واحد في 45 إلى 60 ثانية تقريبًا.
انقر على الزر الأخضر Run workflow (تشغيل سير العمل) داخل النافذة المنبثقة وافتح عملية التشغيل الجارية.
داخل ملف codemender-remediate.yml: إنشاء رموز تصحيح مستقلة
بينما يُنشئ CodeMender التصحيح في السحابة الإلكترونية (يستغرق ذلك من 30 إلى 45 ثانية تقريبًا)، يمكنك الاطّلاع على كيفية تنظيم codemender-remediate.yml (الأسطر 111-184) لعملية المعالجة داخل المشغّل:
استئناف بدون فحص (cm report import): يتم تنزيل العنصر codemender-findings.json من سير عمل الفحص واستيراده إلى مساحة العمل (cm report import -f codemender-findings.json)، مع الرجوع إلى cm find . --quick فقط في حال عدم توفّر عنصر سابق.
Headless Patch Synthesis (cm fix): يثبّت project_paths على $GITHUB_WORKSPACE، ويوجّه < /dev/null لمنع حالات التوقف التفاعلية، ويمرّر --no-reset أثناء عمليات التكرار الحلقي المجمّعة، ما يتيح الحفاظ على الإصلاحات التراكمية في جميع النتائج:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
عمليات دمج الإصدار العلني النظيفة ( الأسطر 155-252): يتم حذف .cm_project و.exploit/ والملفات المؤقتة من خلال .git/info/exclude قبل أن يفتح peter-evans/create-pull-request@v8 الفرع (codemender/auto-remediation-${{ github.run_id }})، مع دمج تغييرات رمز الإصدار العلني فقط:
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -28,8 +28,8 @@ module.exports = function login () {
- models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User })
+ models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+ replacements: { email: req.body.email || '', password: security.hash(req.body.password || '') },
+ model: models.User
+ })
الخطوة 3: مراجعة طلب السحب الذي تم فتحه حديثًا على GitHub
انتقِل إلى علامة التبويب طلبات السحب (Pull requests) في المستودع وافتح طلب السحب الجديد (مثلاً، 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
انقر على الملفات التي تم تغييرها للتأكّد من تعديل routes/login.ts فقط، مع استبعاد جميع البيانات الوصفية الداخلية لوقت التشغيل.
راجِع وصف طلب الدمج الذي يرتبط مباشرةً بتنبيه فحص الرموز البرمجية في GitHub (SARIF) للحصول على موافقة المشرف.
10. تحديد المشاكل وحلّها في الحالات الحدّية والمستودعات الخاصة
المستودعات الخاصة بدون GitHub Advanced Security (GHAS)
تتلقّى مستودعات GitHub العلنية عمليات استيعاب مجانية وغير محدودة لملفات SARIF من GitHub Code Scanning. ومع ذلك، إذا نشرت سير العمل هذا في مستودع خاص لمؤسسة لا يتضمّن ترخيصًا نشطًا لـ GitHub Advanced Security (GHAS)، ستتعذّر خطوة upload-sarif مع ظهور الرسالة التالية:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
الحلّ: استخدام تقرير HTML التفاعلي المستقل كبديل
تُنشئ أداة إنشاء تقارير HTML المضمّنة في CodeMender (cm report -f html) لوحة بيانات أمان تفاعلية ومستقلة تتضمّن بطاقات مقاييس الخطورة ومقتطفات رموز مميّزة مع أرقام الأسطر وعارضًا مضمّنًا لملفات التصحيح بدون أي تبعيات ويب خارجية.
لإتاحة المستودعات الخاصة بدون ترخيص GHAS، يجب تعديل .github/workflows/codemender-scan.yml لأرشفة تقرير HTML بدلاً من تحميل SARIF:
إنشاء تقرير HTML مستقل: في الخطوة Export Security Reports & Publish Job Summary، يمكنك تصدير لوحة بيانات HTML مع ملخّص Markdown باستخدام cm report -f html > codemender-audit-report.html.
أرشِف التقرير كعنصر في سير العمل: استبدِل الخطوة Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) بـ actions/upload-artifact@v4 التي تم ضبطها لتحميل codemender-audit-report.html (على سبيل المثال، ضمن اسم العنصر codemender-security-report).
الفحص محليًا في أي متصفّح: نزِّل codemender-security-report.zip مباشرةً من صفحة ملخّص سير عمل GitHub Actions، واستخرِج الملفات، وافتح codemender-audit-report.html في أي متصفّح ويب لإجراء فحص مرئي.
المعالجة الذاتية للمستودعات الخاصة مع أدلة التدقيق المضمّنة
في المستودعات الخاصة بالشركات، تحتاج فِرق الهندسة والأمان إلى الاطّلاع الكامل على تحليل السبب الأساسي وإثبات جدوى الفكرة وخطة المعالجة بدون الحاجة إلى لوحات بيانات الأدوات الخارجية. ومع ذلك، فإنّ إرسال نصوص برمجية للاستغلال (exploit.sh) أو ملفات Markdown داخلية (PLAN.md وLOG.md) إلى فرع المستودع يؤدي إلى تلويث سجلّ git ويمكن أن يؤدي إلى ظهور تنبيهات خاطئة من أدوات فحص الأمان الأخرى.
لمعالجة هذه المشكلة، يمكنك نشر سير عمل معالجة المستودعات الخاصة المخصّص (codemender-remediate-private-repo.yml):
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate-private-repo.yml \
-o .github/workflows/codemender-remediate.yml
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: switch to private repository remediation workflow with embedded audit evidence"
git push origin $(git branch --show-current)
طريقة عمل معالجة المستودعات الخاصة
التحقّق الديناميكي من إثبات جدوى الفكرة (cm verify): يتم تجميع واختبار برنامج استغلالي عامل قبل إنشاء الإصلاح لتأكيد قابلية الاستغلال، مع تخطّي cm fix تلقائيًا إذا حدّد التحقّق نتيجة غير قابلة للاستغلال على أنّها DISMISSED.
Embedded PR Audit Collapsibles: يستخرج REPORT.md وPLAN.md وexploit.sh إلى /tmp/codemender-evidence/ وينسّقها مباشرةً في وصف طلب السحب داخل كتل <details open> قابلة للتصغير ليتمكّن المراجع من فحصها بنقرة واحدة.
أرشفة العناصر: تتم أرشفة مجلد الأدلة بالكامل من خلال actions/upload-artifact@v4.
عمليات Git Commits الجديدة تمامًا: يتم حذف جميع البيانات الوصفية لوقت التشغيل وأدلة .exploit لكي تحتوي عملية Git Commit لطلب السحب على تغييرات رمز الإنتاج فقط.
قائمة التحقّق من تحديد مشاكل Workload Identity Federation (WIF) وحلّها
يكتب google-github-actions/auth@v2 تلقائيًا ملف إعداد بيانات اعتماد موحّدة على الجهاز أثناء عملية الإعداد، ويتم تبادل الرمز المميّز الفعلي لبروتوكول OAuth 2.0 عند بدء تشغيل cm health --strict أو cm find. استخدِم قائمة التحقّق أدناه لتشخيص أخطاء مصادقة HTTP 400 أو HTTP 403:
مؤشر الخطأ | السبب الأساسي الشائع | التحقّق والإصلاح |
HTTP 403 (تم رفض | عدم توفّر ربط | يُرجى التأكّد من أنّ |
HTTP 400 (تم رفض | لا يتطابق اسم مستودع OIDC | أعِد تنفيذ الخطوة 4 (الخطوتَين 1 و6) مع التأكّد من أنّ |
HTTP 400 ( | تنسيق | تأكَّد من ضبط |
خطأ HTTP 403 مؤقت بعد الإعداد مباشرةً | قد يستغرق نشر "إدارة الهوية وإمكانية الوصول" و"اتحاد Workload Identity" على مستوى العالم من دقيقة إلى 5 دقائق في عمليات الربط التي تم إنشاؤها حديثًا. | انتظِر لمدة دقيقة أو دقيقتَين، ثم انقر على إعادة تشغيل المهام التي تعذّر تنفيذها (Re-run failed jobs) في GitHub Actions. |
لفحص ربط Workload Identity المباشر في حساب خدمة CI/CD في Cloud Shell، نفِّذ الأمر التالي:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
تأكَّد من أنّ الناتج يربط roles/iam.workloadIdentityUser بـ principalSet://iam.googleapis.com/<POOL_ID>/attribute.repository/<GITHUB_USER>/<GITHUB_REPO>:
--- bindings: members: principalSet://iam.googleapis.com/.../attribute.repository/<OWNER>/<REPO> role: roles/iam.workloadIdentityUser
تحديد المشاكل وحلّها في ما يتعلّق بالتحقّق الأولي من CI/CD ورمز الخروج من واجهة سطر الأوامر
تُعرِض أوامر CodeMender (cm health --strict وcm find وcm verify وcm fix) رموز خروج حتمية، ما يتيح لمسارات CI/CD التمييز على الفور بين نتائج الأمان وأخطاء الإعداد أو الخدمة:
رمز الخروج | Category (الفئة) | السبب الأساسي الشائع والمعالجة |
| تم الإجراء بنجاح | تم اجتياز عمليات التحقّق من السلامة أو اكتمل الفحص بدون العثور على أي مشاكل تؤدي إلى الحظر. |
| أدوات جمع قطع المجوهرات / عامة | تم رصد ثغرات أمنية من قِبل |
|
| تعذَّر تبادل رموز OAuth/ADC المميزة في WIF ( |
|
| بنية |
|
| يتعذّر على Runner الوصول إلى |
|
| لا يتوفّر دور |
|
| تجاوز فحص Preflight |
|
| بلغ الوكيل الحدّ الأقصى المسموح به للمهام النشطة المتزامنة. يُرجى إعادة تشغيل سير العمل بعد فترة قصيرة. |
للاطّلاع على الأخطاء الإضافية أثناء التشغيل، مثل حلّ الفرع الأساسي لـ Git diff (fetch-depth: 0) أو تأخيرات نشر الموارد أو أذونات إنشاء طلبات السحب في GitHub Actions، يُرجى الرجوع إلى دليل تحديد مشاكل CodeMender CI/CD وحلّها الرسمي.
11. حذف الموارد
لمنع استهلاك الموارد المستمر أو تنظيف إعدادات الاختبار في بيئات Google Cloud وGitHub، نفِّذ خطوات التنظيف التالية.
الخطوة 1: إزالة أسرار مستودع GitHub وإيقاف مهام سير العمل من خلال واجهة سطر الأوامر gh
استخدِم واجهة سطر الأوامر في GitHub (gh) لحذف أسرار الإجراءات في المستودع نهائيًا وإيقاف مهام سير عمل CodeMender:
# Delete the repository Actions secrets
gh secret delete GCP_WORKLOAD_IDENTITY_PROVIDER --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh secret delete GCP_SERVICE_ACCOUNT --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
# Disable the CodeMender workflows to prevent unwanted automatic triggers
gh workflow disable codemender-scan.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh workflow disable codemender-remediate.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
الخطوة 2: إيقاف أو حذف موارد Google Cloud Workload Identity Federation
لا تفرض مجموعات Workload Identity وموفّروها وحسابات الخدمة أي تكلفة في حال عدم النشاط عند عدم تبادل الرموز المميّزة. اختَر وضع التنظيف الذي يتطابق مع سير العمل:
الخيار "أ" - إيقاف إمكانية الوصول مؤقتًا (يُنصح به إذا كنت تخطّط لإعادة تشغيل المشروع): يؤدي هذا الخيار إلى إيقاف تبادل الرموز المميّزة لبروتوكول OIDC على الفور بدون تفعيل فترة الاحتفاظ بالبيانات المحذوفة نهائيًا لمدة 30 يومًا في Google Cloud IAM أو تأخيرات نشر حساب الخدمة uniqueId:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
الخيار "ب" - الإزالة الكاملة: يؤدي هذا الخيار إلى حذف موفِّر خدمة اتحاد الهوية على الويب ومجموعة الموارد (يتم الاحتفاظ بها في حالة DELETED لمدة 30 يومًا) وحساب الخدمة المخصّص:
# Delete Workload Identity Provider
gcloud iam workload-identity-pools providers delete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete Workload Identity Pool
gcloud iam workload-identity-pools delete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete CI/CD Service Account
gcloud iam service-accounts delete "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--quiet
12. تهانينا
تهانينا! لقد أكملت الدرس التطبيقي حول الترميز تأمين مسار CI/CD باستخدام CodeMender.
لقد نجحت في تصميم وإنشاء وأتمتة مسار DevSecOps على مستوى الإنتاج يستند إلى نموذج "الثقة الصفرية" باستخدام ميزات Workload Identity Federation في Google Cloud وCodeMender وGitHub Actions.
المواضيع التي تناولتها
المصادقة بدون مفتاح وفقًا لنموذج الثقة المعدومة: تم التخلص من مفاتيح JSON الخطيرة والطويلة الأجل لحسابات الخدمة من خلال ربط رموز OIDC المميزة المؤقتة في GitHub بخدمة Google Cloud IAM عبر Workload Identity Federation (WIF).
فحص AST التفاضلي لطلبات السحب وكتم الضوضاء القديمة: فحص مستمر ومحدّد النطاق للملفات المعدَّلة والملفات التابعة (--diff="origin/$BASE_REF")، مع عزل الديون التقنية القديمة ([LEGACY / UNTOUCHED]) للحفاظ على حلقات ملاحظات المطوّرين في أقل من 15 ثانية.
إعداد التقارير المتعددة التنسيقات وملخّصات المهام المدمجة: تم دمج OASIS SARIF v2.1.0 لإجراء فحص مركزي للرموز البرمجية في GitHub باستخدام Markdown المدمج (cm report -f md >> $GITHUB_STEP_SUMMARY) من أجل توفير رؤية تنفيذية فورية مباشرةً على صفحات تشغيل سير عمل CI.
المعالجة الذاتية مع مراجعة المشاركة البشرية: تجاوزنا إشعارات التنبيهات السلبية إلى مسارات المعالجة النشطة التي تجمع تلقائيًا رموز التصحيح المقترَحة، وتتحقّق من حزم الاختبارات الارتجاعية، وتفتح طلبات سحب المراجعة مع عناصر التدقيق لتوقيع المهندس.
القيود الصارمة لضمان الجودة المبرمَجة: تم فرض حماية صارمة على الفروع وقيود على الدمج (--fail-on) لمنع وصول الثغرات الأمنية الخطيرة إلى مرحلة الإنتاج.
نقل الحالة المستند إلى العناصر وعزل مساحة العمل: تم نقل النتائج بسلاسة بين مهام CI باستخدام cm report import، مع استخدام .git/info/exclude للحفاظ على سجلّ Git الأصلي ومنع تسرُّب بيانات الاعتماد.
تغيير طريقة تفكير المطوّرين
ممارسات DevSecOps التقليدية | مسار التكامل المستمر/التسليم المستمر المستقل في CodeMender |
التنبيهات السلبية: تطبع أدوات الفحص سجلّات Terminal الأولية أو قوائم الأخطاء الثابتة، ما ينقل عبء الفرز بالكامل إلى المطوّرين. | Active Co-developer: يجمع هذا الوكيل تصحيحات الرموز البرمجية التي تم التحقّق منها ويفتح طلبات دمج جاهزة ليوافق عليها المهندس. |
ارتفاع معدّل النتائج الموجبة الخاطئة: تضع الأساليب الإرشادية لاختبار AST الثابت علامة على آلاف الثغرات الأمنية النظرية بدون دليل على إمكانية استغلالها. | التحقّق من الثغرات على مستويَين: يتيح إنشاء اختبارات ديناميكية في وضع الحماية ( |
تخزين مفاتيح سرية محفوفة بالمخاطر: إنّ مفاتيح JSON لحسابات الخدمة الطويلة الأمد والمخزَّنة في أسرار CI قد تؤدي إلى تسرُّب البيانات عن طريق الخطأ وانتشار بيانات الاعتماد. | اتحاد هوية أعباء العمل (WIF) المستند إلى نموذج "الثقة المعدومة": مصادقة بدون مفتاح عبر رموز OIDC المميزة المؤقتة التي يتم تبادلها مع Google Cloud STS عند الطلب |
عمليات إعادة الفحص الشاملة: تؤدي كل عملية إرسال إلى إجراء عمليات تدقيق كاملة في المستودع، ما يؤدي إلى تأخير سير عمل CI وإهدار الرموز المميّزة الباهظة الثمن. | توجيه AST المستند إلى الأحداث: تنفّذ طلبات السحب عمليات فحص AST تفاضلية مدتها 15 ثانية ( |
سجلّ المستودع الملوّث: نصوص برمجية مؤقتة للاستغلال وسجلّات الهجمات التي يتم إرسالها مباشرةً إلى فروع المستودع. | Enterprise Workspace Hygiene: Attack evidence embedded cleanly in PR descriptions and workflow artifacts, keeping code commits pure. |
الخطوات التالية
🚀 مواصلة رحلة التعلّم في CodeMender:
الجزء 1: تأمين تطبيقك باستخدام CodeMender: تعرَّف على كيفية اكتشاف الثغرات الأمنية في المستودعات بشكل مستقل، والتحقّق من استغلال الثغرات الأمنية في إثبات جدوى الفكرة، وإنشاء رموز تصحيح محلية.
Shift Left Locally & Serverless Cloud Native CI/CD: يمكنك استكشاف عمليات التنفيذ المرجعية لدليل CI/CD الرسمي لكل من Google Cloud Build (cloudbuild.yaml) وLocal Git Pre-commit Hooks (cm find . --diff --staged).
📖 استكشاف المستندات والمراجع:
دليل Google Cloud الرسمي لدمج CodeMender في CI/CD
مستندات Google Cloud CodeMender الرسمية
مستودع النماذج الأولية لإجراءات GitHub في CodeMender
مستندات Google Cloud Workload Identity Federation
💡 تطبيق ذلك على مستودعاتك:
يمكنك إنشاء نسخة من سير العمل الأساسي وتأمين مستودعات Python وGo وJava وRust وNode.js في مؤسستك باستخدام CodeMender.