ओपन सोर्स मरा नहीं है

 (strix.ai)
1 पॉइंट द्वारा GN⁺ 15 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Cal.com ने AI-आधारित vulnerability detection खतरों का हवाला देते हुए अपने core code को private करने का फैसला किया है, और कहा है कि हम ऐसे दौर में हैं जहाँ “पारदर्शिता ही exposure बन जाती है”
  • Strix एक open source project है जो autonomous AI security agents विकसित करता है, और उसने Cal.com के साथ मिलकर responsible vulnerability disclosure process पर काम किया है
  • Strix का कहना है कि code को private करना AI security threats का समाधान नहीं है, बल्कि यह सद्भावना से होने वाली review के अवसरों को रोकता है
  • AI attacks code access के बिना भी black-box तरीके से घुसपैठ कर सकते हैं, और private strategy automated attacks के सामने कमजोर है
  • असली समाधान है AI defense को development process में integrate करना और लगातार automated validation के जरिए open source की पारदर्शिता और सहयोग को बनाए रखना

Cal.com का code private करना और open source security पर बहस

  • Cal.com ने घोषणा की कि वह अपने core codebase को open source से private में बदल रहा है
    • CEO Bailey Pumfleet ने कहा कि अब AI बड़े पैमाने पर vulnerabilities को अपने-आप खोज सकता है, इसलिए हम ऐसे समय में पहुँच चुके हैं जहाँ “पारदर्शिता ही exposure बन जाती है”
    • उन्होंने यह भी कारण बताया कि AI अब code scanning और exploit को लगभग ‘zero cost’ पर कर सकता है
  • Strix एक open source project है जो autonomous AI security agents बनाता है, और हाल ही में 24k GitHub stars पार कर चुका है
    • यह हर दिन 15 अरब से अधिक LLM tokens प्रोसेस करके software vulnerabilities खोजता है
    • Cal.com के साथ मिलकर Strix ने responsible vulnerability disclosure process चलाया, और जिन bugs का patch अभी तक नहीं हुआ है, उनकी details सार्वजनिक नहीं कीं
    • Strix मानता है कि Cal.com का फैसला users की सुरक्षा करने की मंशा से लिया गया है
  • लेकिन Strix यह भी ज़ोर देकर कहता है कि “code को बंद करना AI-आधारित security threats का समाधान नहीं है”
    • वह इस बात से सहमत है कि AI ने security को बुनियादी रूप से बदल दिया है, लेकिन open source छोड़ने के पक्ष में नहीं है

Black-box AI private code में भी घुस सकता है

  • यह मान लेना कि source code बंद कर देने से attackers उसे पढ़ नहीं पाएँगे, आधुनिक AI attack models पर लागू नहीं होता
    • यह बात पुराने static analysis tools के लिए सही हो सकती थी, लेकिन autonomous AI agents code access के बिना भी attack कर सकते हैं
  • Strix जैसे tools black-box और gray-box testing में खास तौर पर सक्षम हैं
    • ये real endpoints के साथ interact करते हुए browser state manipulation, network traffic analysis, और business logic vulnerabilities detection करते हैं
  • code को private करना सिर्फ सद्भावना वाले developers की review का मौका रोकता है, जबकि attackers के सामने मौजूद API, webhooks जैसी attack surface वैसे की वैसी रहती हैं

‘Security through obscurity’ रणनीति automated attacks के सामने कमजोर है

  • private code का मतलब अक्सर internal security teams और periodic manual penetration testing पर निर्भर रहना होता है
    • लेकिन attackers के पास 24x7 चलने वाले AI bots होते हैं जो लगातार vulnerabilities खोजते रहते हैं
  • यह इस धारणा पर आधारित है कि internal teams बाहरी AI attacks से ज़्यादा तेज़ी से flaws ढूँढ लेंगी, लेकिन व्यवहार में यह संभव नहीं है
  • पहले भी ‘security through obscurity’ विफल रही है, और AI के दौर में इसकी विफलता की रफ़्तार exponential रूप से बढ़ेगी

असली समाधान: AI से AI का बचाव

  • यह सच है कि software development की रफ़्तार इंसानी security review की गति से आगे निकल चुकी है
    • लेकिन समाधान code छिपाना नहीं, बल्कि AI defense को development process में integrate करना है
  • AI-आधारित continuous validation की ज़रूरत है
    • developer जैसे ही Pull Request खोले, AI तुरंत हमला करने की कोशिश करे
    • infrastructure changes होने पर AI अपने-आप attack surface validate करे
  • CI/CD pipeline के भीतर security testing को automate किया जाना चाहिए, और attack automation से बेहतर internal automation के साथ जवाब देना होगा

