Bağımsız Geliştirici Olarak Zaten Sizin İçin Geçerli Olan Güvenlik Yükümlülükleri

Bağımsız geliştiriciler arasında yaygın bir inanış vardır: güvenlik ve gizlilik mevzuatının şirketlerin başına gelen bir şey olduğu — yükümlülüklerin ancak şirketleşince, bir DPO işe alınca ya da bir kurumsal sözleşme imzalanınca başladığı. Bu doğru değil ve yıllardır doğru değil. Müşteri verisiyle çalışan bir serbest çalışan ya da bağımsız geliştiriciyseniz, bugün, şahsen, mevcut ölçeğinizle zaten geçerli olan birçok yükümlülük vardır. Bu yazı bunların neler olduğunu, hangi düzenlemelerden kaynaklandığını ele alacak ve önemli olan pratik soruyla bitecek: hesaplarınızda şu anda somut olarak neler açıkta?

Bu yazının yapmayacağı bir şey var: hiçbir yasanın bir güvenlik aracı satın almanızı gerektirdiğini söylemek. Hiçbiri gerektirmiyor. Yasanın gerektirdiği şey, işlediğiniz veriyle ne yaptığınızı bilmeniz ve bunu uygun şekilde güvence altına almanızdır — bunun dürüst başlangıç noktası da müşteri işinizin barındığı hesaplarda hangi erişimin var olduğunu bilmektir.

GDPR kapsamında müşteri verisi işleyen bir serbest çalışan, doğrudan yükümlülükleri olan bir işleyendir

AB'deki bir müşteri (ya da kullanıcıları AB'de olan bir müşteri) size kişisel veri teslim ediyorsa — taşınacak bir kullanıcı veritabanı, hata ayıklanacak bir üretim sistemi, analiz edilecek bir dışa aktarım — neredeyse her zaman GDPR kapsamında bir veri işleyen olarak hareket ediyorsunuzdur; bazı işlerde de (neyi ne amaçla toplayacağınıza siz karar veriyorsanız) veri sorumlusu olarak. Bu statülerin hiçbiri bir şirket olmayı gerektirmez. GDPR'ın Madde 4'teki tanımları "gerçek veya tüzel bir kişi"ye bağlanır — dizüstü bilgisayarı olan bir kişi de bu tanıma uyar.

Bu statü doğrudan, kişisel yükümlülükler taşır:

• Madde 28, bir müşteri için yaptığınız işlemenin bir sözleşmeyle yönetilmesini şart koşar — kurumsal müşterilerinizin sürekli gönderdiği veri işleme sözleşmesi bürokratik bir gösteri değildir; her ikinizi de bağlayan yasal bir gerekliliktir ve sizi belirli güvenlik taahhütlerine bağlar.
• Madde 32, işlediğiniz kişisel veriyi güvence altına almak için "uygun teknik ve organizasyonel önlemler" uygulamanızı gerektirir — riske uygun önlemler, ki buna kimin ve neyin bu veriye erişebileceğini kontrol etmek de dahildir.
• Madde 33, bir işleyenin bir kişisel veri ihlalinden haberdar olduktan sonra "gereksiz gecikme olmaksızın" veri sorumlusunu bilgilendirmesini gerektirir — ki bu da böyle bir ihlalden haberdar olabilecek bir konumda olduğunuzu varsayar.
• Madde 82, veri sahiplerine, düzenlemeyi ihlal eden bir işlemeden kaynaklanan zarar için işleyenlerden tazminat alma hakkı tanır ve Madde 83, tüm bu çerçeveyi, en ciddi ihlaller için yirmi milyon avroya veya yıllık küresel cironun yüzde dördüne kadar (hangisi daha yüksekse) ulaşabilen idari para cezalarıyla destekler.

Kimse bir denetim otoritesinin bir serbest çalışana karşı ilk hamlesinin yasal üst sınır olacağını söylemiyor. Nokta daha basit: bu yükümlülükler gerçektir, doğrudan size bağlıdır ve "ben sadece tek bir kişiyim" düzenleme metninde tanınan bir istisna değildir.

AB Yapay Zeka Yasası, yapay zeka sistemlerini kullananlar için yükümlülükler ekler

