Aracılığıyla paylaş

Güvenilir ve güvenli C++ programları oluşturma

  • Makale

Birleşik Devletler kamu yayını NISTIR 8397: Yazılım Geliştirici Doğrulaması için En Düşük Standartlar Yönergeleri, herhangi bir programlama dilinde güvenilir ve güvenli yazılım oluşturma konusunda mükemmel rehberlik içerir.

Bu belge NISTIR 8397 ile aynı yapıyı izler. Her bölüm:

  • C++ ve diğer diller için Microsoft geliştirici ürünlerinin bu bölümün güvenlik gereksinimlerini karşılamak için nasıl kullanılacağını özetler ve
  • her alanda en fazla değeri elde etmek için rehberlik sağlar.

2.1 Tehdit modelleme

Özet

Tehdit modelleme, özellikle geliştirme gereksinimlerinizi karşılayacak şekilde ölçeklendirilecek ve gürültüyü azaltacak şekilde uygulandığında değerli bir süreçtir.

Öneriler

Tehdit modellemesi, dinamik Güvenlik Geliştirme Yaşam Döngüsü'nüzün (SDL) bir parçası olmalıdır. Ürününüz için bir bütün olarak, belirli bir özellik için veya önemli bir tasarım veya uygulama değişikliği için şunları öneririz:

  • Geliştirici ekipleriyle erken etkileşime ve yaklaşımın haklaştırılmasına olanak tanıyan sağlam ve dinamik bir SDL'ye sahip olun.
  • Tehdit modellemesini hedeflenen bir şekilde uygulayın. Tüm özelliklere tehdit modellemesi uygulayın, ancak taktiksel olarak kullanıma sunulan, karmaşık veya kritik özelliklerle başlayın. Yukarıdan aşağıya ürün incelemesinin bir parçası olarak düzenli olarak uygulayın.
  • Tasarımı değiştirme fırsatı varken tehdit modellemesini erken uygulayın (tüm güvenlik gereksinimlerinde olduğu gibi). Ayrıca tehdit modelleri, saldırı yüzeyini azaltma veya güvenlik tasarımı gibi diğer işlemlere giriş görevi görür. Daha sonra oluşturulan tehdit modelleri, kalem testi (sızma testi) veya fuzzing gibi güvenlik testi gerektiren alanlar için en iyi "anketlerdir". Temel tehdit modeli oluşturduktan sonra, saldırı yüzeyi değiştikçe üzerinde yinelemeye devam etmek için plan yapın.
  • Bir ürünü neyin oluşturacağını uygun şekilde izlemek ve güvenlik yapıtlarını (tehdit modelleri dahil) ve uygulandıkları varlıklarla birlikte izlemek için varlık envanterini ve uyumluluğu kullanın. Bu yaklaşım, daha iyi otomatik risk değerlendirmesine ve güvenlik çalışmalarının değişen belirli bileşenlere veya özelliklere odaklanmasını sağlar.
  • Azure'da Microsoft Threat Modeling Tool, Azure geliştirmesi için 2022'de güncelleştirildi. Daha fazla bilgi için bkz. Microsoft Threat Modeling Tool'a genel bakış - Azure

Destekleyici faktörler ve uygulamalar

Tehdit modellemesini düzgün bir şekilde uygulamak ve çok fazla kullanmamak için öncelikle aşağıdaki temel kavramların ele alınması gerektiğini bulduk.

Geliştirme yaklaşımı

İlk olarak ekibin geliştirme yaklaşımını anlayın. Her gün üretime onlarca değişiklik getiren çevik geliştirme iş akışlarına sahip ekipler için, her işlevsel değişiklik için bir tehdit modeli güncelleştirmesi gerektirmek pratik veya makul değildir. Bunun yerine, bir özelliğin işlevsel gereksinimlerini yazarken en baştan bir güvenlik gereksinimleri anketi eklemeyi göz önünde bulundurun. Anket, SDL'nizin gelecekteki hangi yönlerinin geçerli olduğunu belirlemek için özellik hakkındaki belirli sorulara odaklanmalıdır. Örneğin:

  • Bu özellik, çok kiracılı bir ortamda müşteri yalıtımı sağlama şeklimiz konusunda önemli bir değişiklik yapıyor mu? Öyleyse, tam bir tehdit modeli gerçekleştirmeyi göz önünde bulundurun.
  • Yeni bir özellik dosya yüklemelerine izin verir mi? Öyleyse, belki de daha uygun olan bir web uygulaması güvenlik değerlendirmesidir.
  • Bu değişiklik öncelikli olarak yalnızca işlevsel bir kullanıcı arabirimi değişikliği mi? Öyleyse, geleneksel otomatik araçlarınızdan başka hiçbir şeye gerek yoktur.

Güvenlik anketi sonuçları, hangi SDL tekniklerinin hangi geliştirme birimiyle ilişkilendirildiği konusunda bilgi verir. Ayrıca geliştirme iş ortaklarını özelliğin SDL zaman çizelgeleri hakkında bilgilendirerek doğru zamanlarda işbirliği yapmalarını sağlar.

Ürün envanteri

İkincisi, değerlendirmekle görevlendirdiğiniz ürünlerin güçlü bir varlık envanterini koruyun. Ürünlerin karmaşıklığı artıyor. Aşağıdakilere sahip bağlı cihazlar için yazılım yazmak yaygın bir uygulamadır:

  • algılayıcılar (yolcu rayı ve araçlar gibi),
  • araçtaki diğer bileşenlerle (CANBUS veya PROFIBUS gibi) konuşan otobüs tabanlı ağlar,
  • müşteri cihazları ve bulut arka uçlarıyla iletişim için kablosuz/hücresel/Bluetooth,
  • cihaza veya filo yönetim uygulamasına geri beslenen bulutta makine öğrenmesi,
  • ve daha fazlası.

Bu tür karmaşık ürünlerde tehdit modelleme kritik önem taşır. Güçlü bir varlık envanterinin olması, resmin tamamını görmek ve yeni veya değiştirilmiş bir özelliğin ürün güvenliğini nasıl etkilediğini değerlendirmek için gerekli önemli yerleri görmek için ürün yığınının tamamını görüntülemenize olanak tanır.

Ayrıntı düzeyi ve tümleştirme

Net ölçümleri kullanarak uyumluluğu ölçmek için sistemler oluşturun.

  • Özellik düzeyi geliştirme için uyumluluğu düzenli olarak ölçün. Özellik uyumluluğu genellikle, bazen geliştiricinin sisteminde veya kod işleme/birleştirme zamanında bile daha yüksek sıklıkta ve daha küçük ayrıntı düzeyiyle ölçülmelidir.
  • Bir özelliğin veya bileşenin tüketildiği daha geniş bir ürün için güvenliği düzenli aralıklarla değerlendirin. Daha geniş değerlendirmeler genellikle modül veya sistem test süresi gibi daha düşük sıklıkta ve daha geniş ayrıntı düzeyiyle yapılır.

