Analisis komposisi perangkat lunak (SCA) adalah proses menganalisis perangkat lunak, paling umum perangkat lunak yang dibangun dari komponen sumber terbuka, untuk memastikan bahwa komponen tersebut terbaru, aman, dan sesuai dengan lisensi.
Alat SCA beroperasi dengan memindai kode sumber perangkat lunak, mengumpulkannya dalam database, membandingkannya dengan database kerentanan yang diketahui, memeriksa pembaruan atau masalah lisensi, dan kemudian menghasilkan laporan.
Meskipun analisis komposisi perangkat lunak dapat memindai semua jenis elemen perangkat lunak, termasuk komponen berpemilik dan image kontainer, analisis ini paling sering digunakan untuk menganalisis pustaka sumber terbuka. Komponen sumber terbuka disertakan sampai batas tertentu di hampir setiap basis kode modern, dan karena kerentanan dalam kodenya sangatlah umum, maka sangat penting untuk menjaga perangkat lunak sumber terbuka tetap diperbarui dan transparan.
Alat SCA mengelola risiko kerentanan keamanan dari komponen perangkat lunak yang tidak diketahui asalnya, masalah kompatibilitas antara lisensi sumber terbuka yang berbeda dan dokumentasi atau dukungan yang tidak lengkap atau tidak mencukupi untuk pustaka sumber terbuka.
Analisis komposisi perangkat lunak adalah bagian dari pipeline cloud-native DevOps yang mengintegrasikan proses pengembangan perangkat lunak dengan operasi TI. SCA juga mendukung postur keamanan organisasi sebagai bagian dari pipeline DevSecOps, yang mengintegrasikan keamanan dengan pengembangan dan operasi. Alat SCA dapat digunakan dalam lingkungan pengembangan terintegrasi (IDE), menyediakan analisis kode secara real-time selama proses pengembangan.
SCA berbeda dengan bentuk pemindaian kerentanan lainnya seperti pengujian keamanan aplikasi statis (SAST), pengujian keamanan aplikasi dinamis (DAST), dan pemindaian ketergantungan.
Tim TI sering menggunakan alat SCA untuk menghasilkan daftar bahan perangkat lunak (SBOM). SBOM mencantumkan semua komponen, pustaka, dan modul dalam produk perangkat lunak dalam format yang dapat dibaca mesin untuk kepatuhan dan keamanan rantai pasokan. SBOM juga dapat menginformasikan kebijakan pemindaian SCA lebih lanjut.
Menurut data survei dari International Data Corporation, 93 persen perusahaan dengan setidaknya 100 karyawan menggunakan perangkat lunak open source pada 2024, yang menyoroti kebutuhan luas akan solusi SCA.1
Tetap terinformasi tentang tren industri yang paling penting—dan menarik—tentang AI, otomatisasi, data, dan di luarnya dengan buletin Think. Lihat Pernyataan Privasi IBM®.
SCA bekerja dengan mengumpulkan kode sumber, membandingkannya dengan basis data kerentanan, menganalisis basis data untuk mengetahui potensi masalah kepatuhan, menghapus positif palsu, dan membuat laporan untuk tim keamanan siber dan tim pengembangan.
Alat SCA secara aktif memindai dan menganalisis kode selama pengembangan sebagai bagian dari pipeline integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) di seluruh siklus pengembangan, berfokus terutama pada komponen sumber terbuka dan dependensi pihak ketiga.
Untuk melakukan ini, alat SCA pertama-tama mencantumkan elemen dasar dari semua perangkat lunak di lingkungan TI, termasuk komponen, kerangka kerja, perpustakaan, image kontainer, modul, dan dependensinya. Dua bentuk utama pemindaian SCA adalah:
Pemindaian statis, atau pemindaian manifes, yang membaca file konfigurasi dan metadata untuk menemukan elemen yang secara eksplisit dijelaskan di sana.
Dinamis, atau pemindaian waktu proses, yang mengidentifikasi pustaka saat berjalan dalam waktu nyata dengan memindai kode biner.
Kedua jenis pemindaian tersebut memiliki manfaat dan kekurangan. Pemindaian statis mungkin mencakup kerentanan dari komponen pihak ketiga dalam kode sumber yang tidak diterapkan di waktu proses, sehingga menciptakan positif palsu. Pemindaian dinamis, di sisi lain, mungkin tidak pernah sepenuhnya menyeluruh, karena semua elemen kode tidak dijalankan di waktu proses. Banyak organisasi menggunakan kombinasi keduanya.
Setelah alat SCA selesai mengumpulkan kode, alat ini membuat daftar bahan perangkat lunak (SBOM) dan membandingkan komponen SBOM dengan database yang menggambarkan kerentanan umum dan risiko keamanan perangkat lunak modern.
Tim keamanan membandingkan SBOM dengan basis data eksklusif yang berisi kerentanan keamanan yang diketahui dan basis data publik seperti National Vulnerability Database (NVD) atau daftar Common Vulnerabilities and Exposures (CVE). Setelah potensi kerentanan ditandai, alat SCA akan menetapkan masing-masing skor ancaman (biasanya menggunakan Sistem Penilaian Kerentanan Umum, atau CVSS) yang memungkinkan tim keamanan siber memprioritaskan remediasi.
Beberapa alat keamanan mengotomatiskan manajemen kerentanan dengan menerapkan patch atau pembaruan yang sesuai sebagai bagian dari pipeline CI/CD. Tim keamanan biasanya memantau proses ini untuk memastikan bahwa perubahan yang diterapkan tidak mempengaruhi dependensi atau fungsionalitas yang ada.
Alat SCA juga memeriksa SBOM terhadap kebijakan dan undang-undang perusahaan tentang lisensi perangkat lunak untuk memastikan kepatuhan.
Inisiatif Sumber Terbuka mencantumkan lebih dari 100 lisensi sumber terbuka yang disetujui, beberapa di antaranya memungkinkan produk berpemilik dibuat dari kode sumber terbuka. Namun, tidak semuanya kompatibel, yang berarti organisasi bertanggung jawab untuk memastikan produk mereka sesuai.
Solusi SCA dapat memeriksa bahwa semua perangkat lunak sumber terbuka membawa atribusi yang diperlukan, atau bahwa elemen yang tunduk pada “copyleft”, yang melarang penggunaannya dalam perangkat lunak berhak cipta dan berhak milik, tidak termasuk dalam pengembangan perangkat lunak itu.
Analisis komposisi perangkat lunak juga dapat mendeteksi dependensi antara komponen proyek, sumber utama kerentanan potensial.
Alat SCA dapat mendeteksi kedua dependensi langsung, di mana komponen perangkat lunak digunakan secara langsung oleh satu sama lain pada tingkat kode, dan dependensi transitif. Ketergantungan transitif terjadi ketika sebuah perangkat lunak menjadi secara tidak langsung bergantung pada komponen perangkat lunak di mana salah satu dependensi langsungnya bergantung. Sebagai contoh: Komponen A bergantung pada komponen B, yang bergantung pada komponen C. Dalam skenario ini, komponen A bergantung secara transitif pada komponen C.
Alat SCA harus menentukan dependensi mana yang menimbulkan kerentanan dan mana yang tidak, untuk mengurangi jumlah peringatan palsu. Mereka melakukan ini dengan menilai rantai pasokan perangkat lunak dan menentukan apakah kerentanan dalam kode “dapat dijangkau”, yaitu, apakah itu akan dipanggil dalam lingkungan waktu proses mengingat konfigurasi jaringan saat ini.
Hasil analisis komposisi perangkat lunak kemudian dikompilasi dalam sebuah laporan dan sering kali disajikan dalam dasbor berpemilik, data mentah seperti file JSON, SBOM baru, atau kombinasi ketiganya.
Dalam beberapa tahun terakhir pengembang telah membuat kemajuan dalam mengurangi positif palsu dalam laporan ini.
Analisis metode rentan melacak jalur panggilan komponen perangkat lunak untuk memastikan bahwa kerentanan yang terdeteksi dapat dijangkau.
Machine learning dan kecerdasan buatan telah berkontribusi pada identifikasi positif palsu. Dengan pelatihan yang tepat, model dapat secara akurat mengidentifikasi apakah kerentanan dapat dijangkau atau tidak. Pemrosesan bahasa alami juga digunakan untuk menganalisis pesan commit kontrol versi dari repositori seperti GitHub untuk deteksi potensi masalah yang tidak dapat diidentifikasi dalam kode.
Beberapa alat SCA mencakup pemantauan berkelanjutan dan fitur remediasi otomatis, yang selanjutnya mengintegrasikan praktik ke dalam alur kerja pengembangan DevSecOps. Remediasi otomatis biasanya dilakukan dengan memulai permintaan tarik yang memberi tahu pengembang untuk perbaikan masalah lisensi atau menerapkan patch keamanan baru.
Manfaat SCA termasuk kepercayaan yang lebih tinggi terhadap kepatuhan organisasi dan postur keamanan siber, serta peningkatan otomatisasi alur kerja TI.
Dengan membantu memastikan bahwa semua komponen sumber terbuka dalam ekosistem TI digunakan sesuai dengan persyaratan lisensi dan kepatuhan mereka, SCA dapat membantu organisasi mengurangi risiko hukum.
Mengidentifikasi kerentanan jaringan yang diciptakan oleh ketidakpastian komponen perangkat lunak sumber terbuka adalah bagian penting dari manajemen risiko TI. Dalam membuat rantai pasokan perangkat lunak sumber terbuka lebih transparan, organisasi dapat menikmati manfaat penyesuaian dan biaya yang lebih rendah sambil tetap yakin bahwa mereka telah mengurangi risiko keamanan yang menyertainya.
Dalam mengotomatiskan sejumlah besar kerentanan, ketergantungan, dan pelacakan kepatuhan, solusi SCA membebaskan tim TI untuk menyelesaikan tugas lain. Otomatisasi ekstensif ini juga membantu memperkuat praktik DevOps organisasi.
Beberapa tantangan yang ditimbulkan oleh analisis komposisi perangkat lunak meliputi kurangnya kelengkapan dalam melacak kerentanan, membatasi positif palsu, dan mengelola ruang lingkup analisis.
Alat SCA yang berbeda mereferensikan database kerentanan yang berbeda yang mungkin tidak selalu terkini. Pandangan organisasi tentang komponen jaringan dan perangkat lunak mungkin berbeda berdasarkan produk mana yang mereka pilih. Hal ini dapat menyebabkan beberapa kerentanan baru lolos dari pengawasan. Analis harus mengingat potensi “yang tidak diketahui” ini saat melakukan pemindaian SCA.
Sementara kemajuan dalam pelacakan panggilan dan analisis machine learning telah menghasilkan peningkatan dalam mengurangi positif palsu, itu merupakan bagian yang tak terhindarkan dari proses SCA. Hal ini dapat menyebabkan kelelahan peringatan, suatu kondisi kelelahan mental dan operasional yang disebabkan oleh jumlah peringatan yang sangat banyak yang dapat menyebabkan penundaan respons dan mengikis kepercayaan terhadap manajemen peringatan dan sistem keamanan.
Melacak dan menganalisis sejumlah besar dependensi dalam sistem TI tertentu dapat menguras kinerja jaringan, terutama ketika proses SCA diotomatisasi sebagai bagian dari pipeline CI/CD. Organisasi harus memastikan mereka memiliki sumber daya untuk mendukung pemindaian SCA dan menerapkannya dengan mempertimbangkan kinerja.
Analisis komposisi perangkat lunak berbeda dari DAST dan SAST, dua metode pengujian tambahan yang digunakan untuk mengidentifikasi kerentanan keamanan dalam aplikasi modern.
Sementara SCA menyediakan tim TI dengan peta komprehensif komponen perangkat lunak, dependensi, dan kerentanan, DAST dan SAST fokus pada dan mengungkapkan kekurangan individu dalam komponen-komponen tersebut dan aplikasi perangkat lunak yang lebih besar yang dibentuknya.
Perbedaan antara DAST dan SAST mirip dengan perbedaan antara pemindaian statis dan dinamis di SCA. Pengujian keamanan aplikasi dinamis (DAST) menilai aplikasi di lingkungan produksinya, meniru pengguna jahat dan serangan siber untuk membantu mengidentifikasi masalah keamanan. Pengujian keamanan aplikasi statis (SAST) menggali kode sumber aplikasi, mencari kerentanan dalam kode saat ditulis.
Sementara SCA berfokus pada penghitungan dan analisis komponen dalam perangkat lunak tertentu, DAST dan SAST secara khusus difokuskan pada pengujian perangkat lunak itu untuk kerentanan keamanan, baik dalam waktu proses dalam kasus yang pertama atau kode sumber dalam kasus yang terakhir. Keduanya sering digunakan bersama SCA, tetapi juga dapat dipraktikkan secara mandiri.
SCA berbeda dari pemetaan ketergantungan, proses mengidentifikasi, memahami, dan memvisualisasikan hubungan antara aplikasi, sistem, dan proses dalam operasi TI organisasi.
Alat SCA memberikan gambaran umum tentang dependensi komponen dan mengidentifikasi potensi kerentanan yang mungkin timbul darinya, tetapi pemetaan ketergantungan mengacu pada kategori praktik pengamatan yang lebih luas yang mengidentifikasi dependensi di seluruh lingkungan TI.
Pemetaan dependensi dapat berfokus pada dependensi di dalam dan di antara aplikasi, tetapi juga dapat menjadi lebih besar, mencari dependensi dalam infrastruktur jaringan atau seluruh sistem dunia nyata, seperti jaringan listrik pintar. Pemetaan ketergantungan sering merupakan komponen praktik SCA, tetapi dapat dijalankan sendiri, terlepas dari solusi SCA.
Layanan penyewa tunggal yang dikelola sepenuhnya untuk mengembangkan dan menyediakan aplikasi Java.
Gunakan perangkat lunak dan alat bantu DevOps untuk membangun, menerapkan, dan mengelola aplikasi cloud native di berbagai perangkat dan lingkungan.
Pengembangan aplikasi cloud berarti membangun sekali, mengulangi dengan cepat, dan menerapkan di mana saja.
1.“IDC PlanScape: Validation of Open Source Software Sources”, Christopher Tozzi, IDC Planscape, Juli 2025.