Cara Kerja Shift-Left Security dalam SDLC (Panduan Lengkap)

Setelah memahami pentingnya Shift-Left Security, tahap berikutnya adalah melihat bagaimana pendekatan ini diterapkan dalam proses pengembangan software. Pada dasarnya, Shift-Left Security bukan sebuah tool tunggal, melainkan cara mengintegrasikan aktivitas keamanan ke berbagai tahapan SDLC.

NIST melalui Secure Software Development Framework (SSDF) menekankan bahwa praktik keamanan perlu diintegrasikan ke dalam model SDLC yang digunakan organisasi. NIST juga mengelompokkan praktik SSDF ke dalam empat kelompok utama, yaitu mempersiapkan organisasi (Prepare the Organization), melindungi software (Protect the Software), menghasilkan software yang aman (Produce Well-Secured Software), serta merespons kerentanan (Respond to Vulnerabilities).

1. Menentukan Security Requirement Sejak Awal

Penerapan Shift-Left Security dapat dimulai bahkan sebelum developer menulis kode.

Pada tahap perencanaan, tim perlu menentukan security requirement yang harus dipenuhi oleh aplikasi. Persyaratan tersebut dapat berkaitan dengan autentikasi, otorisasi, perlindungan data, pengelolaan kredensial, logging, keamanan API, hingga kebutuhan kepatuhan tertentu.

Contohnya, ketika sebuah aplikasi dirancang untuk menyimpan data pengguna, tim perlu menentukan sejak awal:

• data apa yang boleh disimpan;
• siapa yang dapat mengakses data;
• bagaimana autentikasi pengguna dilakukan;
• bagaimana hak akses dibatasi;
• bagaimana data sensitif dilindungi; dan
• bagaimana aktivitas penting dicatat.

NIST SSDF memasukkan pengelolaan kebutuhan keamanan, risiko, serta keputusan desain (task PW.1.2) sebagai bagian dari praktik secure software development.

Dengan menentukan persyaratan keamanan lebih awal, keamanan menjadi bagian dari desain aplikasi, bukan sekadar pemeriksaan setelah aplikasi selesai dibuat.

2. Melakukan Threat Modeling pada Tahap Desain

Setelah kebutuhan keamanan ditentukan, tim dapat melakukan threat modeling untuk mengidentifikasi potensi ancaman terhadap aplikasi.

Threat modeling merupakan proses untuk memahami bagaimana sebuah sistem dapat diserang, aset apa yang perlu dilindungi, serta kontrol keamanan apa yang diperlukan.

Sebagai contoh, aplikasi e-commerce memiliki beberapa aset penting seperti:

• akun pengguna;
• informasi transaksi;
• data pembayaran;
• API;
• database; dan
• sistem administrasi.

Tim kemudian dapat mempertimbangkan bagaimana aset tersebut mungkin disalahgunakan atau diserang.

Threat modeling sebaiknya dilakukan sebelum desain dan implementasi terlalu jauh, karena keputusan arsitektur yang sudah dibuat dapat lebih sulit diubah ketika aplikasi telah berkembang. OWASP Web Security Testing Guide menyarankan agar threat model dibuat sedini mungkin dalam SDLC dan terus ditinjau ulang seiring aplikasi berkembang.

OWASP juga memasukkan threat modeling sebagai salah satu aktivitas yang dapat digunakan dalam secure development dan DevSecOps.

3. Menerapkan Secure Coding Saat Development

Tahap berikutnya adalah memasukkan keamanan ke dalam proses penulisan kode.

Developer perlu mengikuti prinsip secure coding untuk mengurangi kemungkinan munculnya kerentanan. Praktiknya dapat mencakup validasi input, pengelolaan autentikasi dan otorisasi, penanganan error, perlindungan secret, serta penggunaan API dan library secara aman.

Pada tahap ini, pemeriksaan otomatis juga dapat membantu developer menemukan pola kode yang berpotensi bermasalah.

Salah satu teknologi yang umum digunakan adalah Static Application Security Testing (SAST). SAST menganalisis source code atau representasi kode tanpa harus menjalankan aplikasi untuk membantu menemukan kelemahan keamanan.

OWASP memasukkan SAST sebagai salah satu jenis pengujian yang dapat diintegrasikan ke dalam proses DevSecOps.

4. Melakukan Code Review

Selain automated scanning, code review tetap menjadi bagian penting dari proses keamanan.

Dalam code review, perubahan kode diperiksa oleh developer lain atau pihak yang memiliki kompetensi terkait untuk memastikan kode memenuhi standar kualitas dan keamanan.