Ölçek

Güvenlik yapıtlarını ve tehdit modeli incelemelerinin çıkışını yakalayan ve koruyan uygun bir varlık envanteri sistemi tutun. Net bir envantere sahip olmak, desenler için gözden geçirme çıkışlarını değerlendirmenize ve ürün güvenlik programını düzenli olarak iyileştirme konusunda akıllı kararlar almanızı sağlar.

Gereksinimler aşaması güvenlik anketlerini, tehdit modelleme sonuçlarını, güvenlik değerlendirmesi sonuçlarını ve otomatik araçlardan elde edilmiş sonuçları birleştirmeyi deneyin. Bunları birleştirmek, tehdit modellemeden en iyi şekilde yararlanmak için güvenlik ekiplerinize odaklanmanız gereken noktaları bildirmek için belirli bir ürünün göreli riskine ilişkin bir bakış açısını otomatikleştirmenizi sağlar.

2.2 Otomatik test

Özet

Otomatikleştirilmiş testler, kodunuzun kalitesini ve güvenliğini sağlamanın önemli bir yoludur. Bunlar, bu belgede bahsedilen Tehdit Modellemesi gibi diğer alanları destekleyen ayrılmaz bir parçadır. Diğer güvenli kodlama uygulamalarıyla eşleştirildiğinde, kod tabanına sunulan hatalara ve güvenlik açıklarına karşı korunmaya yardımcı olur.

Anahtar öznitelikleri

Testler güvenilir, tutarlı ve yalıtılmış olmalıdır. Bu testler, kodun mümkün olduğunca çoğunu kapsamalıdır. Tüm yeni özellikler ve hata düzeltmeleri, mümkün olduğunda kodun uzun vadeli güvenliğini ve güvenilirliğini sağlamak için ilgili testlere sahip olmalıdır. Otomatikleştirilmiş testleri düzenli olarak ve mümkün olduğunca çok ortamda çalıştırarak çalıştırıldığından ve tüm alanları kapsadığından emin olun:

  • Çalıştırmaları gereken ilk yer, değişiklikleri yapan makinedir. Testleri çalıştırmak, düzenleme için kullanılan IDE içinde veya geliştirici değişiklikleri yaptığında komut satırında betik olarak en kolay şekilde gerçekleştirilir.
  • Çalıştıracakları bir sonraki yer, çekme isteği işleme/birleştirme işleminin bir parçasıdır.
  • Testleri çalıştırmak için son yer, Sürekli Tümleştirme ve Sürekli Dağıtım (CI/CD) işlem hattının bir parçası veya sürüm adayı derlemelerinizdir.

Testlerin kapsamı her adımda artmalıdır ve son adım diğer adımların kaçırabileceği her şey için tam kapsam sağlar.

Sürekli kullanım ve bakım

Test güvenilirliği, test paketinin etkinliğini korumanın önemli bir parçasıdır. Test hataları atanmalı ve araştırılmalı ve olası güvenlik sorunları yüksek öncelikli olmalı ve bir istem ve önceden belirlenmiş bir zaman çerçevesi içinde güncelleştirilmelidir. Test hatalarını yoksaymak yaygın bir uygulama olmamalıdır, ancak güçlü bir gerekçe ve onay gerektirmelidir. Test paketindeki sorunlardan kaynaklanan test hataları, ürün sorunlarının atlanabileceği kapsamanın engellenmesi için diğer hatalarla aynı şekilde ele alınmalıdır.

Test türleri, özellikle birim testleri

Çeşitli otomatik test türleri vardır ve tüm uygulamalar için geçerli olmasa da, iyi bir test paketi birkaç farklı türde seçim içerir. Birim testleri gibi Kod Tabanlı Test Çalışmaları, tüm uygulamalar için geçerli olan ve doğruluk için mümkün olduğunca çok kod yolunu kasıtlı olarak kapsayan en yaygın ve en tam sayıdır. Bu testler küçük, hızlı olmalı ve makinenin durumunu etkilememelidir, böylece test paketinin tamamı hızlı ve sık çalıştırılabilir. Mümkünse, tek bir makinede yeniden üretilmeyen sorunları yakalamak için farklı donanım kurulumlarına sahip birçok makinede testler çalıştırın.

Visual Studio

Visual Studio Test Gezgini en popüler C++ test çerçevelerinin çoğunu yerel olarak destekler ve daha fazla çerçeve için uzantı yükleme seçeneklerine sahiptir. Bu esneklik, üzerinde çalıştığınız kodu kapsayan bir test alt kümesini çalıştırmak için yararlıdır ve ortaya çıkan test hatalarında hata ayıklamayı kolaylaştırır. Visual Studio ayrıca mevcut projeler için yeni test paketleri ayarlamayı kolaylaştırır ve bu testleri yönetmeyi kolaylaştırmak için CodeLens gibi yararlı araçlar sağlar. Visual Studio ile C/C++ testleri yazma, çalıştırma ve yönetme hakkında daha fazla bilgi için bkz . C/C++ için birim testleri yazma - Visual Studio (Windows).

Azure ve GitHub'da CI/CD

Statik analiz, bileşen algılama vb. gibi daha derin doğrulamalar yapıp daha uzun süre çalışan testler, çekme isteği testi veya sürekli tümleştirme testi için iyi adaylardır. Azure DevOps ve GitHub Actions doğrulamaları otomatik olarak çalıştırmayı ve doğrulama başarısız olursa kod iadelerini engellemeyi kolaylaştırır. Otomatik zorlama, çalıştırılan bu daha sıkı denetimler temelinde iade edilmiş tüm kodların güvenli olmasını sağlamaya yardımcı olur. Azure Pipelines ve Azure DevOps Derleme Doğrulaması burada açıklanmıştır:

2.3 Kod tabanlı veya statik analiz

Özet Statik kod/ikili çözümleme, varsayılan olarak güvenli olacak şekilde varsayılan olarak etkinleştirilmelidir. Statik analiz, müşterinin makinesinde bir açık oluşması durumunda yürütme zamanında değil, oluşturulduğu sırada gerekli güvenlik ve güvenlik ilkeleri için bir programı analiz eder. Statik analiz, programı kaynak kod biçiminde veya derlenmiş yürütülebilir biçimde analiz edebilir.

