Semakan Kod Sumber RMiT: Apa Yang BNM Mahu, Cara Membuktikannya

Bayangkan seorang pembangun dalam pasukan pembayaran sebuah bank di Kuala Lumpur menggabungkan (merge) satu perubahan pada perkhidmatan pindahan DuitNow pada hari Khamis. Enam bulan kemudian, juruaudit teknologi memilih perubahan itu daripada log keluaran dan bertanya satu soalan: di mana semakan kod sumber untuknya?

Jika jawapan jujurnya ialah seseorang telah melihatnya tetapi tiada siapa menyimpan rekod, maka bagi tujuan audit, semakan itu dianggap tidak pernah berlaku.

RMiT (Risk Management in Technology) ialah dasar risiko teknologi Bank Negara Malaysia untuk institusi kewangan. Di bawah, setiap peraturan RMiT yang menyentuh kod diterjemahkan kepada bukti yang akan diminta oleh juruaudit. Itulah maksud semakan kod sumber RMiT dalam amalan.

Artikel ini ditulis untuk mereka yang menjawab soalan juruaudit di bank, syarikat insurans atau fintech, dan untuk vendor yang membina sistem mereka.

Nombor perenggan diambil daripada dokumen dasar RMiT BNM yang dikeluarkan pada 25 September 2026 (BNM/RH/PD 028-98). Dokumen itu menyatakan tarikh berkuat kuasa 28 November 2025, kecuali jika sesuatu perenggan menetapkan tarikhnya sendiri. Semak bnm.gov.my untuk keluaran yang lebih baharu.

Ini ialah bacaan teks kawal selia awam dalam bahasa mudah, bukan nasihat undang-undang. Sahkan kewajipan anda dengan pasukan pematuhan anda.

Ringkasan pendek

Berikut ialah apa yang RMiT minta daripada kod anda, dalam bahasa mudah. Bahagian seterusnya menerangkan setiap baris dan bukti di sebaliknya.

Cara membaca rujukan RMiT

RMiT menomborkan peraturannya mengikut perenggan, dan menandakan setiap satu sebagai "S" atau "G". Perenggan S ialah standard wajib; perenggan G ialah panduan. Lampiran mengandungi senarai semak terperinci. Contohnya, Lampiran 5 menyenaraikan kawalan ketahanan siber, termasuk keselamatan API dalam Bahagian E, dan perenggan 11.5 menjadikannya wajib.

Dalam artikel ini, "perenggan 10.10" bermaksud perenggan 10.10 RMiT. Kami akan nyatakan apabila sesuatu perenggan hanya panduan.

Apa kata RMiT tentang kod sumber

Kata-kata RMiT sendiri jelas tentang pembahagian ini. Perenggan S "must be complied with" (mesti dipatuhi), dan ketidakpatuhan "may result in enforcement action" (boleh membawa kepada tindakan penguatkuasaan). Perenggan G mengandungi cadangan yang "encouraged to be adopted" (digalakkan untuk diguna pakai).

Ingat pembahagian ini. Beberapa klausa yang sering dipetik tentang pengimbasan kod sebenarnya panduan, bukan standard.

Apa yang wajib untuk kod anda sendiri

Semak setiap perubahan sebelum ia dilancarkan. Perubahan pada kod sumber sistem kritikal mesti "subject to adequate source code reviews" (tertakluk kepada semakan kod sumber yang mencukupi, perenggan 10.10). Semakan itu memastikan kod selamat dan "developed in line with recognised coding practices" (dibangunkan selaras dengan amalan pengekodan yang diiktiraf). Ia mesti berlaku "prior to introducing any system changes" (sebelum sebarang perubahan sistem diperkenalkan).

Sistem kritikal ialah mana-mana sistem aplikasi yang menyokong perkhidmatan perbankan, insurans, takaful, pembayaran, pelaburan atau dagangan yang kritikal.

Dapatkan kelulusan bebas bagi setiap perubahan. Anda mungkin pernah melihat perenggan 10.10 diringkaskan sebagai mewajibkan semakan kod yang "independent" (bebas). Teks semasa menyebut "adequate" (mencukupi), bukan "independent". Kebebasan datang dalam perenggan seterusnya, yang mewajibkan prosedur untuk "independently review and approve system changes" (menyemak dan meluluskan perubahan sistem secara bebas, perenggan 10.11).

Dalam amalan, anda perlukan kedua-duanya: semakan kod, dan kelulusan bebas bagi perubahan itu. Apabila ejen pengekodan menulis perubahan, peraturan yang sama menentukan siapa yang menyemak kod yang dijana AI dan siapa yang boleh meluluskannya.

