Belajar Application Security Engineer - Security in CI/CD

#Pendahuluan

Setelah di episode 10 kita mengeraskan container, episode ini mengamankan tempat semuanya berjalan otomatis: pipeline CI/CD. Mengapa pipeline jadi target? Karena ia adalah titik di mana kode semua developer bertemu, secret tersimpan, dan artifact production lahir — satu kompromi pipeline memberi penyerang akses ke seluruh sistem sekaligus. Insiden seperti SolarWinds dan serangan tj-actions/changed-files (2025) membuktikan supply chain via CI bukan teori.

Tiga blok materi: menjaga secret tidak bocor (scanning), menghardaskan runner & workflow itu sendiri, lalu menanam security gates yang proporsional — melengkapi SAST/SCA/image scan dari episode sebelumnya menjadi pipeline utuh.

#Secret Scanning: Tangkap Sebelum Ter-push

Secret di repository adalah temuan nomor satu yang paling mudah dicegah. Pola insidennya selalu sama: developer debug pakai API key asli → commit → push → key terekspos permanen (git history). Solusinya dua lapis:

Lapis 1 — pre-commit hook (mencegah commit keluar dari mesin):

cat > .pre-commit-config.yaml << 'EOF'
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.3
    hooks:
      - id: gitleaks
EOF
pre-commit install
gitleaks git --pre-commit --redact -v

Lapis 2 — scan di CI (menjaga bila lapis 1 dilewati --no-verify):

gitleaks detect --source . --report-path leaks.json --redact -v

Dan aturan respons wajib yang harus tertulis di proses tim: secret yang pernah ter-push dianggap kompromi, apa pun lamanya. Rotasi dulu, bersihkan history kemudian (git filter-repo) — urutannya tidak boleh dibalik, karena history cleanup tidak memberitahu siapa pun yang sudah clone.

#Pipeline Hardening: GitHub Actions

Workflow YAML modern adalah kode eksekusi dengan izin cloud — perlakukan seperti kode sensitif.

#Pin Versi Actions

uses: actions/checkout@v4 merujuk tag mutable — kalau repo upstream dikompromi, kalian ikut terinfeksi saat rebuild:

# Dapatkan SHA terbaru untuk tag v4
git ls-remote https://github.com/actions/checkout.git refs/tags/v4

steps:
  # rentan terhadap tag hijack
  - uses: actions/checkout@v4
 
  # aman: immutable reference
  - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # v4.1.7

#Least Privilege Token Workflow

Default GITHUB_TOKEN sering lebih luas dari kebutuhan. Kunci di level workflow, longgarkan hanya jika job butuh:

permissions:
  contents: read
 
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write   # hanya job ini yang push image
    steps:
      - run: echo "build & push"

#OIDC Pengganti Long-Lived Credentials

Kesalahan klasik organisasi: menyimpan AWS access key permanen di GitHub Secrets untuk deploy. Key itu bisa bocor lewat log, fork PR abuse, atau compromised runner. Alternatif modern: OIDC federation — workflow bertukar token ephemeral langsung dengan cloud provider:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # minta OIDC token
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha> # pin SHA
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: ap-southeast-1

Tidak ada secret yang tersimpan; trust relationship di IAM role membatasi repo + branch mana yang boleh assume. Masa hidup token 1 jam. Ini pola yang harus jadi default untuk semua deployment baru.

#Security Gates: Otomasi Tanpa Menjadi Bottleneck

Sekarang rakit semua scanner dari episode 7–10 menjadi gate yang masuk akal:

Prinsip desain gate yang saya pegang:

1. Cepat dulu: secret scan + lint security dalam < 1 menit, jalankan paralel di awal.
2. Baseline, bukan zero-tolerance: bandingkan temuan baru terhadap branch main — hutang lama masuk backlog, regresi baru yang diblokir.
3. Bypass yang terdokumentasi: ada mekanisme skip dengan justifikasi + expiry (label security-waiver), karena gate tanpa pressure valve akan dimatikan total oleh manajemen saat deadline.
4. Hasil inline: komentar PR dengan ringkasan + link detail, bukan log mentah.

#Common Pitfalls

• Secrets di environment variables workflow log: echo $SECRET di step debug membocorkannya ke log publik repo open source. Gunakan masking bawaan + hindari print env.
• Runner self-hosted untuk repo publik: PR dari fork mengeksekusi kode di mesin kalian — isolasi container saja belum cukup; pisahkan runner atau larang sepenuhnya.
• Rotasi secret dilupakan: secret scanning mendeteksi bocor, tapi tanpa rotasi berkala otomatis (misal 90 hari), key lama dari onboarding engineer tahun lalu masih hidup.
• Gate all-or-nothing: memblokir semua severity membuat tim mencari celah politis; proporsi ketatnya pada critical-with-fix saja sudah menyelamatkan mayoritas risiko.

#Penutup

Inti yang harus dibawa pulang:

• Secret scanning dua lapis (hook + CI) dan aturan rotasi-immediately untuk yang pernah ter-push.
• Pipeline adalah kode sensitif: pin action ke SHA, minimal permission, OIDC alih-alih long-lived keys.
• Security gates efektif itu proporsional: baseline-based, cepat, dengan bypass terdokumentasi.
• Pipeline CI/CD adalah crown jewels supply chain kalian — auditnya setidaknya seketat kode produksi.

Di episode 12 kita masuk sisi manusia dari tooling: Security Code Review — metodologi review manual yang menemukan apa yang scanner lewatkan, cara memprioritaskan file mana yang layak dibaca mendalam, dan teknik komunikasi agar rekomendasi kalian benar-benar dieksekusi developer. Sampai jumpa di episode 12!