Microsoft'un önerdiği öneriler:

  • Hem giriş kaynak kodu (derlemeden önce) hem de yürütülebilir ikili dosyalar (derlemeden sonra) için tüm C++ programları için statik analizi etkinleştirin. "Etkinleştir", geliştiricinin makinesindeki her derleme sırasında veya kodu daha sonra incelemek için ayrı bir derleme olarak veya iade gereksinimi olarak analiz çalıştırmak anlamına gelebilir.
  • Statik analizi bir test biçimi olarak CI işlem hatlarına dahil edin.
  • Tanıma göre statik analiz yanlış pozitiflerle birlikte gelir ve bu gerçeği kalite geri bildirim döngünüze dahil etmeye hazır olun. Tüm düşük hatalı pozitif uyarıları önceden etkinleştirmek için hızlı olun. Ardından, önemli hataları aşamalı olarak daha yüksek hatalı pozitif sonuçların (başlangıçta kod tabanı da bu kurallar için temizlenmeden önce) bayrak ekleyen daha fazla kural eklediğinizde, kod tabanınızın uyarı temizlemeyi derlediği kuralların sayısını kademeli olarak artırmak için proaktif olun.
  • Her zaman Visual Studio'nun desteklenen en son sürümlerini kullanın ve mühendislik ortamınızı bir sonraki geliştirme aşamasına/döngüsüne gecikmeden en son düzeltme eki sürümlerini kullanıma sunuldukları anda hızla kullanacak şekilde ayarlayın.

Önemli araçlar Aşağıdakilere dikkat edin ve bunları kullanın:

Notlar:

  • /analyze kritik güvenlik ve güvenilirlik kodu güvenlik açıklarını belirlemek için derleme zamanında C++ kodunun statik analizini etkinleştirir. Bir C++ programının tüm geliştirme zaman çizelgesi boyunca etkinleştirilmelidir. En az "Microsoft Yerel Önerilen" öğesini varsayılan olarak en düşük taban çizgisi olarak etkinleştirerek başlayın. Ardından, mühendislik ilkelerinizin gerektirdiği şekilde daha fazla kuralın (özellikle C++ Temel Yönergeleri kurallarının) nasıl belirtileceğini öğrenmek için belgelere bakın. Kaynak kodu Statik Çözümleme özelliği hem Visual C++ IDE'de hem de komut satırı Derleme Araçları'nda kullanılabilir.
  • /W4ve /WX kodunuzu yüksek uyarı düzeylerinde () temiz bir şekilde derlediğinizden emin olmak ve uyarıları düzeltilmesiWX gereken hatalar (W4) olarak değerlendirdiğinizden emin olmak için mümkün olduğunca etkinleştirilmelidir. Bu seçenekler, diğer statik çözümleme araçlarının denetleyemediği başlatılmamış veri hatalarını bulmayı sağlar, çünkü hatalar yalnızca derleyici arka ucu yordamlar arası çözümleme ve inlining gerçekleştirdikten sonra görünür hale gelir.
  • BinSkim ikili analizi, projelerin çok çeşitli güvenlik özelliklerine olanak tanımasını sağlar. BinSkim, gözetim zincirini doğrulamayı ve güvenlik sorunlarına verimli bir şekilde yanıt vermeyi kolaylaştıran PDB'ler ve diğer çıkışlar oluşturur. Microsoft, .dll programlarınız için üretilen veya programlar tarafından kullanılan tüm yürütülebilir ikili dosyaları (.sysveya .exe) analiz etmek için BinSkim aracını çalıştırmanızı önerir. BinSkim Kullanıcı Kılavuzu desteklenen güvenlik standartlarının listesini içerir. Microsoft, BinSkim aracı tarafından "hatalar" olarak bildirilen tüm sorunları düzeltmenizi önerir. "Uyarı" olarak bildirilen sorunlar seçmeli olarak değerlendirilmelidir, çünkü bunları çözümlemenin performans üzerindeki etkileri olabilir veya gerekli olmayabilir.

Azure ve GitHub CI/CD'de Microsoft, yayın CI/CD senaryolarında kaynak kodu ve ikili statik analizin her zaman etkinleştirilmesini önerir. Kaynak hatalarını olabildiğince erken yakalamak ve genel maliyetleri en aza indirmek için kaynak analizini yerel geliştiricinin makinesinde hemen veya en azından her işleme veya çekme isteği için çalıştırın. İkili düzeyde hatalar daha yavaş kullanılma eğilimindedir, bu nedenle daha az sık yayın öncesi CI/CD senaryolarında (gecelik veya haftalık derlemeler gibi) ikili analiz çalıştırmak yeterli olabilir.

2.4 Sabit kodlanmış gizli dizileri gözden geçirme

Özet

Gizli dizileri yazılım içinde sabit kodlamayın. Kaynak kod tabanınızın tamamını tarayabilen güvenilir araçları kullanarak gizli dizileri kaynak koddan verimli bir şekilde bulabilir ve kaldırabilirsiniz. Gizli dizileri bulduğunuzda, gizli dizileri güvenli depolama ve kullanma yönergelerini izleyerek güvenli bir yere taşıyın.

Sorun

"Gizli diziler", kimlik oluşturan ve kaynaklara erişim sağlayan ya da hassas verileri imzalamak veya şifrelemek için kullanılan varlıklar anlamına gelir. Örnek olarak parolalar, depolama anahtarları, bağlantı dizesi ve özel anahtarlar verilebilir. Yazılım tarafından gerektiğinde kolayca elde edilebilmeleri için yazılım ürünündeki gizli dizileri saklamak caziptir. Ancak bu sabit kodlanmış gizli diziler, kolayca keşfedildikleri ve hizmetinizin ve verilerinizin güvenliğini tehlikeye atmak için kullanılabildikleri için ciddi veya yıkıcı güvenlik olaylarına yol açabilir.

Korunma