Misalnya, reviewer dapat memperhatikan apakah:

• input pengguna sudah divalidasi;
• hak akses sudah diperiksa;
• informasi sensitif tidak ditulis langsung dalam source code;
• error handling tidak membocorkan informasi sensitif;
• dependency digunakan dengan benar; dan
• perubahan kode memperkenalkan risiko baru.

Code review tidak harus menggantikan automated security testing. Keduanya dapat digunakan secara bersama-sama karena memiliki kemampuan yang berbeda.

Automated tools dapat membantu menemukan pola tertentu secara cepat, sedangkan manusia dapat memahami konteks bisnis dan desain aplikasi yang mungkin tidak dapat dinilai hanya berdasarkan pola kode.

5. Memeriksa Dependency dan Komponen Pihak Ketiga

Aplikasi modern biasanya tidak dibuat hanya dari kode yang ditulis sendiri oleh developer. Aplikasi dapat menggunakan framework, library, package, container, dan komponen open source lainnya.

Karena itu, Shift-Left Security juga perlu memperhatikan software supply chain.

Salah satu pendekatan yang dapat digunakan adalah Software Composition Analysis (SCA) untuk membantu mengidentifikasi komponen dan dependency yang digunakan serta mengetahui apakah terdapat kerentanan yang telah diketahui.

OWASP memasukkan SCA sebagai salah satu aktivitas keamanan yang dapat diintegrasikan ke dalam pipeline DevSecOps.

Pemeriksaan dependency menjadi semakin penting karena aplikasi modern dapat terdiri dari banyak komponen yang berasal dari sumber berbeda. NIST pada proyek DevSecOps (dokumen draf publik NCCoE, Maret 2026) juga menyoroti bahwa aplikasi saat ini umumnya dibangun menggunakan kombinasi berbagai komponen, framework, library, dan tools.

6. Mengintegrasikan Security Testing ke CI/CD

Salah satu karakteristik penting Shift-Left Security adalah otomatisasi pengujian keamanan.

Dalam lingkungan CI/CD, perubahan kode biasanya melewati serangkaian proses otomatis sebelum dapat diterapkan ke production. Contoh alur berikut adalah ilustrasi umum — urutan dan tahapan aktual dapat bervariasi tergantung arsitektur pipeline masing-masing organisasi:

Developer → Commit → Build → Security Scan → Automated Test → Review → Deployment

Security testing dapat ditempatkan pada beberapa titik dalam pipeline tersebut.

Misalnya:

• SAST untuk menganalisis kode;
• SCA untuk memeriksa dependency;
• DAST untuk menguji aplikasi yang sedang berjalan;
• secret scanning untuk mencari kredensial atau secret yang tidak semestinya masuk ke repository;
• container scanning untuk memeriksa image container; dan
• infrastructure scanning untuk menemukan masalah keamanan pada lingkungan infrastruktur.

OWASP DevSecOps Guideline secara khusus mencantumkan SAST, DAST, IAST, SCA, infrastructure vulnerability scanning, dan container vulnerability scanning sebagai contoh aktivitas yang dapat dimasukkan ke dalam CI/CD pipeline.

7. Menggunakan Security Gate

Setelah security testing terintegrasi ke pipeline, organisasi dapat menetapkan security gate.

Security gate merupakan aturan yang menentukan apakah sebuah perubahan boleh melanjutkan proses atau harus diperbaiki terlebih dahulu.

Sebagai contoh, organisasi dapat menetapkan bahwa build tidak boleh diteruskan apabila ditemukan vulnerability dengan tingkat keparahan tertentu.

Namun, security gate perlu dirancang secara hati-hati. Jika terlalu banyak temuan berstatus warning atau false positive diperlakukan sebagai kegagalan, developer dapat menghadapi terlalu banyak hambatan dalam pipeline.

Karena itu, penerapan Shift-Left Security sebaiknya mempertimbangkan risiko, tingkat keparahan, konteks aplikasi, dan kebutuhan bisnis, bukan sekadar menghentikan pipeline untuk setiap temuan.

NIST menekankan bahwa selain risiko, faktor seperti biaya, kelayakan, dan kesesuaian juga perlu dipertimbangkan saat memutuskan praktik SSDF mana yang digunakan. SSDF juga secara eksplisit dinyatakan bukan dimaksudkan sebagai checklist kaku, melainkan dasar untuk pendekatan yang berbasis risiko dan perbaikan berkelanjutan.

8. Melakukan Pengujian Keamanan Secara Berkelanjutan