Uji API anda secara berkala. Institusi mesti "conduct periodic security assessments on APIs, including penetration testing and static / dynamic security testing" (menjalankan penilaian keselamatan API secara berkala, termasuk ujian penembusan dan ujian keselamatan statik / dinamik; Lampiran 5, Bahagian E 1(h)). Ini wajib, kerana perenggan 11.5 menjadikan Lampiran 5 wajib.

Semak kod pihak ketiga dalam API anda. Pembangunan API juga mesti mengikut pengekodan selamat, termasuk "validating security of third party code and libraries" (mengesahkan keselamatan kod dan pustaka pihak ketiga; Lampiran 5, Bahagian E 1(c)).

Jika anda membina perisian untuk bank atau syarikat insurans

Di sinilah vendor terlibat. RMiT tidak mengikat anda secara langsung; ia mengikat institusi, yang kemudian mengikat anda melalui kontrak.

Apabila pihak ketiga membangunkan atau menyelenggara sistem kritikal, institusi mesti mewajibkan vendor itu untuk "demonstrate that it adopts secure by design principles in IT system development methodology" (menunjukkan bahawa ia mengguna pakai prinsip secure by design dalam metodologi pembangunan sistem IT; perenggan 10.12(b)). Vendor juga mesti memastikan "the source code continues to be readily accessible" (kod sumber terus mudah diakses; perenggan 10.12(c)).

Secara berasingan, usaha wajar vendor oleh institusi mesti mengambil kira satu senarai risiko (perenggan 10.47). Senarai itu termasuk "secure system development lifecycle" (kitaran hayat pembangunan sistem yang selamat) dan "vetting of third party or open source software" (penapisan perisian pihak ketiga atau sumber terbuka; Lampiran 8).

Automasi wajib; alat dan SBOM hanya panduan

Pasukan yang bergerak pantas mesti mengautomasikan semakan keselamatan. Jika institusi menggunakan kaedah pembangunan pantas seperti DevOps, ia "shall automate the IT security compliance review" (mesti mengautomasikan semakan pematuhan keselamatan IT; perenggan 10.6). Ini termasuk mengesan dan menguji kelemahan keselamatan.

Alat pengimbasan kod dicadangkan, bukan diwajibkan. Institusi "may deploy automated tools" (boleh menggunakan alat automatik) untuk pembangunan, ujian, pengurusan perubahan, "code scanning and software version control" (pengimbasan kod dan kawalan versi perisian; perenggan 10.14, panduan).

SBOM dicadangkan, bukan diwajibkan. Institusi boleh mempertimbangkan "adopting Software-Bill-of-Materials (SBOM)" (perenggan 10.15, panduan). SBOM ialah senarai setiap komponen pihak ketiga dalam perisian anda. Perenggan yang sama mencadangkan dasar keselamatan perisian sumber terbuka.

Dua perenggan panduan ini menunjukkan apa yang BNM anggap amalan baik. Ia tidak mewujudkan kewajipan berasingan untuk membeli pengimbas.

Jika anda ialah infrastruktur maklumat kritikal negara

Sesetengah institusi ditetapkan sebagai entiti NCII (infrastruktur maklumat kritikal negara). Bagi mereka, RMiT memasukkan Kod Amalan sektor perbankan di bawah Akta Keselamatan Siber 2024 (Lampiran 12).

Kod itu meminta garis panduan pengekodan selamat yang selaras dengan OWASP Top 10, senarai standard kelemahan aplikasi web yang paling biasa. Ia juga meminta ujian sebelum pelancaran yang merangkumi "Validation of compliance with secure coding guidelines" (pengesahan pematuhan terhadap garis panduan pengekodan selamat). Ia berkuat kuasa sebaik sahaja Ketua Eksekutif NACSA, Agensi Keselamatan Siber Negara Malaysia, mengesahkannya.

Bukti semakan kod sumber RMiT yang diminta juruaudit dan BNM

Baca perenggan wajib sebagai permintaan bukti, dan satu senarai kerja akan terbentuk. Inilah senarai yang akan kami sediakan sebelum audit teknologi dalaman atau semakan usaha wajar vendor.