Kaynak kodunda sabit kodlanmış gizli diziler (düz metin veya şifrelenmiş blob olarak) bir güvenlik açığıdır. Kaynak kodunda gizli dizileri önlemeye ilişkin genel yönergeler aşağıdadır:

  • Kaynak denetimine göndermeden önce kodda olası sabit kodlanmış gizli dizileri taramak ve yakalamak için bir ön denetim aracı kullanın.
  • Kaynak koduna veya yapılandırma dosyalarına düz metin kimlik bilgileri koymayın.
  • SharePoint, OneNote, dosya paylaşımları vb.'de düz metin kimlik bilgilerini depolamayın. İsterseniz bunları e-posta, anlık ileti vb. aracılığıyla da paylaşabilirsiniz.
  • Kolayca bulunabilen bir şifre çözme anahtarıyla gizli dizi şifrelemeyin. Örneğin, PFX dosyasını parolasını içeren bir dosyayla birlikte depolamayın.
  • Gizli diziyi zayıf bir şifre çözme ile şifrelemeyin. Örneğin, PFX dosyasını zayıf veya ortak bir parolayla şifrelemeyin.
  • Şifrelenmiş kimlik bilgilerini kaynak koduna yerleştirmekten kaçının. Bunun yerine kaynağınızdaki yer tutucuları kullanın ve dağıtım sisteminizin bunları onaylı depolardaki gizli dizilerle değiştirmesine izin verin.
  • Üretim dağıtımlarında yaptığınız gibi test, hazırlama vb. gibi ortamlardaki gizli dizilere de aynı ilkeleri uygulayın. Saldırganlar genellikle üretim dışı sistemleri daha az iyi yönetildikleri için hedefler, ardından üretime özet olarak eklemek için kullanırlar.
  • Dağıtımlar arasında gizli dizileri paylaşmayın (örneğin, test etme, hazırlama, üretim).

Doğrudan sabit kodlanmış gizli diziler ile ilgili olmasa da, test, geliştirme ve üretim için gizli dizilerin güvenliğini sağlamayı da unutmayın:

  • Gizli dizilerinizi belirli aralıklarla ve açığa çıkarılmış olabilecek her zaman döndürün. Gizli dizileri döndürme/yeniden dağıtma konusunda göstermiş bir beceriye sahip olmak, güvenli bir sistemin kanıtıdır. Daha da önemlisi, bu özelliğin olmaması kaçınılmaz bir güvenlik açığının daha da güçlü bir kanıtıdır.
  • Ortak geliştirici mantığına "test kimlik bilgilerim risk oluşturmaz" ifadesini vermeyin. Pratikte neredeyse her zaman yaparlar.
  • Gizli dizileri (örneğin, parolalar, taşıyıcı anahtarlar) tamamen RBAC/kimlik temelli çözümleri tercih ederek gizli dizilerin kötü yönetilmesini tamamen engelleyebilecek iyi bir mühendislik çözümü olarak kullanmayı göz önünde bulundurun.

Algılama

Ürününüzün eski bileşenleri, kaynak kodlarında gizli sabit kodlanmış gizli diziler içerebilir. Bazen geliştiricilerin masaüstü makinelerindeki gizli diziler uzak dala sızabilir ve yayın dalını birleştirerek istemeden gizli dizileri sızdırabilir. Kaynak kodunuzda gizlenebilecek gizli dizileri bulmak için kodunuzu sabit kodlanmış gizli diziler için tarayabilen araçları kullanabilirsiniz:

Düzeltme

Kaynak kodunuzda kimlik bilgileri bulunduğunda, acil olarak kullanıma sunulan anahtarı geçersiz kılmanız ve açığa çıkma temelinde bir risk analizi gerçekleştirmeniz gerekir. Sisteminizin çalışmaya devam etmesi gerekse bile, aşağıdaki adımları kullanarak düzeltme için gizli dizi yöneticisini etkinleştirebilirsiniz:

  1. Düzeltme, yönetilen kimliklere geçişe izin veriyorsa veya Azure Key Vault (AKV) gibi bir gizli dizi yöneticisinin bırakılmasını gerektiriyorsa, önce bunu yapın. Ardından güncelleştirilmiş kimlik veya anahtarla yeniden dağıtın.
  2. Kullanıma sunulan gizli diziyi geçersiz kılın.
  3. Riskten kaynaklanan olası hasarlar için denetim/risk değerlendirmesi gerçekleştirin.

Bulut uygulamaları ve hizmetleri tarafından kullanılan şifreleme anahtarlarını ve diğer gizli dizileri korumak için uygun erişim ilkesiyle Azure Key Vault'u kullanın.

Belirli müşteri verilerinin/PII'lerinin gizliliğini tehlikeye sokarsa, diğer uyumluluk/raporlama gereksinimleri gerekebilir.

Şimdi geçersiz kılınan gizli dizileri kaynak kodunuzdan kaldırın ve bunları doğrudan kaynak kodunuzda gizli dizileri kullanıma açmayan alternatif yöntemlerle değiştirin. Azure AD gibi araçları kullanarak gizli dizileri mümkün olduğunca ortadan kaldırma fırsatlarını arayın. Azure Active Directory aracılığıyla yönetilen kimliklerden yararlanmak için kimlik doğrulama yöntemlerinizi güncelleştirebilirsiniz. Azure Key Vault (AKV) gibi gizli dizileri depolamak ve yönetmek için yalnızca onaylı depoları kullanın. Daha fazla bilgi için bkz.

Azure DevOps (AzDO)

AzDO kullanıcıları, Azure DevOps için GitHub Gelişmiş Güvenlik (GHAzDO) aracılığıyla kodlarını tarayabilir. GHAzDO ayrıca kullanıcıların depolarında Anında İletilen Koruma'yı etkinleştirerek gizli pozlamaları engellemesine ve daha sızdırılamadan önce olası pozlamaları yakalamasına da olanak tanır. Azure DevOps'ta kodda sabit kodlanmış gizli dizileri algılama hakkında daha fazla bilgi için aşağıdaki bağlantıların her birinde Bkz . Azure DevOps için Github Gelişmiş Güvenliği için Gizli Dizi Tarama:

GitHub'da

Gizli dizi taraması GitHub.com iki biçimde kullanılabilir:

  • İş ortakları için gizli dizi tarama uyarıları. Tüm genel depolarda otomatik olarak çalışır. Gizli dizi tarama iş ortakları tarafından sağlanan desenlerle eşleşen tüm dizeler doğrudan ilgili iş ortağına bildirilir.
  • Kullanıcılar için gizli dizi tarama uyarıları. GitHub Enterprise Cloud kullanan ve GitHub Gelişmiş Güvenlik lisansına sahip olan kuruluşların sahip olduğu depolar için ek taramayı etkinleştirebilir ve yapılandırabilirsiniz. Bu araçlar özel ve iç depoları da destekler.

GitHub, iş ortakları ve kullanıcılar için gereksinimlerinizi karşılayacak şekilde yapılandırabileceğiniz bilinen gizli dizi desenleri sağlar. Daha fazla bilgi için bkz.

Not

Azure DevOps için GitHub Gelişmiş Güvenliği, GitHub kullanıcıları için zaten kullanılabilir olan gizli dizi tarama, bağımlılık tarama ve CodeQL kod tarama çözümlerini getirir ve Azure Depolarınızı ve İşlem Hatlarınızı korumak için bunları Azure DevOps ile yerel olarak tümleştirir.

