1. Sebelum memulai
Selamat datang di codelab interaktif untuk Mengamankan Pipeline CI/CD dengan CodeMender.
Dalam pengiriman software modern, alat analisis statis (seperti CodeQL) sangat penting untuk menangkap pola sintaksis yang diketahui, tetapi alat ini sering kali melewatkan kerentanan bernuansa yang tersembunyi jauh di dalam logika bisnis dan menghasilkan pemberitahuan yang bising dan tidak terverifikasi.
CodeMender (CLI yang dapat dieksekusi: cm) meningkatkan kualitas pipeline CI/CD Anda—beroperasi bersama alat SAST yang ada—dengan men-deploy agen penalaran keamanan yang didukung Gemini dari Google untuk:
Mengungkap kelemahan logika bisnis yang kompleks: Memahami konteks aplikasi dan aliran data arsitektur di luar aturan pola statis yang kaku.
Mengurangi positif palsu secara drastis melalui verifikasi eksploitasi mandiri: Membuktikan eksploitabilitas secara dinamis di lingkungan sandbox sebelum memberi tahu developer.
Memperbaiki temuan terverifikasi secara mandiri: Menyintesis patch kode, memvalidasi terhadap suite pengujian untuk mencegah regresi, dan mengirimkan Permintaan Pull yang siap ditinjau.
Dalam codelab ini, Anda akan mengintegrasikan CodeMender ke repositori OWASP Juice Shop menggunakan GitHub Actions dan Workload Identity Federation (WIF) Google Cloud tanpa kunci.
Prasyarat
- Direkomendasikan: Pemahaman dasar tentang konsep CodeMender (dibahas dalam Mengamankan Aplikasi Anda dengan CodeMender)
- Pemahaman dasar tentang alur kerja, pemicu, dan sintaksis YAML GitHub Actions
- Pemahaman dasar tentang perintah Git dan alur kerja peninjauan permintaan pull
- Pengetahuan dasar tentang konsep IAM Google Cloud (Akun Layanan, Peran, dan API)
- Memahami kerentanan umum aplikasi web (seperti Injeksi SQL dan XSS)
Yang akan Anda pelajari
- Cara mengonfigurasi autentikasi tanpa kunci zero-trust antara GitHub Actions dan Google Cloud melalui Workload Identity Federation (WIF)
- Cara membangun alur kerja pemindaian kerentanan otomatis menggunakan CodeMender dan
gemini-3.8-flash - Cara memublikasikan laporan keamanan yang dapat ditindaklanjuti menggunakan OASIS SARIF v2.1.0 dan Ringkasan Tugas GitHub Actions native
- Cara membuat alur kerja perbaikan otonom yang menghasilkan patch kode yang diverifikasi pengujian dan membuka Permintaan Pull untuk ditinjau secara manual
- Cara menerapkan gerbang keras kualitas otomatis (
--fail-on) dan caching pipeline untuk keamanan berkelanjutan berkecepatan tinggi
Yang Anda butuhkan
- Project Google Cloud dengan penagihan yang diaktifkan dan izin Project Owner/Editor
- Akun GitHub dengan izin untuk membuat repositori, mengonfigurasi Secret, dan mengelola Action (Anda akan melakukan fork Repo GitHub OWASP Juice Shop di Langkah 3 menggunakan GitHub CLI).
2. Memahami arsitektur CI/CD CodeMender
Dalam DevSecOps perusahaan modern, keamanan yang didukung AI tidak boleh hanya menjadi alat desktop manual. Alat ini harus beroperasi sebagai gatekeeper otomatis (memblokir permintaan pull yang tidak aman) dan co-developer otonom (mengusulkan patch terverifikasi langsung ke Git).
Untuk mencapai hal ini, Anda akan menerapkan Arsitektur Alur Kerja Ganda yang didukung oleh Workload Identity Federation (WIF) Google Cloud dan model penalaran Gemini Enterprise.
Arsitektur alur kerja ganda
Daripada menjejalkan deteksi dan remediasi ke dalam satu skrip monolitik, pipeline memisahkan keamanan menjadi dua alur kerja yang terpisah dan dibuat khusus:
Alur kerja | Pemicu Utama | Tanggung Jawab Inti | Gerbang Keras Kualitas |
1. Pemindai Kerentanan( | Permintaan Pull, Push Utama, Cron Mingguan, Pengiriman Manual | • Menjalankan pemindaian AST diferensial cepat pada PR (~15 dtk), pemindaian dasar pengukuran cepat pada push ( | Memblokir penggabungan PR jika kerentanan Tinggi atau Kritis yang baru diperkenalkan terdeteksi ( |
2. Autonomous Remediator( | Pemicu Manual ( | • Melanjutkan status dari artefak pemindaian ( | Memastikan perbedaan produksi yang bersih sebelum membuka PR |
Tiga prinsip desain perusahaan inti
Saat Anda membangun alur kerja ini di bagian mendatang, ingatlah tiga pilar arsitektur dasar ini:
🔑 Autentikasi Tanpa Kunci Zero-Trust dan Validasi Preflight:
Tidak ada kunci JSON Akun Layanan Google Cloud yang berumur panjang yang disimpan di GitHub Secrets. Runner menghasilkan token OIDC berumur pendek yang ditukarkan melalui Google Cloud STS untuk kredensial sementara berdurasi 1 jam, menetapkan persist-credentials: false pada checkout Git, dan menjalankan cm health --strict untuk memverifikasi kredensial, keterjangkauan jaringan, dan izin IAM sebelum menggunakan kuota model.
⚡ Pemilihan Rute Pemindaian Adaptif dan Peredam Kebisingan Lama:
Alih-alih menjalankan audit repositori penuh yang lambat pada setiap permintaan pull, CodeMender mengarahkan setiap peristiwa CI ke mode pemindaian yang optimal: Permintaan Pull memicu analisis AST diferensial (--diff="origin/$BASE_REF") pada file yang dimodifikasi dan pemanggil 1-hop dalam waktu kurang dari 15 detik; push cabang utama menjalankan pemindaian dasar pengukuran cepat satu sesi (--quick); dan jadwal mingguan menjalankan audit mendalam file demi file secara serentak (default cm find .). Kerentanan codebase yang sudah ada sebelumnya dan tidak tersentuh oleh PR diberi label [LEGACY / UNTOUCHED]; kerentanan tersebut muncul dalam laporan SARIF untuk visibilitas, tetapi tidak memblokir gerbang penggabungan PR dan tidak memicu perbaikan otomatis.
🛡️ Kemampuan Observasi Keamanan yang Tangguh dan Tidak Memblokir:
Meskipun --fail-on keluar dengan kode 1 untuk memblokir PR yang tidak aman, melindungi langkah-langkah ekspor laporan dan upload SARIF dengan steps.scan.outputs.completed == 'true' dan hashFiles('results.sarif') != '' menjamin bahwa pemberitahuan SARIF OASIS dan Ringkasan Tugas tetap dipublikasikan—sekaligus melewati ekspor dan upload dengan rapi jika operasi dibatalkan atau dihentikan karena error penyiapan atau kapasitas (10–60).
3. Melakukan autentikasi dan menyiapkan repositori target di Cloud Shell
Untuk membuat autentikasi tanpa kunci dan menjalankan pipeline keamanan otomatis, Anda memerlukan repositori GitHub target yang dapat diakses dan Anda miliki. Dalam codelab ini, Anda akan menggunakan OWASP Juice Shop—aplikasi web Node.js yang sengaja dibuat rentan—sebagai playground keamanan siap pakai.
Anda akan menggunakan GitHub CLI (gh), yang telah diinstal sebelumnya di Google Cloud Shell, untuk melakukan autentikasi dengan GitHub, mengambil detail pengguna Anda secara otomatis, dan menyiapkan repositori Anda dalam satu alur yang efisien.
Langkah 1: Buka Cloud Shell dan autentikasi GitHub CLI
Buka Konsol Google Cloud dan aktifkan Cloud Shell (ikon >_ di menu navigasi atas).
Autentikasi GitHub CLI (gh) untuk mengonfigurasi pengelolaan kredensial Git:
gh auth login --hostname github.com --git-protocol https --web
Ikuti petunjuk di layar:
Salin kode sekali pakai 8 karakter yang dicetak di Cloud Shell (misalnya, 1234-ABCD).
Tekan Enter untuk membuka https://github.com/login/device di browser Anda.
Tempel kode dan klik Authorize github.
Langkah 2: Ekspor variabel secara dinamis dan buat fork OWASP Juice Shop
Jalankan perintah berikut di Cloud Shell untuk otomatis mengambil nama pengguna GitHub Anda dan menyiapkan repositori:
# 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. Mengonfigurasi Workload Identity Federation Google Cloud melalui gcloud
Pada langkah ini, Anda akan menggunakan gcloud CLI di Google Cloud Shell untuk mengaktifkan API yang diperlukan, membuat Akun Layanan CI/CD khusus, menyiapkan Workload Identity Pool, dan membuat kepercayaan OIDC dengan repositori GitHub Anda (${GITHUB_REPOSITORY}).
Langkah 1: Tetapkan variabel lingkungan Google Cloud
Di terminal Cloud Shell (di dalam ruang kerja repositori yang di-clone), ambil Project ID Google Cloud aktif Anda, verifikasi variabel repositori GitHub, dan tentukan nama resource 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
Langkah 2: Aktifkan Google Cloud API yang diperlukan
Aktifkan IAM API, Security Token Service API, IAM Credentials API, Agent Platform API, dan Resource Manager API:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
Langkah 3: Buat akun layanan CI/CD khusus
Buat Akun Layanan Google Cloud dengan hak istimewa terendah yang dikhususkan untuk eksekusi pipeline CI/CD (gunakan kembali dengan aman jika sudah ada):
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}"
Langkah 4: Memberikan izin IAM Agent Platform
Berikan peran roles/aiplatform.user (Agent Platform User) ke Akun Layanan agar dapat berkomunikasi dengan Gemini Enterprise Agent Platform:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
Langkah 5: Buat Workload Identity pool
Buat Workload Identity Pool untuk mengelola pernyataan identitas GitHub Actions (atau pulihkan dan aktifkan secara otomatis jika sudah ada di project Anda):
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
Langkah 6: Buat Workload Identity Provider dengan OIDC GitHub
Buat (atau perbarui) Penyedia OIDC dalam pool, dengan mengikat URL penerbit https://token.actions.githubusercontent.com dan memetakan pernyataan token GitHub ke atribut 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
Langkah 7: Izinkan repositori GitHub untuk meniru identitas akun layanan
Ikat peran roles/iam.workloadIdentityUser untuk mengizinkan token yang berasal dari repositori Anda meniru identitas Akun Layanan runner CI, dan verifikasi binding kebijakan:
# 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
Langkah 8: Ambil nilai konfigurasi untuk secret GitHub
Ambil nama resource lengkap Workload Identity Provider Anda dan simpan dalam variabel lingkungan untuk pendaftaran otomatis di langkah berikutnya:
# 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. Mengonfigurasi secret repositori GitHub dan izin alur kerja
Setelah Google Cloud WIF disediakan, Anda akan mengonfigurasi GitHub Repository Secrets dan memberikan izin alur kerja yang diperlukan untuk pemindaian keamanan otomatis dan Permintaan Pull perbaikan otomatis.
Anda dapat mengonfigurasi setelan ini langsung dari Cloud Shell menggunakan GitHub CLI (gh), sehingga tidak perlu lagi menyalin dan menempel nama resource yang panjang secara manual.
Langkah 1: Tetapkan secret repositori menggunakan GitHub CLI
Di terminal Cloud Shell, jalankan perintah berikut untuk menetapkan dua secret repositori yang diperlukan dengan aman menggunakan variabel lingkungan aktif:
# 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}"
Langkah 2: Berikan izin alur kerja untuk PR otomatis
Secara default, alur kerja GitHub Actions berjalan dengan izin hanya baca dan tidak dapat membuat Permintaan Pull. Pada Langkah 9, CodeMender akan otomatis membuat dan mengirimkan Permintaan Pull perbaikan yang telah diverifikasi.
Berikan izin tulis dan aktifkan pembuatan permintaan pull langsung melalui 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
Langkah 3: Nonaktifkan alur kerja Juice Shop upstream yang diwariskan
Membuat fork OWASP Juice Shop akan membawa lebih dari 16 alur kerja CI upstream (seperti PR Compliance Check, CI/CD Pipeline, dan CodeQL Scan) bersama dengan template PR kontributor upstream yang otomatis menutup PR yang menargetkan master. Nonaktifkan semua alur kerja non-CodeMender melalui GitHub CLI dan hapus file upstream secara lokal agar fork Anda hanya menjalankan alur kerja 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. Membangun alur kerja pemindaian kerentanan otomatis dengan SARIF
Pada langkah ini, Anda akan membuat alur kerja pemindaian keamanan berkelanjutan utama (.github/workflows/codemender-scan.yml) yang menjalankan pemindaian dasar pada push cabang, gerbang diferensial pada Permintaan Pull, dan ekspor SARIF ke GitHub Code Scanning.
Langkah 1: Download alur kerja pemindaian CodeMender
Download codemender-scan.yml dari repositori awal ke .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
Langkah 2: Commit, kirim, dan picu pemindaian CI
Commit perubahan alur kerja dan kirim langsung ke cabang utama repositori Anda (master untuk Juice Shop, atau 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)
Di browser Anda:
Buka repositori GitHub yang di-fork: https://github.com/YOUR_GITHUB_USER/juice-shop (misalnya, https://github.com/octocat/juice-shop).
Klik tab Actions di menu navigasi atas.
Di sidebar kiri di bagian Workflows, pilih CodeMender Security Scan & SARIF Export.
Picu atau lihat eksekusi alur kerja:
Pemicu Otomatis: Jika operasi otomatis yang dipicu oleh push Anda tercantum, klik langsung untuk memantau eksekusi langsung.
Pemicu On-Demand Manual (workflow_dispatch): Jika belum ada operasi yang dimulai, klik tombol Run workflow ▾ di sebelah kanan, pastikan Branch: master dipilih (biarkan kotak centang deep_scan tidak dicentang agar pemindaian dasar pengukuran --quick yang cepat berjalan), lalu klik tombol Run workflow berwarna hijau.
Klik operasi yang sedang berjalan dan pilih Autonomous Code Vulnerability Scan untuk melihat alur kerja berjalan secara real-time.
Di dalam codemender-scan.yml: Pemilihan rute pemindaian berbasis peristiwa
Saat pemindaian dasar pengukuran --quick berjalan di cloud (~3–5 menit), periksa cara codemender-scan.yml (baris 118–155) merutekan setiap peristiwa GitHub ke mode pemindaian khusus di dalam 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
Penyiapan Hardened Runner ( baris 27–117): Melewati fork eksternal yang tidak tepercaya dan PR dependabot[bot], melakukan checkout dengan persist-credentials: false, meng-cache ~/.local/bin/cm dan ~/.codemender/state.db, serta menjalankan cm health --strict sebelum menggunakan kuota model.
Headless Sandbox Boundaries (--sandbox=false --yes --bypass-warning): Menonaktifkan isolasi namespace pengguna Linux (dibatasi di dalam container GitHub Actions tanpa hak istimewa) sekaligus menjaga batas jalur ruang kerja (project_paths) dan command_policy.yaml tetap diterapkan.
Ekspor Artefak & SARIF yang Dilindungi Kode Keluar ( baris 147–194): Menetapkan steps.scan.outputs.completed=true secara ketat saat cm find keluar dengan 0 (bersih) atau 1 (batas --fail-on terpenuhi). Hal ini menjamin bahwa laporan SARIF (cm report -f sarif dengan skor tingkat keparahan CVSS), tabel $GITHUB_STEP_SUMMARY (cm report -f md), dan artefak codemender-findings.json tetap dipublikasikan saat --fail-on memblokir PR—sekaligus melewati ekspor pada error penyiapan atau kapasitas (10–60) sehingga file SARIF kosong tidak pernah menutup pemberitahuan yang ada.
7. Memeriksa pemberitahuan GitHub Code Scanning dan dasbor keamanan
Setelah alur kerja push dasar pengukuran selesai, GitHub akan memproses file SARIF yang diupload dan mengisi ringkasan operasi Actions serta tab Security repositori.
Langkah 1: Periksa ringkasan tugas native di GitHub Actions
Setiap operasi alur kerja menambahkan tabel ringkasan Markdown (cm report -f md) langsung ke ringkasan operasi GitHub Actions:
Di repositori GitHub Anda, klik tab Actions.
Pilih operasi CodeMender Security Scan & SARIF Export yang telah selesai (audit push cabang dasar selesai dengan tanda centang ✅ hijau setelah memublikasikan temuan SARIF).
Scroll ke bawah ke bagian 🛡️ CodeMender Security Scan Summary untuk memeriksa perincian temuan:
🔒 Laporan Keamanan CodeMender
Ringkasan
Total temuan: 28
Keparahan | Jumlah |
🔴 KRITIS | 6 |
🟠 TINGGI | 16 |
🟡 SEDANG | 6 |
Status | Jumlah |
🔴 BUKA | 28 |
Findings
ID | Keparahan | Keyakinan | Status | Perbaiki | File | Judul |
| 🔴 KRITIS | 100% | BUKA | — |
| Eksekusi Kode Jarak Jauh melalui Injeksi Kode Sisi Server di Profil Pengguna |
| 🔴 KRITIS | 100% | BUKA | — |
| Injeksi SQL di Rute Autentikasi Pengguna |
| 🔴 KRITIS | 100% | BUKA | — |
| Eksekusi Kode Jarak Jauh melalui Sandbox Escape dalam Pemrosesan Pesanan B2B |
Langkah 2: Pelajari dasbor Code Scanning terpusat
Di menu navigasi atas repositori GitHub Anda, klik tab Security and quality (atau Security).
Di sidebar kiri di bagian Findings, pilih Code scanning.
Jika beberapa alat aktif, filter Tool ke CodeMender (is:open branch:master tool:CodeMender) untuk memeriksa pemberitahuan yang dipetakan dengan badge tingkat keparahan CVSS native:
Badge Tingkat Keparahan | Judul Kerentanan | Lokasi yang Terdeteksi | Branch |
🔴 Kritis | Eksekusi Kode Jarak Jauh melalui Injeksi Kode Sisi Server di Profil Pengguna |
|
|
🔴 Kritis | Injeksi SQL di Rute Autentikasi Pengguna |
|
|
🔴 Kritis | Eksekusi Kode Jarak Jauh melalui Sandbox Escape dalam Pemrosesan Pesanan B2B |
|
|
Klik Injeksi SQL di Rute Autentikasi Pengguna (routes/login.ts:34) untuk meninjau aliran data yang tercemar dan Analisis Penyebab Utama yang disintesis oleh Gemini.
8. Memblokir Permintaan Pull yang tidak aman dengan pemindaian diferensial
Pemindaian dasar Anda menemukan 28 kerentanan yang sudah ada sebelumnya di OWASP Juice Shop. Dengan penganalisis statis tradisional, 28 temuan lama tersebut akan menggagalkan setiap Permintaan Pull mendatang hingga seluruh backlog diperbaiki—sehingga memaksa tim untuk menonaktifkan pemblokiran penggabungan.
Sekarang Anda akan menguji PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") CodeMender dalam tindakan: membuka Permintaan Pull yang memperkenalkan kerentanan baru dan melihat CodeMender mengisolasi delta, memblokir penggabungan dalam ~15–25 detik, dan menganotasi baris yang bermasalah.
Langkah 1: Buka Permintaan Pull yang memperkenalkan kelemahan injeksi perintah
Di Cloud Shell (di dalam ruang kerja repositori yang di-clone), buat cabang fitur, tambahkan rute Express baru yang berisi kerentanan Injeksi Perintah OS, dan buka Permintaan Pull terhadap fork Anda:
[ -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."
Langkah 2: Verifikasi gerbang penggabungan diferensial dan anotasi PR inline
Buka URL Permintaan Pull yang dicetak di akhir output terminal.
Scroll ke kotak Checks di bagian bawah halaman percakapan permintaan pull dan lihat Autonomous Code Vulnerability Scan:
Kecepatan Delta: Alih-alih memindai semua 680+ file di repositori (~3–5 menit), cm find . --diff="origin/${PRIMARY_BRANCH}" membatasi analisis secara ketat pada routes/diagnostics.ts (dan pemanggil 1-hop), sehingga pemindaian selesai dalam ~15–25 detik.
Isolasi Utang Lama & Pemblokiran Penggabungan: Tidak ada satu pun dari 28 kerentanan lama Juice Shop yang tidak tersentuh yang gagal dalam pemeriksaan—hanya Injeksi Perintah CRITICAL yang baru diperkenalkan yang memicu --fail-on="CRITICAL,HIGH", keluar dengan kode status 1 (❌ merah) untuk memblokir penggabungan PR.
Klik tab Files changed di bagian atas Permintaan Pull:
Karena guard kode keluar alur kerja (steps.scan.outputs.completed == 'true') masih mengekspor dan mengupload results.sarif saat --fail-on keluar dengan kode 1, GitHub Code Scanning merender anotasi keamanan CodeMender — Critical inline langsung di bawah execSync di routes/diagnostics.ts.
Langkah 3: Bersihkan PR pengujian dan kembali ke cabang utama
Alihkan ruang kerja Cloud Shell Anda kembali ke cabang utama dan tutup Permintaan Pull pengujian yang tidak aman sebelum melanjutkan ke perbaikan otonom:
[ -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. Membangun alur kerja perbaikan otonom dan PR otomatis
Setelah gerbang Permintaan Pull mencegah kerentanan baru masuk ke codebase, Anda akan men-deploy Autonomous Remediation (.github/workflows/codemender-remediate.yml) untuk secara aktif memperbaiki kerentanan yang ada dan membuka Permintaan Pull yang siap ditinjau.
Langkah 1: Download file alur kerja perbaikan
CodeMender menyediakan dua template perbaikan, bergantung pada visibilitas repositori:
Repositori Publik/Open Source (codemender-remediate.yml): Responsible Disclosure Mode—menautkan ke pemberitahuan SARIF Pemindaian Kode GitHub tanpa mengekspos vektor eksploitasi mentah secara publik.
Repositori Pribadi/Enterprise (codemender-remediate-private-repo.yml): Mode Bukti Audit Internal—menyematkan artefak verifikasi (PLAN.md, REPORT.md, exploit.sh) di dalam bagian PR yang dapat diciutkan, sekaligus mengecualikannya dari commit Git.
Download alur kerja perbaikan yang aman untuk publik ke repositori Anda:
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
Langkah 2: Commit dan picu alur kerja perbaikan otonom
Commit dan kirim alur kerja perbaikan ke cabang utama Anda:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
Di browser, buka tab Actions repositori GitHub Anda.
Di sidebar kiri di bagian Workflows, pilih CodeMender Autonomous Security Remediation & Auto-PR.
Klik dropdown Run workflow berwarna hijau di sebelah kanan:
Use workflow from: Pastikan cabang default (master) dipilih.
Specific Finding ID or prefix to fix: Masukkan awalan 8 karakter untuk routes/login.ts yang dicatat di Langkah 7 (misalnya, cd47b38a). Jika dibiarkan kosong, perbaikan batch akan dijalankan di semua temuan Kritis dan Tinggi yang terbuka (~10–15 menit); menargetkan satu ID akan selesai dalam ~45–60 detik.
Klik tombol Run workflow hijau di dalam popover dan buka operasi yang sedang berjalan.
Di dalam codemender-remediate.yml: Sintesis patch otonom
Selagi CodeMender menyintesis patch di cloud (~30–45 detik), periksa cara codemender-remediate.yml (baris 111–184) mengatur remediasi di dalam runner:
Zero-Scan Resume (cm report import): Mendownload artefak codemender-findings.json dari alur kerja pemindaian dan mengimpornya ke ruang kerja (cm report import -f codemender-findings.json), dan kembali ke cm find . --quick hanya jika tidak ada artefak sebelumnya.
Headless Patch Synthesis (cm fix): Menyematkan project_paths ke $GITHUB_WORKSPACE, mengarahkan < /dev/null untuk mencegah hang interaktif, dan meneruskan --no-reset selama loop batch sehingga perbaikan kumulatif dipertahankan di seluruh temuan:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Clean Production Commits ( baris 155–252): Menghapus .cm_project, .exploit/, dan file sementara melalui .git/info/exclude sebelum peter-evans/create-pull-request@v8 membuka cabang (codemender/auto-remediation-${{ github.run_id }}), yang secara ketat melakukan commit perubahan kode produksi:
--- 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
+ })
Langkah 3: Tinjau Permintaan Pull yang baru dibuka di GitHub
Buka tab Pull requests di repositori Anda dan buka Permintaan Pull baru (misalnya, 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
Klik Files changed untuk mengonfirmasi bahwa hanya routes/login.ts yang diubah, dengan semua metadata runtime internal dikecualikan.
Tinjau deskripsi PR yang tertaut langsung ke pemberitahuan GitHub Code Scanning (SARIF) untuk persetujuan pengelola.
10. Memecahkan masalah kasus ekstrem dan repositori pribadi
Repositori pribadi tanpa GitHub Advanced Security (GHAS)
Repositori GitHub publik menerima penyerapan SARIF GitHub Code Scanning gratis tanpa batas. Namun, jika Anda men-deploy alur kerja ini ke repositori Private Enterprise yang tidak memiliki lisensi GitHub Advanced Security (GHAS) aktif, langkah upload-sarif akan gagal dengan:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
Penyelesaian: Penggantian Laporan HTML Interaktif Mandiri
Generator laporan HTML bawaan CodeMender (cm report -f html) membuat dasbor keamanan interaktif mandiri yang menampilkan kartu metrik tingkat keparahan, cuplikan kode yang ditandai sintaksisnya dengan nomor baris, dan penampil perbedaan patch inline tanpa dependensi web eksternal.
Untuk mendukung repositori pribadi tanpa lisensi GHAS, update .github/workflows/codemender-scan.yml untuk mengarsipkan artefak laporan HTML, bukan mengupload SARIF:
Membuat laporan HTML mandiri: Pada langkah Export Security Reports & Publish Job Summary, ekspor dasbor HTML bersama ringkasan Markdown Anda menggunakan cm report -f html > codemender-audit-report.html.
Arsipkan laporan sebagai artefak alur kerja: Ganti langkah Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) dengan actions/upload-artifact@v4 yang dikonfigurasi untuk mengupload codemender-audit-report.html (misalnya, di bawah nama artefak codemender-security-report).
Periksa secara lokal di browser apa pun: Download codemender-security-report.zip langsung dari halaman ringkasan operasi alur kerja GitHub Actions, ekstrak, dan buka codemender-audit-report.html di browser web apa pun untuk triase visual.
Perbaikan otonom repositori pribadi dengan bukti audit tersemat
Di repositori perusahaan pribadi, tim engineering dan keamanan memerlukan visibilitas penuh ke analisis penyebab utama, bukti konsep eksploitasi, dan rencana perbaikan tanpa memerlukan dasbor alat eksternal. Namun, meng-commit skrip eksploitasi (exploit.sh) atau file markdown internal (PLAN.md, LOG.md) ke cabang repositori akan mengotori histori git dan dapat memicu pemberitahuan palsu dari pemindai keamanan lainnya.
Untuk mengatasinya, deploy Alur Kerja Perbaikan Repositori Pribadi (codemender-remediate-private-repo.yml) khusus:
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)
Cara kerja perbaikan repositori pribadi
Dynamic PoC Verification (cm verify): Melakukan sintesis dan menguji eksploitasi yang berfungsi sebelum membuat perbaikan untuk mengonfirmasi eksploitabilitas—otomatis melewati cm fix jika verifikasi menandai temuan yang tidak dapat dieksploitasi sebagai DISMISSED.
Embedded PR Audit Collapsibles: Mengekstrak REPORT.md, PLAN.md, dan exploit.sh ke dalam /tmp/codemender-evidence/ dan memformatnya langsung ke dalam deskripsi Permintaan Pull di dalam blok yang dapat diciutkan <details open> untuk pemeriksaan peninjau sekali klik.
Pengarsipan Artefak: Mengarsipkan folder bukti lengkap melalui actions/upload-artifact@v4.
Pristine Git Commits: Menghapus total semua metadata runtime dan direktori .exploit sehingga commit git Permintaan Pull hanya berisi perubahan kode produksi.
Checklist pemecahan masalah Workload Identity Federation (WIF)
Secara default, google-github-actions/auth@v2 menulis file konfigurasi kredensial gabungan lokal selama penyiapan, dan pertukaran token OAuth 2.0 yang sebenarnya terjadi saat cm health --strict atau cm find dimulai. Gunakan checklist di bawah untuk mendiagnosis error autentikasi HTTP 400 atau HTTP 403:
Gejala Error | Penyebab Utama yang Umum | Verifikasi & Perbaikan |
HTTP 403 ( | Binding | Konfirmasi bahwa |
HTTP 400 ( | Nama repositori OIDC | Jalankan kembali Langkah 4 (Langkah 1 dan 6) untuk memastikan |
HTTP 400 ( |
| Pastikan |
HTTP 403 sementara segera setelah penyiapan | Penyebaran IAM global dan Workload Identity Federation dapat memerlukan waktu 1–5 menit pada binding yang baru dibuat. | Tunggu 1–2 menit, lalu klik Re-run failed jobs di GitHub Actions. |
Untuk memeriksa binding Workload Identity aktif di Akun Layanan CI/CD Anda di Cloud Shell, jalankan:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
Pastikan output mengikat roles/iam.workloadIdentityUser ke 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
Pemecahan masalah preflight CI/CD dan kode keluar CLI
Perintah CodeMender (cm health --strict, cm find, cm verify, dan cm fix) menampilkan kode keluar deterministik sehingga pipeline CI/CD dapat segera membedakan temuan keamanan dari error penyiapan atau layanan:
Kode Keluar | Kategori | Penyebab Utama & Perbaikan Umum |
| Berhasil | Health check lulus atau pemindaian selesai tanpa temuan yang memblokir. |
| Temuan / Umum |
|
|
| Pertukaran token OAuth/ADC WIF gagal ( |
|
| Sintaksis |
|
| Runner tidak dapat menjangkau |
|
| Akun Layanan tidak memiliki |
|
| Pemeriksaan preflight |
|
| Agen mencapai batas tugas aktif serentak; jalankan ulang alur kerja setelah jeda singkat. |
Untuk error runtime tambahan—seperti resolusi cabang dasar diff Git (fetch-depth: 0), penundaan propagasi resource, atau izin pembuatan Permintaan Pull GitHub Actions—lihat Panduan Pemecahan Masalah CI/CD CodeMender resmi.
11. Membersihkan resource
Untuk mencegah konsumsi resource yang berkelanjutan atau membersihkan konfigurasi pengujian di lingkungan Google Cloud dan GitHub Anda, lakukan langkah-langkah pembersihan berikut.
Langkah 1: Hapus secret repositori GitHub dan nonaktifkan alur kerja melalui gh CLI
Gunakan GitHub CLI (gh) untuk menghapus secret Actions repositori dengan rapi dan menonaktifkan alur kerja 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
Langkah 2: Nonaktifkan atau hapus resource Google Cloud Workload Identity Federation
Workload Identity Pool, Penyedia, dan Akun Layanan dikenai biaya nonaktif nol saat tidak bertukar token. Pilih mode pembersihan yang sesuai dengan alur kerja Anda:
Opsi A — Jeda akses (Direkomendasikan jika Anda berencana menjalankan ulang di project ini): Menonaktifkan pertukaran token OIDC segera tanpa memicu retensi penghapusan sementara selama 30 hari di Google Cloud IAM atau penundaan penerapan uniqueId Akun Layanan:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
Opsi B — Penghapusan penuh: Menghapus Penyedia WIF, Pool (dipertahankan dalam status DELETED selama 30 hari), dan Akun Layanan khusus:
# 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. Selamat
Selamat! Anda telah menyelesaikan codelab Mengamankan Pipeline CI/CD dengan CodeMender.
Anda telah berhasil mendesain, membangun, dan mengotomatiskan pipeline DevSecOps zero-trust tingkat produksi menggunakan Workload Identity Federation Google Cloud, CodeMender, dan GitHub Actions.
Yang telah Anda bahas
Autentikasi Tanpa Kunci Zero-Trust: Menghilangkan kunci JSON akun layanan yang berisiko dan berumur panjang dengan mengikat token OIDC GitHub sementara ke Google Cloud IAM melalui Workload Identity Federation (WIF).
Pemindaian AST Diferensial PR dan Peredam Bising Lama: Pemindaian berkelanjutan yang dicakupkan ke file yang diubah dan dependensinya (--diff="origin/$BASE_REF"), mengisolasi utang teknis lama ([LEGACY / UNTOUCHED]) untuk menjaga feedback loop developer di bawah 15 detik.
Pelaporan Multi-Format dan Ringkasan Tugas Native: Menggabungkan OASIS SARIF v2.1.0 untuk GitHub Code Scanning terpusat dengan Markdown native (cm report -f md >> $GITHUB_STEP_SUMMARY) untuk visibilitas eksekutif instan langsung di halaman operasi alur kerja CI.
Perbaikan Otonom dengan Peninjauan Human-in-the-Loop: Beralih dari notifikasi pemberitahuan pasif ke pipeline perbaikan aktif yang secara otonom menyintesis patch kode yang diusulkan, memverifikasi terhadap rangkaian pengujian regresi, dan membuka Permintaan Pull peninjauan dengan artefak audit untuk persetujuan engineer.
Gerbang Keras Kualitas Otomatis: Menerapkan perlindungan cabang dan gerbang penggabungan yang ketat (--fail-on) untuk mencegah kerentanan berbahaya mencapai produksi.
Transfer Status Berbasis Artefak dan Isolasi Ruang Kerja: Mentransfer temuan dengan lancar antara tugas CI menggunakan cm report import, sekaligus menggunakan .git/info/exclude untuk mempertahankan histori Git yang asli dan mencegah kebocoran kredensial.
Perubahan pola pikir developer
Praktik DevSecOps Tradisional | Pipeline CI/CD Otonom CodeMender |
Pembuangan Pemberitahuan Pasif: Pemindai mencetak log terminal mentah atau daftar error statis, sehingga mengalihkan beban triase sepenuhnya kepada developer. | Active Co-developer: Menyintesis patch kode yang diverifikasi dan membuka Permintaan Pull yang siap digabungkan untuk disetujui engineer. |
Positif Palsu Tinggi: Heuristik AST statis menandai ribuan kerentanan teoretis tanpa bukti eksploitabilitas. | Verifikasi Eksploitasi 2 Tingkat: Pembuatan pengujian sandbox dinamis ( |
Penyimpanan Secret yang Berisiko: Kunci JSON akun layanan yang aktif dalam waktu lama yang disimpan di secret CI berisiko mengalami kebocoran yang tidak disengaja dan penyebaran kredensial. | WIF Zero-Trust: Autentikasi tanpa kunci melalui token OIDC sementara yang ditukar dengan Google Cloud STS sesuai permintaan. |
Pemindaian Ulang Monolitik: Setiap commit memicu audit repositori penuh, sehingga menunda alur kerja CI dan membuang-buang token yang mahal. | Pemilihan Rute AST Berbasis Peristiwa: Permintaan Pull menjalankan pemindaian AST diferensial selama 15 detik ( |
Histori Repositori yang Tercemar: Skrip eksploitasi sementara dan log serangan yang di-commit langsung ke cabang repositori. | Kebersihan Workspace Perusahaan: Bukti serangan disematkan dengan rapi dalam deskripsi PR dan artefak alur kerja, sehingga commit kode tetap murni. |
Langkah berikutnya
🚀 Lanjutkan perjalanan pembelajaran CodeMender:
Bagian 1: Mengamankan Aplikasi Anda dengan CodeMender — Kuasai penemuan kerentanan repositori otonom, verifikasi eksploitasi PoC, dan sintesis patch lokal.
Shift Left Secara Lokal & CI/CD Berbasis Cloud Serverless: Pelajari implementasi referensi panduan CI/CD resmi untuk Google Cloud Build (cloudbuild.yaml) dan Hook Pra-commit Git Lokal (cm find . --diff --staged).
📖 Pelajari dokumentasi dan referensi:
Panduan Resmi Integrasi CI/CD CodeMender Google Cloud
Dokumentasi Resmi CodeMender Google Cloud
Repositori Template Awal GitHub Actions CodeMender
Dokumentasi Workload Identity Federation Google Cloud
💡 Terapkan ke repositori Anda sendiri:
Lakukan fork pada alur kerja awal dan amankan repositori Python, Go, Java, Rust, dan Node.js organisasi Anda dengan CodeMender.