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.

Share
DevSecOps 2026: SBOM, SLSA, dan Software Supply Chain Security di Era AI

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

MingguFokusDeliverable
1–2Inventarisasi pipeline & artifact registryMatrix build tools, registries, signing keys
3–4SBOM generation di semua repo100% build produce signed SBOM
5–6SLSA Level 1 (provenance generation)Provenance terpublish ke registry
7–8SLSA Level 2 (hardened builder)Ephemeral runners, OIDC keyless signing
9–10Policy admission Kyverno/OPACluster reject image non-compliant
11–12Observability & alertingDashboard 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.