Ek Kaynaklar

2.5 Dil ve işletim sistemi tarafından sağlanan denetimler ve koruma ile çalıştırma

Özet

İkili sağlamlaştırma, derleme zamanı güvenlik denetimleri uygulanarak yapılır. Bunlar şunlara yönelik risk azaltmaları içerir:

  • kodda kötüye kullanılabilir güvenlik açıklarını önleme,
  • güvenlik savunmalarını sömürüye tetikleyen çalışma zamanı algılamalarını etkinleştirme ve
  • güvenlik olaylarının neden olduğu hasarı sınırlamaya yardımcı olmak için veri üretimini ve arşivlemeyi etkinleştirin.

İkili tüketicilerin sağlamlaştırmanın tüm avantajlarından yararlanmak için Windows güvenlik özelliklerini kabul etmesi gerekir.

Microsoft, geliştiricilerin daha güvenli ve daha güvenli kod yazmasına ve göndermesine yardımcı olmak için C++ projelerine özgü bir dizi olanak sağlar. C++ geliştiricileri, yürütülebilir kod oluşturan dillerde ortak olan güvenlik standartlarına da uymalıdır. Microsoft, bu bölümde açıklanan birçok korumanın kullanılmasını zorunlu kılmaya yardımcı olan genel bir OSS ikili denetleyicisi olan BinSkim'i korur. BinSkim hakkında daha fazla bilgi için bkz . Binskim kullanıcı kılavuzu | GitHub

İkili düzey denetimler, mühendislik sürecinde uygulandıkları yere göre farklılık gösterir. Derleyici ve bağlayıcı seçenekleri arasında ayrım yapmanız gerekir: kesinlikle derleme zamanıdır, çalışma zamanı ek yüküyle kod oluşturmayı değiştirir ve işletim sistemi korumalarıyla uyumluluk elde etmek için kod oluşturmayı değiştirirsiniz.

Geliştirici ayarları mümkün olduğunca çok statik analizi etkinleştirmeyi, hata ayıklamayı hızlandırmak için özel veri üretimini etkinleştirmeyi vb. tercih etmelidir. Sürüm derlemeleri, güvenlik, performans ve diğer kod oluşturma sorunlarının uygun bir bileşimine ayarlanmalıdır. Yayın işlemleri, genel ve özel olarak kullanılan derleme verilerini (örneğin, genel ve özel simgeler) düzgün bir şekilde oluşturacak ve yönetecek şekilde yapılandırılmalıdır.

Güncel kalın: Her zaman güncel derleyicileri ve araçları kullanın

Güncel dil desteği, statik analiz, kod oluşturma ve güvenlik denetimlerinden yararlanmak için tüm kodu geçerli araç kümeleriyle derleyin. Derleyiciler oluşturulan her bileşeni etkilediğinden, araç güncelleştirmesinde regresyon olasılığı nispeten yüksektir. Eski derleyicilerin kullanılması, bir güvenlik olayına yanıt verirken düzeltici eylem için belirli bir risk oluşturur çünkü ekiplerin derleyicileri yükseltmek için yeterli zamanı olmayabilir. Microsoft, ekiplerin derleyici güncelleştirmelerini düzenli olarak yenilemek ve test etmek için tesisi geliştirmesini önerir.

Güvenli geliştirme yöntemlerini, dil sürümlerini, çerçeveleri/API'leri kullanma

Kod, C++'ta güvenliği ve basitliği teşvik ederek riski en aza indiren geliştirme yöntemlerini, dil sürümlerini, çerçeveyi, API'leri vb. kullanmalıdır:

  • En iyi yöntemleri izleyen ve yaygın tuzakları önleyen modern, güvenli ve tutarlı C++ kodu yazma yönergeleri için bkz . C++ Temel Yönergeleri Kılavuz Destek Kitaplığı (GSL ).
  • C++ Çekirdek Yönergeleri'nin kullanmanızı önerdiği işlevler ve türler için bkz . Microsoft GSL uygulaması .
  • Kaynak açısından güvenli C++ kapsayıcıları, C çalışma zamanı kitaplığı (CRT) bellek taşması korumaları: Tercih et std::vector ve std::stringkaynak açısından güvenlidir. C verilerini kullanmanız gerekiyorsa, arabellek kötüye kullanımı ve tanımlanmamış dil davranışları nedeniyle bellek bozulmasını önlemeye yardımcı olmak için tasarlanan CRT işlevlerinin güvenli sürümlerini kullanın.
  • SafeInt kitaplığı, matematik ve karşılaştırma işlemlerinde tamsayı taşmasına karşı koruma sağlar.

Güvenli bağımlılıkları kullanma

İkili dosyalar güvenli olmayan kitaplıklara ve bağımlılıklara bağlanmamalıdır. Geliştirme ekipleri tüm dış bağımlılıkları izlemeli ve bu güvenlik açıklarına tabi olduğunda daha güvenli sürümlere güncelleştirerek bu bileşenlerdeki CV'leri/tanımlanan güvenlik açıklarını çözmelidir.

Güvenlik yanıtının kod başarısı garantilerini ve verimliliğini en üst düzeye çıkarın

Derleme, arka kapı ve diğer kötü amaçlı kodların tanıtılmasını algılamaya ve önlemeye yardımcı olmak için güçlü kod başarısı garantilerini etkinleştirmelidir. Hata ayıklama ve araştırma açısından da kritik öneme sahip olan sonuçta elde edilen veriler, güvenliği ihlal edilirse verimli bir güvenlik yanıtı sağlamak amacıyla tüm yazılım sürümleri için arşivlenmelidir. Aşağıdaki derleyici anahtarları, bir güvenlik yanıtı için kritik öneme sahip bilgiler oluşturur:

  • /ZH:SHA_SHA256 In Visual C++ - Tüm PDB kaynak dosyası karmalarını oluşturmak için şifreleme açısından güvenli bir algoritmanın kullanılmasını sağlar.
  • /Zi, /ZI (Hata Ayıklama Bilgileri Biçimi) Visual C++ içinde - Kilitlenme verilerini ve diğer genel kullanım senaryolarını toplamak için kaldırılmış simgeler yayımlamaya ek olarak, derlemelerin yayımlanan tüm ikili dosyalar için özel PDB'ler ürettiğinden ve arşivlediğinden emin olun. İkili çözümleme araçları, derleme zamanında birçok güvenlik azaltmanın etkinleştirilip etkinleştirilmediğini doğrulamak için tam simgeler gerektirir. Özel simgeler güvenlik yanıtı açısından kritik öneme sahiptir ve mühendisler açıklardan yararlanma gerçekleştiğinde hasarı değerlendirmek ve sınırlamak için yarışırken hata ayıklama ve araştırma maliyetlerini düşürür.
  • /SOURCELINK Visual C++ Bağlayıcısı'nda - Sourcelink dosyasını PDB'ye ekle: Kaynak bağlantısı, ikili dosyalar için kaynak hata ayıklaması sağlayan dil ve kaynak denetimi belirsiz bir sistemdir. Kaynak hata ayıklama, yayın öncesi güvenlik doğrulamaları ve yayın sonrası olay yanıtı aralığının verimliliğini büyük ölçüde artırır.

