Belajar Application Security Engineer - Dependencies & SCA

#Pendahuluan

Setelah di episode 8 kita menguji aplikasi secara dinamis, episode ini menyasar sumber risiko yang bukan tulisan tim kalian: dependency pihak ketiga. Angka yang sering mengagetkan orang baru: pada aplikasi web modern, 70–90% baris kode production berasal dari open source. Kalian tidak men-audit semuanya secara manual — mustahil — tapi kalian wajib tahu apa saja yang masuk, risikonya apa, dan seberapa cepat bisa kalian ganti bila salah satunya meledak. Log4Shell (2021) membuktikan satu library logging bisa menjadi insiden global.

Topiknya kita susun berlapis: anatomi dependency tree → SCA & vulnerability database → SBOM → licensing → praktik pipeline.

#Anatomi Risiko Dependency

npm install express tidak hanya memasang express — ia memasang seluruh pohon transitive: rata-rata paket npm populer menarik puluhan sampai ratusan sub-dependency. Tiga properti risikonya:

1. Jumlah: permukaan audit kalian = seluruh pohon, bukan manifest langsung.
2. Transitivitas: kerentanan sering ada di level dalam yang bahkan tidak pernah kalian dengar namanya.
3. Kecepatan publikasi CVE: dependency yang aman hari ini bisa jadi headline minggu depan — status "sudah di-scan saat rilis" bukan perlindungan.

Konsekuensi strategisnya: SCA bukan kegiatan sekali-jalan saat rilis; ia harus berjalan terus-menerus terhadap codebase yang sudah ada, karena ancamannya datang belakangan.

#Software Composition Analysis

SCA tool bekerja dengan pola umum: parse lockfile → identifikasi komponen + versi → cocokkan dengan database advisory (OSV, GitHub Advisory, NVD) → laporkan yang cocok. Pilihan utamanya:

Praktik cepat dengan dua lapis:

npm audit --audit-level=high
npm audit fix --dry-run   # lihat dulu apa yang akan berubah
 
# Lapis 2: scanner lintas ekosistem termasuk lockfile lain
trivy fs --scanners vuln,misconfig --severity HIGH,CRITICAL .

Perhatikan output severity dan — lebih penting — apakah CVE tersebut punya fix version. Temuan tanpa fix perlu mitigasi beda (pin, fork, replace, atau accept dengan justifikasi).

#SBOM: Daftar Bahan Software

SBOM (Software Bill of Materials) adalah manifest formal seluruh komponen software — analog daftar bahan di kemasan makanan. Dua standar dominan:

• CycloneDX — fokus security, kaya metadata kerentanan; pilihan umum untuk toolchain AppSec.
• SPDX — fokus legal/licensing; dipakai luas di dunia kernel/embedded.

Kenapa SBOM penting bagi AppSec engineer? Bayangkan CVE baru di library X dirilis pagi ini. Pertanyaan manajemen: "apakah kita terdampak?" Tanpa SBOM, jawabannya butuh grepping belasan repo. Dengan SBOM:

npx @cyclonedx/cyclonedx-npm --output-file sbom.json
jq -r '.components[].name' sbom.json | grep -i '^lodash$'

Jawaban dalam hitungan detik, untuk setiap repo, tanpa build ulang. Regulasi (EU CRA, US EO 14028) mendorong SBOM dari "nice to have" menuju syarat pasar — organisasi kalian akan minta lebih cepat dari perkiraan.

#Licensing Compliance

Bagian SCA yang sering dilupakan: setiap paket punya lisensi, dan beberapa lisensi bermasalah untuk penggunaan komersial:

Automasi minimal: generate SBOM SPDX, filter licenseConcluded, alarm untuk lisensi di denylist organisasi. Ini pekerjaan sekali-setup yang melindungi dari risiko hukum mahal.

#Praktik: Pipeline SCA yang Sehat

Susunan yang saya rekomendasikan untuk organisasi kecil-menengah:

name: SCA
on:
  pull_request:
  schedule:
    - cron: "0 3 * * *"   # scan ulang harian — CVE baru tanpa push baru
jobs:
  deps:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm ci
      - name: Fail on new critical vulns
        run: trivy fs --exit-code 1 --severity CRITICAL .
      - name: Generate SBOM artifact
        run: npx @cyclonedx/cyclonedx-npm --output-file sbom.json
      - uses: actions/upload-artifact@v4
        with: { name: sbom, path: sbom.json }

Dua keputusan desain di workflow ini yang layak digarisbawahi:

1. PR gate hanya CRITICAL — HIGH dan below masuk dashboard backlog. Gate agresif = dimatikan developer.
2. Scheduled scan harian — menutup celah "CVE terbit setelah merge", yang tidak tertangkap oleh trigger PR mana pun.

Tambahkan Dependabot config minimal di .github/dependabot.yml agar update minor otomatis jadi PR mingguan — kombinasi gate keras (critical) + otomatisasi lembut (update rutin) menjaga hutang dependency tetap rendah tanpa drama.

#Common Pitfalls

• Severity sebagai satu-satunya prioritas: CVSS 9.8 pada library yang kalian pakai hanya di script dev lokal ≠ CVSS 7.5 pada library di request path production. Gunakan konteks reachability (apakah kode benar-benar memanggil fungsi rentan?).
• Mengabaikan devDependencies: build CI mengeksekusinya dengan secret repo — supply chain attack modern menyasar sana.
• Lockfile di-commit tapi jarang di-update: semakin besar gap antara lockfile dan registry terbaru, semakin mahal upgrade darurat.
• Tidak punya proses exception: kadang fix belum tersedia; tanpa proses accept-with-expiry resmi, orang akan diam-diam mematikan scanner.

#Penutup

Inti yang harus dibawa pulang:

• Mayoritas kode produksi adalah milik orang lain — kelola pohon transitif dengan scanner kontinu, bukan audit manual.
• Lapis praktis: npm audit native + Trivy lintas ekosistem + Dependabot/Renovate untuk auto-update.
• SBOM (CycloneDX/SPDX) menjawab "apakah kita terdampak CVE X" dalam detik — dan mulai disyaratkan regulasi.
• Licensing adalah bagian SCA: waspadai GPL/AGPL/SSPL untuk produk proprietary.
• Gate proporsional: fail hanya critical baru di PR; sisanya dashboard + scan harian terjadwal.

Di episode 10 kita turun satu lapis lagi ke unit deployment: Container & Deployment Security — Dockerfile hardening, pemilihan base image, image scanning, dan guard runtime yang membuat container sulit dieksploitasi. Sampai jumpa di episode 10!