Ketakutan dan Membenci DevSecOps

Kami memiliki 2 penganalisa kode, 4 alat untuk pengujian dinamis, kerajinan tangan kami sendiri dan 250 skrip. Bukan berarti semua ini diperlukan dalam proses saat ini, tetapi karena saya mulai menerapkan DevSecOps, maka kita harus pergi ke akhir.



Sumber Penulis karakter: Justin Royland dan Dan Harmon.

Apa itu SecDevOps? Bagaimana dengan DevSecOps? Apa perbedaannya? Keamanan Aplikasi - tentang apa ini? Mengapa pendekatan klasik tidak berfungsi lagi? Yury Shabalin dari Swordfish Security tahu jawaban untuk semua pertanyaan ini . Yuri akan menjawab semuanya secara terperinci dan menganalisis masalah beralih dari model Keamanan Aplikasi klasik ke proses DevSecOps: bagaimana cara mendekati integrasi proses pengembangan aman ke dalam proses DevOps dan tidak memecahkan apa pun, bagaimana melewati tahap utama pengujian keamanan, alat apa yang dapat digunakan, apa mereka berbeda dan cara mengkonfigurasinya dengan benar untuk menghindari jebakan.


Tentang pembicara: Yuri Shabalin - Kepala Arsitek Keamanan di Swordfish Security . Dia bertanggung jawab atas implementasi SSDL, untuk integrasi umum alat analisis aplikasi ke dalam pengembangan tunggal dan ekosistem pengujian. 7 tahun pengalaman dalam keamanan informasi. Dia bekerja di Alfa Bank, Sberbank dan Positive Technologies, yang mengembangkan perangkat lunak dan menyediakan layanan. Pembicara konferensi internasional ZerONights, PHDays, RISSPA, OWASP.

Keamanan Aplikasi: tentang apa ini?

Keamanan Aplikasi adalah bagian keamanan yang bertanggung jawab atas keamanan aplikasi. Ini tidak berlaku untuk infrastruktur atau keamanan jaringan, yaitu, apa yang kami tulis dan apa yang sedang dikerjakan pengembang - ini adalah kelemahan dan kerentanan aplikasi itu sendiri.

Arah SDL atau SDLC - Daur hidup pengembangan keamanan - dikembangkan oleh Microsoft. Diagram menunjukkan model SDLC kanonik, tugas utamanya adalah partisipasi keamanan pada setiap tahap pengembangan, dari persyaratan, untuk melepaskan dan melepaskan ke produksi. Microsoft menyadari bahwa ada terlalu banyak bug dalam prom, ada lebih banyak bug dan sesuatu yang perlu dilakukan, dan mereka mengusulkan pendekatan ini, yang menjadi kanonik.



Keamanan Aplikasi dan SSDL tidak ditujukan untuk mendeteksi kerentanan, seperti yang diyakini umum, tetapi untuk mencegah terjadinya mereka. Seiring waktu, pendekatan kanonik dari Microsoft ditingkatkan, dikembangkan, dan perendaman yang lebih dalam muncul di dalamnya.



Canonical SDLC sangat terperinci dalam berbagai metodologi - OpenSAMM, BSIMM, OWASP. Metodologinya berbeda, tetapi umumnya serupa.

Membangun Keamanan Dalam Model Kedewasaan

Saya paling suka BSIMM - Membangun Keamanan Dalam Maturitas Model . Dasar dari metodologi ini adalah pemisahan proses Keamanan Aplikasi menjadi 4 domain: Tata Kelola, Intelijen, Touchpoints dan Penerapan SSDL. Setiap domain memiliki 12 praktik, yang direpresentasikan sebagai 112 aktivitas.



Masing-masing dari 112 kegiatan memiliki 3 tingkat kematangan : dasar, menengah dan lanjutan. Ke-12 praktik tersebut dapat dipelajari dalam bagian, pilih hal-hal penting untuk Anda, pahami cara mengimplementasikannya dan secara bertahap menambahkan elemen, misalnya, analisis kode statis dan dinamis atau tinjauan kode. Anda melukis rencana dan bekerja dengan tenang sebagai bagian dari implementasi kegiatan yang dipilih.

Mengapa DevSecOps

DevOps adalah proses besar umum di mana Anda perlu menjaga keamanan.