Kod yazma zamanındaki sorunları önlemek için derleyici hatalarını etkinleştirme

Derleme, güvenlikle ilgili derleyici denetimlerini hata olarak etkinleştirmelidir, örneğin:

İkili dosyaları işletim sistemi çalışma zamanı güvenlik azaltmalarıyla uyumlu olarak işaretleme

Derleyici ve bağlayıcı ayarları, aşağıdakiler dahil olmak üzere kötü amaçlı kod yürütmeyi algılayan ve azaltan kod oluşturma özelliklerini kabul etmelidir:

Hassas bilgilerin açığa çıkmasını önleme

Derleyici ayarları hassas bilgi bulma önlemeyi kabul etmelidir. Son yıllarda araştırmacılar, kurgusal yürütme gibi donanım özellikleriyle ortaya çıkan istenmeyen bilgi sızıntılarını ortaya çıkarmaktadır.

Yazılım düzeyinde gizli veriler beklenmedik şekilde sızdırılırsa saldırganlara iletilebilir. Arabellekleri sıfır başlatma hatası ve diğer arabellek kötüye kullanımı, güvenilen API'yi çağıran saldırganlara özel gizli verileri sızdırabilir. Bu sorun sınıfı, daha önce açıklandığı gibi ek statik analiz etkinleştirilerek ve güvenli kaynak kapsayıcıları kullanılarak en iyi şekilde işlenir.

  • /Qspectre - Kurgusal yürütme yan kanal saldırılarını azaltma - Kurgusal yürütme tarafından üretilen hassas verilerin açığa çıkmasını önlemeye yardımcı olan engelleyici yönergeler ekler. Bu azaltmalar, hassas verileri bellekte depolayan ve bir güven sınırı boyunca çalışan kod için etkinleştirilmelidir. Microsoft, performans açısından kritik bloklarda veya döngülerde çalışma zamanı denetimleri sunma olasılığı nedeniyle Spectre-risk azaltmalarını etkinleştirirken her zaman uygun karşılaştırmalara karşı performans etkisinin ölçülmesi önerilir. Bu kod yolları, değiştirici aracılığıyla spectre(nomitigation) declspec risk azaltmaları devre dışı bırakabilir. Etkinleştiren /Qspectre projeler, Microsoft çalışma zamanı kitaplıkları da dahil olmak üzere bu azaltmalarla derlenen kitaplıklara da bağlanmalıdır.

2.6 Kara kutu test çalışmaları

Özet

Kara kutu testleri, test edilen bileşenin iç çalışmalarına güvenmez. Kara kutu testleri, üründeki özelliklerin uçtan uca işlevselliğini herhangi bir katmanda veya düzeyde test etmek için tasarlanmıştır. Kara kutu testleri işlevsel testler, ui testleri, performans testleri ve tümleştirme testleri olabilir. Kara kutu testleri, genel güvenilirliği ve işlevsel doğruluğu ölçmek ve ürünün beklendiği gibi davranmasını sağlamak için değerlidir.

Diğer bölümlerle ilişki

Bu tür gereksinim tabanlı testler, Tehdit Modeli'nde yapılan varsayımları doğrulamak ve bu bölümde açıklandığı gibi olası tehditleri kapsamak için yararlıdır. Bu testler, özellikle tehdit modelinde açıklandığı gibi güven sınırlarının ötesinde olanlar olmak üzere ürünün ayrı bileşenleri arasındaki tümleştirmeyi test etmede yararlıdır. Kara kutu test çalışmaları, kullanıcı girişi doğrulaması için her türlü uç örneğini test etmede de yararlıdır. Bilinen uç durumlarını ve hata durumlarını test etme yararlı olur. Fuzzing, daha az belirgin durumları test etmek için de yararlıdır.

Otomasyon ve regresyon

Bu testleri düzenli olarak çalıştırın ve hataya neden olan değişiklikleri veya performans regresyonlarını yakalamak için sonuçları önceki çalıştırmalarla karşılaştırın. Ayrıca, bu testleri birçok farklı makinede ve yükleme kurulumunda çalıştırmak, farklı mimarilerden veya kurulum değişikliklerinden kaynaklanabilir sorunların ele alınabilmesine yardımcı olabilir.

Kilitlenme dökümleri

Bu testler güvenilirlikle ilgili sorunların bulunmasına yardımcı olur ve kilitlenmeler, kilitlenmeler, kilitlenmeler vb. ile karşılaşabilecek birçok farklı senaryoyu test edebilir. Test hatalarının bir parçası olarak kilitlenme bilgi dökümlerini toplayarak dökümleri doğrudan Visual Studio'ya aktararak kodun hangi bölümlerinin bu sorunlarla karşılaştığını daha fazla araştırabilirsiniz. İşlevsel testleri Visual Studio'dan çalıştırırsanız, testin tam olarak kara kutunun içinde nerede başarısız olduğunu görerek hataları kolayca çoğaltabilir ve hatalarını ayıklayabilir ve düzeltmeleri hızlı bir şekilde test edebilirsiniz.

Hata ayıklama testlerini kullanmaya başlamak için bkz . Test Gezgini ile birim testlerinin hatalarını ayıklama - Visual Studio (Windows)

Azure'da

Azure DevOps, Test Planlarının kullanımıyla bu testleri yönetmenize ve doğrulamaya da yardımcı olabilir. Bu testler, el ile doğrulama ile onay sağlamak ve ürün gereksinimleriyle ilişkili otomatikleştirilmiş testleri çalıştırmak için kullanılabilir. Azure Test Planları ve bunları otomatik test çalıştırmak için kullanma hakkında daha fazla bilgiyi burada bulabilirsiniz:

2.7 Kod tabanlı test çalışmaları

Özet

Kod tabanlı test çalışmaları, ürününüzün güvenliğini ve güvenilirliğini korumanın ayrılmaz bir parçasıdır. Bu testler küçük ve hızlı olmalı ve paralel olarak çalıştırılabilmeleri için birbirlerini etkilememelidir. Kod tabanlı testler, geliştiricilerin geliştirme döngülerini yavaşlatma konusunda endişelenmeden kodda değişiklik yaptıkları her zaman geliştirme makinelerinde yerel olarak çalışması kolaydır.