Müşteri işiniz artık ürünlere yapay zeka entegre etmeyi de içeriyorsa — bir müşterinin uygulamasında bir asistan, bir iş akışını otomatikleştiren bir yapay zeka ajanı, insanları etkileyen kararlar alan bir model — AB Yapay Zeka Yasası sizinle ilgilidir. Bu Yasa yalnızca modelleri eğiten şirketleri düzenlemez; dağıtıcılara — yani bu yapay zeka sistemlerini kendi yetkileri altında profesyonel bir bağlamda kullananlara — da yükümlülükler yükler.

Madde 26, yüksek riskli yapay zeka sistemleri için dağıtıcı yükümlülüklerini belirler; buna sistemleri talimatlarına uygun kullanmak, uygun insan gözetimini sağlamak ve işleyişi izlemek dahildir. Madde 4, hem sağlayıcıların hem de dağıtıcıların, bu sistemleri kendi adlarına işleten kişilerde yeterli düzeyde yapay zeka okuryazarlığı sağlamalarını gerektirir. Madde 99 ise bu çerçeveyi, uyumsuzluk için idari para cezalarıyla destekler. Belirli bir iş için hangi yükümlülüklerin geçerli olduğu, sistemin ne yaptığına ve hangi risk kategorisine girdiğine bağlıdır — ama "ben sadece entegre ettim, ben yapmadım" tam olarak dağıtıcı kategorisinin yazılma sebebidir.

Burada sürekli gördüğümüz pratik bir ironi var: yapay zeka ajanı yönetişimi alanında bağımsız geliştiriciler, yapay zeka kodlama ajanlarının ve otomasyon botlarının en yoğun kullanıcılarıdır — ve bu ajanların nereye erişebildiğinin envanterine sahip olma ihtimali en düşük olanlardır. Bir yapay zeka ajanı sahip olduğunuz her depoya (repository) push yapabiliyorsa, bu, bir düzenleyici hiç sormasa bile güvenlik duruşunuzla ilgili bir gerçektir.

Kurumsal müşterileriniz zaten düzenlemeye tabidir — ve onların yükümlülükleri size de yansır

Hiçbir zaman AB kişisel verisine dokunmasanız ve hiçbir zaman bir yapay zeka sistemi dağıtmasanız bile, her büyüklükteki işletmeyle çalışan neredeyse tüm serbest çalışanlar için geçerli olan üçüncü bir güvenlik yükümlülüğü kaynağı vardır: sözleşmeler. Kurumsal müşteriler, denetçilerinin gerçekten kontrol ettiği SOC 2 raporları, ISO 27001 sertifikaları, GDPR Madde 28 işleyen gereklilikleri ve tedarikçi yönetimi programları altında faaliyet gösterir. Bu programlar 500 kişilik bir tedarikçi ile tek kişilik bir tedarikçi arasında ayrım yapmaz. Tedarikçi tedarikçidir.

Güvenlik anketinin sözleşmeden önce gelmeye devam etmesinin sebebi budur. Müşteriniz — kendi çerçevesi, denetçisi ya da kendi müşterileri tarafından — veri teslim ettiği kişilerden güvenlik kanıtı toplamakla yükümlüdür. Buna siz de dahilsiniz. ("Geliştirme ortamıma neyin erişimi var, bunu nasıl kontrol ediyorum, işte kanıt" diyerek) inandırıcı yanıt verebilen serbest çalışanlar, doğaçlama yapanlara göre bu anlaşmaları daha hızlı kapatır. Bu dinamiğin kurum tarafındaki versiyonunu denetçilerin 2026'da yapay zeka yönetişimi için neler istediği yazımızda ele aldık; tedarikçi tarafındaki versiyonu ise masanıza bir anket olarak düşer.

Bir ihlal bağımsız bir geliştiriciye gerçekte neye mal olur

Risk çerçevesi, çünkü bu dürüst çerçevedir: bir müşteri projesindeki bir güvenlik olayı, sözleşmenizin tazminat maddesi kapsamında doğrudan mali sorumluluk anlamına gelebilir, kişisel veri söz konusuysa GDPR Madde 82 kapsamında işleyen sorumluluğu anlamına gelebilir ve — bir serbest çalışan için en somut olanı — müşteri ilişkisinin ve beraberinde gelen referansın sonu anlamına gelebilir. Tek kişilik bir danışmanlık için itibar varlığı, işin kendisidir. Bunların hiçbiri varsayımsal bir egzotizm değildir; ele geçirilmiş bir kimlik bilgisinin ya da aşırı yetkilendirilmiş bir entegrasyonun bir müşteri verisi olayına dönüşmesinin sıradan sonuçlar zinciridir.