Open source अब भी प्रासंगिक है

  • “कई लोगों की नज़र bugs को उथला बना देती है” वाला पारंपरिक सिद्धांत कमज़ोर पड़ सकता है, लेकिन open source खुद खत्म नहीं हुआ है
  • Strix पारदर्शिता को ताकत मानते हुए open source बना हुआ है
    • अगली पीढ़ी के security tools को attack tools जितना ही सुलभ और खुला होना चाहिए
  • code छिपाने से AI hackers को रोका नहीं जा सकता, लेकिन developers को autonomous security agents देकर defense की संभावना बढ़ाई जा सकती है
  • Strix AI-आधारित continuous security testing को मुफ्त में आज़माने की सुविधा देता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 15 일 전
Hacker News की राय

  • मैं एक open source प्रोजेक्ट चला रहा हूँ, और पिछले कुछ महीनों में security vulnerability reports बहुत बढ़ गई हैं
    ज़्यादातर मामूली केस थे, लेकिन कुछ असली समस्याएँ भी थीं, और मैंने सब ठीक कर दीं
    बंद source software को ऐसी reports नहीं मिलेंगी, लेकिन AI द्वारा दुरुपयोग का जोखिम है
    इसलिए मैं इस लेख के संदेश से पूरी तरह सहमत हूँ

    • बंद source होने पर भी क्या अंदरूनी तौर पर AI scanner नहीं चलाए जा सकते?
      यह सिर्फ बाहर के लिए बंद है, अंदर के developers के लिए नहीं
    • automated repo scanners से reports नहीं आएँगी, लेकिन bug bounty program अब भी बहुत सारी reports बनाते हैं
      बस AI tools आने के बाद अब नए लोग AI द्वारा बनाई गई काल्पनिक reports भी submit करने लगे हैं
      बंद source कंपनियों को भी स्वेच्छा से security audit करना चाहिए
    • attacker के नज़रिए से AI का इस्तेमाल करके open source repositories पर हमला करना कहीं ज़्यादा फायदेमंद है
      Cal.com का बंद source में जाना समझ में आता है, लेकिन आखिरकार यह Strix की marketing जैसा लगता है
      open source कंपनियों के लिए खुले बने रहने का नुकसान लगातार बढ़ता जाता है
    • मैंने भी अपने open source प्रोजेक्ट पर रात का automated penetration test सेट किया है
      अगर ऐसी reports नियमित रूप से public की जाएँ, तो शायद security trust साबित किया जा सकता है
      लेकिन पुराने प्रोजेक्ट्स में medium और low severity issues पहले से जमा हैं, इसलिए उन्हें ठीक करने में समय लगेगा
    • हमारी कंपनी अंदरूनी तौर पर AI scanners और manual penetration testing दोनों साथ चलाती है
      यानी code private रखते हुए AI vulnerability detection और layered defense दोनों का उपयोग कर रही है

  • CEO ने जो कहा कि “AI बड़े पैमाने पर vulnerabilities अपने-आप ढूँढ़ लेती है”, वह बहाने जैसा लगता है
    असली वजह शायद यह है कि open source से sustainable business model बनाना मुश्किल है

    • सहमत। profitability के लिए बंद source में जाना समझ में आता है, लेकिन security का बहाना ईमानदार नहीं लगता
    • हमने 5 साल तक open source के साथ 300% growth rate बनाए रखते हुए revenue कमाया है
      बंद source में जाना business के लिए उल्टा नुकसानदेह है, लेकिन हमने customer data protection को ज़्यादा महत्वपूर्ण माना
    • आजकल हर चीज़ का दोष AI पर डालने का चलन है
      चाहे layoffs हों या license change, “AI की वजह से” कहना एक आसान बहाना बन गया है
    • अब open source code को सीधे इस्तेमाल किए बिना ज़रूरी हिस्से निकालकर दोबारा बनाना बहुत आसान हो गया है
      npmjs जैसी जगहें जल्द ही शायद reference sites बनकर रह जाएँ
    • ‘cal.diy’ को खुला छोड़कर enterprise version को बंद करना एक क्लासिक open-core strategy है
      इसका दोष AI scanners पर डालना सिर्फ PR packaging भर है

  • यह लेख सचमुच content marketing की पाठ्यपुस्तक जैसा लगता है

    1. सनसनीखेज शीर्षक से ध्यान खींचो
    2. Cal.com की स्थिति से सहानुभूति दिखाकर पाठक की सहमति लो
    3. समस्या का गंभीर समाधान पेश करो
    4. और आखिर में सहज रूप से अपने product के प्रचार तक पहुँचो
      यह sincerity और marketing के बहुत महीन मिश्रण का उदाहरण है
    • मैंने भी इसे ऐसे ही पढ़ा। यह पोस्ट लिखने वाली कंपनी AI vulnerability scanning service बेचती है, इसलिए आखिरकार मकसद signup कराना ही है
      वास्तव में Strix ने Cal.com के code को scan किया था, लेकिन कई vulnerabilities छूट गईं
      कोई भी platform perfect नहीं होता, और सिर्फ AI scanners काफ़ी नहीं हैं
    • अफसोस है कि इस लेख को इतनी ज़्यादा upvotes मिलीं। content density एक comment जितनी है
    • मैं व्यक्तिगत रूप से AI का उपयोग नहीं करता। इस समय AI hype पर सवार होना marketing के लिहाज़ से आसान है, लेकिन इसमें असली value है या नहीं, इस पर शक है

  • “Security through obscurity” अपने-आप में इस्तेमाल हो तभी समस्या है
    attacker की cost बढ़ाने वाली deterrence layer के रूप में यह एक वैध strategy है
    आखिरकार security इस बात की लड़ाई है कि कौन ज़्यादा resources झोंकता है
    AI सिर्फ इंसानों से ज़्यादा efficient है, लेकिन open बनाम closed की मूल गणना नहीं बदलती

  • समझ नहीं आता कि Cal.com सच में security को लेकर चिंतित है, या यह open source SaaS की मुश्किलों को ढकने का बहाना है
    यह तर्क तो दशकों पहले ही गलत साबित हो चुका है

  • मुझे नहीं लगता कि “obscurity-based security” असली वजह है
    बस उन्हें लगा होगा कि open source बंद करके ज़्यादा revenue कमाया जा सकता है

    • सही बात। product उनका है, वे जैसा चाहें कर सकते हैं
      open source का एक बदसूरत पहलू यह है कि लोग मुफ़्त मेहनत को स्वाभाविक मान लेते हैं
      जो developers सालों तक बिना पैसे काम करते रहे, उन्हें धन्यवाद देने के बजाय लोग इस बात पर नाराज़ होते हैं कि वे आगे भी मुफ़्त में काम क्यों नहीं कर रहे
      जबकि खुद वे बिना salary के काम नहीं करेंगे

  • लेख पढ़कर लगता है कि Cal.com ने शायद red-team bots से vulnerability testing करवाई थी
    bugs बहुत जल्दी मिलने लगे, तो हो सकता है CEO को fixing cost का बोझ भारी लगा हो और उन्होंने code बंद कर दिया हो
    यह लगभग “Cal.com के code में बहुत vulnerabilities हैं” जैसी public declaration लगती है

    • या फिर scanner ने false positives बहुत ज़्यादा निकाले हों, यही समस्या रही हो सकती है
      उन्हें tune करो तो असली vulnerabilities छूट सकती हैं, और आखिरकार verification cost बढ़ जाती है
      open source में ऐसी reports public हो जाती हैं, जिससे reputation damage होता है, लेकिन closed source में ऐसा नहीं होता
      इसलिए शायद उन्होंने बंद source में जाने का फैसला किया हो

  • असली खतरा vulnerability detection नहीं, बल्कि LLM की यह क्षमता है कि वह open source projects को दूसरी भाषाओं में फिर से लिखकर license को bypass कर दे

    • सैद्धांतिक रूप से closed source projects के साथ भी ऐसा हो सकता है, लेकिन पाबंदियाँ ज़्यादा हैं
    • वास्तव में यह अक्सर होता है। AI code को लगभग ज्यों का त्यों फिर से बनाकर clone projects तैयार कर देता है
      कानूनी रूप से यह धुंधला क्षेत्र है। कोई इंसान सीखकर नया लिखे तो ठीक माना जाता है, लेकिन AI करे तो यह असल में जटिल copy-paste जैसा है
      ऐसे मामलों में license कैसे लागू होगा, यह स्पष्ट नहीं है
    • कई open source licenses fork और resale की अनुमति देते हैं
      सिर्फ code public कर देने से business नहीं बनता, operational capability ज़्यादा महत्वपूर्ण है

  • “security testing को CI/CD pipeline में automate किया जाना चाहिए” इस बात से सहमत हूँ
    लेकिन इससे open source की अनिवार्यता साबित नहीं होती

  • open source का संतुलन तो बहुत पहले ही बिगड़ चुका था
    कंपनियाँ open source code का इस्तेमाल करके paid products बनाती हैं, लेकिन योगदान नहीं करतीं — यह ढाँचा बहुत पहले से मौजूद है
    PHP इसका उदाहरण है, जिसे पूरी दुनिया इस्तेमाल करती है लेकिन जिसके पास बजट की कमी रहती है