Masalah dan ruang lingkup
Platform ini melayani jutaan repositori. Sebuah repositori dapat mengirimkan lockfile, manifes citra, atau SBOM sementara feed kerentanan menambahkan, merevisi, atau menarik kembali catatan. Desain proses penyerapan (ingestion), pencocokan versi, siklus hidup peringatan, notifikasi, dan verifikasi remediasi. Dukung npm, PyPI, dan Maven; pemindaian kode, penggabungan patch otomatis, dan riset kerentanan manual berada di luar cakupan.
Hal yang dievaluasi pewawancara
Memisahkan antara “versi dependensi cocok dengan kerentanan” dan “peringatan memiliki siklus hidup”. Versi yang memahami ekosistem, dependensi langsung vs transitif, revisi feed, penarikan kembali (withdrawals), deduplikasi, pekerjaan yang dapat diputar ulang (replayable), idempotensi notifikasi, dan otorisasi tenant adalah sinyal-sinyal kuncinya. Hasil pemindaian adalah bukti untuk sebuah snapshot, bukan kebenaran permanen.
Pertanyaan klarifikasi
- Apakah setiap manifes dikunci ke versi pasti atau rentang yang diizinkan? Haruskah pencocokan menggunakan versi yang terselesaikan (resolved) atau deklarasi?
- Apakah paket transitif, pengembangan, lapisan kontainer, dan privat termasuk dalam cakupan?
- Bisakah sebuah feed menarik kembali, membuat alias, atau merevisi tingkat keparahan, dan snapshot historis mana yang dipertahankan?
- Apakah peringatan dicakup per cabang (branch), dan apa yang terjadi jika sebuah cabang dihapus?
- Saluran mana, durasi jeda (cooldown), dan tunda (snooze) tingkat organisasi apa saja yang diperlukan?
Kerangka jawaban 30 detik
“Saya akan mempertahankan snapshot manifes yang tidak dapat diubah (immutable), mengurai graf dependensi spesifik ekosistem, dan mencocokkan versi melalui rentang kerentanan yang terindeks. Hasilnya menjadi proyeksi peringatan idempoten dengan kunci repositori, komponen, kerentanan, dan snapshot bukti. Revisi feed memicu komputasi ulang secara bertahap. Penyerapan, pembaruan feed, dan notifikasi menggunakan antrean tahan lama yang dapat diputar ulang; notifikasi diagregasikan per organisasi dan membawa kunci idempotensi. Peringatan mempertahankan bukti, sementara commit baru dipindai ulang sebelum dapat ditandai telah diperbaiki. Rekonsiliasi, otorisasi, dan metrik kesegaran data membuat sistem dapat dijelaskan.”
Desain mendalam langkah demi langkah
Control plane menyimpan organisasi, repositori, cabang, dan kebijakan notifikasi. API penyerapan menerima manifes dengan hash commit, menulis objek asli dan metadata, lalu memancarkan manifest_received. Mengulang repositori, cabang, commit, dan digest manifes yang sama akan mengembalikan snapshot yang sudah ada. SBOM besar menggunakan unggahan multipart dan checksum; kuota per tenant melindungi parser.
Parser menormalkan nama dan versi sesuai dengan masing-masing ekosistem dan memperluas graf transitif yang terkunci. Sebuah snapshot mencatat koordinat komponen, jalur sumber, dan cakupan pengembangan atau produksi. Kegagalan penguraian mempertahankan file asli, lokasi kesalahan, dan status coba lagi; “tidak dapat mengurai” tidak boleh menjadi “tidak ada kerentanan”.
Penyerap feed menarik atau menerima delta dari sumber seperti OSV, memvalidasi skema, tanda tangan sumber, dan versi feed, lalu menyimpan ekosistem yang terpengaruh, nama paket, rentang versi, alias, tingkat keparahan, versi yang diperbaiki, stempel waktu, dan penanda penarikan. Pencocokan rentang menggunakan semantik ekosistem daripada pengurutan string. Indeks terbalik membuat pemrosesan komponen bervolume tinggi menjadi inkremental.
Sebuah peringatan mencakup alert_id, organisasi, repositori, cabang, koordinat komponen, ID kerentanan, snapshot bukti, status, waktu pertama kali dilihat, konfirmasi terbaru, commit perbaikan, dan versi aturan. Batasan unik pada (repository, branch, component, vulnerability_id, vulnerable_version) mencegah duplikasi; alias dinormalkan sebelum kunci ini dibuat. Status mencakup OPEN, FIXED, DISMISSED, dan REOPENED, dengan peristiwa audit untuk setiap transisi. Penarikan menghentikan notifikasi baru tetapi mempertahankan riwayat dan alasannya.
Notifikasi berada di luar transaksi pemindaian. Peristiwa peringatan masuk ke antrean yang dipartisi berdasarkan organisasi; agregator mengelompokkan peringatan serupa, menerapkan jeda (cooldown), dan memancarkan kunci notifikasi yang stabil. Adapter email, komentar code-host, dan obrolan masing-masing memiliki batas, coba lagi, dan tanda terima pengiriman; konsumen mendeduplikasi berdasarkan kunci. Penundaan (snooze) memiliki cakupan, masa kedaluwarsa, pemilik, dan alasan, sementara eskalasi keparahan dapat mengabaikan penundaan yang kedaluwarsa atau tidak valid.
Verifikasi remediasi menerima commit baru atau snapshot terjadwal, mengurai ulang graf saat ini, dan menerapkan aturan pencocokan yang sama. Peringatan hanya ditutup ketika snapshot cabang default saat ini tidak lagi cocok atau sebuah organisasi secara eksplisit menerima risiko tersebut. Versi perbaikan yang disarankan bukanlah bukti remediasi. Cabang yang dihapus menghasilkan peristiwa terminasi tanpa menghapus riwayat audit.
Daya tahan berasal dari peristiwa yang dapat diputar ulang dan rekonsiliasi. Bandingkan manifes yang disimpan dengan hasil penguraian, kecocokan, proyeksi peringatan, versi feed, notifikasi yang diharapkan, dan tanda terima adapter. Pantau latensi p95 dari manifes hingga peringatan, kegagalan penguraian, kelambatan feed, throughput pencocokan, tingkat duplikasi, propagasi penarikan, percobaan ulang notifikasi, dan hit penundaan. Suntikkan duplikasi antrean, crash selama revisi feed, indeks basi, batas waktu adapter, dan kegagalan pemulihan database.
Contoh jawaban berkualitas tinggi
“Saya akan menyimpan manifes asli beserta hash commit-nya, mengurai graf dependensi spesifik ekosistem, dan mempertahankan indeks terbalik atas rentang kerentanan. Pencocokan menghasilkan peringatan idempoten dengan snapshot bukti dan versi aturan; kunci unik mencegah duplikasi peringatan untuk repositori, komponen, dan kerentanan yang sama. Penarikan menghentikan notifikasi baru tetapi tetap menyimpan bukti historis.
Peristiwa notifikasi dipisahkan dari pemindaian melalui antrean tahan lama, diagregasikan per organisasi, dan dicoba ulang dengan kunci yang stabil. Penundaan dapat kedaluwarsa dan diaudit; eskalasi keparahan dapat membatalkannya. Setiap commit baru dipindai ulang, dan hanya kondisi benar-benar tidak cocok yang menandai peringatan telah diperbaiki. Rekonsiliasi memeriksa batasan manifes, feed, peringatan, dan notifikasi, sementara metrik mencakup visibilitas, propagasi penarikan, backlog, duplikasi, dan kegagalan adapter. Pendekatan ini dapat diskalakan hingga jutaan manifes harian dan menjelaskan mengapa sebuah peringatan muncul, berubah, atau dibuka kembali.”
Kesalahan umum
- Hanya membandingkan nama paket → semantik ekosistem dan rentang menghasilkan kecocokan palsu → gunakan koordinat ekosistem dan perbandingan rentang.
- Menganggap kegagalan penguraian sebagai aman → lockfile yang rusak secara diam-diam menyembunyikan risiko → pertahankan bukti kegagalan dan coba lagi.
- Membuat peringatan baru pada setiap pemindaian → satu masalah membanjiri pengembang → buat kunci peringatan yang idempoten.
- Menimpa revisi feed → riwayat keparahan dan penarikan menjadi tidak dapat dijelaskan → buat versi sumber dan pertahankan bukti.
- Mengirim notifikasi di dalam proses pemindaian → saluran yang lambat memblokir deteksi → pisahkan dengan peristiwa tahan lama.
- Menutup berdasarkan saran versi perbaikan → commit sebenarnya mungkin masih cocok → pindai ulang commit saat ini.
- Mengizinkan penundaan permanen → risiko kehilangan penanggung jawab → wajibkan kedaluwarsa, alasan, dan pengingat.
- Membuat peringatan terpisah untuk alias → satu kerentanan muncul berkali-kali → normalkan alias terlebih dahulu.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Bagaimana Anda menangani rentang terdampak yang direvisi?
Beri versi pada pembaruan feed, hitung kumpulan komponen yang terpengaruh, dan hitung ulang hanya snapshot yang cocok. Simpan versi aturan dan bukti pada setiap peringatan; catat setiap perubahan status.
Pertanyaan lanjutan 2: Mengapa mempertahankan manifes asli?
Parser dan aturan terus berkembang. File asli mendukung pemutaran ulang di bawah aturan baru dan membuktikan commit mana yang menghasilkan peringatan tersebut.
Pertanyaan lanjutan 3: Bagaimana Anda mengurangi kelelahan akibat notifikasi (notification fatigue)?
Agregasikan berdasarkan organisasi, kerentanan, dan komponen dengan jeda (cooldown) dan ringkasan. Penundaan dibatasi cakupannya, memiliki masa kedaluwarsa, dan diaudit; eskalasi keparahan dapat langsung mengirim notifikasi.
Pertanyaan lanjutan 4: Bagaimana Anda menghindari kesalahan pada dependensi transitif?
Gunakan graf yang terkunci, pertahankan jalur induk dan cakupan dependensi, serta tampilkan “unknown” ketika tidak ada lockfile yang dapat menetapkan versi terselesaikan.
Pertanyaan lanjutan 5: Bagaimana Anda memodelkan cabang (branch)?
Perlakukan cabang sebagai dimensi snapshot dan sertakan dalam kunci peringatan. Penghapusan mengakhiri pekerjaan di masa mendatang tetapi tidak menghapus riwayat audit.
Pertanyaan lanjutan 6: Bagaimana jika feed kerentanan tidak tersedia?
Gunakan versi terverifikasi terakhir dengan peringatan kesegaran data yang eksplisit; jangan mengklaim hasil bersih. Lakukan backoff, failover ke cermin (mirror), dan putar ulang delta versi setelah pemulihan.