Awalnya, DevOps menyertakan pemeriksaan keamanan. Dalam praktiknya, jumlah tim keamanan jauh lebih kecil dari sekarang, dan mereka bertindak bukan sebagai peserta dalam proses, tetapi sebagai badan kontrol dan pengawasan yang menetapkan persyaratan untuk itu dan memeriksa kualitas produk pada akhir rilis. Ini adalah pendekatan klasik di mana tim keamanan berada di belakang tembok dari pengembangan dan tidak terlibat dalam proses.



Masalah utama adalah bahwa keamanan informasi terpisah dari pengembangan. Biasanya ini adalah sejenis sirkuit IB dan mengandung 2-3 alat besar dan mahal. Setiap enam bulan sekali, kode sumber atau aplikasi tiba, yang perlu diperiksa, dan sekali setahun diproduksi. Ini semua mengarah pada fakta bahwa tenggat waktu untuk memasuki prom ditunda, dan sejumlah besar kerentanan dari alat otomatis jatuh pada pengembang. Semua ini tidak dapat dibongkar dan diperbaiki, karena hasil untuk enam bulan sebelumnya belum disortir, dan ini adalah kumpulan baru.

Dalam proses perusahaan kami, kami melihat bahwa keamanan di semua bidang dan industri memahami bahwa inilah saatnya untuk menarik diri dan berputar dengan pengembangan dalam satu roda - dalam Agile . Paradigma DevSecOps cocok dengan metodologi pengembangan tangkas, pada implementasi, dukungan, dan partisipasi dalam setiap rilis dan iterasi.

Transisi ke DevSecOps

Kata paling penting dalam Siklus Hidup Pengembangan Keamanan adalah "proses . " Anda harus memahami ini sebelum berpikir tentang membeli alat.

Memasukkan alat ke dalam proses DevOps saja tidak cukup - interaksi dan pemahaman di antara para peserta proses itu penting.

Lebih penting daripada orang, bukan alat

Seringkali, perencanaan proses pengembangan yang aman dimulai dengan pemilihan dan pembelian alat, dan berakhir dengan upaya untuk mengintegrasikan alat ke dalam proses saat ini, yang tetap merupakan upaya. Ini menimbulkan konsekuensi yang menyedihkan, karena semua alat memiliki karakteristik dan keterbatasannya sendiri.

Kasus umum ketika departemen keamanan memilih alat yang bagus dan mahal, dengan fitur-fitur hebat, dan mendatangi pengembang - untuk menanamkan dalam proses. Tapi itu tidak berhasil - prosesnya terstruktur sehingga keterbatasan alat yang sudah dibeli tidak sesuai dengan paradigma saat ini.

Pertama, jelaskan hasil apa yang Anda inginkan dan bagaimana proses akan terlihat. Ini akan membantu untuk memahami peran alat dan keamanan dalam proses.

Mulailah dengan apa yang sudah digunakan

Sebelum membeli alat mahal, lihat apa yang sudah Anda miliki. Setiap perusahaan memiliki persyaratan keamanan untuk pengembangan, ada cek, pentest - mengapa tidak mengubah semua ini menjadi bentuk yang mudah dimengerti dan nyaman untuk semua orang?

Biasanya, persyaratannya adalah kertas Talmud, yang terletak di rak. Ada kasus ketika kami datang ke perusahaan untuk melihat proses dan meminta untuk menunjukkan persyaratan keamanan untuk perangkat lunak. Spesialis yang melakukan ini sedang mencari waktu yang lama:

- Sekarang, di suatu tempat di catatan ada cara di mana dokumen ini berada.

Hasilnya, kami menerima dokumen itu seminggu kemudian.

Untuk persyaratan, pemeriksaan, dan hal-hal lain, buat halaman, misalnya, tentang Confluence - ini nyaman untuk semua orang.

Lebih mudah untuk memformat ulang apa yang sudah ada dan menggunakannya untuk memulai.

Gunakan Security Champions

Biasanya, di perusahaan menengah untuk 100-200 pengembang, satu petugas keamanan bekerja, yang melakukan beberapa fungsi, dan secara fisik tidak punya waktu untuk memeriksa semuanya. Bahkan jika dia mencoba yang terbaik, dia sendiri tidak akan memeriksa semua kode yang dihasilkan pengembangan. Untuk kasus seperti itu, konsep telah dikembangkan - Security Champion .

Security Champion adalah orang dalam tim pengembangan yang tertarik dengan keamanan produk Anda.

Juara Keamanan adalah titik masuk ke tim pengembangan dan penginjil keamanan semuanya digabung menjadi satu.

