DevSecOps 2026: SBOM, SLSA, dan Software Supply Chain Security di Era AI
Tahun 2026 menandai titik balik DevSecOps di Indonesia. SBOM dan SLSA tidak lagi opsional — jadi kebutuhan wajib untuk enterprise yang serius soal integritas software supply chain. Panduan implementasi bertahap dari visibility ke enforcement.
Tahun 2026 bukan sekadar tahun baru bagi praktisi DevOps Indonesia — ini tahun DevSecOps keluar dari buzzword jadi baseline wajib. Peraturan Baru BSSN, kebutuhan compliance internasional, dan maraknya serangan supply chain (Log4j, xz-utils, malicious npm packages) memaksa organisasi beralih dari “scan nanti” ke “verify sebelum deploy”. Dua standar jadi tulang punggung transformasi ini: SBOM (Software Bill of Materials) untuk visibilitas, dan SLSA (Supply-chain Levels for Software Artifacts) untuk integritas build.
Mengapa 2026 Jadi Titik Balik
Tiga driver konvergen mendorong adopsi massal:
- Regulasi — Perpres 82/2022 turunan BSSN mewajibkan SBOM untuk sistem kritis nasional. Deadline compliance 2026.
- Standar Global — SLSA Level 3 jadi syarat procurement vendor cloud besar (AWS, GCP, Azure) untuk workload enterprise.
- Realita Ancaman — Laporan Sonatype 2026 catat peningkatan 742% serangan supply chain YoY. Vektor utama: dependency confusion, CI/CD poisoning, dan malicious maintainer.
Ponytail: Jangan targetkan SLSA Level 3 sekaligus. Mulai Level 1 (build scripted), naik Level 2 (tamper-resistant), baru Level 3 (hardened). Lompat level = gagal adopsi.
Fase 1: Visibility — SBOM Everywhere
SBOM bukan daftar dependensi statis. Harus generated at build time, signed, dan stored di artifact registry.
# Syft generate SBOM SPDX-JSON di CI
syft packages dir:. -o spdx-json=sbom.spdx.json
# Cosign sign SBOM
cosign sign-blob --yes sbom.spdx.json \
--output-signature sbom.spdx.json.sig \
--output-certificate sbom.spdx.json.pem
# Upload ke OCI registry (Harbor/JFrog/Artifactory)
oras push registry.example.com/sbom/myapp:v1.2.3 \
sbom.spdx.json:application/spdx+json \
sbom.spdx.json.sig:application/octet-stream \
sbom.spdx.json.pem:application/octet-stream
Integrasikan ke pipeline: setiap build produce SBOM. Tanpa SBOM, artifact unreleasable.
Fase 2: Integrity — SLSA Level 1–2
SLSA Level 1: Build scripted, reproducible, output provenance. Level 2: Build service tamper-resistant (ephemeral, isolated, hermetic).
# .github/workflows/slsa-build.yml
name: SLSA Build
on:
push:
tags: ['v*']
jobs:
build:
uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
with:
base64-subjects: "${{ hashFiles('dist/*') }}"
provenance-name: provenance.intoto.jsonl
Kunci Level 2: GitHub Actions/OIDC tokens untuk keyless signing, reproducible builds (fixed timestamps, deterministic compilers), dan provenance yang terverifikasi slsa-verifier.
Fase 3: Policy Enforcement — Admission Control
SBOM + provenance tanpa enforcement = paperwork. Deploy-time policy via Kyverno atau OPA Gatekeeper di cluster Kubernetes.
# Kyverno ClusterPolicy: require SLSA provenance & SBOM
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-slsa-sbom
spec:
validationFailureAction: Enforce
rules:
- name: check-provenance
match:
any:
- resources:
kinds: ["Deployment", "StatefulSet", "DaemonSet"]
verifyImages:
- image: "*"
attestations:
- type: slsaprovenance
conditions:
- all:
- key: "$.predicate.buildType"
operator: Equals
value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/[email protected]"
- key: "$.predicate.builder.id"
operator: Matches
value: "https://github.com/.*/.github/workflows/.*\.yml@refs/tags/v.*"
- name: check-sbom
match:
any:
- resources:
kinds: ["Deployment", "StatefulSet", "DaemonSet"]
verifyImages:
- image: "*"
attestations:
- type: spdx
Policy ini blokir deployment image tanpa provenance SLSA valid dan SBOM SPDX terverifikasi. Shift-left jadi shift-down ke runtime admission.
Roadmap 12 Minggu untuk Enterprise Indonesia
| Minggu | Fokus | Deliverable |
|---|---|---|
| 1–2 | Inventarisasi pipeline & artifact registry | Matrix build tools, registries, signing keys |
| 3–4 | SBOM generation di semua repo | 100% build produce signed SBOM |
| 5–6 | SLSA Level 1 (provenance generation) | Provenance terpublish ke registry |
| 7–8 | SLSA Level 2 (hardened builder) | Ephemeral runners, OIDC keyless signing |
| 9–10 | Policy admission Kyverno/OPA | Cluster reject image non-compliant |
| 11–12 | Observability & alerting | Dashboard SBOM drift, provenance verification rate |
Tantangan Khusus Indonesia
- Hybrid cloud — Banyak enterprise pakai on-prem + multi-cloud. SBOM/SLSA harus portable across Harbor, ECR, GCR, ACR.
- Vendor lock-in — Hindari tool proprietary. Pilih open standard (in-toto, SPDX, Cosign, Rekor).
- Talent gap — Investasi upskilling tim platform engineering. Certifikasi SLSA Practitioner & SBOM Author jadi nilai plus hiring 2026.
Kesimpulan: DevSecOps 2026 bukan soal tambah tools — soal membedakan artifact yang trusted vs untrusted di setiap layer. SBOM kasih visibility, SLSA kasih integrity, admission policy kasih enforcement. Tiga pilar ini, kalau diimplementasikan bertahap, bikin software supply chain Indonesia verifiable by default. Mulai minggu ini: tambah SBOM generation di satu repo pilot. Ukur. Iterasi. Skala.