Türler ve diğer bölümlerle ilişki

Yaygın kod tabanlı test çalışması türleri şunlardır:

  • birim testleri,
  • birden çok giriş türüne sahip işlevleri kapsayacak parametreli testler,
  • her test bileşenini ayrı tutmak için bileşen testleri ve
  • diğer hizmetlerle iletişim kuran kodun bölümlerini doğrulamak için sahte test, testin kapsamını bu hizmetleri içerecek şekilde genişletmeden.

Bu testler yazılan iç kodu temel alırken, kara kutu testleri ürünün dış işlevsel gereksinimlerini temel alır.

Hedef

Bu testlerle amaç, kodunuz üzerinde yüksek düzeyde test kapsamı elde etmektir. Bu kapsamı ve boşlukların nerede olduğunu etkin bir şekilde izlemeniz gerekir. Daha fazla kod yolu kullanan daha fazla test ekledikçe kodunuzun güvenliği ve güvenilirliğindeki genel güven artar.

Visual Studio

Visual Studio'daki test gezgini araçları, bu testleri sık çalıştırmayı ve geçiş/başarısızlık oranları ve hata konumları hakkında hızlı bir şekilde geri bildirim almayı kolaylaştırır. Test çerçevelerinin çoğu, test durumunu testin konumunda görmek için CodeLens özelliklerini de destekler ve bu da test paketinin eklenmesini ve bakımını kolaylaştırır. Test Gezgini ayrıca bu testleri yönetmeyi kolaylaştırarak test gruplarını, özel test çalma listelerini, filtrelemeyi, sıralamayı, aramayı ve daha fazlasını sağlar.

Daha fazla bilgi için bkz.

Visual Studio ayrıca kod kapsamını izlemeye yönelik araçlarla birlikte gelir. Bu araçlar, yaptığınız kod değişikliklerinin mevcut testlerin kapsamında olduğundan emin olmanıza veya yeni ve test edilmemiş kod yollarını kapsayacak yeni testler eklemenize olanak tanır. Araçlar ayrıca genel kod kalitesinde güven için hedef düzeyin üzerinde tutulabilmesi için kod kapsamı yüzdesini gösterir.

Bu araçlar hakkında bilgi için bkz . Kod kapsamı testi - Visual Studio (Windows)

Azure'da

Azure DevOps, derleme işlem hattı işleminin bir parçası olarak ürünün tamamı için kod kapsamı sonuçlarının izlenmesine de yardımcı olabilir. Daha fazla bilgi için bkz . Kod kapsamını gözden geçirme - Azure Pipelines.

2.8 Geçmiş test çalışmaları

Özet

Regresyon test çalışmaları olarak da bilinen geçmiş test çalışmaları, eski sorunların yeniden ortaya çıkmasını önler ve ürünün genel test kapsamını artırır. Bir hata düzeltildiğinde projenin de buna karşılık gelen bir test çalışması eklediğinden emin olmalısınız. Zamanla, düzeltmeler yapıldıktan sonra test paketinin genel sağlamlığı gelişmeye devam edecek ve güvenilirlik ve güvenlik konusunda daha iyi güvenceler sağlayacaktır.

Önemli nitelikler ve diğer bölümlerle ilişki

Hata regresyonlarını test ettikleri için bu testlerin hızlı ve kolay bir şekilde çalıştırılması gerekir, böylece Kod Tabanlı Test Çalışmaları ile birlikte çalışabilir ve ürünün genel kod kapsamına katkıda bulunabilirler. Bununla birlikte, yeni test çalışmalarını teşvik etmek için müşterilerden gerçek örnekler kullanmak, test kapsamını ve kalitesini iyileştirmenin harika bir yoludur.

Visual Studio

Visual Studio, hatayı düzeltmek için değişiklikleri yaparken pakete kolayca test eklemenize ve tüm yeni durumların dikkate alındığından emin olmak için testleri ve kod kapsamını hızlı bir şekilde çalıştırmanıza olanak tanır. Testi yazdığınız kodunuzda sorun izleme sisteminizdeki hata kimliğine başvurmak, regresyon testlerini ilgili sorunlara bağlamak için iyi bir yoldur. Azure Boards ve test planlarını Visual Studio ile birlikte kullanmayı tercih edin:

  • testleri, test çalışmalarını ve sorunları ilişkilendirmek; ve
  • bir sorunun tüm yönlerini ve ilgili testlerini izlemek için.

Daha fazla bilgi için bkz.

Sonuç olarak, bu testleri kod bölümünü kapsaması gereken birim testi alanıyla tümleştirmek, test paketini düzenli tutmaya ve yönetmeyi kolaylaştırmaya yardımcı olur. Birlikte ait olan testleri etkili bir şekilde izlemek için Test Gezgini'nin test gruplandırma özelliğini kullanabilirsiniz. Daha fazla bilgi için bkz . Test Gezgini ile birim testleri çalıştırma - Visual Studio (Windows)

2.9 Uzzing

Özet Fuzzing (fuzz testi olarak da bilinir), bir programa giriş olarak geçersiz, beklenmeyen veya rastgele veriler sağlamayı içeren otomatik bir yazılım testi tekniğidir. Ardından program kilitlenmeler, başarısız olan yerleşik veya derleyici tarafından eklenen kod onayları ve olası bellek sızıntıları gibi özel durumlar için izlenir.

Rehber

Bir saldırganın denetleyebileceği güvenilmeyen girişleri işleyebilen tüm yazılımlarda fuzzing kullanın. Yeni bir uygulama ve ilişkili test paketi oluşturuyorsanız, anahtar modüller için mümkün olan en erken şekilde fuzzing'i de dahil edin. Bir yazılım parçası üzerinde ilk kez fuzzing çalıştırmak, neredeyse her zaman önceden bilinmeyen gerçek güvenlik açıklarını ortaya çıkarır. Bir kez fuzzing başladıktan sonra, asla durma.

Diğer bölümlerle ilişki

Fuzzing bir hata bildirdiğinde, her zaman doğal olarak hatayı gösteren yeniden üretilebilir bir test çalışması sağlar. Bu test çalışması yeniden oluşturulabilir, çözümlenebilir ve ardından Geçmiş Test Çalışmalarına eklenebilir.

