1. ก่อนเริ่มต้น
ยินดีต้อนรับสู่ Codelab แบบลงมือปฏิบัติจริงสำหรับการรักษาความปลอดภัยไปป์ไลน์ CI/CD ด้วย CodeMender
ในการส่งมอบซอฟต์แวร์สมัยใหม่ เครื่องมือวิเคราะห์แบบคงที่ (เช่น CodeQL) มีความสำคัญต่อการตรวจจับรูปแบบทางไวยากรณ์ที่รู้จัก แต่มักพลาดช่องโหว่ที่ละเอียดอ่อนซึ่งซ่อนอยู่ลึกภายในตรรกะทางธุรกิจ และสร้างการแจ้งเตือนที่รบกวนและไม่ได้รับการยืนยัน
CodeMender (ไฟล์ปฏิบัติการ CLI: cm) ช่วยปรับปรุงไปป์ไลน์ CI/CD ซึ่งทำงานร่วมกับเครื่องมือ SAST ที่มีอยู่ โดยการติดตั้งใช้งาน Agent การให้เหตุผลด้านความปลอดภัยที่ทำงานด้วยระบบ Gemini ของ Google เพื่อทำสิ่งต่อไปนี้
ค้นพบข้อบกพร่องของตรรกะทางธุรกิจที่ซับซ้อน: ให้เหตุผลเกี่ยวกับบริบทของแอปพลิเคชันและสถาปัตยกรรมของโฟลว์ข้อมูลที่นอกเหนือจากกฎรูปแบบคงที่ที่เข้มงวด
ลดผลบวกลวงได้อย่างมากผ่านการยืนยันการเจาะระบบด้วยตนเอง: พิสูจน์ความสามารถในการเจาะระบบแบบไดนามิกในสภาพแวดล้อมแซนด์บ็อกซ์ก่อนแจ้งเตือนนักพัฒนาแอป
แก้ไขผลการตรวจสอบที่ได้รับการยืนยันโดยอัตโนมัติ: สังเคราะห์แพตช์โค้ด ตรวจสอบกับชุดโปรแกรมทดสอบเพื่อป้องกันการถดถอย และส่ง Pull Request ที่พร้อมตรวจสอบ
ใน Codelab นี้ คุณจะผสานรวม CodeMender เข้ากับที่เก็บ OWASP Juice Shop โดยใช้ GitHub Actions และ Google Cloud Workload Identity Federation (WIF) แบบไม่ใช้คีย์
ข้อกำหนดเบื้องต้น
- แนะนำ: มีความคุ้นเคยพื้นฐานเกี่ยวกับแนวคิดของ CodeMender (ครอบคลุมในหัวข้อรักษาความปลอดภัยให้แอปพลิเคชันด้วย CodeMender)
- ความเข้าใจพื้นฐานเกี่ยวกับเวิร์กโฟลว์ ทริกเกอร์ และไวยากรณ์ YAML ของ GitHub Actions
- มีความคุ้นเคยเบื้องต้นเกี่ยวกับคำสั่ง Git และเวิร์กโฟลว์การตรวจสอบ Pull Request
- ความรู้พื้นฐานเกี่ยวกับแนวคิด Cloud IAM ของ Google Cloud (บัญชีบริการ บทบาท และ API)
- ความคุ้นเคยกับช่องโหว่ของเว็บแอปพลิเคชันทั่วไป (เช่น การแทรก SQL และ XSS)
สิ่งที่คุณจะได้เรียนรู้
- วิธีกำหนดค่าการตรวจสอบสิทธิ์แบบไม่ใช้คีย์ตามแนวคิด Zero Trust ระหว่าง GitHub Actions กับ Google Cloud ผ่าน Workload Identity Federation (WIF)
- วิธีสร้างเวิร์กโฟลว์การสแกนช่องโหว่อัตโนมัติโดยใช้ CodeMender และ
gemini-3.8-flash - วิธีเผยแพร่รายงานความปลอดภัยที่นำไปใช้ได้จริงโดยใช้ OASIS SARIF v2.1.0 และสรุปงานของ GitHub Actions แบบเนทีฟ
- วิธีสร้างเวิร์กโฟลว์การแก้ไขอัตโนมัติที่สร้างแพตช์โค้ดที่ผ่านการตรวจสอบการทดสอบแล้ว และเปิด Pull Request สำหรับการตรวจสอบจากเจ้าหน้าที่
- วิธีบังคับใช้เกตฮาร์ดแวร์คุณภาพอัตโนมัติ (
--fail-on) และการแคชไปป์ไลน์เพื่อความปลอดภัยอย่างต่อเนื่องความเร็วสูง
สิ่งที่ต้องมี
- โปรเจ็กต์ Google Cloud ที่เปิดใช้การเรียกเก็บเงินและสิทธิ์เจ้าของ/ผู้แก้ไขโปรเจ็กต์
- บัญชี GitHub ที่มีสิทธิ์สร้างที่เก็บ กำหนดค่าข้อมูลลับ และจัดการการดำเนินการ (คุณแยก OWASP Juice Shop GitHub Repo ในขั้นตอนที่ 3 โดยใช้ GitHub CLI)
2. ทำความเข้าใจสถาปัตยกรรม CI/CD ของ CodeMender
ใน DevSecOps ขององค์กรสมัยใหม่ การรักษาความปลอดภัยที่ทำงานด้วยระบบ AI ไม่ได้เป็นเพียงเครื่องมือเดสก์ท็อปที่ต้องดำเนินการด้วยตนเองเท่านั้น โดยต้องทำหน้าที่เป็นผู้ดูแลอัตโนมัติ (บล็อก Pull Request ที่ไม่ปลอดภัย) และนักพัฒนาร่วมแบบอัตโนมัติ (เสนอแพตช์ที่ได้รับการยืนยันไปยัง Git โดยตรง)
เพื่อให้บรรลุเป้าหมายนี้ คุณจะต้องใช้สถาปัตยกรรมเวิร์กโฟลว์แบบคู่ที่ขับเคลื่อนโดย Google Cloud Workload Identity Federation (WIF) และโมเดลการให้เหตุผลของ Gemini Enterprise
สถาปัตยกรรมเวิร์กโฟลว์แบบคู่
ไปป์ไลน์จะแยกการรักษาความปลอดภัยออกเป็น 2 เวิร์กโฟลว์ที่แยกกันและสร้างขึ้นเพื่อวัตถุประสงค์เฉพาะ แทนที่จะรวมการตรวจจับและการแก้ไขไว้ในสคริปต์แบบโมโนลิธเดียว ดังนี้
ขั้นตอนการทำงาน | ทริกเกอร์หลัก | ความรับผิดชอบหลัก | เกณฑ์คุณภาพที่เข้มงวด |
1. โปรแกรมสแกนช่องโหว่( | Pull Request, Main Push, Cron รายสัปดาห์, การส่งด้วยตนเอง | • เรียกใช้การสแกน AST แบบดิฟเฟอเรนเชียลที่รวดเร็วใน PR (~15 วินาที) การสแกนพื้นฐานที่รวดเร็วในการพุช ( | บล็อกการผสาน PR หากตรวจพบช่องโหว่ระดับสูงหรือร้ายแรงที่เพิ่งพบใหม่ ( |
2. Autonomous Remediator( | ทริกเกอร์ด้วยตนเอง ( | • ดำเนินการต่อจากอาร์ติแฟกต์การสแกน ( | ตรวจสอบความแตกต่างของเวอร์ชันที่ใช้งานจริงอย่างละเอียดก่อนเปิด PR |
หลักการออกแบบองค์กรหลัก 3 ประการ
ขณะสร้างเวิร์กโฟลว์เหล่านี้ในส่วนถัดไป โปรดคำนึงถึงเสาหลักด้านสถาปัตยกรรมพื้นฐาน 3 ประการต่อไปนี้
🔑 การตรวจสอบสิทธิ์แบบไม่ใช้คีย์และการตรวจสอบก่อนการบินแบบ Zero Trust:
ไม่มีการจัดเก็บคีย์ JSON ของบัญชีบริการ Google Cloud ที่มีอายุการใช้งานยาวนานไว้ใน GitHub Secrets Runner จะสร้างโทเค็น OIDC ที่มีอายุสั้นซึ่งแลกเปลี่ยนผ่าน Google Cloud STS เพื่อรับข้อมูลเข้าสู่ระบบชั่วคราวที่มีอายุ 1 ชั่วโมง ตั้งค่า persist-credentials: false ในการชำระเงิน Git และเรียกใช้ cm health --strict เพื่อยืนยันข้อมูลเข้าสู่ระบบ ความสามารถในการเข้าถึงเครือข่าย และสิทธิ์ IAM ก่อนใช้โควต้าโมเดล
⚡ การกำหนดเส้นทางการสแกนแบบปรับอัตโนมัติและการตัดเสียงรบกวนแบบเดิม:
CodeMender จะกำหนดเส้นทางเหตุการณ์ CI แต่ละรายการไปยังโหมดการสแกนที่เหมาะสมที่สุด แทนที่จะเรียกใช้การตรวจสอบที่เก็บทั้งหมดแบบช้าๆ ในทุก Pull Request โดย Pull Request จะทริกเกอร์การวิเคราะห์ AST แบบดิฟเฟอเรนเชียล (--diff="origin/$BASE_REF") ในไฟล์ที่แก้ไขและผู้เรียกแบบ 1-hop ในเวลาไม่ถึง 15 วินาที การพุชสาขาหลักจะเรียกใช้การสแกนพื้นฐานแบบรวดเร็วในเซสชันเดียว (--quick) และกำหนดการรายสัปดาห์จะเรียกใช้การตรวจสอบเชิงลึกแบบไฟล์ต่อไฟล์พร้อมกัน (ค่าเริ่มต้น cm find .) ช่องโหว่ของฐานของโค้ดที่มีอยู่ก่อนแล้วซึ่ง PR ไม่ได้แตะต้องจะติดป้ายกำกับว่า [LEGACY / UNTOUCHED] โดยจะปรากฏในรายงาน SARIF เพื่อให้เห็นได้ แต่จะไม่บล็อกเกตการผสาน PR และจะไม่ทริกเกอร์การแก้ไขอัตโนมัติ
🛡️ ความสามารถในการสังเกตด้านความปลอดภัยแบบไม่บล็อกที่มีความยืดหยุ่น:
แม้ว่า --fail-on จะออกด้วยโค้ด 1 เพื่อบล็อก PR ที่ไม่ปลอดภัย แต่การป้องกันขั้นตอนการส่งออกรายงานและการอัปโหลด SARIF ด้วย steps.scan.outputs.completed == 'true' และ hashFiles('results.sarif') != '' จะรับประกันว่าการแจ้งเตือน OASIS SARIF และข้อมูลสรุปงานจะยังคงเผยแพร่ต่อไป ขณะเดียวกันก็ข้ามการส่งออกและการอัปโหลดอย่างราบรื่นหากการเรียกใช้ถูกยกเลิกหรือหยุดทำงานเนื่องจากข้อผิดพลาดในการตั้งค่าหรือความจุ (10–60)
3. ตรวจสอบสิทธิ์และเตรียมที่เก็บเป้าหมายใน Cloud Shell
หากต้องการสร้างการตรวจสอบสิทธิ์แบบไม่ใช้คีย์และเรียกใช้ไปป์ไลน์ความปลอดภัยอัตโนมัติ คุณต้องมีที่เก็บ GitHub เป้าหมายที่เข้าถึงได้ซึ่งคุณเป็นเจ้าของ ใน Codelab นี้ คุณจะใช้ OWASP Juice Shop ซึ่งเป็นเว็บแอปพลิเคชัน Node.js ที่มีช่องโหว่โดยเจตนา เป็นสนามทดสอบความปลอดภัยแบบเบ็ดเสร็จ
คุณจะใช้ GitHub CLI (gh) ที่ติดตั้งไว้ล่วงหน้าใน Google Cloud Shell เพื่อตรวจสอบสิทธิ์กับ GitHub, บันทึกรายละเอียดผู้ใช้โดยอัตโนมัติ และเตรียมที่เก็บในขั้นตอนเดียวที่ราบรื่น
ขั้นตอนที่ 1: เปิด Cloud Shell และตรวจสอบสิทธิ์ GitHub CLI
เปิดคอนโซล Google Cloud และเปิดใช้งาน 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
ในขั้นตอนนี้ คุณจะใช้ gcloud CLI ใน Google Cloud Shell เพื่อเปิดใช้ API ที่จำเป็น สร้างบัญชีบริการ CI/CD โดยเฉพาะ ตั้งค่า Workload Identity Pool และสร้างความเชื่อถือ OIDC กับที่เก็บ GitHub (${GITHUB_REPOSITORY})
ขั้นตอนที่ 1: ตั้งค่าตัวแปรสภาพแวดล้อมของ Google Cloud
ในเทอร์มินัล Cloud Shell (ภายในพื้นที่ทำงานของที่เก็บที่โคลน) ให้บันทึกรหัสโปรเจ็กต์ที่อยู่ในระบบคลาวด์ของ Google ที่ใช้งานอยู่ ยืนยันตัวแปรที่เก็บ 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: สร้างบัญชีบริการ CI/CD โดยเฉพาะ
สร้างบัญชีบริการ 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) ให้กับบัญชีบริการเพื่อให้สื่อสารกับแพลตฟอร์ม Agent ของ Gemini Enterprise ได้ โดยทำดังนี้
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
ขั้นตอนที่ 5: สร้าง Workload Identity Pool
สร้าง Workload Identity Pool เพื่อจัดการการยืนยันตัวตนของ 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 Runner และยืนยันการเชื่อมโยงนโยบายโดยทำดังนี้
# 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 และจัดเก็บไว้ในตัวแปรสภาพแวดล้อมเพื่อลงทะเบียนอัตโนมัติในขั้นตอนถัดไป
# 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 และให้สิทธิ์เวิร์กโฟลว์ที่จำเป็นสำหรับการสแกนความปลอดภัยอัตโนมัติและ Pull Request การแก้ไขอัตโนมัติ
คุณสามารถกำหนดการตั้งค่าเหล่านี้ได้โดยตรงจาก Cloud Shell โดยใช้ GitHub CLI (gh) ซึ่งจะช่วยลดการคัดลอกและวางชื่อทรัพยากรที่ยาวด้วยตนเองได้อย่างสมบูรณ์
ขั้นตอนที่ 1: ตั้งค่าข้อมูลลับของที่เก็บโดยใช้ GitHub CLI
ในเทอร์มินัล Cloud Shell ให้เรียกใช้คำสั่งต่อไปนี้เพื่อตั้งค่าข้อมูลลับของที่เก็บที่จำเป็น 2 รายการอย่างปลอดภัยโดยใช้ตัวแปรสภาพแวดล้อมที่ใช้งานอยู่
# 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: ให้สิทธิ์เวิร์กโฟลว์สำหรับ PR อัตโนมัติ
โดยค่าเริ่มต้น เวิร์กโฟลว์ GitHub Actions จะทำงานด้วยสิทธิ์แบบอ่านอย่างเดียวและสร้าง Pull Request ไม่ได้ ในขั้นตอนที่ 9 CodeMender จะสร้างและส่ง Pull Request การแก้ไขที่ได้รับการยืนยันโดยอัตโนมัติ
ให้สิทธิ์เขียนและเปิดใช้การสร้าง Pull Request โดยตรงผ่าน 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 จะนำเวิร์กโฟลว์ CI ต้นทางมากกว่า 16 รายการ (เช่น PR Compliance Check, CI/CD Pipeline และ CodeQL Scan) ไปด้วย พร้อมกับเทมเพลต PR ของผู้ร่วมให้ข้อมูลต้นทางที่ปิด PR ที่กำหนดเป้าหมายเป็น master โดยอัตโนมัติ ปิดใช้เวิร์กโฟลว์ทั้งหมดที่ไม่ใช่ CodeMender ผ่าน GitHub CLI และนำไฟล์อัปสตรีมออกในเครื่องเพื่อให้ Fork เรียกใช้เวิร์กโฟลว์ 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) ซึ่งจะเรียกใช้การสแกนพื้นฐานในการพุชสาขา, เกตส่วนต่างใน Pull Request และการส่งออก 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
เรียกใช้หรือดูการดำเนินการตามเวิร์กโฟลว์โดยทำดังนี้
ทริกเกอร์อัตโนมัติ: หากมีการเรียกใช้โดยอัตโนมัติที่ทริกเกอร์โดยการพุชของคุณ ให้คลิกที่การเรียกใช้นั้นโดยตรงเพื่อตรวจสอบการดำเนินการแบบเรียลไทม์
ทริกเกอร์แบบออนดีมานด์ด้วยตนเอง (workflow_dispatch): หากยังไม่มีการเรียกใช้ ให้คลิกปุ่มเรียกใช้เวิร์กโฟลว์ ▾ ทางด้านขวา ตรวจสอบว่าได้เลือก Branch: master แล้ว (ปล่อยช่องทำเครื่องหมาย deep_scan ว่างไว้เพื่อให้การสแกนพื้นฐาน --quick แบบรวดเร็วทำงาน) แล้วคลิกปุ่มเรียกใช้เวิร์กโฟลว์สีเขียว
คลิกการเรียกใช้ที่กำลังดำเนินการอยู่ แล้วเลือกการสแกนช่องโหว่ของโค้ดแบบอัตโนมัติเพื่อดูเวิร์กโฟลว์ที่เริ่มทำงานแบบเรียลไทม์
ภายใน codemender-scan.yml: การกำหนดเส้นทางการสแกนที่รับรู้เหตุการณ์
ขณะที่การสแกนพื้นฐานของ --quick ทำงานในระบบคลาวด์ (ประมาณ 3-5 นาที) ให้ตรวจสอบวิธีที่ codemender-scan.yml (บรรทัดที่ 118-155) กำหนดเส้นทางเหตุการณ์ GitHub แต่ละรายการไปยังโหมดการสแกนเฉพาะภายใน Runner ดังนี้
# 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
การตั้งค่า Hardened Runner ( บรรทัดที่ 27-117): ข้าม Fork ภายนอกที่ไม่น่าเชื่อถือและ PR ของ dependabot[bot], ตรวจสอบด้วย persist-credentials: false, แคช ~/.local/bin/cm และ ~/.codemender/state.db และเรียกใช้ cm health --strict ก่อนใช้โควต้าโมเดล
Headless Sandbox Boundaries (--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 บล็อก PR โดยจะข้ามการส่งออกเมื่อเกิดข้อผิดพลาดในการตั้งค่าหรือความจุ (10–60) เพื่อไม่ให้ไฟล์ SARIF ที่ว่างเปล่าปิดการแจ้งเตือนที่มีอยู่
7. ตรวจสอบการแจ้งเตือนการสแกนโค้ดของ GitHub และแดชบอร์ดความปลอดภัย
หลังจากเวิร์กโฟลว์การพุชพื้นฐานเสร็จสิ้น GitHub จะประมวลผลไฟล์ SARIF ที่อัปโหลดและป้อนข้อมูลทั้งสรุปการเรียกใช้การดำเนินการและแท็บความปลอดภัยของที่เก็บ
ขั้นตอนที่ 1: ตรวจสอบสรุปงานแบบเนทีฟใน GitHub Actions
การเรียกใช้เวิร์กโฟลว์แต่ละครั้งจะเพิ่มตารางสรุป Markdown (cm report -f md) ลงในภาพรวมการเรียกใช้ GitHub Actions โดยตรง ดังนี้
ในที่เก็บ GitHub ให้คลิกแท็บการดำเนินการ
เลือกการเรียกใช้ CodeMender Security Scan & SARIF Export ที่เสร็จสมบูรณ์ (การตรวจสอบการพุชสาขาพื้นฐานจะเสร็จสิ้นด้วยเครื่องหมายถูก ✅ สีเขียวหลังจากเผยแพร่ผลการค้นหา SARIF)
เลื่อนลงไปที่ส่วน 🛡️ สรุปการสแกนความปลอดภัยของ CodeMender เพื่อตรวจสอบรายละเอียดการค้นพบ ดังนี้
🔒 รายงานความปลอดภัยของ CodeMender
สรุป
ผลการค้นหาทั้งหมด: 28 รายการ
ระดับความรุนแรง | จำนวน |
🔴 วิกฤต | 6 |
🟠 สูง | 16 |
🟡 ปานกลาง | 6 |
สถานะ | จำนวน |
🔴 เปิด | 28 |
ผลการวิจัย
รหัส | ระดับความรุนแรง | ความมั่นใจ | สถานะ | แก้ไข | ไฟล์ | ชื่อ |
| 🔴 วิกฤต | 100% | เปิด | — |
| การเรียกใช้โค้ดระยะไกลผ่านการแทรกโค้ดฝั่งเซิร์ฟเวอร์ในโปรไฟล์ผู้ใช้ |
| 🔴 วิกฤต | 100% | เปิด | — |
| การแทรก SQL ในเส้นทางการตรวจสอบสิทธิ์ผู้ใช้ |
| 🔴 วิกฤต | 100% | เปิด | — |
| การเรียกใช้โค้ดระยะไกลผ่านการหลบหนีแซนด์บ็อกซ์ในการประมวลผลคำสั่งซื้อแบบ B2B |
ขั้นตอนที่ 2: สำรวจแดชบอร์ดการสแกนโค้ดแบบรวมศูนย์
ในแถบนำทางด้านบนของที่เก็บ GitHub ให้คลิกแท็บความปลอดภัยและคุณภาพ (หรือความปลอดภัย)
ในแถบด้านข้างทางซ้ายใต้ผลการค้นพบ ให้เลือกการสแกนโค้ด
หากมีเครื่องมือหลายรายการทำงานอยู่ ให้กรองเครื่องมือเป็น CodeMender (is:open branch:master tool:CodeMender) เพื่อตรวจสอบการแจ้งเตือนที่แมปกับป้ายความรุนแรง CVSS แบบเนทีฟ ดังนี้
ป้ายระดับความรุนแรง | Vulnerability Headline | ตำแหน่งที่ตรวจพบ | Branch |
🔴 สำคัญมาก | การเรียกใช้โค้ดระยะไกลผ่านการแทรกโค้ดฝั่งเซิร์ฟเวอร์ในโปรไฟล์ผู้ใช้ |
|
|
🔴 สำคัญมาก | การแทรก SQL ในเส้นทางการตรวจสอบสิทธิ์ผู้ใช้ |
|
|
🔴 สำคัญมาก | การเรียกใช้โค้ดระยะไกลผ่านการหลบหนีแซนด์บ็อกซ์ในการประมวลผลคำสั่งซื้อแบบ B2B |
|
|
คลิก SQL Injection in User Authentication Route (routes/login.ts:34) เพื่อตรวจสอบ Dataflow ที่มีช่องโหว่และการวิเคราะห์สาเหตุของปัญหาที่ Gemini สังเคราะห์ขึ้น
8. บล็อก Pull Request ที่ไม่ปลอดภัยด้วยการสแกนแบบ Differential
การสแกนพื้นฐานพบช่องโหว่ที่มีอยู่ก่อนแล้ว 28 รายการใน OWASP Juice Shop เมื่อใช้เครื่องมือวิเคราะห์แบบคงที่แบบดั้งเดิม ผลการค้นหาเดิม 28 รายการเหล่านั้นจะทำให้ Pull Request ในอนาคตทั้งหมดไม่สำเร็จจนกว่าจะแก้ไขงานที่ค้างอยู่ทั้งหมด ซึ่งทำให้ทีมต้องปิดใช้การบล็อกการผสาน
ตอนนี้คุณจะได้ทดสอบ PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") ของ CodeMender ในการทำงานจริง โดยเปิด Pull Request ที่ทำให้เกิดช่องโหว่ใหม่และดู CodeMender แยกเดลต้า บล็อกการผสานในเวลาประมาณ 15-25 วินาที และใส่คำอธิบายประกอบบรรทัดที่ทำให้เกิดปัญหาได้อย่างแม่นยำ
ขั้นตอนที่ 1: เปิด Pull Request ที่ทำให้เกิดข้อบกพร่องในการแทรกคำสั่ง
ใน Cloud Shell (ภายในพื้นที่ทำงานของที่เก็บที่โคลน) ให้สร้าง Feature Branch, เพิ่มเส้นทาง Express ใหม่ที่มีช่องโหว่การแทรกคำสั่ง OS และเปิด Pull Request กับ Fork ของคุณ โดยทำดังนี้
[ -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: ยืนยันเกตการผสานแบบดิฟเฟอเรนเชียลและคำอธิบายประกอบ PR ในบรรทัด
เปิด URL ของ Pull Request ที่พิมพ์ไว้ที่ส่วนท้ายของเอาต์พุตเทอร์มินัล
เลื่อนไปที่ช่องการตรวจสอบที่ด้านล่างของหน้าการสนทนา Pull Request แล้วดูการสแกนช่องโหว่ของโค้ดแบบอัตโนมัติ
ความเร็วเดลต้า: แทนที่จะสแกนไฟล์ทั้งหมดกว่า 680 ไฟล์ในที่เก็บ (~3-5 นาที) cm find . --diff="origin/${PRIMARY_BRANCH}" จะจำกัดขอบเขตการวิเคราะห์ไว้ที่ routes/diagnostics.ts (และผู้เรียกแบบ 1-hop) เท่านั้น โดยสแกนเสร็จภายใน ~15-25 วินาที
การแยกหนี้ทางเทคนิคเดิมและการบล็อกการผสาน: ช่องโหว่เดิมที่ไม่มีการแตะต้อง 28 รายการของ Juice Shop ไม่ผ่านการตรวจสอบ มีเพียงการแทรกคำสั่ง CRITICAL ที่เพิ่งเพิ่มเข้ามาเท่านั้นที่ทริกเกอร์ --fail-on="CRITICAL,HIGH" โดยออกด้วยรหัสสถานะ 1 (สีแดง ❌) เพื่อบล็อกการผสาน PR
คลิกแท็บ Files changed ที่ด้านบนของ Pull Request
เนื่องจาก Guard ของ Exit Code ของเวิร์กโฟลว์ (steps.scan.outputs.completed == 'true') ยังคงส่งออกและอัปโหลด results.sarif เมื่อ --fail-on ออกด้วยโค้ด 1 การสแกนโค้ดของ GitHub จึงแสดงคำอธิบายประกอบด้านความปลอดภัย CodeMender — วิกฤตในบรรทัดใต้ execSync ใน routes/diagnostics.ts โดยตรง
ขั้นตอนที่ 3: ล้าง PR ทดสอบและกลับไปยังสาขาหลัก
เปลี่ยนพื้นที่ทำงาน Cloud Shell กลับไปเป็นสาขาหลักและปิด Pull Request ทดสอบที่ไม่ปลอดภัยก่อนดำเนินการแก้ไขอัตโนมัติ โดยทำดังนี้
[ -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. สร้างเวิร์กโฟลว์การแก้ไขอัตโนมัติและ PR อัตโนมัติ
เมื่อเกต Pull Request ป้องกันไม่ให้ช่องโหว่ใหม่เข้าสู่ฐานของโค้ดแล้ว คุณจะติดตั้งใช้งานการแก้ไขอัตโนมัติ (.github/workflows/codemender-remediate.yml) เพื่อแก้ไขช่องโหว่ที่มีอยู่อย่างสม่ำเสมอและเปิด Pull Request ที่พร้อมตรวจสอบ
ขั้นตอนที่ 1: ดาวน์โหลดไฟล์เวิร์กโฟลว์การแก้ไข
CodeMender มีเทมเพลตการแก้ไข 2 แบบ โดยขึ้นอยู่กับระดับการเข้าถึงที่เก็บ ดังนี้
ที่เก็บสาธารณะ/โอเพนซอร์ส (codemender-remediate.yml): โหมดการเปิดเผยข้อมูลอย่างมีความรับผิดชอบ - ลิงก์ไปยังการแจ้งเตือน SARIF ของการสแกนโค้ด GitHub โดยไม่เปิดเผยเวกเตอร์การเจาะช่องโหว่ดิบต่อสาธารณะ
ที่เก็บส่วนตัว/ขององค์กร (codemender-remediate-private-repo.yml): โหมดหลักฐานการตรวจสอบภายใน - ฝังอาร์ติแฟกต์การยืนยัน (PLAN.md, REPORT.md, exploit.sh) ไว้ในส่วน PR ที่ยุบได้ แต่ไม่รวมไว้ในคอมมิต 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)
ในเบราว์เซอร์ ให้ไปที่แท็บการดำเนินการของที่เก็บ GitHub
ในแถบด้านข้างทางซ้ายในส่วนเวิร์กโฟลว์ ให้เลือกการแก้ไขด้านความปลอดภัยอัตโนมัติและ PR อัตโนมัติของ CodeMender
คลิกเมนูแบบเลื่อนลงเรียกใช้เวิร์กโฟลว์สีเขียวทางด้านขวา
Use workflow from: ตรวจสอบว่าได้เลือก Branch เริ่มต้น (master) แล้ว
รหัสหรือคำนำหน้าการค้นพบที่เฉพาะเจาะจงที่จะแก้ไข: ป้อนคำนำหน้า 8 อักขระสำหรับ routes/login.ts ที่ระบุไว้ในขั้นตอนที่ 7 (เช่น cd47b38a) การเว้นช่องนี้ว่างไว้จะเรียกใช้การแก้ไขแบบเป็นกลุ่มในการค้นพบที่เปิดอยู่ทั้งหมดซึ่งมีระดับความรุนแรงเป็นวิกฤตและสูง (~10-15 นาที) การกำหนดเป้าหมายรหัสเดียวจะเสร็จสมบูรณ์ใน ~45-60 วินาที
คลิกปุ่มเรียกใช้เวิร์กโฟลว์สีเขียวภายในป๊อปโอเวอร์ แล้วเปิดการเรียกใช้ที่กำลังดำเนินการอยู่
ภายใน codemender-remediate.yml: การสังเคราะห์แพตช์อัตโนมัติ
ขณะที่ CodeMender สังเคราะห์แพตช์ในระบบคลาวด์ (ประมาณ 30-45 วินาที) ให้ตรวจสอบวิธีที่ codemender-remediate.yml (บรรทัดที่ 111-184) จัดระเบียบการแก้ไขภายใน Runner ดังนี้
Zero-Scan Resume (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
Clean Production Commits ( บรรทัดที่ 155–252): ล้าง .cm_project, .exploit/ และไฟล์ชั่วคราวผ่าน .git/info/exclude ก่อนที่ peter-evans/create-pull-request@v8 จะเปิด Branch (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: ตรวจสอบ Pull Request ที่เปิดใหม่ใน GitHub
ไปที่แท็บ Pull requests ในที่เก็บข้อมูล แล้วเปิด Pull Request ใหม่ (เช่น 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route)
คลิกไฟล์ที่มีการเปลี่ยนแปลงเพื่อยืนยันว่ามีการแก้ไขเฉพาะ routes/login.ts โดยไม่รวมข้อมูลเมตาของรันไทม์ภายในทั้งหมด
ตรวจสอบคำอธิบาย PR ที่ลิงก์โดยตรงกับการแจ้งเตือนการสแกนโค้ด GitHub (SARIF) เพื่อให้ผู้ดูแลลงชื่ออนุมัติ
10. แก้ปัญหาเกี่ยวกับกรณีที่เกิดขึ้นไม่บ่อยนักและที่เก็บส่วนตัว
ที่เก็บส่วนตัวที่ไม่มี GitHub Advanced Security (GHAS)
ที่เก็บ GitHub สาธารณะจะได้รับการนำเข้า SARIF สำหรับการสแกนโค้ด GitHub ฟรีแบบไม่จำกัด อย่างไรก็ตาม หากคุณติดตั้งใช้งานเวิร์กโฟลว์นี้ในที่เก็บ Enterprise ส่วนตัวที่ไม่มีใบอนุญาต 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) จะสร้างแดชบอร์ดความปลอดภัยแบบอินเทอร์แอกทีฟสแตนด์อโลนที่มีการ์ดเมตริกความรุนแรง ข้อมูลโค้ดที่ไฮไลต์ไวยากรณ์พร้อมหมายเลขบรรทัด และเครื่องมือดูความแตกต่างของแพตช์ในบรรทัดโดยไม่มีทรัพยากร Dependency ของเว็บภายนอก
หากต้องการรองรับที่เก็บส่วนตัวที่ไม่มีใบอนุญาต 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) หรือไฟล์มาร์กดาวน์ภายใน (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)
วิธีการทำงานของการแก้ไขที่เก็บส่วนตัว
การยืนยัน PoC แบบไดนามิก (cm verify): สังเคราะห์และทดสอบการเจาะระบบที่ใช้งานได้ก่อนที่จะสร้างการแก้ไขเพื่อยืนยันความสามารถในการเจาะระบบ โดยจะข้าม cm fix โดยอัตโนมัติหากการยืนยันทำเครื่องหมายการค้นพบที่ไม่สามารถเจาะระบบได้เป็น DISMISSED
Embedded PR Audit Collapsibles: ดึงข้อมูล REPORT.md, PLAN.md และ exploit.sh ไปยัง /tmp/codemender-evidence/ และจัดรูปแบบข้อมูลเหล่านั้นลงในคำอธิบาย Pull Request โดยตรงภายในบล็อกที่ยุบได้ <details open> เพื่อให้ผู้ตรวจสอบตรวจสอบได้ในคลิกเดียว
การเก็บอาร์ติแฟกต์: เก็บโฟลเดอร์หลักฐานทั้งหมดผ่าน actions/upload-artifact@v4
Pristine Git Commits: ล้างข้อมูลเมตาของรันไทม์และไดเรกทอรี .exploit ทั้งหมดเพื่อให้คอมมิต Git ของ Pull Request มีการเปลี่ยนแปลงโค้ดเวอร์ชันที่ใช้งานจริงอย่างเคร่งครัด
รายการตรวจสอบการแก้ปัญหาการรวมศูนย์ Workload Identity (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 ชั่วคราวทันทีหลังจากการตั้งค่า | การเผยแพร่ IAM ทั่วโลกและการรวมศูนย์ Workload Identity อาจใช้เวลา 1-5 นาทีในการเชื่อมโยงที่สร้างขึ้นใหม่ | รอ 1-2 นาที แล้วคลิกเรียกใช้งานที่ล้มเหลวอีกครั้งใน 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 และการแก้ปัญหาเกี่ยวกับรหัสออกของ CLI
คำสั่ง CodeMender (cm health --strict, cm find, cm verify และ cm fix) จะแสดงผลรหัสออกเชิงกำหนด เพื่อให้ไปป์ไลน์ CI/CD แยกแยะผลการค้นหาด้านความปลอดภัยจากข้อผิดพลาดในการตั้งค่าหรือบริการได้ทันที ดังนี้
โค้ดสำหรับออก | หมวดหมู่ | สาเหตุของปัญหาที่พบบ่อยและการแก้ไข |
| สำเร็จ | การตรวจสอบประสิทธิภาพผ่านแล้วหรือการสแกนเสร็จสมบูรณ์โดยไม่พบสิ่งที่บล็อก |
| เครื่องมือช่าง / ทั่วไป |
|
|
| การแลกเปลี่ยนโทเค็น WIF OAuth/ADC ไม่สำเร็จ ( |
|
| ไวยากรณ์ |
|
| Runner เข้าถึง |
|
| บัญชีบริการไม่มี |
|
| การตรวจสอบ Preflight |
|
| Agent มีงานที่ทำงานพร้อมกันถึงขีดจำกัดแล้ว โปรดเรียกใช้เวิร์กโฟลว์อีกครั้งหลังจากผ่านไปสักครู่ |
สำหรับข้อผิดพลาดขณะรันไทม์เพิ่มเติม เช่น การแก้ไข Branch พื้นฐานของ Git diff (fetch-depth: 0), ความล่าช้าในการเผยแพร่ทรัพยากร หรือสิทธิ์การสร้าง Pull Request ของ GitHub Actions โปรดดูคู่มือการแก้ปัญหา CI/CD ของ CodeMender อย่างเป็นทางการ
11. ล้างทรัพยากร
หากต้องการป้องกันไม่ให้มีการใช้ทรัพยากรอย่างต่อเนื่องหรือล้างการกำหนดค่าการทดสอบในสภาพแวดล้อม Google Cloud และ GitHub ให้ทำตามขั้นตอนการล้างต่อไปนี้
ขั้นตอนที่ 1: นำข้อมูลลับของที่เก็บ GitHub ออกและปิดใช้เวิร์กโฟลว์ผ่าน gh CLI
ใช้ GitHub CLI (gh) เพื่อลบข้อมูลลับของ Actions ในที่เก็บอย่างสมบูรณ์และปิดใช้เวิร์กโฟลว์ 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: ปิดใช้หรือลบทรัพยากร Workload Identity Federation ของ Google Cloud
Workload Identity Pool, ผู้ให้บริการ และบัญชีบริการจะไม่มีค่าใช้จ่ายเมื่อไม่มีการใช้งานหากไม่มีการแลกเปลี่ยนโทเค็น เลือกโหมดการล้างข้อมูลที่ตรงกับเวิร์กโฟลว์ของคุณ ดังนี้
ตัวเลือก ก — หยุดการเข้าถึงชั่วคราว (แนะนำหากคุณวางแผนที่จะเรียกใช้ซ้ำในโปรเจ็กต์นี้): ปิดใช้การแลกเปลี่ยนโทเค็น 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}"
ตัวเลือก ข — การแยกส่วนทั้งหมด: ลบผู้ให้บริการ WIF, พูล (เก็บไว้ในสถานะ 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. ขอแสดงความยินดี
ยินดีด้วย คุณทำ Codelab รักษาความปลอดภัยให้ไปป์ไลน์ CI/CD ด้วย CodeMender เสร็จแล้ว
คุณได้ออกแบบ สร้าง และทำให้ไปป์ไลน์ DevSecOps ระดับ Production แบบ Zero Trust เป็นอัตโนมัติเรียบร้อยแล้วโดยใช้ Workload Identity Federation ของ Google Cloud, CodeMender และ GitHub Actions
สิ่งที่คุณได้พูดถึง
การตรวจสอบสิทธิ์แบบไม่ใช้คีย์และไม่เชื่อใจใคร: กำจัดคีย์ JSON ของบัญชีบริการที่มีอายุการใช้งานยาวนานและมีความเสี่ยงโดยการเชื่อมโยงโทเค็น OIDC ของ GitHub แบบชั่วคราวกับ Google Cloud IAM ผ่าน Workload Identity Federation (WIF)
การสแกน AST แบบดิฟเฟอเรนเชียลของ PR และการตัดเสียงรบกวนแบบเดิม: การสแกนอย่างต่อเนื่องที่กำหนดขอบเขตไปยังไฟล์ที่แก้ไขและทรัพยากร Dependency (--diff="origin/$BASE_REF") โดยแยกหนี้ทางเทคนิคแบบเดิม ([LEGACY / UNTOUCHED]) เพื่อให้การเก็บฟีดแบ็กมาแก้ไขของนักพัฒนาซอฟต์แวร์อยู่ภายใต้ 15 วินาที
การรายงานหลายรูปแบบและสรุปงานแบบเนทีฟ: รวม OASIS SARIF v2.1.0 สำหรับการสแกนโค้ด GitHub แบบรวมศูนย์เข้ากับ Markdown แบบเนทีฟ (cm report -f md >> $GITHUB_STEP_SUMMARY) เพื่อให้ผู้บริหารมองเห็นได้ทันทีบนหน้าการเรียกใช้เวิร์กโฟลว์ CI โดยตรง
การแก้ไขอัตโนมัติพร้อมการตรวจสอบแบบมีมนุษย์ร่วม: เปลี่ยนจากการแจ้งเตือนแบบพาสซีฟไปเป็นไปป์ไลน์การแก้ไขแบบแอ็กทีฟที่สังเคราะห์แพตช์โค้ดที่เสนอโดยอัตโนมัติ ยืนยันกับชุดโปรแกรมทดสอบการถดถอย และเปิด Pull Request สำหรับการตรวจสอบพร้อมอาร์ติแฟกต์การตรวจสอบเพื่อให้วิศวกรลงชื่ออนุมัติ
เกตคุณภาพอัตโนมัติที่เข้มงวด: บังคับใช้การป้องกัน Branch และการกำหนดเกตการผสาน (--fail-on) ที่เข้มงวดเพื่อบล็อกช่องโหว่ที่เป็นอันตรายไม่ให้เข้าถึงเวอร์ชันที่ใช้งานจริง
การโอนสถานะที่ขับเคลื่อนด้วยอาร์ติแฟกต์และการแยกพื้นที่ทำงาน: โอนผลการค้นพบระหว่างงาน CI ได้อย่างราบรื่นโดยใช้ cm report import ขณะที่ใช้ .git/info/exclude เพื่อรักษาประวัติ Git ที่สมบูรณ์และป้องกันการรั่วไหลของข้อมูลเข้าสู่ระบบ
การเปลี่ยนแนวคิดของนักพัฒนาแอป
แนวทางปฏิบัติ DevSecOps แบบดั้งเดิม | ไปป์ไลน์ CI/CD อัตโนมัติของ CodeMender |
การแสดงการแจ้งเตือนแบบพาสซีฟ: เครื่องมือสแกนจะพิมพ์บันทึกเทอร์มินัลดิบหรือรายการข้อผิดพลาดแบบคงที่ ซึ่งจะทำให้ภาระในการคัดแยกตกเป็นของนักพัฒนาแอปทั้งหมด | Active Co-developer: สังเคราะห์แพตช์โค้ดที่ได้รับการยืนยันแล้ว และเปิด Pull Request ที่พร้อมผสานรวมเพื่อให้วิศวกรอนุมัติ |
ผลบวกลวงสูง: การวิเคราะห์พฤติกรรมของ AST แบบคงที่จะแจ้งเตือนช่องโหว่ทางทฤษฎีหลายพันรายการโดยไม่มีหลักฐานการใช้ประโยชน์จากช่องโหว่ | การยืนยันการเจาะระบบแบบ 2 ระดับ: การสร้างการทดสอบแซนด์บ็อกซ์แบบไดนามิก ( |
พื้นที่เก็บข้อมูลลับที่มีความเสี่ยง: คีย์ JSON ของบัญชีบริการที่มีอายุการใช้งานยาวนานซึ่งจัดเก็บไว้ในข้อมูลลับของ CI มีความเสี่ยงต่อการรั่วไหลโดยไม่ตั้งใจและการแพร่กระจายของข้อมูลเข้าสู่ระบบ | WIF แบบ Zero Trust: การตรวจสอบสิทธิ์แบบไม่ใช้คีย์ผ่านโทเค็น OIDC แบบชั่วคราวที่แลกเปลี่ยนกับ STS ของ Google Cloud ตามต้องการ |
การสแกนซ้ำแบบ Monolithic: ทุกคอมมิตจะทริกเกอร์การตรวจสอบที่เก็บข้อมูลทั้งหมด ซึ่งทำให้เวิร์กโฟลว์ CI ล่าช้าและสิ้นเปลืองโทเค็นที่มีราคาแพง | การกำหนดเส้นทาง AST ที่รับรู้เหตุการณ์: Pull Request จะเรียกใช้การสแกน AST แบบส่วนต่าง 15 วินาที ( |
ประวัติที่เก็บที่ปนเปื้อน: สคริปต์การเจาะระบบชั่วคราวและบันทึกการโจมตีที่ส่งไปยังสาขาของที่เก็บโดยตรง | Enterprise Workspace Hygiene: หลักฐานการโจมตีที่ฝังไว้อย่างแนบเนียนในคำอธิบาย PR และอาร์ติแฟกต์เวิร์กโฟลว์ ทำให้การคอมมิตโค้ดดูไม่มีพิรุธ |
ขั้นตอนถัดไป
🚀 เรียนรู้เกี่ยวกับ CodeMender ต่อ
ส่วนที่ 1: รักษาความปลอดภัยให้แอปพลิเคชันด้วย CodeMender - เรียนรู้การค้นหาช่องโหว่ในที่เก็บข้อมูลแบบอัตโนมัติ การยืนยันการเจาะระบบ PoC และการสังเคราะห์แพตช์ในเครื่อง
Shift Left Locally และ Serverless Cloud Native CI/CD: สำรวจการติดตั้งใช้งานอ้างอิงของคู่มือ CI/CD อย่างเป็นทางการสำหรับ Google Cloud Build (cloudbuild.yaml) และฮุก Pre-commit ของ Git ในเครื่อง (cm find . --diff --staged)
📖 ดูเอกสารประกอบและแหล่งข้อมูล
คู่มือการผสานรวม CI/CD ของ Google Cloud CodeMender อย่างเป็นทางการ
เอกสารประกอบอย่างเป็นทางการของ Google Cloud CodeMender
ที่เก็บเทมเพลตเริ่มต้นของ GitHub Actions สำหรับ CodeMender
เอกสารประกอบเกี่ยวกับ Workload Identity Federation ใน Google Cloud
💡 นำไปใช้กับที่เก็บของคุณเอง
แยกเวิร์กโฟลว์เริ่มต้นและรักษาความปลอดภัยให้ที่เก็บ Python, Go, Java, Rust และ Node.js ขององค์กรด้วย CodeMender