Kewajiban Pelaporan Cyber Resilience Act: Runbook DevOps

Pada 11 September 2026, aturan yang oleh banyak tim engineering ditaruh di folder nanti tiba-tiba berubah menjadi urusan pager. Pasal 14 Cyber Resilience Act mulai berlaku hari itu, dan bersamanya sebuah jam yang mulai berdetak saat manufacturer menyadari bahwa salah satu produknya sedang dieksploitasi. Bagian lain dari Regulasi belum harus siap. Yang satu ini harus.

Saya membaca halaman pelaporan Komisi Eropa, FAQ dan factsheet ENISA untuk Single Reporting Platform, panduan komunitas OpenSSF, dan teks Regulation (EU) 2024/2847 itu sendiri, lalu menyusunnya menjadi runbook. Tanggal riset: 17 Oktober 2026. Saya belum pernah mengirim laporan sendiri, jadi semua isi di sini adalah hasil membaca sumber tersebut, bukan pengalaman lapangan, dan apa pun yang tidak bisa saya telusuri ke sumber itu sengaja dibuang.

Tulisan ini panduan engineering, bukan nasihat hukum. Apakah produk Anda masuk cakupan, siapa yang dihitung sebagai manufacturer, dan kapan Anda dianggap mengetahui adalah pertanyaan hukum untuk penasihat hukum Anda. Teks resmi Regulasi adalah yang terbit di EUR-Lex, dan halaman ENISA mungkin sudah berubah sejak 17 Oktober 2026.

Dua pemicu, satu tanggal, dan kewajiban yang menjangkau produk yang sudah terjual

Pasal 14 menciptakan dua kewajiban pelaporan. Pertama, actively exploited vulnerability, yaitu kerentanan yang punya bukti andal bahwa pelaku jahat telah mengeksploitasinya tanpa izin pemilik sistem (ENISA FAQ 7). Kedua, severe incident yang berdampak pada keamanan produk. Pasal 14(5) menyebut insiden itu severe bila ia memengaruhi, atau mampu memengaruhi, kemampuan produk melindungi ketersediaan, keaslian, integritas atau kerahasiaan data atau fungsi yang sensitif atau penting, atau bila ia telah menyebabkan, atau mampu menyebabkan, malicious code masuk atau berjalan di produk atau di sistem jaringan dan informasi milik pengguna.

Tanggalnya ada di Pasal 71(2): Regulasi berlaku mulai 11 Desember 2027, tetapi Pasal 14 berlaku mulai 11 September 2026. Yang sering mengejutkan tim adalah Pasal 69(3). Pasal 69(2) menyatakan produk yang sudah beredar sebelum 11 Desember 2027 baru tunduk pada Regulasi setelah ada substantial modification, tetapi Pasal 69(3) mengecualikan Pasal 14, sehingga kewajiban pelaporan berlaku untuk semua produk dalam cakupan yang sudah ada di pasar. Installed base Anda tercakup walau tidak pernah perlu CE marking. Di sisi lain, ENISA FAQ 13 menyatakan manufacturer yang sudah mengetahui adanya eksploitasi sebelum 11 September 2026 tidak wajib melaporkannya secara retrospektif.

Jamnya: 24 jam, 72 jam, lalu dua laporan akhir yang berbeda

Kedua jenis kejadian berbagi dua tahap pertama dan berpisah di akhir. Tabel ini meringkas Pasal 14(2) dan 14(4), dan halaman pelaporan Komisi serta factsheet ENISA menyebut empat tenggat yang sama. Tiap tahap berbunyi unless the relevant information has already been provided, jadi laporan berikutnya tidak perlu mengulang apa yang sudah dimuat laporan sebelumnya.

Perhatikan asimetri di tahap terakhir. Jam kerentanan dipicu oleh adanya fix, jadi bisa mulai berhari-hari setelah dua tahap pertama. Jam insiden dipicu oleh notifikasi Anda sendiri sebelumnya. Tulis keduanya di runbook sebagai dua timer terpisah, karena satu timer bernama deadline pelaporan pasti salah untuk salah satunya.

Saat Anda mengetahui adalah garis start, jadi catat seperti timestamp

Setiap tenggat dihitung sejak manufacturer mengetahui. Artinya momen Anda mencatat awareness adalah baris terpenting di incident log, dan harus berupa timestamp UTC yang ditulis orang yang berwenang menulisnya, bukan direkonstruksi dari riwayat chat keesokan harinya. Apakah suatu alert sudah menjadi bukti andal adanya eksploitasi adalah penilaian yang harus disepakati penasihat hukum dan security lead sebelum insiden, bukan saat insiden.