Biasanya, ketika brankas datang ke tim pengembangan dan menunjukkan kesalahan dalam kode, itu menerima jawaban yang mengejutkan:

"Kamu siapa?" Saya melihat Anda untuk pertama kalinya. Saya baik-baik saja - teman senior saya di ulasan kode yang ditetapkan "berlaku", kita melangkah lebih jauh!

Ini adalah situasi yang khas, karena ada lebih banyak kepercayaan pada rekan tim senior atau hanya, dengan siapa pengembang terus berinteraksi dalam pekerjaan dan dalam tinjauan kode. Jika, bukannya penjaga keamanan, Juara Keamanan menunjukkan kesalahan dan konsekuensi, maka kata-katanya akan lebih berat.

Juga, pengembang tahu kode mereka lebih baik daripada penyedia keamanan. Untuk seseorang yang memiliki setidaknya 5 proyek dalam alat analisis statis, biasanya sulit untuk mengingat semua nuansa. Security Champions tahu produk mereka: apa yang berinteraksi dengan apa dan apa yang harus dilihat di tempat pertama - mereka lebih efektif.

Jadi pikirkan tentang menerapkan Security Champion dan memperluas pengaruh tim keamanan. Bagi sang juara sendiri, ini juga berguna: pengembangan profesional di bidang baru, memperluas cakrawala teknis, meningkatkan keterampilan teknis, manajerial dan kepemimpinan, meningkatkan nilai pasar. Ini adalah beberapa elemen dari rekayasa sosial, "mata" Anda dalam tim pengembangan.

Langkah-langkah pengujian

Paradigma 20 hingga 80 mengatakan bahwa 20% dari upaya menghasilkan 80% dari hasilnya. 20% ini adalah praktik analisis aplikasi yang dapat dan harus otomatis. Contoh kegiatan tersebut adalah analisis statis - SAST , analisis dinamis - DAST, dan kontrol Open Source . Saya akan memberi tahu Anda lebih banyak tentang kegiatan, serta tentang alat, fitur apa yang biasanya kita temui ketika diperkenalkan ke dalam proses, dan bagaimana melakukannya dengan benar.

Masalah utama alat

Saya akan menyoroti masalah yang relevan untuk semua alat yang membutuhkan perhatian. Saya akan menganalisisnya secara lebih detail agar tidak terulang lagi.

Analisis lama. Jika diperlukan 30 menit untuk menyelesaikan semua pengujian dan perakitan dari komitmen untuk menuju ke prod, maka pemeriksaan keamanan informasi akan memakan waktu sehari. Jadi tidak ada yang akan memperlambat prosesnya. Pertimbangkan fitur ini dan buat kesimpulan.

Tinggi Palsu Negatif atau Palsu Positif. Semua produk berbeda, semua orang menggunakan kerangka kerja yang berbeda dan gaya penulisan kode mereka sendiri. Pada basis kode dan teknologi yang berbeda, alat dapat menunjukkan tingkat False Negative dan False Positive yang berbeda. Karena itu, lihat apa yang sebenarnya ada di perusahaan Anda dan untuk aplikasi Anda akan menunjukkan hasil yang baik dan dapat diandalkan.

Tidak ada integrasi dengan alat yang ada . Lihatlah alat-alat dalam hal integrasi sehingga Anda sudah menggunakan. Misalnya, jika Anda memiliki Jenkins atau TeamCity, periksa integrasi alat dengan perangkat lunak ini, dan bukan dengan GitLab CI, yang tidak Anda gunakan.

Tidak adanya atau kompleksitas kustomisasi yang berlebihan. Jika alat tidak memiliki API, lalu mengapa itu diperlukan? Segala sesuatu yang dapat dilakukan di antarmuka harus dapat diakses melalui API. Idealnya, alat harus memiliki kemampuan untuk menyesuaikan pemeriksaan.

Tidak ada pengembangan produk roadmap. Pengembangan tidak berhenti, kami selalu menggunakan kerangka kerja dan fungsi baru, menulis ulang kode lama ke dalam bahasa baru. Kami ingin memastikan bahwa alat yang kami beli akan mendukung kerangka kerja dan teknologi baru. Oleh karena itu, penting untuk mengetahui bahwa produk memiliki Roadmap pengembangan nyata dan tepat.

Fitur proses

Selain fitur alat, pertimbangkan fitur proses pengembangan. Misalnya, mengganggu pembangunan adalah kesalahan umum. Mari kita lihat fitur apa yang harus dipertimbangkan dan apa yang harus diperhatikan oleh tim keamanan.

