Güvenli bir GitHub deposunun bakımı

Tamamlandı

Burada, GitHub depo yöneticilerinin kullanabileceği temel güvenlik araçlarından ve tekniklerinden bazılarını ele aacağız.

Not Alın

Aşağıdaki içerik, güvenli kod yazmanın temellerini değil, gitHub deposunda kullanılacak önemli güvenlik konularını, araçları ve özellikleri kapsar.

Güvenli bir geliştirme stratejisinin önemi

Uygulama güvenliği önemlidir. Haber hizmetleri sıklıkla bir şirketin sistemlerinin ve çalınan özel şirket ve müşteri verilerinin ihlal edilmesiyle ilgili hikayeler taşır.

Peki, güvenli bir geliştirme stratejisi planlarken düşünmem gereken sorunlar nelerdir? Açıkçası, bilgileri erişimi olmaması gereken kişilere ifşa edilmekten korumamız gerekir, ancak daha da önemlisi, bilgilerin yalnızca uygun olduğunda değiştirildiğinden veya yok edildiğinden emin olmamız gerekir.

Verilere kimlerin eriştiğini doğru şekilde doğruladığımızdan ve bunu yapmak için doğru izinlere sahip olduklarından emin olmamız gerekir. Geçmiş veya arşiv verileri veya günlükler aracılığıyla bir sorun olduğunda kanıt bulabilmeliyiz.

Güvenli uygulamalar oluşturmanın ve dağıtmanın birçok yönü vardır. Dikkate alınması gereken üç şey şunlardır:

• genel bir bilgi sorunu vardır: Birçok geliştirici ve diğer personel, güvenliği anladığını varsayar ancak anlamaz. Siber güvenlik sürekli gelişen bir disiplindir. Devam eden bir eğitim ve öğretim programı esastır.

• Kodun doğru ve güvenli bir şekilde oluşturulması: Kodun doğru oluşturulduğundan ve gerekli özellikleri güvenli bir şekilde uyguladığından emin olmamız gerekir. Özelliklerin güvenlik göz önünde bulundurularak tasarlandığından da emin olmamız gerekir.

• Uygulamalarkurallar ve düzenlemelere uymalıdır: Kodun gerekli kural ve düzenlemelere uygun olduğundan emin olmamız gerekir. Kodu oluştururken uyumluluğu test edip dağıtımdan sonra bile düzenli aralıklarla yeniden test etmeliyiz.

Her adımda güvenlik

Güvenlik, bir uygulamaya veya sisteme daha sonra ekleyebileceğiniz bir şey değildir. Güvenli geliştirme, yazılım geliştirme yaşam döngüsünün her aşamasının bir parçası olmalıdır. Bu kavram, kritik uygulamalar ve hassas veya çok gizli bilgileri işleyen uygulamalar için daha da önemlidir.

Uygulamada, ekipleri geliştirdikleri işlemlerden sorumlu tutmak için süreçlerin sola kayması veya geliştirme yaşam döngüsünde daha önce tamamlanmasıgerekir. Dağıtım zamanındaki son bir geçitten önceki bir adıma geçildiğinde daha az hata yapılır ve geliştiriciler daha hızlı hareket edebilir.

Uygulama güvenliği kavramları geçmişte geliştiriciler için bir odak noktası değildi. Eğitim ve öğretim sorunlarının dışında, kuruluşlarının özelliklerin hızlı geliştirilmesini vurguladığı içindir.

Ancak DevOps uygulamalarının kullanıma sunulmasıyla birlikte, güvenlik testlerinin işlem hattıyla tümleştirilmesi daha kolaydır. Güvenlik uzmanları tarafından gerçekleştirilen bir görev yerine, güvenlik testi günlük teslim süreçlerinin bir parçası olmalıdır.

Genel olarak, yeniden çalışma zamanı dikkate alındığında geliştirme yaşam döngüsünün önceki bölümlerinde DevOps uygulamalarınıza güvenlik eklenmesi, geliştirme ekiplerinin sorunları daha önce yakalamasına olanak tanır. Sorunları daha önce yakalamak, kaliteli yazılım geliştirmek için gereken genel süreyi azaltabilir.