• Rekod semakan bagi setiap perubahan pada sistem kritikal. Tunjukkan siapa yang menyemaknya, berdasarkan peraturan pengekodan mana, dan hasilnya, bertarikh sebelum keluaran (perenggan 10.10).
• Kelulusan bebas bagi setiap perubahan (perenggan 10.11). RMiT juga menjangkakan "appropriate segregation of duties throughout the SDLC" (pengasingan tugas yang sewajarnya sepanjang SDLC), jadi dalam amalan, pelulus bukan penulis kod itu.
• Keputusan ujian API. Simpan keputusan ujian keselamatan statik dan dinamik berkala serta laporan ujian penembusan (Lampiran 5, Bahagian E).
• Standard pengekodan bertulis anda. Ia memberi "recognised coding practices" sesuatu yang konkrit untuk dirujuk (perenggan 10.10). Entiti NCII juga memerlukan standard yang selaras dengan OWASP Top 10 (Lampiran 12).
• Bukti vendor. Kumpulkan penerangan SDLC selamat vendor dan bukti ia dipatuhi (perenggan 10.12). Sahkan kod sumber kekal boleh diakses, dan simpan jawapan usaha wajar anda (Lampiran 8).
• Inventori komponen sumber terbuka dan pihak ketiga, sebaik-baiknya SBOM, berserta keputusan penapisan (Lampiran 8). SBOM itu sendiri ialah panduan (perenggan 10.15).
• Status kelemahan yang diketahui. Sistem mesti "not running with known security vulnerabilities" (tidak berjalan dengan kelemahan keselamatan yang diketahui; perenggan 10.17).
• Analisis jurang anda. Institusi mesti menghantar analisis jurang dan pelan tindakan kepada BNM "no later than 90 days after the issuance date of this policy document" (tidak lewat daripada 90 hari selepas tarikh dokumen dasar ini dikeluarkan; perenggan 18.1). Institusi yang telah menghantar di bawah versi terdahulu mesti terus mengenal pasti "any new gaps against the enhanced or revised requirements" (sebarang jurang baharu berbanding keperluan yang dipertingkat atau disemak semula). Mereka juga mesti menyediakan penilaian tahunan kepada BNM apabila diminta.

Dua daripada ini paling sukar dihasilkan selepas kejadian: rekod semakan bagi setiap perubahan dan inventori komponen. Kedua-duanya murah untuk disimpan jika alat menulisnya pada setiap pull request. Kedua-duanya menyusahkan untuk dibina semula enam bulan kemudian.

Bagaimana SonarQube menyokong bukti itu, mengikut edisi

SonarQube tidak menjadikan anda patuh RMiT. Kekuatannya ialah menulis sebahagian besar bukti semakan kod sumber RMiT anda secara automatik, pada setiap perubahan. Bukti mana yang dihasilkan bergantung pada edisi.

Apa yang diberikan oleh setiap edisi

Rekod semakan bagi setiap perubahan: Developer edition dan ke atas. Setiap pull request dianalisis sebelum digabungkan. Quality gate boleh menyekat penggabungan jika kod baharu melanggar peraturan anda. Sejarah analisis menyokong bukti anda bagi semakan setiap perubahan (perenggan 10.10). Quality profile ialah standard pengekodan anda dalam bentuk bertulis.

Community Build percuma hanya menganalisis cawangan utama, jadi ia tidak dapat memberi rekod bagi setiap perubahan. Perbandingan kami tentang SonarQube Community vs Developer vs Enterprise menerangkan apa yang ditambah oleh setiap edisi.

Fail yang boleh disimpan oleh juruaudit: Enterprise edition. SonarQube Server Enterprise menambah artifak yang boleh difailkan oleh pasukan usaha wajar atau juruaudit:

• laporan pematuhan berdasarkan OWASP Top 10, CWE Top 25 (senarai MITRE bagi kelemahan perisian paling berbahaya) dan PCI DSS (standard keselamatan industri kad);
• laporan PDF;
• laporan kawal selia, iaitu fail ZIP yang mengandungi status quality gate, penarafan dan quality profile;
• log audit.

Satu perkara praktikal: secara lalai, pembersihan log audit memadamkan entri setiap bulan, jadi panjangkan tempoh simpanan sebelum tempoh audit bermula.

Inventori komponen dan SBOM: add-on Advanced Security. Ini menyokong penapisan sumber terbuka dalam usaha wajar vendor (Lampiran 8). SonarQube Advanced Security, add-on berbayar mulai Server Enterprise, menambah analisis komposisi perisian (pengimbasan kebergantungan pihak ketiga anda). Ia juga mengeksport SBOM dalam format CycloneDX atau SPDX, dua format fail SBOM standard. SBOM tidak disimpan, jadi eksport satu bagi setiap keluaran.

Menutup penemuan: Remediation Agent. SonarQube Remediation Agent mencadangkan pembetulan dan membukanya sebagai pull request untuk semakan anda, sambil menjalankan semula analisis Sonar ke atas setiap pembetulan.

Kelemahan logik dan kawalan akses: Hunter Agent. SonarQube Hunter Agent mencari kelemahan kawalan akses dan logik perniagaan, iaitu kelas serangan yang dinamakan oleh PCI DSS 6.2.4 (di bawah), serta kelemahan pengesahan identiti.