Agar tidak mengganggu tanggal pengembangan dan rilis, buat aturan yang berbeda dan show stop yang berbeda - kriteria untuk menghentikan proses pembangunan di hadapan kerentanan - untuk lingkungan yang berbeda . Sebagai contoh, kami memahami bahwa cabang saat ini pergi ke stand pengembangan atau UAT, jadi kami tidak berhenti dan tidak mengatakan:

- Anda memiliki kerentanan di sini, Anda tidak akan melangkah lebih jauh!

Pada titik ini, penting untuk memberi tahu pengembang bahwa ada masalah keamanan yang perlu diperhatikan.

Kehadiran kerentanan bukanlah halangan untuk pengujian lebih lanjut : manual, integrasi, atau manual. Di sisi lain, kita perlu entah bagaimana meningkatkan keamanan produk, dan agar pengembang tidak lupa tentang apa yang mereka temukan aman. Oleh karena itu, kadang-kadang kita melakukan ini: di stand, ketika diluncurkan ke lingkungan pengembangan, kami hanya memberi tahu pengembangan:

- Guys, Anda punya masalah, harap perhatikan mereka.

Pada tahap UAT, kami sekali lagi menunjukkan peringatan tentang kerentanan, dan pada tahap keluar di prom kami mengatakan:

- Guys, kami telah memperingatkan beberapa kali, Anda tidak melakukan apa-apa - kami tidak akan membiarkan Anda keluar dengan ini.

Jika kita berbicara tentang kode dan dinamika, kita perlu menunjukkan dan memperingatkan tentang kerentanan hanya fitur dan kode yang baru saja ditulis dalam fitur ini. Jika pengembang memindahkan tombol 3 piksel dan kami memberitahunya bahwa ia memiliki injeksi SQL di sana dan oleh karena itu perlu segera diperbaiki, ini salah. Lihatlah hanya apa yang tertulis sekarang dan perubahan yang terjadi pada aplikasi.

Misalkan kita memiliki cacat fungsional tertentu - cara aplikasi seharusnya tidak berfungsi: uang tidak ditransfer, ketika Anda mengklik tombol, tidak ada transisi ke halaman berikutnya atau produk tidak dimuat. Cacat keamanan adalah cacat yang sama, tetapi tidak dalam konteks aplikasi, tetapi keamanan.

Tidak semua masalah kualitas perangkat lunak adalah masalah keamanan. Tetapi semua masalah keamanan terkait dengan kualitas perangkat lunak. Sherif Mansour, Expedia.

Karena semua kerentanan adalah cacat yang sama, mereka harus ditempatkan di tempat yang sama dengan semua cacat pembangunan. Jadi lupakan laporan dan PDF menakutkan yang tidak ada yang membaca.



Ketika saya bekerja untuk perusahaan pengembangan, saya mendapat laporan dari alat analisis statis. Saya membukanya, ngeri, membuat kopi, membalik-balik halaman 350, menutupnya dan terus bekerja lebih jauh. Laporan besar adalah laporan mati . Biasanya mereka tidak pergi ke mana-mana, surat dihapus, dilupakan, hilang atau bisnis mengatakan bahwa itu mengambil risiko.

Apa yang harus dilakukan Kami hanya mengubah cacat dikonfirmasi yang kami temukan ke dalam bentuk yang nyaman untuk pengembangan, misalnya, menambahkannya ke jaminan simpanan di Jira. Kami memprioritaskan dan menghilangkan cacat dalam urutan prioritas bersama dengan cacat fungsional dan cacat pengujian.

Analisis Statis - SAST

Ini adalah analisis kode untuk kerentanan , tetapi tidak sama dengan SonarQube. Kami memeriksa tidak hanya berdasarkan pola atau gaya. Dalam analisis, sejumlah pendekatan digunakan: di pohon kerentanan, di DataFlow , dalam analisis file konfigurasi. Ini semua terkait langsung dengan kode.

Keuntungan dari pendekatan : mengidentifikasi kerentanan dalam kode pada tahap awal pengembangan , ketika tidak ada dudukan dan alat jadi, dan kemungkinan pemindaian tambahan : pemindaian bagian kode yang telah berubah, dan hanya fitur yang kami lakukan sekarang, yang mengurangi waktu pemindaian.

Kontra - ini adalah kurangnya dukungan untuk bahasa yang diperlukan.