Adres Dezenfektanı (ASan) ve fuzzing gibi her iki dezenfektanı kullanırken:

  • Sorun olup olmadığını görmek için önce normal testlerinizi etkinleştirilmiş olarak çalıştırın, ardından kod dezenfektan temizleme işlemine geçtikten sonra fuzzing'i başlatın.
  • C veya C++ için, ASan'ı etkinleştiren çalışma zamanı onaylarının ve meta verilerin eklenmesini otomatik hale getiren derleyiciler vardır. ASan için derlendiğinde, sonuçta elde edilen ikili dosyalar sıfır hatalı pozitif ile 15'in üzerinde bellek güvenliği hatası kategorisini tam olarak tanılayan bir çalışma zamanı kitaplığına bağlanır. Kaynağınız olduğunda C veya C++ için, önce ASan'ın etkinleştirilmesini gerektiren LibFuzzer kullanın.
  • Java, C#, Python, Rust vb. ile yazılmış kitaplıklar için AFL++ çerçevesini kullanın.

Temel nitelikler

  • Fuzzing genellikle statik program analizi, kapsamlı özellik testi ve el ile kod denetimi tarafından kaçırılan güvenlik açıklarını bulur.
  • Fuzzing, yazılımdaki güvenlik ve güvenilirlik hatalarını bulmanın etkili bir yoludur, böylece Microsoft Güvenlik Geliştirme Yaşam Döngüsü her ürünün güvenilmeyen her arabiriminde bilgilenme gerektirir (ayrıca bkz. Tehdit Modelleme).
  • Güvenilmeyen girişleri işleyebilen yazılımlar için her zaman fuzzing kullanın.
  • Fuzzing, büyük veri ayrıştırıcıları olan tek başına uygulamalar için etkilidir.

Azure ve GitHub CI/CD

Derlemelerinizi, LibFuzzer veya AFL++ kullanan yürütülebilir dosyaları sürekli oluşturmayı destekleyecek şekilde değiştirin. OSS-Fuzz veya OneFuzz gibi hizmetlere ek bilgi işlem kaynakları ekleyebilirsiniz.

2.10 Web Uygulaması Tarama

Özet

Windows üzerinde Microsoft Visual C++ kapsamında Microsoft şunları önerir:

  • Web uygulamaları için TypeScript, JavaScript ve ASP.NET tercih edin.
  • C++ dilinde web uzantıları yazmayın. Microsoft, ActiveX'i kullanım dışı bırakmıştır.
  • Kod, Emscripten/WASM olarak derlendiğinde artık C++ değildir ve diğer araçlar geçerlidir.
  • Microsoft, durum bilgisi olan bir REST API fuzzer olan RESTler'ı sağlar.

Genel bakış ve önemli nitelikler

Web uygulaması tarayıcısı, web sayfalarında gezinerek bir web uygulamasını inceler ve güvenlik açıklarına karşı inceler. Bu gezinme, kötü amaçlı girişlerin otomatik olarak oluşturulmasını ve uygulamanın yanıtlarının değerlendirilmesini içerir. Kritik olarak, web uygulaması tarama şunları kapsamalı/desteklemelidir:

  • Ağınızdaki yeni ve bilinmeyen uygulamalar da dahil olmak üzere tüm web uygulamalarını kataloglar ve birkaç uygulamadan binlercesine ölçeklendirilir.
  • Mobil cihazlar tarafından kullanılan yazılım sürümleri, SOAP ve REST API hizmetleri ve API'ler için derin tarama.
  • DevOps ortamlarında uygulama geliştirme ve dağıtıma güvenlik temel öğelerinin eklenmesi. Bu temel öğeler gezginle birlikte çalışır.
  • Kötü amaçlı yazılım algılama.

2.11 Kontrol özel Yazılım Bileşenleri

Özet

C++ kodunuzu diğer programlama dillerinde yazılmış kodlarla aynı şekilde işleyebilir ve şirketiniz tarafından benimsenen tüm Yazılım Oluşturma Analizi (SCA) ve Kaynak Analizi (OA) araçlarını C++ kodunuz için uygulayabilirsiniz. İş akışları ve güvenlik taraması CI/CD (sürekli tümleştirme ve sürekli teslim) sistemlerinin bir parçası olarak tasarlanmalıdır.

Yukarı akış savunması

Yukarı akış bağımlılıklarına yönelik saldırı riskini azaltmak için üçüncü taraf kaynaklar/bileşenler, SCA ve OA araçlarının çalıştırıldığı kurumsal denetimli bir varlıkta depolanmalıdır.

  • Araçlar, güvenlik açıkları tanımlandığında (genel veritabanları dahil) taramalı ve uyarı vermelidir: Giriş | CVE
  • Güvenlik açığı bulunan kod desenlerini belirlemek için uygulamanıza/deponuza dahil edilen tüm yazılım bileşenlerinde statik analiz çalıştırın.

Bağımlılık savunması

Bu tür tüm oluşumların SCA ve OA araçlarınız tarafından hesaba eklendiğini ve kapsadığını doğrulamak için bağımlılıkların denetimini gerçekleştirin ve koruyun.

  • Bileşenler düzenli olarak denetlenmeli ve en son doğrulanmış sürümlere güncelleştirilmelidir.
  • Paket akışı bağımlılıkları.
  • SCA/OA araçları, tek bir akıştan gelen tüm paket bağımlılıklarını kapsar ve denetler.

SBOM

Ürününüzle aşağıdaki gibi tüm bağımlılıkları listeleyen bir SBOM (yazılım ürün reçetesi) üretin:

  • kaynak (örneğin, URL (Tekdüzen Kaynak Bulucu))
  • sürüm
  • tutarlılık (örneğin, SHA-256 kaynak karması) ve deterministik derlemeler gibi tutarlılığı doğrulamaya yönelik diğer araçlar.
  • Yazılım bağımlılıklarında veya OSS (açık kaynak yazılım) dahil olmak üzere bir derlemenin parçası olarak üretilen SBOM dosyalarını zorunlu kıl ve denetle.
  • Microsoft, SPDX (Yazılım Paketi Veri Değişimi) sürüm 2.2 veya üzerini standartlaştırıyor ve önerir | SBOM belge biçimi olarak Linux Foundation .
  • Derleme determinizmi, bit tabanlı özdeş ikili dosyaları bağımsız olarak üretmek ve bağımsız bütünlük doğrulamaları sağlamak için kullanılabilir:
    • Yeniden üretilebilirlik için birinci taraf veya üçüncü taraf kanıtlama
    • Güvenilir bir sertifika kaynağı aracılığıyla ikili imzalama gibi diğer teknikler de ikili bütünlüğün bazı güvencelerini sağlayabilir.

Ek Kaynaklar

Microsoft çözümleri aşağıdaki yönergeleri ve ürünleri içerir: