1 puan yazan GN⁺ 13 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Cal.com, yapay zeka tabanlı zafiyet tespit tehditlerini gerekçe göstererek çekirdek kodunu kapalı hale dönüştürdü ve “şeffaflığın maruziyet anlamına geldiği” bir döneme girildiğini söyledi
  • Strix, otonom yapay zeka güvenlik ajanları geliştiren bir açık kaynak proje olarak Cal.com ile birlikte sorumlu zafiyet açıklama süreci yürüttü
  • Strix, kodu kapatmanın yapay zeka güvenlik tehditlerine çözüm olmadığını, aksine iyi niyetli inceleme fırsatlarını engellediğini vurguluyor
  • Yapay zeka saldırıları, koda erişim olmadan da kara kutu yaklaşımıyla sızabilir; kapalı kod stratejisi otomatik saldırılara karşı savunmasız kalır
  • Gerçek çözüm, yapay zeka savunmasını geliştirme sürecine entegre etmek ve sürekli otomatik doğrulama ile açık kaynağın şeffaflık ve iş birliğini korumaktır

Cal.com'un kodu kapatma kararı ve açık kaynak güvenliği tartışması

  • Cal.com, çekirdek kod tabanını açık kaynaktan kapalı hale çevireceğini duyurdu
    • CEO Bailey Pumfleet, yapay zekanın büyük ölçekte zafiyetleri otomatik olarak bulabildiği ve “şeffaflığın maruziyet anlamına geldiği” bir döneme girildiğini söyledi
    • Gerekçe olarak, yapay zekanın kod tarama ve exploit işlemlerini neredeyse “sıfır maliyetle” yapabilir hale gelmesini gösterdi
  • Strix, otonom yapay zeka güvenlik ajanları geliştiren bir açık kaynak proje ve yakın zamanda GitHub'da 24 bin yıldızı geçti
    • Günde 15 milyardan fazla LLM token işleyerek yazılım zafiyetlerini tespit ediyor
    • Cal.com ile birlikte Strix kullanılarak sorumlu zafiyet açıklama süreci yürütüldü; henüz yamalanmamış hataların ayrıntıları açıklanmadı
    • Cal.com'un kararının kullanıcıları koruma isteğinden kaynaklandığını kabul ediyor
  • Ancak Strix, “kodu kapatmak yapay zeka tabanlı güvenlik tehditlerinin çözümü değildir” diye özellikle belirtiyor
    • Yapay zekanın güvenliği kökten değiştirdiği görüşüne katılsa da, açık kaynaktan vazgeçilmesine karşı çıkıyor

Kara kutu yapay zeka, kapalı koda da sızabilir

  • Kaynak kodu kapatmanın saldırganların kodu okuyamayacağı anlamına geleceği varsayımı, modern yapay zeka saldırı modelleri için geçerli değil
    • Bu yaklaşım geçmişte statik analiz araçları için işe yarayabilirdi, ancak otonom yapay zeka ajanları kod erişimi olmadan da saldırı gerçekleştirebilir
  • Strix gibi araçlar, kara kutu ve gri kutu testlerine odaklanıyor
    • Gerçek uç noktalarla etkileşime girerek tarayıcı durumunu manipüle etme, ağ trafiğini analiz etme ve iş mantığı zafiyetlerini tespit etme işlemlerini yapıyor
  • Kodu kapatmak yalnızca iyi niyetli geliştiricilerin inceleme fırsatını ortadan kaldırıyor; saldırganlara açık olan API, webhook gibi saldırı yüzeyleri ise yerinde duruyor

‘Gizleyerek güvenlik’ stratejisi otomatik saldırılar karşısında zayıf

  • Kapalı kod, iç güvenlik ekiplerine ve düzenli manuel sızma testlerine dayanıyor
    • Ancak saldırganlar, 7/24 zafiyet arayan sürekli çalışan yapay zeka botları kullanabiliyor
  • Bu yaklaşım, şirket içindeki ekiplerin dışarıdaki yapay zeka saldırılarından daha hızlı açık bulabileceği varsayımına dayanıyor; pratikte bu mümkün değil
  • Geçmişte de ‘gizleyerek güvenlik (Security through obscurity)’ başarısız olmuştu; yapay zeka çağında bu başarısızlığın hızı katlanarak artacak

