Belajar DevSecOps Engineer - Software Composition & Licensing

#Pendahuluan

Episode 12 membahas SBOM sebagai daftar isi dependency — untuk keamanan. Episode ini menutup sisi lain dari daftar itu: lisensi. Setiap package yang kalian install membawa kontrak hukum, dan sebagian kontrak itu punya gigi: lisensi copyleft kuat bisa mewajibkan kalian membuka source seluruh produk komersial jika cara distribusinya keliru.

Ini bukan masalah teoretis: produk SaaS sudah pernah harus rewrite komponen karena terlanjur memakai library AGPL; vendor hardware pernah recall firmware karena GPL compliance. Sebagai DevSecOps engineer, tugas kalian membuat keputusan lisensi ini otomatis dan dini — di PR saat dependency ditambahkan, bukan saat due diligence akuisisi.

#Spektrum Lisensi Open Source

Kategori	Contoh	Implikasi Praktis
Permissive	MIT, Apache-2.0, BSD	Aman hampir semua use case; jaga attribution
Weak copyleft	LGPL, MPL-2.0, EPL	Batasan hanya pada file/library itu
Strong copyleft	GPL-2.0/3.0	Turunan wajib open source bila didistribusikan
Network copyleft	AGPL-3.0	Memicu bahkan untuk penggunaan via network (SaaS)

Dua catatan penting:

AGPL vs SaaS adalah pertanyaan pertama yang harus kalian jawab sebelum pakai library AGPL — kalau produk kalian berupa layanan jaringan, AGPL berlaku sedangkan GPL biasanya tidak.
GPL dalam konteks container punya nuansa: menggabungkan binary GPL dengan kode proprietary dalam image yang didistribusikan bisa dianggap derivative work. Konsultasikan legal untuk kasus distribusi fisik/embedded.

#Mendeteksi Lisensi Otomatis

Tool yang sudah kalian kenal bisa langsung dipakai:

Syft: SBOM lengkap dengan lisensi

syft dir:. -o cyclonedx-json \
  | jq -r '.components[] | select(.licenses) | "\(.name) -> \(.licenses[0].license.id)"'

Untuk ekosistem tertentu, tool native lebih cepat:

npx license-checker --summary --onlyAllow "MIT;Apache-2.0;BSD-3-Clause;ISC"

Tantangan teknisnya: metadata lisensi kadang kosong/salah di manifest. Tool seperti scancode-toolkit melakukan deteksi mendalam dengan membaca file LICENSE asli — lebih akurat tapi lambat; pola umumnya: checker cepat di setiap PR, scancode mendalam berkala.

#License Policy Organisasi

Kebijakan yang bisa dieksekusi mesin, bukan dokumen 40 halaman:

license-policy.yaml

allowed:
  - MIT
  - Apache-2.0
  - BSD-2-Clause
  - BSD-3-Clause
  - ISC
review-required:
  - LGPL-2.1        # ok jika dinamically linked & replacable
  - MPL-2.0         # ok untuk file-level isolation
denied:
  - GPL-2.0         # risiko distribusi produk kita
  - GPL-3.0
  - AGPL-3.0        # produk kita = network service
  - Unlicensed      # tanpa lisensi = all rights reserved!
  - Unknown         # harus diklarifikasi manual
exceptions:
  - package: internal-fork-gpl-lib
    reason: "Fork internal, tidak didistribusikan keluar"
    expires: "2027-01-01"

Perhatikan dua kategori yang sering terlupakan: Unlicensed dan Unknown — kode tanpa lisensi secara default tidak boleh dipakai sama sekali. Dan exceptions tetap mengikuti pola series ini: berjustifikasi + expiry.

#Gate di CI

Policy di atas dieksekusi sebagai gate sederhana:

License gate pada perubahan lockfile

jobs:
  license-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Cek lisensi vs policy
        run: |
          npx license-checker --json > licenses.json
          node scripts/check-license-policy.js \
            licenses.json license-policy.yaml

Script membandingkan hasil scan terhadap YAML policy → fail dengan pesan jelas kalau ada lisensi denied. Developer yang menambahkan package GPL akan tahu dalam hitungan menit di PR, bukan enam bulan kemudian.

Tip

Jalankan license gate pada level lockfile, bukan sekadar direct dependencies — lisensi transitive yang paling sering lolos perhatian namun sama mengikatnya.

#Approval Workflow Dependency Baru

Lisensi adalah salah satu dimensi review dependency baru; gabungkan dengan risiko supply chain (episode 12) menjadi checklist approval:

Checklist adopsi dependency baru

[x] Lisensi sesuai policy?            -> gate otomatis
[x] Maintenance sehat?                -> commit aktif 6 bulan, maintainer > 1
[x] Popularitas cukup?                -> downloads/stars sebagai sinyal
[x] Tidak typo-squat?                 -> verifikasi nama resmi
[x] Dibutuhkan nyata?                 -> bisakah stdlib/internal lib?
[x] Alternatif berlisensi aman ada?   -> bandingkan dulu

Untuk organisasi besar: private registry proxy (Artifactory/Nexus) dengan allowlist membuat workflow ini natural — package baru harus di-request, lalu tersedia untuk semua tim setelah disetujui sekali.

#Attribution & Notice

Sisi positif compliance: lisensi permissive biasanya hanya minta attribution. Otomasikan pembuatan NOTICE file:

Generate notice otomatis tiap release

npx license-checker --production --csv > THIRD-PARTY-NOTICES.csv
# atau dari SBOM:
syft myapp:latest -o template --file NOTICES.tmpl

Generate di pipeline rilis → file selalu sinkron dengan dependency aktual → satu beban audit hilang permanen.

#Penutup

Inti yang harus dibawa pulang:

Dependency = kontrak hukum; copyleft kuat (GPL/AGPL) bisa memaksa open-source produk, AGPL mengenai SaaS.
Deteksi otomatis: license-checker/pip-licenses cepat di PR; scancode mendalam berkala; SBOM juga membawa data lisensi.
Policy organisasi = YAML executable: allowed/review/denied + exception ber-expiry; Unlicensed/Unknown otomatis ditolak.
Approval dependency baru menggabungkan lisensi + health + supply chain risk; attribution di-generate pipeline.

Di episode 24 selanjutnya kita membahas Security Observability — menyatukan semua telemetry security yang tersebar di episode-episode sebelumnya: pipeline detection-as-code dengan Sigma rules, integrasi SIEM, dan metrik-metrik yang menunjukkan apakah deteksi kalian benar-benar mencakup ancaman yang relevan. Sampai jumpa!