Sola kaydırma bir işlem değişikliğidir, ancak tek bir denetim veya belirli bir araç değildir. Tüm güvenliğinizi geliştirici odaklı hale getirmek ve geliştiricilere bulundukları yerde güvenlik geri bildirimi vermekle ilgili.

Güvenlik sekmesi özellikleri

GitHub, depolarda ve kuruluşlarda verilerin güvenliğini sağlamaya yardımcı olan güvenlik özellikleri sunar. Güvenlik sekmesini bulmak için:

1. GitHub.com deponun ana sayfasına gidin.

2. Depo adının altında Güvenliköğesini seçin.

Deponuzda ve kod tabanınızda güvenlik açıklarını önlemeye yardımcı olmak için Güvenlik sekmesinde GitHub iş akışınıza özellikler ekleyebilirsiniz. Bu özellikler şunlardır:

• Güvenlik ilkeleri, deponuza bir SECURITY.md dosyası ekleyerek projenizdeki bir güvenlik açığının nasıl bildirileceğini belirtmenize olanak sağlayan.
• Dependabot uyarıları, GitHub deponuzun savunmasız bir bağımlılık veya kötü amaçlı yazılım kullandığını algıladığında sizi bilgilendirir.
• Güvenlik önerileri, deponuzdaki güvenlik açıkları hakkındaki bilgileri özel olarak tartışmak, düzeltmek ve yayımlamak için kullanabileceğiniz.
• Kodunuzdaki güvenlik açıklarını ve hataları bulmanıza, önceliklendirmenize ve düzeltmenize yardımcı olan kod tarama .

Daha fazla bilgi için bkz. GitHub güvenlik özellikleri.

Not

Kötü amaçlı yazılımlara yönelik Dependabot uyarı önerileri şu anda beta aşamasındadır ve değiştirilebilir. Yalnızca GitHub tarafından gözden geçirilmiş olan öneriler Dependabot uyarılarını tetikler.

Şimdi bu özelliklerden bazılarını keşfedecek ve yazılım geliştirme yaşam döngüsünün tüm aşamalarında güvenlik ve operasyonel sorumlulukları dağıtmanın yollarını öğreneceğiz.

güvenlik ilkesini SECURITY.md ile iletme

GitHub'ın topluluk avantajları önemli olsa da potansiyel riskler de taşır. Herkesin genel olarak hata düzeltmeleri önerebileceği gerçeği belirli sorumluluklarla birlikte gelir. En önemlisi, temel alınan hataların düzeltilmesinden önce güvenlik açıklarına yol açabilecek bilgilerin sorumlu bir şekilde açıklanmasıdır. Güvenlik sorunlarını bildirmek veya gidermek isteyen geliştiriciler, endişelerini sorumlu bir şekilde açıklamak için deponun kökünde bir SECURITY.md dosyası arar. Bu dosyada rehberlik sağlamak, sonuçta bu kritik sorunların çözümünü hızlandırır.

SECURITY.mdhakkında daha fazla bilgi edinmek için bkz. Deponuza güvenlik ilkesi ekleme.

GitHub Güvenlik Önerileri

GitHub Güvenlik Önerileri, depo bakımcıların bir projedeki güvenlik açığını özel olarak tartışmasına ve düzeltmesine olanak sağlar. Depo bakımcıları bir düzeltme üzerinde işbirliği yaptıktan sonra, güvenlik açığını projenin topluluğuna genel olarak açıklamak için güvenlik önerisini yayımlayabilir. Depo bakımcıları, güvenlik önerilerini yayımlayarak, topluluklarının paket bağımlılıklarını güncelleştirmesini ve güvenlik açıklarının sonuçlarını araştırmasını kolaylaştırır. GitHub yayımlanan önerileri Ortak Güvenlik Açıkları ve Etkilenmeler (CVE) listesinde depolar. Bu liste, listelenen bir güvenlik açığına sahip yazılımları kullanan etkilenen depoları otomatik olarak bilgilendirmek için kullanılır. Daha fazla bilgi için bkz. Depo güvenlik önerileri hakkında.