Integrasi yang diperlukan yang harus ada dalam alat, menurut pendapat subjektif saya:

• Alat integrasi: Jenkins, TeamCity dan Gitlab CI.
  
• Lingkungan Pengembangan: Intellij IDEA, Visual Studio. Lebih mudah bagi pengembang untuk tidak naik ke antarmuka yang tidak dapat dipahami yang masih perlu diingat, tetapi tepat di tempat kerja di lingkungan pengembangannya sendiri untuk melihat semua integrasi dan kerentanan yang diperlukan yang ia temukan.
  
• Ulasan kode: SonarQube dan ulasan manual.
  
• Pelacak Cacat: Jira dan Bugzilla.
  

Gambar menunjukkan beberapa perwakilan terbaik dari analisis statis.



Bukan alat yang penting, tetapi prosesnya, jadi ada solusi Open Source yang juga baik untuk menjalankan proses.



SAST Open Source tidak akan menemukan sejumlah besar kerentanan atau DataFlow yang kompleks, tetapi Anda dapat dan harus menggunakannya saat membangun suatu proses. Mereka membantu untuk memahami bagaimana proses akan dibangun, siapa yang akan menanggapi bug, siapa yang melaporkan, siapa yang melaporkan. Jika Anda ingin melakukan tahap awal membangun keamanan kode Anda, gunakan solusi Open Source.

Bagaimana ini bisa diintegrasikan jika Anda berada di awal jalan, Anda tidak punya apa-apa: baik CI, maupun Jenkins, maupun TeamCity? Pertimbangkan integrasi ke dalam proses.

Integrasi CVS

Jika Anda memiliki Bitbucket atau GitLab, Anda dapat melakukan integrasi pada level Sistem Versi Bersamaan .

Berdasarkan acara - tarik permintaan, komit. Anda memindai kode dan menunjukkan dalam status build bahwa pemeriksaan keamanan telah lulus atau gagal.

Umpan balik. Tentu saja, umpan balik selalu dibutuhkan. Jika Anda hanya tampil di sisi keamanan, taruh di dalam kotak dan tidak memberi tahu siapa pun tentang hal itu, lalu membuang banyak bug pada akhir bulan - ini tidak benar atau tidak baik.

Integrasi dengan tinjauan kode

Sekali, di sejumlah proyek penting, kami menetapkan resensi default dari pengguna teknis AppSec. Bergantung pada apakah kesalahan terdeteksi dalam kode baru atau jika tidak ada kesalahan, peninjau menempatkan status pada "menerima" atau "perlu bekerja" pada permintaan tarik - apakah semuanya OK, atau Anda perlu memperbaiki dan menautkan ke apa yang harus diselesaikan. Untuk integrasi dengan versi yang masuk ke prod, kami memiliki larangan penggabungan yang diaktifkan jika tes IB tidak lulus. Kami memasukkan ini dalam tinjauan kode manual, dan peserta lain dalam proses melihat status keamanan untuk proses khusus ini.

Integrasi SonarQube

Banyak yang memiliki gerbang kualitas untuk kualitas kode. Hal yang sama di sini - Anda dapat membuat gerbang yang sama hanya untuk alat SAST. Akan ada antarmuka yang sama, gerbang kualitas yang sama, hanya saja akan disebut gerbang keamanan . Dan juga, jika Anda memiliki proses menggunakan SonarQube, Anda dapat dengan mudah mengintegrasikan semuanya di sana.

Integrasi CI

Di sini juga, semuanya cukup sederhana:

• Pada tingkat yang sama dengan uji otomatis, tes unit.
  
• Pemisahan dengan tahapan perkembangan : dev, test, prod. Rangkaian aturan yang berbeda dapat dimasukkan, atau kondisi gagal yang berbeda: hentikan perakitan, jangan hentikan perakitan.
  
• Mulai sinkron / asinkron . Kami sedang menunggu akhir dari tes keamanan atau tidak menunggu. Artinya, kami baru meluncurkannya dan melanjutkan, dan kemudian kami menerima status bahwa semuanya baik atau buruk.
  

Semuanya ada di dunia pink sempurna. Dalam kehidupan nyata, ini bukan, tapi kami berusaha. Hasil pemeriksaan keamanan harus serupa dengan hasil tes unit.