Shift-Left Security tidak berhenti ketika aplikasi berhasil melewati CI/CD.

Beberapa masalah keamanan baru dapat diketahui ketika aplikasi sudah berjalan dalam lingkungan tertentu. Karena itu, pengujian pada tahap selanjutnya tetap diperlukan.

OWASP merekomendasikan prinsip “test early and test often”, yang menyatakan bahwa bug keamanan yang ditemukan lebih awal dalam SDLC dapat ditangani lebih cepat dan dengan biaya lebih rendah. Panduan ini juga menyarankan agar pengujian keamanan diintegrasikan ke dalam workflow CI/CD dan dilakukan secara rutin menggunakan metode seperti SAST, DAST, serta SCA.

Dengan demikian, pendekatan Shift-Left bukan:

“Security dilakukan di awal lalu selesai.”

Melainkan:

“Security dimulai lebih awal dan terus dilakukan sepanjang siklus pengembangan.”

9. Menangani Temuan dan Melakukan Perbaikan

Ketika security testing menemukan masalah, hasilnya perlu masuk kembali ke proses development.

Contohnya:

Security Scan → Vulnerability Ditemukan → Analisis → Perbaikan Kode → Testing Ulang → Deployment

Proses ini memungkinkan masalah keamanan ditangani sebelum perubahan masuk lebih jauh ke lingkungan produksi.

NIST SSDF juga menempatkan respons terhadap kerentanan (Respond to Vulnerabilities) sebagai salah satu dari empat kelompok praktik utamanya. Tujuannya bukan hanya menangani vulnerability yang ditemukan, tetapi juga mencegah masalah serupa terjadi kembali di masa depan.

Dengan demikian, hasil security testing dapat menjadi masukan untuk meningkatkan secure coding guideline, proses review, desain sistem, maupun konfigurasi tool.

10. Gambaran Alur Shift-Left Security

Jika seluruh proses tersebut disederhanakan, penerapan Shift-Left Security dapat digambarkan sebagai berikut (ilustrasi umum, dapat disesuaikan dengan kebutuhan masing-masing organisasi):

Perencanaan ↓ Menentukan security requirement ↓ Desain ↓ Threat modeling dan analisis risiko ↓ Development ↓ Secure coding + code review + SAST + pemeriksaan dependency ↓ CI/CD ↓ Automated security testing + security gate ↓ Deployment ↓ Validasi keamanan dan pengujian aplikasi ↓ Operasional ↓ Monitoring + vulnerability management + perbaikan berkelanjutan

Alur tersebut menunjukkan bahwa keamanan tidak ditempatkan sebagai satu aktivitas yang berdiri sendiri. Keamanan menjadi bagian dari proses pengembangan dari awal hingga operasional.

NIST pada proyek DevSecOps (dokumen draf publik NCCoE, Maret 2026) juga menekankan pendekatan yang mengintegrasikan keamanan ke setiap fase pengembangan dan menggunakan pendekatan berbasis risiko untuk menerapkan praktik yang selaras dengan SSDF.

Kesimpulan

Cara kerja Shift-Left Security pada dasarnya adalah mengintegrasikan keamanan ke dalam setiap tahap pengembangan software, mulai dari menentukan security requirement, melakukan threat modeling, menerapkan secure coding, code review, pemeriksaan dependency, hingga automated security testing dalam CI/CD.

Pendekatan ini tidak menghilangkan security testing pada tahap akhir. Sebaliknya, pengujian awal dan otomatis ditambahkan agar masalah dapat ditemukan lebih cepat, sementara pengujian pada tahap berikutnya tetap digunakan untuk menemukan risiko yang tidak dapat terdeteksi sebelumnya.

NIST SSDF menyediakan kerangka praktik yang dapat diintegrasikan ke berbagai model SDLC, sedangkan OWASP memberikan contoh penerapan DevSecOps melalui integrasi berbagai security testing ke dalam pipeline CI/CD.

Ingin mempelajari lebih banyak seputar web development, cloud computing, keamanan siber, server, hingga berbagai tren teknologi terbaru? Kunjungi blog Hosteko untuk mendapatkan artikel yang informatif, mudah dipahami, dan selalu diperbarui mengikuti perkembangan dunia digital.

Jangan lewatkan berbagai panduan, tips, serta tutorial yang dapat membantu Anda mengembangkan website, meningkatkan performa bisnis online, dan memperluas wawasan di bidang teknologi. Temukan artikel menarik lainnya hanya di Hosteko Blog dan terus ikuti informasi terbaru untuk mendukung perjalanan digital Anda.