Gerçek çözüm: yapay zekayı yine yapay zekayla savunmak

  • Yazılım geliştirme hızının, insanların güvenlik incelemesi yapma hızını geçtiği doğru
    • Ancak çözüm kodu gizlemek değil, yapay zeka savunmasını geliştirme sürecine entegre etmek
  • Yapay zeka tabanlı sürekli doğrulama (continuous validation) gerekiyor
    • Geliştirici bir Pull Request açtığında yapay zeka hemen saldırı denemelerine başlıyor
    • Altyapı değiştiğinde yapay zeka saldırı yüzeyini otomatik olarak doğruluyor
  • Güvenlik testleri CI/CD pipeline içinde otomatik hale getirilmeli; saldırı otomasyonundan daha iyi iç otomasyonla karşılık verilmesi gerekiyor

Açık kaynak hâlâ geçerli

  • “Yeterince çok göz, hataları yüzeysel hale getirir” şeklindeki geleneksel ilke zayıflıyor olabilir, ancak açık kaynak ölmedi
  • Strix, şeffaflığın güç yarattığı inancıyla açık kaynak kalmayı sürdürüyor
    • Yeni nesil güvenlik araçları, saldırı araçları kadar erişilebilir ve açık olmalı
  • Kodu gizlemek yapay zeka korsanlarını durduramaz; ancak geliştiricilere otonom güvenlik ajanları sağlamak, savunma olasılığını artırır
  • Strix, yapay zeka tabanlı sürekli güvenlik testini ücretsiz denemeye sunuyor

