Modern yazılım geliştirme süreçlerinde kod artık yalnızca derlenip çalıştırılan bir çıktı değil; sürekli değişen, sürekli büyüyen ve her değişiklikle birlikte yeni riskler üreten canlı bir varlıktır. Geliştiricinin yaptığı küçük bir kod değişikliği, eklediği masum görünen bir bağımlılık ya da alel acele açılmış bir pull request farkında olmadan büyük riskler doğurabilir. Bu yüzden güvenlikte ne kadar sola, yani geliştirme sürecinin başına kayıp orada önlemler alırsak, o kadar iyidir. Bu yazımızda Sonatype’ın SCM entegrasyonunu konuşacağız.
SCM (Source Control Management), geliştiricilerin kaynak kodda yapılan değişiklikleri yönetmelerini ve izlemelerini sağlayan yapıdır. VCS (Version Control System) olarak da bilinir. Kodun bir merkezde tutulmasını, sürüm kontrolünü, kod değişikliklerinin takibinin yapılmasını sağlar. Sonatype resmi dökümanında, SCM entegrasyonunu bankanın dışında değil de kasanın önünde bir güvenlik görevlisi görevlendirmeye benzetir. Bu anlamda erken aşamada önlem alınmasını sağlar.
Sonatype; GitHub, GitLab, Bitbucket, Azure gibi birçok SCM sistemiyle entegre olabilmektedir. Yazımızdaki Bitbucket (on-prem) üzerinden ilerleyeceğiz. Öncelikle Bitbucket üzerinden access token oluşturmalıyız. Görseldeki gibi en az project seviyesinde read, repository seviyesinde write yetkisi gerekmektedir.
Sonatype tarafında source control entegrasyon ayarları organizasyon seviyesinde yapılmaktadır. Farklı organizasyonlar için farklı entegrasyonlar yapılabilir. Örneğimizde Root Organization için yapıyoruz.
Burada kullanıcı adı ve token’imizi girdikten sonra uygulamaları çekeceğimiz organizasyona girip Import Applications demeliyiz.
Sonrasında bizden SCM sunucusunun URL’ini isteyecektir. Bunu girdikten sonra erişim ve yetki sorunumuz yoksa repoları görebiliriz.
Sonrasında repolarımız listeleniyor ve istediğimiz repoyu Sonatype taramalarına dahil edebiliyoruz.
SCM entegrasyonları için 2, daha doğrusu 3 farklı tarama tipi bulunmaktadır. Birincisi import eder etmez yapılan ilk taramadır. Sonatype bunu Instant Risk Profile olarak isimlendirmektedir (Import edilen repository’ler Sonatype sunucusuna çekilmektedir ve taramalar sunucudan tetiklenmektedir). İkincisi, default branch’i kontrol ettikten sonra (bu aralığın default değeri günde 1’dir, API üzerinden değiştirilebilmektedir) değişiklik varsa gerçekleştirilen periyodik taramadır. Buna Continuous Risk Profile denmektedir. Bunun yanı sıra, Continuous Risk Profile kapsamında olay tabanlı taramalar da gerçekleştirebilmektedir. Bu taramalar son 7 günde bir aktivite gerçekleşmediyse tetiklenmektedir. Edge case’ler için Continuous Risk Profile adresindeki örneklere göz atabilirsiniz.
SCM sistemi üzerinde (örneğimizde Bitbucket) repository ayarlarından aşağıdaki şekilde minimum successful builds ayarını enabled edersek, source stage’i için fail olarak verdiğimiz policy ayarları gerektiği durumda merge yapılmasını engelleyecektir.
Üçüncü tarama tipimiz, CLI veya API endpointi kullanılarak CI/CD pipeline’ları üzerinden veya manuel yapılan, stage’i source veya develop olarak belirlenmiş taramalardır. Örneğin Continuous Risk Profile’ı günde 2 defa olacak şekilde konfigüre etmiş olalım. Ancak hızlı bir şekilde merge yapmamız gerekiyor ve zafiyetli kod parçası giderilmiş olsun. Bu durumda iletişim tek taraflı olduğu için (Sonatype -> SCM) bir sonraki taramaya kadar SCM tarafında son build failed olarak kalacaktır. /api/v2/evaluation/applications/{appId}/sourceControlEvaluation API endpointini commit sonrası otomatize veya manuel kullanarak (stage’i source olarak vererek), Continuous Risk Profile ile yapılan günlük taramayı bir anlamda erkene çekip SCM tarafında build durumunun güncellenmesini sağlayabiliriz.
Bunun yanısıra, API endpointi veya CLI kullanarak develop stage’i için tarama tetikleyebiliriz. Bu taramaların raporları Sonatype üzerinde gözükmeyecektir ancak pipelinelar üzerinde develop için seçilmiş policy aksiyonlarının gerçekleşmesini sağlar. Sonatype, develop stage’inin feature branchleri için kullanılmasını önermektedir. Raporların Sonatype üzerinde gözükmemesi ise, feature branchlerinin raporlarının arayüz üzerinde karmaşa yaratmasını engelleyecektir.
Son olarak, Automated Source Control Feedback özelliklerinden bahsedebiliriz. Automated Source Control Feedback ile Sonatype, policy ihlallerini doğrudan SCM üzerinde geliştiricinin önüne getirir. Yeni pull requestlerde otomatik policy evaluation summary çalıştırarak build failed/passed olarak sonuçları gösterir. Daha önceden bahsettiğimiz üzere SCM üzerinden minimum successful builds ayarı enabled edilirse merge kırar. Bunun yanı sıra gerekli konfigürasyon yapılıp yetkiler tanımlandığında (hangi özellik için hangi yetki gerektiğine Source Control Configuration adresinden bakabilirsiniz) PR yorumu, line comment, otomatik PR gibi özellikler de mevcuttur.