.gitignore ile hassas dosyaları deponuzdan uzak tutun

Geliştiricilerin işlemeye dahil olan dosyaları gözden kaçırması kolaydır. Bazen bu göz ardı edilen dosyalar ara derleme dosyaları gibi zararsızdır. Ancak, birisinin istemeden hassas verileri işleme riski her zaman vardır. Örneğin, birisi kötü amaçlı bir aktörün kullanabileceği bir API anahtarı veya özel yapılandırma verileri işleyebilir. Bu riskten kaçınmaya yardımcı olan tekniklerden biri, .gitignore dosyaları oluşturmak ve korumaktır. Bu dosyalar, git komut satırı yardımcı programı gibi istemci araçlarına, commit işlemi için dosyaları toplarken yolları ve desenleri yoksaymalarını söylediği talimatları içerir.

Dosyaları yoksaymanın yaygın kullanım örneklerinden bazıları aşağıdaki örnekte gösterilmektedir.

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Deponuz birden çok .gitignore dosyası içerebilir. Ayarlar üst dizinlerden devralınır ve yeni .gitignore dosyalarındaki alanlar, klasörleri ve alt klasörleri için üst ayarlardan daha önceliklidir. Kök .gitignore dosyasını korumak önemlidir, ancak proje dizinine bir .gitignore dosyası eklemek, projenin üst öğeden ayrı olarak bakımı daha kolay olan belirli gereksinimleri olduğunda ( yoksayılmaması gereken dosyalar gibi) yararlı olabilir.

Daha fazla bilgi edinmek için .gitignore, dosyaları yoksayma bölümüne bakınız. Ayrıca gitignore deposundakiçeşitli platformlar için sunulan başlangıç .gitignore dosyalarının koleksiyonuna da göz atın.

Depodan hassas verileri kaldırma

.gitignore dosyaları katkıda bulunanların hassas verileri işlemekten kaçınmalarına yardımcı olmak için yararlı olsa da, bu yalnızca güçlü bir öneridir. "Geliştiriciler yeterince motive olduklarında, dosya eklemek için alternatif çözümler üretebilir ve bazen dosyalar .gitignore dosya yapılandırmasını karşılamadıkları için gözden kaçabilir." Proje katılımcıları her zaman depoya veya geçmişine dahil edilmemesi gereken verileri içeren commit'leri gözlemeli ve dikkat etmelidir.

Önemli

Herhangi bir noktada GitHub'a işlenen tüm verilerin gizliliğinin ihlal edildiğini varsaymalısınız. Bir commit'in üstüne yazmak, verilerin gelecekte erişilebilir olmayacağından emin olmak için yeterli değildir. GitHub'dan hassas verileri kaldırma kılavuzunun tamamı için bkz. Depodan hassas verileri kaldırma.

Dal koruma kuralları

Bir veya daha fazla dal için belirli iş akışlarını zorunlu kılmak için dal koruma kuralı oluşturabilirsiniz. Örneğin, korunan dala birleştirilen tüm pull request'ler için onaylayıcı bir inceleme veya durum kontrollerinin geçilmesini zorunlu kılabilirsiniz.

Dalını koruyan iş akışlarını kullanarak aşağıdakileri yapabilirsiniz:

• Kod değişikliklerinin derlenebilir olduğunu doğrulamak için bir derleme yapın
• Yazım hatalarını ve iç kodlama kurallarına uyumluluğu denetlemek için bir linter çalıştırın
• Kodun davranış değişikliklerini denetlemek için otomatikleştirilmiş testler çalıştırma
• Ve bu şekilde devam

CODEOWNERS dosyası ekleme

Deponuza bir CODEOWNERS dosyası ekleyerek, deponuzdaki yollara tek tek ekip üyelerini veya tüm ekipleri kod sahibi olarak atayabilirsiniz. Bu kod sahiplerinin, yapılandırıldıkları bir yoldaki dosyalarda yapılan değişikliklerle ilgili çekme isteği incelemelerinde yer alması zorunludur.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

CODEOWNERS dosyasını deponun kökünde veya docs veya .github klasöründe oluşturabilirsiniz.