Peki hesabınızda şu anda gerçekte neler açıkta?

Sorunun rahatsız edici, somut hali işte bu. Müşteri işiniz neredeyse kesinlikle kişisel bir GitHub hesabında barınıyor. Bu hesap, yıllar süren projeler boyunca şunları biriktirdi:

• Yüklenen GitHub Uygulamaları — dağıtım botları, CI araçları, yapay zeka asistanları — her biri bir kez onayladığınız ve muhtemelen hiç gözden geçirmediğiniz bir izin verisi taşıyor. Bazıları sahip olduğunuz her şey üzerinde yazma veya yönetici (admin) yetkisi taşıyor. Bazıları 2024'te sona eren projelere ait.
• Dağıtım anahtarları (deploy keys) — sunucularda oturan, denetimsiz SSH kimlik bilgileri, bazıları yalnızca okuma amacıyla verilmiş olmasına rağmen sahip oldukları depoya yazma erişimi olan. Bu sunucu ele geçirilirse, okuma-yazma yetkili bir dağıtım anahtarı, müşterinizin ürününe kod enjeksiyonu yapılabilecek bir yoldur.
• İşbirlikçiler (Collaborators) — çoktan sona ermiş bir işbirliği sırasında eklediğiniz ama hâlâ yazma erişimine sahip kişiler, hatta bazı depolar herkese açık olsa bile.
• Depo (repository) açığa çıkması — hangi depolarınızın herkese açık olduğu ve içinde ne bulunduğu, çoğu geliştiricinin hafızasından yanıtlayamayacağı bir envanter sorusudur.

Bunların her biri GitHub'ın kendi API'si üzerinden makine tarafından okunabilir durumdadır, yani her biri kontrol edilebilir — hafızanıza güvenerek değil, bugün gerçekten erişimi olan şeyleri tek tek listeleyerek. Bu envanter tam olarak 8200.dev'in GitHub konektörünün artık yalnızca organizasyonlar için değil, kişisel hesaplar için de ürettiği şeydir: kendi GitHub girişinizi bağlayın, tarama yüklü uygulamaları ve izin verilerini, dağıtım anahtarlarını ve her birinin salt okunur olup olmadığını, depo başına işbirlikçileri ve bu grafikten çıkan bulguları listeler — unutulmuş yönetici yetkili bot, yazma yetkili dağıtım anahtarı, bir yıldır kimsenin dokunmadığı eski uygulama.

Ücretsiz kişisel katman tam taramayı çalıştırır ve en ciddi bulguları gösterir; ücretli kişisel katman — kurumsal yazılım gibi değil, bir kod tamamlama aboneliği gibi fiyatlandırılmış — sürekli izleme ve uyarılarla eksiksiz listenin kilidini açar. Bir organizasyon hesabına sahip bir ajansa büyürseniz de aynı tarama, aynı kurallar ve aynı kanıt izi sizinle birlikte ölçeklenir — bu, ürünün organizasyon tarafıdır ve aynı konektördür.

Yukarıdaki yükümlülükler, hiç tarama çalıştırmasanız bile sizin için geçerlidir. Taramanın değiştirdiği şey, bu yükümlülüklerin ima ettiği sorulara yanıt verip veremeyeceğinizdir — neyin, neden erişimi var ve kimsenin gerekçelendiremediği erişim için ne yaptınız. Ücretsiz katmanla başlayın, hesabınızda sessizce nelerin biriktiğini görün ve oradan karar verin — fiyatlandırma herkese açıktır, self-servistir ve sıfırdan başlar.

*Bu yazı, bağımsız geliştiricilere yaygın olarak uygulanan düzenlemeler hakkında genel bilgi niteliğindedir; hukuki tavsiye değildir ve her düzenlemenin sizin özel durumunuza nasıl uygulanacağı, bir tarama aracının bilemeyeceği gerçeklere bağlıdır. Bunun için bir avukatla görüşün.*