1 yorum

 
GN⁺ 13 일 전
Hacker News görüşleri
  • Ben bir açık kaynak proje işletiyorum ve son birkaç ayda güvenlik açığı raporlarında patlama oldu
    Çoğu önemsiz vakalardı ama gerçek sorunlar da vardı ve hepsini düzelttim
    Kapalı kaynak yazılımlar bu tür raporları almaz ama AI ile istismar edilme riski var
    Bu yüzden bu yazının mesajına tamamen katılıyorum

    • Kapalı olsa bile içeride AI tarayıcıları çalıştırılamaz mı?
      Sadece dışarıya kapalıdır, iç geliştiricilere kapalı değildir
    • Otomatik repo tarayıcılarından rapor gelmez ama bug bounty programları hâlâ çok sayıda rapor üretir
      Ancak AI araçları ortaya çıktığından beri yeni başlayanların AI'ın ürettiği hayali raporları göndermesi gibi bir sorun da var
      Kapalı şirketler de gönüllü olarak güvenlik denetimleri yapmalı
    • Saldırgan açısından AI kullanarak açık kaynak depolarına saldırmak çok daha kârlı
      Cal.com'un kapalı kaynağa geçmesini anlıyorum ama sonuçta bu daha çok Strix'in pazarlaması gibi görünüyor
      Açık kaynak şirketleri, açık kaldıkları sürece giderek daha fazla zarar görüyor
    • Ben de açık kaynak projeme gecelik otomatik sızma testleri kurdum
      Bu tür raporları düzenli olarak yayımlarsak güvenlik güvenilirliğini kanıtlayabiliriz gibi geliyor
      Ancak mevcut projelerde orta ve düşük seviyeli meseleler birikmiş durumda, bunları çözmek zaman alacak gibi
    • Şirketimiz içeride AI tarayıcıları ile manuel sızma testlerini birlikte kullanıyor
      Yani kod kapalıyken AI ile zafiyet tespiti ve çok katmanlı savunmadan aynı anda yararlanıyoruz
  • CEO'nun “AI büyük ölçekte açıkları otomatik tespit ediyor” sözü bahane gibi geliyor
    Asıl sebep muhtemelen açık kaynakla sürdürülebilir bir iş modeli kurmanın zor olması

    • Katılıyorum. Kârlılığı sağlamak için kapalı kaynağa geçmeyi anlamak mümkün ama güvenlik bahanesi dürüst değil
    • Biz 5 yıl boyunca açık kaynakla %300 büyüme oranını koruyup gelir elde ettik
      Kapalı kaynağa geçmek iş açısından aslında daha dezavantajlı ama müşteri verisini korumanın daha önemli olduğuna karar verdik
    • Bugünlerde her şeyi AI'ın üstüne atma eğilimi var
      İster çalışan azaltma olsun ister lisans değişikliği, “AI yüzünden” bahanesi kullanışlı oluyor
    • Artık açık kaynak kodu doğrudan kullanmadan sadece gereken kısımları çekip yeniden kurgulamak fazla kolay
      npmjs gibi yerler yakında birer referans sitesine dönüşebilir
    • 'cal.diy'yi bırakıp kurumsal tarafı kapatmak tipik bir open-core stratejisi
      Bunu AI tarayıcılarına bağlamak sadece PR ambalajından ibaret
  • Bu yazı tam anlamıyla content marketing ders kitabı gibi

    1. Kışkırtıcı bir başlıkla dikkat çekiyor
    2. Cal.com'un pozisyonuna empati kurarak okurun sempatisini kazanıyor
    3. Soruna ciddi bir çözüm öneriyor
    4. Sonunda da doğal biçimde kendi ürününün tanıtımına bağlanıyor
      Samimiyetle pazarlamanın ustaca karıştığı bir örnek
    • Ben de öyle okudum. Yazıyı yazan şirket AI güvenlik açığı tarama hizmeti satıyor, yani sonuçta amaç kayıt toplamak
      Nitekim Strix Cal.com kodunu taradı ama birçok açığı kaçırdı
      Hiçbir platform kusursuz değil ve yalnızca AI tarayıcıları yeterli değil
    • Bu yazının bu kadar çok oy almış olmasına üzüldüm. İçerik yoğunluğu bir yorum kadar
    • Ben kişisel olarak AI kullanmıyorum. Şu anda AI rüzgârına kapılmak pazarlama açısından kolay, ama gerçek değer üretip üretmediği tartışmalı
  • Security through obscurity” tek başına kullanıldığında ancak sorun olur
    Saldırganın maliyetini artıran bir caydırıcılık katmanı olarak geçerli bir stratejidir
    Sonuçta güvenlik, hangi tarafın daha fazla kaynak koyduğunun mücadelesidir
    AI'ın insanlardan daha verimli olması dışında, açık ve kapalı arasındaki temel denklem değişmiş değil

  • Cal.com gerçekten güvenlik konusunda mı endişeli, yoksa açık kaynak SaaS'in zorluklarını örtmek için mi bunu bahane ediyor, merak ediyorum
    Bu mantığın yanlış olduğu onlarca yıl önce zaten kanıtlanmıştı

  • Obscurity ile güvenlik”in gerçek sebep olduğuna inanmıyorum
    Sadece açık kaynağı kapatırsa daha fazla para kazanabileceğini düşündü

    • Aynen öyle. Ürün onların, istediklerini yapabilirler
      Açık kaynağın çirkin taraflarından biri, insanların ücretsiz emeği doğal hakları gibi görmesi
      Yıllarca bedava çalışan geliştiricilere teşekkür etmek yerine, artık ücretsiz çalışmadıkları için öfkeleniyorlar
      Kendileri maaşsız çalışmazken bunu yapmaları ayrı bir ironi
  • Yazıya bakınca Cal.com sanki red-team botuyla zafiyet testi yaptırmış gibi görünüyor
    Hatalar çok hızlı bulununca CEO'nun düzeltme maliyetinden çekinip kodu kapatmış olması mümkün
    Neredeyse “Cal.com kodunda çok fazla açık var” diye kamusal bir ilan gibi duruyor

    • Ya da tarayıcı çok fazla false positive ürettiği için sorun olmuştur
      Bunu ayarlarsanız gerçek açıkları kaçırma riski doğar ve sonuçta doğrulama maliyeti artar
      Açık kaynakta bu raporlar görünür olduğu için itibar kaybı yaşanır, kapalı kaynakta ise yaşanmaz
      Bu yüzden kapalıya geçmiş olmaları da mümkün
  • Asıl risk açık tespiti değil, LLM'lerin açık kaynak projeleri başka dillere yeniden yazarak lisansı aşabilmesi

    • Teorik olarak aynı şey kapalı kaynak projelerde de mümkün ama kısıtlar daha fazla
    • Bu pratikte sık yaşanıyor. AI kodu neredeyse aynen yeniden üretip kopya projeler oluşturabiliyor
      Hukuken gri bir alan. Bir insan öğrenip baştan yazarsa sorun olmaz, ama AI yapınca bu fiilen karmaşık bir kopyala-yapıştır oluyor
      Böyle durumlarda lisansın nasıl uygulanacağı belirsiz
    • Birçok açık kaynak lisansı fork ve yeniden satışa izin verir
      Sadece kodu açmakla iş kurulmaz; asıl önemli olan operasyon kabiliyetidir
  • “Güvenlik testleri CI/CD pipeline'ına otomatikleştirilmeli” görüşüne katılıyorum
    Ama bunun açık kaynağın gerekliliğini kanıtladığını düşünmüyorum

  • Açık kaynağın dengesi zaten uzun zaman önce bozuldu
    Şirketlerin açık kaynak kod kullanıp ücretli ürünler üretirken katkı yapmaması uzun süredir var olan bir yapı
    PHP bunun iyi bir örneği; dünya çapında kullanılıyor ama bütçesi yetersiz bir dil olmaya devam ediyor