- Katılım
- 21 May 2023
- Mesajlar
- 496
- Tepki
- 17
- Puan
- 18
Bir yazılım projesini teslim etmek, kaynak kodu ZIP dosyasıyla göndermekten ibaret değil. Kod elinizde olsa bile depo başka birinin hesabındaysa, canlı sistemin anahtarları bilinmiyorsa veya yalnızca eski geliştirici dağıtım yapabiliyorsa proje gerçekte devredilmiş sayılmaz.
Sağlam bir devirde amaç, müşterinin projeyi bağımsız olarak çalıştırabilmesi ve yeni ekibin nereden başlayacağını anlayabilmesidir. Bunun için kaynak kod, hesap sahipliği, sırlar, dokümantasyon ve çalışan bir kabul testi aynı paketin parçaları olmalı.
Devir günü gelmeden proje varlıklarını tek listede toplayın. Liste yalnızca dosya adlarından oluşmasın; her varlığın sahibi, bulunduğu hizmet, yeni sorumlusu ve aktarım durumu da yazılsın.
Bu envanter sözleşmedeki “kaynak kod teslimi” maddesini somutlaştırır. Hangi lisansların, tasarım dosyalarının, verilerin veya harici hizmetlerin kapsama dahil olmadığı da aynı yerde açıkça belirtilmelidir.
Müşteriye yeni bir depo açıp son hâli yüklemek hızlı görünür; fakat commit geçmişi, sorunlar, sürümler ve otomasyon ayrıntıları kaybolabilir. Mümkünse proje, müşterinin yönettiği bir GitHub organizasyonunda tutulmalı ve kişilere görevleri kadar rol verilmelidir.
GitHub’ın depo aktarımı, içerikle birlikte issues, pull request’ler, releases ve ayarları da yeni sahibe taşır. Ancak webhooks, secrets ve deploy keys aktarım sonrasında depoyla ilişkili kalabilir. Bu yüzden “Transfer tamamlandı” ekranı güvenlik kontrolünün sonu değil, başlangıcıdır.
Ortak bir metin dosyasına kullanıcı adı ve parola yazmak yerine, her hizmette müşteriye ait hesap oluşturun ve isimli kullanıcı daveti gönderin. Önce yeni erişimin çalıştığını doğrulayın; sonra eski ekibin rolünü azaltın veya kaldırın.
API anahtarları, veritabanı parolaları, SSH anahtarları, deploy key’ler ve CI/CD sırları ayrıca ele alınmalıdır. Bunları kaynak koda ya da teslim belgesine düz metin olarak koymayın. Yeni sorumlu erişimi aldıktan sonra sırları döndürün; eski değerleri iptal edin ve hangi uygulamanın hangi sırrı kullandığını kaydedin.
OWASP sır yönetimini oluşturma, saklama, erişim kontrolü, döndürme, iptal ve süre sonu olan bir yaşam döngüsü olarak ele alıyor. Devir kontrol listesi de aynı mantığı izlemeli; yalnızca “anahtar gönderildi” kutusuna indirgenmemeli.
Teslim belgesinin doğruluğunu ölçmenin en iyi yolu, projeyi temiz bir ortamda kurmaktır. Yeni sorumlu kendi hesabıyla depoyu klonlamalı, bağımlılıkları kurmalı, testleri çalıştırmalı ve mümkünse deneme ortamına dağıtım yapmalıdır.
NIST SSDF, kodun yetkisiz erişim ve kurcalamaya karşı korunmasını ve yazılım sürümlerinin bütünlüğünün sağlanmasını güvenli geliştirme sürecinin bir parçası olarak tanımlar. Bu nedenle depo yetkileri, yayın hattı ve sürüm doğrulaması teslimin teknik ayrıntısı değil, temel kabul maddesidir.
Son toplantıda “dosyalar geldi” demek yerine doğrulanabilir sonuçları kaydedin: deponun yeni sahibi, erişimi test edilen servisler, döndürülen sırlar, son yedek tarihi, çalışan sürüm etiketi, açık sorunlar ve destek bitiş tarihi. Her madde için teslim eden ve kabul eden kişi belli olsun.
Devir tamamlandıktan sonra eski ekip erişimlerinin gerçekten kaldırıldığını iki taraftan kontrol edin. Acil durumda kullanılacak hesap, iletişim kişisi ve kurtarma yöntemi de not edilmeli; fakat parolalar tutanağın içine yazılmamalıdır.
Müşteri sahipliği + yeniden kurulabilir sistem + döndürülmüş erişimler + çalışan kabul testi gerçek bir yazılım tesliminin omurgasıdır. Sizce devirlerde en sık unutulan parça depo sahipliği mi, sunucu erişimi mi, yoksa dokümantasyon mu? Eksik kalan senaryoyu yazın; listeyi birlikte genişletelim.
Güncelleme: 16 Ağustos 2026. Platformların aktarım ve yetki kuralları değişebileceği için işlem öncesi kullanılan hizmetin güncel belgesini kontrol edin.
Sağlam bir devirde amaç, müşterinin projeyi bağımsız olarak çalıştırabilmesi ve yeni ekibin nereden başlayacağını anlayabilmesidir. Bunun için kaynak kod, hesap sahipliği, sırlar, dokümantasyon ve çalışan bir kabul testi aynı paketin parçaları olmalı.
Önce “Teslim Edilecekler” Envanteri Çıkarın
Devir günü gelmeden proje varlıklarını tek listede toplayın. Liste yalnızca dosya adlarından oluşmasın; her varlığın sahibi, bulunduğu hizmet, yeni sorumlusu ve aktarım durumu da yazılsın.
- Kaynak depo: Tüm dallar, etiketler, sürümler, sorun kayıtları, pull request’ler ve Git LFS dosyaları.
- Çalışma ortamı: Alan adı, DNS, sunucu veya bulut, veritabanı, dosya depolama ve e-posta servisi.
- Dağıtım hattı: CI/CD iş akışları, container kayıtları, imzalama anahtarları ve yayın hedefleri.
- Üçüncü taraflar: Ödeme, harita, SMS, analiz, hata izleme ve mobil mağaza hesapları.
- Bilgi paketi: Kurulum, test, dağıtım, yedek geri yükleme, geri alma ve bilinen sorun notları.
Bu envanter sözleşmedeki “kaynak kod teslimi” maddesini somutlaştırır. Hangi lisansların, tasarım dosyalarının, verilerin veya harici hizmetlerin kapsama dahil olmadığı da aynı yerde açıkça belirtilmelidir.
Depoyu Kopyalamak mı, Sahipliğini Aktarmak mı?
Müşteriye yeni bir depo açıp son hâli yüklemek hızlı görünür; fakat commit geçmişi, sorunlar, sürümler ve otomasyon ayrıntıları kaybolabilir. Mümkünse proje, müşterinin yönettiği bir GitHub organizasyonunda tutulmalı ve kişilere görevleri kadar rol verilmelidir.
GitHub’ın depo aktarımı, içerikle birlikte issues, pull request’ler, releases ve ayarları da yeni sahibe taşır. Ancak webhooks, secrets ve deploy keys aktarım sonrasında depoyla ilişkili kalabilir. Bu yüzden “Transfer tamamlandı” ekranı güvenlik kontrolünün sonu değil, başlangıcıdır.
Kritik ayrım' Alıntı:
Erişimleri Şifre Listesiyle Devretmeyin
Ortak bir metin dosyasına kullanıcı adı ve parola yazmak yerine, her hizmette müşteriye ait hesap oluşturun ve isimli kullanıcı daveti gönderin. Önce yeni erişimin çalıştığını doğrulayın; sonra eski ekibin rolünü azaltın veya kaldırın.
API anahtarları, veritabanı parolaları, SSH anahtarları, deploy key’ler ve CI/CD sırları ayrıca ele alınmalıdır. Bunları kaynak koda ya da teslim belgesine düz metin olarak koymayın. Yeni sorumlu erişimi aldıktan sonra sırları döndürün; eski değerleri iptal edin ve hangi uygulamanın hangi sırrı kullandığını kaydedin.
OWASP sır yönetimini oluşturma, saklama, erişim kontrolü, döndürme, iptal ve süre sonu olan bir yaşam döngüsü olarak ele alıyor. Devir kontrol listesi de aynı mantığı izlemeli; yalnızca “anahtar gönderildi” kutusuna indirgenmemeli.
Yeni Ekip Projeyi Sıfırdan Kurabiliyor mu?
Teslim belgesinin doğruluğunu ölçmenin en iyi yolu, projeyi temiz bir ortamda kurmaktır. Yeni sorumlu kendi hesabıyla depoyu klonlamalı, bağımlılıkları kurmalı, testleri çalıştırmalı ve mümkünse deneme ortamına dağıtım yapmalıdır.
- Desteklenen çalışma zamanı ve araç sürümlerini doğrulayın.
- Örnek çevre değişkeni dosyasında yalnız anahtar adlarını ve açıklamaları tutun; gerçek sırları koymayın.
- Veritabanı migration ve başlangıç verisi adımlarını çalıştırın.
- Bir yedeği ayrı ortamda geri yükleyip okunabildiğini kontrol edin.
- Sağlık kontrolü, loglar ve hata bildirimlerinin yeni ekibe ulaştığını görün.
- Başarısız dağıtım için geri alma yolunu en azından masa başında değil, deneme ortamında sınayın.
NIST SSDF, kodun yetkisiz erişim ve kurcalamaya karşı korunmasını ve yazılım sürümlerinin bütünlüğünün sağlanmasını güvenli geliştirme sürecinin bir parçası olarak tanımlar. Bu nedenle depo yetkileri, yayın hattı ve sürüm doğrulaması teslimin teknik ayrıntısı değil, temel kabul maddesidir.
İmza Atmadan Önce Kısa Kabul Tutanağı
Son toplantıda “dosyalar geldi” demek yerine doğrulanabilir sonuçları kaydedin: deponun yeni sahibi, erişimi test edilen servisler, döndürülen sırlar, son yedek tarihi, çalışan sürüm etiketi, açık sorunlar ve destek bitiş tarihi. Her madde için teslim eden ve kabul eden kişi belli olsun.
Devir tamamlandıktan sonra eski ekip erişimlerinin gerçekten kaldırıldığını iki taraftan kontrol edin. Acil durumda kullanılacak hesap, iletişim kişisi ve kurtarma yöntemi de not edilmeli; fakat parolalar tutanağın içine yazılmamalıdır.
İç Bağlantılar
- Programlama hizmetinin kapsamını belirleme
- Yazılım geliştirmede veri odaklı çalışma
- Python ortamını yeniden kurulabilir hâle getirme
Resmî Kaynaklar
- GitHub depo aktarımı ve aktarılan varlıklar
- GitHub organizasyon depo rolleri
- NIST Secure Software Development Framework 1.1
- OWASP Secrets Management Cheat Sheet
Özetle
Müşteri sahipliği + yeniden kurulabilir sistem + döndürülmüş erişimler + çalışan kabul testi gerçek bir yazılım tesliminin omurgasıdır. Sizce devirlerde en sık unutulan parça depo sahipliği mi, sunucu erişimi mi, yoksa dokümantasyon mu? Eksik kalan senaryoyu yazın; listeyi birlikte genişletelim.
Güncelleme: 16 Ağustos 2026. Platformların aktarım ve yetki kuralları değişebileceği için işlem öncesi kullanılan hizmetin güncel belgesini kontrol edin.
Dijital Dünyanıza Yön Veren Pusula