Skrip di bawah mengubah satu timestamp itu menjadi empat tenggat. Ia memakai GNU date, jadi di macOS pasang coreutils dan ganti dengan gdate. Baris laporan akhir sengaja kosong sampai Anda tahu waktu fix atau waktu notifikasi, karena itulah pemicu yang sebenarnya.

#!/usr/bin/env bash
# cra-clocks.sh: turn ONE awareness timestamp into the Article 14 deadlines.
# GNU date. On macOS: brew install coreutils, then replace date with gdate.
#
#   ./cra-clocks.sh 2026-10-19T08:30:00Z
#   FIX_AT=2026-10-21T16:00:00Z ./cra-clocks.sh 2026-10-19T08:30:00Z
#   NOTIFIED_AT=2026-10-21T07:50:00Z ./cra-clocks.sh 2026-10-19T08:30:00Z
set -euo pipefail

AWARE="${1:?usage: cra-clocks.sh <awareness-timestamp-UTC>}"
t0=$(date -u -d "$AWARE" +%s)
fmt() { date -u -d "@$1" +%Y-%m-%dT%H:%M:%SZ; }

echo "aware               $(fmt "$t0")"
echo "early warning by    $(fmt $((t0 + 24 * 3600)))   # Art. 14(2)(a), 14(4)(a)"
echo "notification by     $(fmt $((t0 + 72 * 3600)))   # Art. 14(2)(b), 14(4)(b)"

# Vulnerability: the final report is keyed to the FIX, not to awareness.
if [ -n "${FIX_AT:-}" ]; then
  echo "vuln final report   $(date -u -d "$FIX_AT + 14 days" +%Y-%m-%dT%H:%M:%SZ)   # Art. 14(2)(c): no later than"
else
  echo "vuln final report   (set FIX_AT when a corrective or mitigating measure is available)"
fi

# Incident: the final report is keyed to YOUR OWN notification submission.
if [ -n "${NOTIFIED_AT:-}" ]; then
  echo "incident final      $(date -u -d "$NOTIFIED_AT + 1 month" +%Y-%m-%dT%H:%M:%SZ)   # Art. 14(4)(c)"
else
  echo "incident final      (set NOTIFIED_AT when the 72-hour notification is submitted)"
fi

Ada satu keanehan platform yang perlu diketahui sebelum Anda memercayai hitung mundurnya. ENISA FAQ 26 menyatakan saat ini counter 72 jam dihitung dari 48 jam setelah early warning, sehingga laporan bisa tampak terlambat lebih awal, dan rilis mendatang akan memakai tanggal awareness. FAQ itu juga menyebut tidak ada counter laporan akhir untuk kerentanan. Simpan jam Anda sendiri; anggap jam platform sebagai petunjuk.

Mengirimnya: satu platform, CSIRT yang tepat, dan login yang perlu dilatih

Pasal 14(7) mengarahkan notifikasi lewat single reporting platform yang dibentuk Pasal 16, ke electronic end-point CSIRT yang ditunjuk sebagai koordinator di Member State tempat main establishment Anda, dan sekaligus dapat diakses ENISA. Halaman Komisi dan factsheet ENISA melengkapi alurnya: CSIRT penerima meneruskan notifikasi tanpa penundaan ke CSIRT di Member State tempat produk tersedia, dan hanya boleh menunda dalam keadaan luar biasa menurut Pasal 16(2), yang dirinci Commission Delegated Regulation (EU) 2026/881.

Memilih CSIRT bukan formalitas. ENISA FAQ 18 memperingatkan bahwa salah memilih koordinator dapat membatalkan notifikasi dan memaksa Anda mengirim ulang, jadi putuskan sebelum ada insiden. Pasal 14(7) memberi urutannya:

1. Main establishment: Member State tempat keputusan terkait keamanan siber produk Anda terutama diambil.
2. Bila itu tidak dapat ditentukan: Member State tempat Anda punya establishment dengan jumlah karyawan terbanyak di Uni.
3. Bila tidak punya establishment di Uni, Member State tempat authorised representative yang mewakili produk Anda terbanyak, lalu importer yang memasarkan terbanyak, lalu distributor yang menyediakan terbanyak.
4. Terakhir dalam urutan itu: Member State tempat pengguna produk Anda paling banyak berada.

Akses berjalan lewat EU Login dengan multi-factor authentication, dan akun bersifat personal (FAQ 9). Satu manufacturer punya satu Primary Assigned Representative dan hingga 20 Secondary, Primary harus diverifikasi CSIRT sebelum mengundang yang lain, dan draft tersimpan di akun masing-masing sehingga tidak terlihat rekan kerja. Verifikasi berjalan paralel dengan pelaporan, dan hingga 20 notifikasi dapat dikirim sebelum verifikasi menjadi wajib. Tidak ada API saat peluncuran, antarmukanya hanya berbahasa Inggris, dan bila platform tidak tersedia Anda boleh menghubungi CSIRT koordinator langsung tetapi tetap harus mengirim lewat platform setelah pulih (FAQ 15, 24, 25).

Dependensi open-source: kewajiban Anda, bukan mereka

Pasal 13(5) meminta manufacturer menerapkan due diligence saat mengintegrasikan komponen pihak ketiga, termasuk komponen free dan open-source yang tidak diedarkan dalam kegiatan komersial. Pasal 13(6) lebih jauh: saat menemukan kerentanan pada komponen, termasuk komponen open-source, manufacturer harus melaporkannya kepada pihak yang membuat atau memelihara komponen itu, menanganinya menurut Part II Annex I, dan bila ia mengembangkan modifikasi, membagikan kode atau dokumentasi terkait kepada mereka, bila perlu dalam format machine-readable.

Panduan OpenSSF, terakhir diperbarui 12 Oktober 2026, tegas soal siapa yang menanggung. Kewajiban 11 September berlaku untuk manufacturer, bukan untuk maintainer hanya karena mereka memelihara proyek open-source. Manufacturer yang menemukan flaw yang dieksploitasi dan bersumber dari komponen upstream bertanggung jawab atas laporannya, tetapi boleh menghubungi proyek, maintainer atau steward-nya. Open-source steward punya kewajiban pelaporan menurut Pasal 24(3) mulai 11 Desember 2027, dan OpenSSF mencatat bahwa interaksi Pasal 13(6) bukan bagian dari tonggak September.

Konsekuensi praktisnya adalah masalah inventaris. Saat sebuah komponen dilaporkan dieksploitasi, Anda perlu tahu dalam hitungan jam produk mana yang membawanya, dan di versi berapa. Query di bawah mengasumsikan Anda menyimpan satu SBOM CycloneDX JSON per rilis; nama field-nya milik CycloneDX, dan nama package-nya hanya placeholder.

# Which releases ship a given component, and at which version?
# Assumes one CycloneDX JSON SBOM per release under sboms/. The package name is a placeholder.
# Article 13(6): once you know, you must also report the flaw UPSTREAM to the maintainer.
COMPONENT="example-lib"

for f in sboms/*.cdx.json; do
  jq -r --arg c "$COMPONENT" --arg f "$f" '
    .components[]?
    | select(.name == $c)
    | [$f, .name, .version, (.purl // "no-purl")] | @tsv' "$f"
done | sort

Di mana ini bisa salah, dan berapa harganya

Kegagalannya kebanyakan biasa saja. Salah memilih CSIRT koordinator dapat membatalkan notifikasi. Tidak ada API, jadi notifikasi diketik atau di-paste ke form web di jam paling tidak enak. Draft bersifat privat untuk satu akun, jadi engineer yang memulai laporan satu-satunya yang bisa melihatnya sampai dikirim. Counter 72 jam platform saat ini tampak terlambat lebih awal. Dan bila platform down, fallback-nya adalah menelepon CSIRT lalu mengirim ulang, yang hanya membantu bila seseorang sudah tahu CSIRT mana itu.

Dua kewajiban berdampingan dengan laporan dan mudah terlupa. Pasal 14(8) mewajibkan manufacturer memberi tahu pengguna yang terdampak, dan bila perlu semua pengguna, tentang actively exploited vulnerability atau severe incident, beserta mitigasinya, bila perlu dalam format terstruktur yang machine-readable. Bila gagal melakukannya tepat waktu, CSIRT koordinator dapat memberi tahu pengguna sendiri. Terpisah dari itu, ENISA FAQ 30 menyatakan pihak yang bukan manufacturer sebaiknya menghubungi CSIRT nasional langsung, dan kiriman mereka ke platform dapat ditandai tidak valid.

Trade-off yang tidak bisa saya selesaikan untuk Anda adalah cakupan. Produk mana milik Anda yang termasuk produk dengan elemen digital, dan tim mana yang dihitung sebagai manufacturer, bergantung pada definisi yang tidak saya coba tafsirkan di sini. Bila ragu, biaya salah tebak itu asimetris: terlambat melapor adalah pelanggaran, sedangkan melapor lebih awal untuk kasus perbatasan paling buruk hanya berupa percakapan dengan CSIRT.

Record runbook yang cocok dengan isian platform

ENISA FAQ 11 mendaftar field yang mungkin diminta platform: untuk kerentanan, CVE ID, EUVD ID, rincian eksploitasi, severity, pelaku jahat dan sifat exploit; untuk insiden, sifat insiden, langkah mitigasi, severity dan threat atau root cause yang mungkin. Field wajib berbeda per tahap, dan SRP Glossary menandai tiap field sebagai required, optional, conditionally required atau carried forward. Record di bawah menampung field itu dan isi Pasal 14 dalam satu file per kejadian, sehingga responder jam pertama mengisinya sekali dan tiap tahap berikutnya tinggal menyalin.

# incidents/2026-10-19-example-product.cra.yaml  (one file per event)
event_type: actively_exploited_vulnerability   # or: severe_incident
product: example-product 4.2.1
coordinating_csirt: <member state>             # Art. 14(7); decided BEFORE the incident
aware_at_utc: 2026-10-19T08:30:00Z             # written by the person authorised to declare awareness
member_states_available: [DE, FR, NL]          # asked for in the 24h early warning

early_warning:                                 # due: aware_at + 24h
  submitted_at_utc: null
  suspected_unlawful_or_malicious: null        # incidents: include at least this

notification:                                  # due: aware_at + 72h
  submitted_at_utc: null
  cve_id: null                                 # FAQ 11 lists CVE ID and EUVD ID
  euvd_id: null
  nature_of_exploit_and_vulnerability: ""
  measures_taken: []
  measures_users_can_take: []
  sensitivity_of_information: ""               # Art. 14(2)(b): how sensitive you consider it

final_report:
  fix_available_at_utc: null                   # vulnerability: due 14 days after this
  notification_submitted_at_utc: null          # incident: due one month after this
  description_severity_impact: ""
  malicious_actor: ""                          # where available
  security_update_details: ""                  # vulnerability
  threat_type_or_root_cause: ""                # incident
  mitigation_applied_and_ongoing: []           # incident

user_notice:                                   # Art. 14(8), separate from the reports
  sent_at_utc: null
  machine_readable_advisory: ""

upstream:                                      # Art. 13(6), when a third-party component is involved
  component: null
  maintainer_notified_at_utc: null
  fix_shared_with_maintainer: null

Saya akan meng-commit template ini ke repositori insiden dan menyimpan satu salinan terisi per kejadian. Intinya bukan formatnya; intinya tidak ada yang menyusun submission regulasi dari ingatan.

Yang dikerjakan hari Senin

Lima langkah, dalam urutan yang akan saya kerjakan. Tidak satu pun butuh keputusan dari Komisi.

1. Tentukan entitas manufacturer untuk tiap lini produk dan catat CSIRT Member State mana yang menjadi koordinator menurut Pasal 14(7), beserta alasannya.
2. Tetapkan siapa yang berwenang menyatakan awareness, dan jadikan pencatatan timestamp UTC itu langkah pertama template insiden Anda.
3. Daftarkan satu Primary Assigned Representative dan minimal satu Secondary di EU Login dengan MFA, lalu lakukan satu dry run login di perangkat on-call.
4. Masukkan query SBOM ke runbook on-call dan pastikan ia mengembalikan hasil untuk komponen open-source yang paling banyak Anda pakai.
5. Tambahkan dua timer laporan akhir secara terpisah ke template: 14 hari setelah fix, dan satu bulan setelah notifikasi insiden.

Maintainer open-source punya hari Senin yang lebih ringan: simpan SECURITY.md dengan jalur disclosure privat dan kontak yang terkini, lalu cari tahu steward atau foundation mana yang akan berkoordinasi dengan manufacturer. Itu saran OpenSSF, bukan kewajiban hukum untuk Anda.

Aturan yang dibawa pulang: jam Pasal 14 mulai saat Anda mengetahui, bukan saat triage selesai, dan itu kewajiban manufacturer walau flaw-nya ada di kode open-source milik orang lain. Putuskan entitas, CSIRT, orang yang punya login dan timestamp awareness sebelum insiden pertama, karena setelahnya Anda hanya punya 24 jam.