Misalnya, kami mengambil proyek besar dan memutuskan bahwa sekarang kami akan memindai dengan SAST'om - OK. Kami mendorong proyek ini ke SAST, itu memberi kami 20.000 kerentanan, dan dengan keputusan yang kuat, kami menerima bahwa semuanya baik-baik saja. 20.000 kerentanan adalah tugas teknis kami. Kami akan meletakkan utang dalam kotak, dan kami perlahan-lahan akan menyapu dan mulai bug di pelacak cacat. Kami menyewa perusahaan, mengerjakan semuanya sendiri atau Security Champion akan membantu kami - dan hutang teknis kami akan berkurang.

Dan semua kerentanan yang baru muncul dalam kode baru harus diperbaiki serta kesalahan dalam unit atau dalam autotest. Secara relatif, pertemuan dimulai, pergi, dua tes dan dua tes keamanan jatuh. OK - mereka pergi, melihat apa yang terjadi, mengoreksi satu hal, mengoreksi yang kedua, mengusirnya di waktu berikutnya - semuanya baik-baik saja, tidak ada kerentanan baru, tes tidak gagal. Jika tugas ini lebih dalam dan Anda harus memahaminya dengan baik, atau memperbaiki kerentanan memengaruhi lapisan besar dari apa yang ada di balik tudung: mereka membawa bug ke pelacak cacat, prioritas dan diperbaiki. Sayangnya, dunia tidak sempurna dan tes terkadang gagal.

Contoh dari gerbang keamanan adalah analog dari gerbang kualitas, dengan keberadaan dan jumlah kerentanan dalam kode.

Kami berintegrasi dengan SonarQube - plugin terinstal, semuanya sangat nyaman dan keren.

Integrasi lingkungan pengembangan

Kemampuan Integrasi:

• Memulai pemindaian dari lingkungan pengembangan sebelum melakukan.
  
• Lihat hasil.
  
• Analisis hasil.
  
• Sinkronisasi dengan server.
  

Sepertinya mendapatkan hasil dari server.



Di lingkungan pengembangan IDEA Intellij kami , item tambahan hanya muncul yang melaporkan bahwa kerentanan tersebut terdeteksi selama pemindaian. Anda dapat segera mengedit kode, lihat rekomendasi dan Grafik Alir . Ini semua terletak di tempat kerja pengembang, yang sangat nyaman - Anda tidak harus pergi ke seluruh tautan dan menonton sesuatu yang ekstra.

Sumber terbuka

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, Open Source.


— Dependency-Check OWASP. , , . , on-premise, . , , , , .

, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .

CI . , - : dev, test, prod. , , , - «critical» -, .

: Nexus JFrog.

. , , . , CVS.

CD. , — . .



Public Component Repositories — , . , trusted components. , . , , . , - , — .

• build' , , .
  
• trusted components.
  
• : war, jar, DL Docker- , .
  
• , : .
  

— DAST

, . . -, , , , : , , , , .

Open Source. DAST , Open Source , «» :

— , , .

, , — .

• \ .
  
• .
  
• .
  
• .
  
• .
  

, AppScan: , 3 — - ! , , AppScan — -, , , mailform -. :

— , ?! , !

. , -, . — , .

, . 10-15 , , , , .

, .



Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .

: .

mock-, — , .

• — .
  
• .
  
• — .
  

, . — , , OpenSource, - , , Waf .

.

, , , , -.

. , , . , , . , .



API, , , , — AppSec , .

, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .

— , . , , . DevSecOps, SecDevOps, .

, : , , , , . — . — .

.

, . , — . - , . , .

— Security Champions .

, , , - — . pilih alat berdasarkan persyaratan proses Anda . Jangan melihat apa yang dikatakan masyarakat bahwa alat ini buruk dan yang ini bagus. Mungkin itu kebalikan dari produk Anda.

Persyaratan Alat.

• Positif Palsu Rendah.
  
• Waktu analisis yang memadai.
  
• Kemudahan penggunaan.
  
• Ketersediaan integrasi.
  
• Memahami Pengembangan Produk Roadmap.
  
• Kemampuan untuk menyesuaikan alat.
  

Laporan Yuri dipilih sebagai salah satu yang terbaik di DevOpsConf 2018. Untuk berkenalan dengan ide-ide yang lebih menarik dan kasus-kasus praktis, datang ke Skolkovo pada 27 dan 28 Mei di DevOpsConf sebagai bagian dari festival RIT ++ . Lebih baik lagi, jika Anda siap untuk membagikan pengalaman Anda, maka ajukan permohonan laporan paling lambat 21 April.