Kedua-dua ejen ialah langganan berasingan. Pada SonarQube Server, ia memerlukan Enterprise edition, versi 2026.5 atau lebih baharu. Hunter Agent pada SonarQube Cloud memerlukan pelan Enterprise. Kedua-duanya tidak menggantikan penyemak anda atau kelulusan bebas (perenggan 10.11).

Di mana kod dijalankan. Bagi institusi yang dikawal selia, perkara ini boleh menentukan edisi. SonarQube Cloud menyimpan data di EU atau AS sahaja (setakat Oktober 2026), dan rantau itu tidak boleh ditukar selepas pendaftaran. Tiada rantau Asia Pasifik.

SonarQube Server diurus sendiri, jadi anda menentukan di mana ia dijalankan, termasuk pada infrastruktur anda sendiri. Lesen dikira mengikut baris kod; lihat cara harga SonarQube berfungsi.

Apa yang tidak diliputi. Teras SonarQube ialah analisis statik. Ia tidak menggantikan ujian dinamik dan ujian penembusan yang turut diminta oleh RMiT untuk API (Lampiran 5, Bahagian E). Ia juga tidak menggantikan kelulusan bebas bagi setiap perubahan. Anggap ia sebagai satu kawalan dalam bukti anda, bukan keseluruhannya.

Turut terpakai jika anda mengendalikan data kad: PCI DSS

PCI DSS v4.0.1 meminta bukti yang hampir sama dari sudut berbeza:

• Semak kod tersuai sebelum keluaran. Perisian khusus dan tersuai mesti "reviewed prior to being released into production or to customers" (disemak sebelum dikeluarkan ke pengeluaran atau kepada pelanggan; keperluan 6.2.3). Nota kebolehgunaannya menyatakan bahawa "Code reviews may be performed using either manual or automated processes, or a combination of both." (Semakan kod boleh dibuat secara manual, automatik, atau gabungan kedua-duanya.)
• Pertahankan diri daripada serangan logik dan kawalan akses. Kaedah kejuruteraan anda mesti menangani serangan ke atas logik perniagaan dan mekanisme kawalan akses, antara lain (keperluan 6.2.4). Di situlah Hunter Agent berperanan.
• Simpan inventori perisian. Anda perlukan "An inventory of bespoke and custom software, and third-party software components" (inventori perisian khusus dan tersuai, serta komponen perisian pihak ketiga; keperluan 6.3.2). SBOM daripada Advanced Security menyokongnya.

SonarQube Server Enterprise termasuk laporan pematuhan PCI DSS, yang dipetakan oleh Sonar kepada PCI DSS versi 4.0 dan 3.2.1 setakat Oktober 2026. Ia menyokong bukti anda; QSA anda (Qualified Security Assessor yang mengesahkan PCI DSS) tetap membuat keputusan.

Turut terpakai jika anda dikawal selia di Singapura: MAS TRM

Technology Risk Management Guidelines MAS (Januari 2021) meliputi perkara yang sama:

• Tetapkan standard pengekodan dan semakan. Institusi kewangan "should adopt standards on secure coding, source code review and application security testing" (patut mengguna pakai standard pengekodan selamat, semakan kod sumber dan ujian keselamatan aplikasi; perenggan 6.1.1).
• Gabungkan kaedah ujian anda. Institusi "may use a mixture of static, dynamic and interactive application security testing" (boleh menggunakan gabungan ujian keselamatan aplikasi statik, dinamik dan interaktif; perenggan 6.1.6).
• Betulkan isu besar sebelum keluaran. Isu patut dijejak, dan "Major issues and software defects should be remediated before production deployment" (isu besar dan kecacatan perisian patut dibetulkan sebelum pelancaran ke pengeluaran; perenggan 6.1.7).

Quality gate yang menyekat penggabungan apabila ada isu besar baharu ialah cara langsung untuk menunjukkan perkara terakhir itu berfungsi. Halaman SonarQube Singapura kami memetakan setiap perenggan MAS TRM kepada ciri SonarQube.

Soalan lazim

Ringkasnya, semakan kod sumber RMiT bukan tentang membeli alat. Ia tentang menyimpan rekod yang betul untuk setiap perubahan, sebelum juruaudit bertanya.

Sumber

• Bank Negara Malaysia, Risk Management in Technology (RMiT), dikeluarkan 25 September 2026, BNM/RH/PD 028-98.
• Monetary Authority of Singapore, Technology Risk Management Guidelines, Januari 2021.
• PCI Security Standards Council, PCI DSS v4.0.1, Jun 2024.
• Dokumentasi Sonar tentang laporan pematuhan, Advanced Security dan rantau SonarQube Cloud, disemak Oktober 2026.

Bacaan berkaitan: SonarQube untuk bank dan institusi kewangan di Malaysia, dan menyemak kod tulisan AI dengan SonarQube AI Code Assurance.