โอเพนซอร์สยังไม่ตาย

 (strix.ai)
1 คะแนน โดย GN⁺ 13 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Cal.com เปลี่ยนโค้ดหลักเป็นแบบปิดด้วยเหตุผลเรื่องภัยคุกคามจากการตรวจหาช่องโหว่ด้วย AI โดยกล่าวถึงยุคที่ “ความโปร่งใสเท่ากับการเปิดช่องให้ถูกโจมตี”
  • Strix เป็นโปรเจกต์โอเพนซอร์สที่พัฒนา เอเจนต์ความปลอดภัย AI แบบอัตโนมัติ และทำงานร่วมกับ Cal.com ในกระบวนการ เปิดเผยช่องโหว่อย่างมีความรับผิดชอบ
  • Strix ชี้ว่าการปิดโค้ด ไม่ใช่วิธีแก้ภัยคุกคามด้านความปลอดภัยจาก AI และกลับกันยัง ปิดกั้นโอกาสในการตรวจสอบจากผู้หวังดี
  • การโจมตีด้วย AI สามารถเจาะระบบแบบแบล็กบ็อกซ์ได้แม้ไม่เข้าถึงโค้ด และกลยุทธ์แบบปิดก็ยังเปราะบางต่อการโจมตีอัตโนมัติ
  • ทางแก้ที่แท้จริงคือ ผสานการป้องกันด้วย AI เข้ากับกระบวนการพัฒนา และรักษา ความโปร่งใสและการทำงานร่วมกัน ของโอเพนซอร์สไว้ด้วย การตรวจสอบอัตโนมัติอย่างต่อเนื่อง

การเปลี่ยนโค้ดของ Cal.com เป็นแบบปิด และข้อถกเถียงเรื่องความปลอดภัยของโอเพนซอร์ส

  • Cal.com ประกาศว่าจะเปลี่ยนโค้ดเบสหลักจากโอเพนซอร์สเป็นแบบปิด
    • CEO Bailey Pumfleet ระบุว่าเราเข้าสู่ยุคที่ AI สามารถตรวจหาช่องโหว่ได้โดยอัตโนมัติในวงกว้าง จน “ความโปร่งใสเท่ากับการเปิดช่องให้ถูกโจมตี”
    • เขายกเหตุผลว่า AI ทำให้การสแกนโค้ดและการใช้ประโยชน์จากช่องโหว่ทำได้แทบจะด้วยต้นทุน “เป็นศูนย์”
  • Strix เป็นโปรเจกต์โอเพนซอร์สที่พัฒนา เอเจนต์ความปลอดภัย AI แบบอัตโนมัติ และเพิ่งมียอด 24k GitHub stars
    • ประมวลผล LLM tokens มากกว่า 15 พันล้านรายการต่อวัน เพื่อตรวจหาช่องโหว่ซอฟต์แวร์
    • ได้ทำงานร่วมกับ Cal.com เพื่อดำเนินการ เปิดเผยช่องโหว่อย่างมีความรับผิดชอบ โดยใช้ Strix และยังไม่เปิดเผยรายละเอียดของบั๊กที่ยังไม่ได้แพตช์
    • ยอมรับว่าการตัดสินใจของ Cal.com มีที่มาจาก ความตั้งใจที่จะปกป้องผู้ใช้
  • อย่างไรก็ตาม Strix เน้นย้ำว่า “การปิดโค้ดไม่ใช่วิธีแก้ภัยคุกคามด้านความปลอดภัยจาก AI”
    • แม้จะเห็นด้วยว่า AI ได้เปลี่ยนภูมิทัศน์ด้านความปลอดภัยไปอย่างสิ้นเชิง แต่ก็ ไม่เห็นด้วยกับการละทิ้งโอเพนซอร์ส

AI แบบแบล็กบ็อกซ์สามารถเจาะระบบที่ปิดโค้ดได้เช่นกัน

  • สมมติฐานที่ว่าเมื่อปิดซอร์สโค้ดแล้วผู้โจมตีจะอ่านโค้ดไม่ได้ ใช้ไม่ได้กับโมเดลการโจมตีด้วย AI ในปัจจุบัน
    • อาจเคยใช้ได้กับเครื่องมือวิเคราะห์แบบสแตติกในอดีต แต่ เอเจนต์ AI แบบอัตโนมัติ สามารถโจมตีได้แม้ไม่เข้าถึงโค้ด
  • เครื่องมืออย่าง Strix เชี่ยวชาญด้าน การทดสอบแบบแบล็กบ็อกซ์และเกรย์บ็อกซ์
    • โดยโต้ตอบกับเอนด์พอยต์จริง พร้อมทำ การจัดการสถานะของเบราว์เซอร์, การวิเคราะห์ทราฟฟิกเครือข่าย และ การตรวจหาช่องโหว่ในบิสซิเนสลอจิก
  • การปิดโค้ดมีแต่จะ ตัดโอกาสการตรวจสอบของนักพัฒนาที่หวังดี ขณะที่ พื้นผิวการโจมตี อย่าง API และเว็บฮุกที่เปิดเผยต่อผู้โจมตียังคงอยู่เหมือนเดิม

กลยุทธ์ ‘ซ่อนเพื่อความปลอดภัย’ เปราะบางต่อการโจมตีอัตโนมัติ

  • โค้ดแบบปิดต้องพึ่งพาทีมความปลอดภัยภายในและ การทดสอบเจาะระบบด้วยมือเป็นระยะ
    • แต่ฝั่งผู้โจมตีมี บอต AI ที่ทำงานได้ไม่รู้จบ คอยค้นหาช่องโหว่ตลอด 24 ชั่วโมง
  • นี่ตั้งอยู่บนสมมติฐานว่าทีมภายในจะสามารถหาข้อบกพร่องได้ เร็วกว่าการโจมตีด้วย AI จากภายนอก ซึ่งในความเป็นจริงแทบเป็นไปไม่ได้
  • ในอดีต ‘Security through obscurity’ ก็ล้มเหลวมาแล้ว และ ในยุค AI ความล้มเหลวนั้นจะยิ่งเกิดเร็วขึ้นแบบทวีคูณ

ทางออกจริง: ใช้ AI ป้องกัน AI

  • เป็นความจริงที่ความเร็วในการพัฒนาซอฟต์แวร์ได้แซงความเร็วของการตรวจสอบความปลอดภัยโดยมนุษย์ไปแล้ว
    • แต่คำตอบคือ ไม่ใช่การซ่อนโค้ด แต่คือการผสานการป้องกันด้วย AI เข้ากับกระบวนการพัฒนา
  • จำเป็นต้องมี การตรวจสอบต่อเนื่องด้วย AI (continuous validation)
    • เมื่อนักพัฒนาเปิด Pull Request, AI ควรเริ่มพยายามโจมตีทันที
    • เมื่อมีการเปลี่ยนแปลงโครงสร้างพื้นฐาน AI ควร ตรวจสอบพื้นผิวการโจมตีโดยอัตโนมัติ
  • การทดสอบความปลอดภัยควรถูกทำให้เป็นอัตโนมัติภายใน CI/CD pipeline และ ต้องรับมือด้วย ระบบอัตโนมัติภายในที่ดีกว่าระบบอัตโนมัติของฝั่งโจมตี

โอเพนซอร์สยังคงใช้ได้

  • แม้หลักการดั้งเดิมที่ว่า “สายตาจำนวนมากช่วยให้บั๊กตื้นขึ้น” อาจอ่อนแรงลง แต่ โอเพนซอร์สเองยังไม่ตาย
  • Strix ยังคงรักษาความเป็นโอเพนซอร์สไว้ ด้วยความเชื่อว่า ความโปร่งใสสร้างจุดแข็ง
    • เครื่องมือความปลอดภัยยุคถัดไปควร เข้าถึงได้และเปิดกว้าง พอๆ กับเครื่องมือโจมตี
  • การซ่อนโค้ดอาจ หยุดแฮ็กเกอร์ AI ไม่ได้ แต่ หากมอบเอเจนต์ความปลอดภัยอัตโนมัติให้นักพัฒนา ก็จะเพิ่มโอกาสในการป้องกันได้
  • Strix เปิดให้ทดลองใช้ การทดสอบความปลอดภัยต่อเนื่องด้วย AI ได้ฟรี

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 13 일 전
ความเห็นจาก Hacker News

  • ฉันดูแลโปรเจ็กต์โอเพนซอร์สอยู่ และในช่วงไม่กี่เดือนที่ผ่านมา รายงานช่องโหว่ความปลอดภัย เพิ่มขึ้นอย่างมาก
    ส่วนใหญ่เป็นเคสเล็กน้อย แต่ก็มีปัญหาจริงอยู่ด้วย และฉันก็แก้ทั้งหมดแล้ว
    ซอฟต์แวร์แบบปิดอาจไม่ได้รับรายงานแบบนี้ แต่ก็มี ความเสี่ยงที่จะถูก AI นำไปใช้โจมตี
    เพราะงั้นฉันเห็นด้วยกับสารของบทความนี้เต็มที่

    • ถึงจะเป็นซอฟต์แวร์ปิด ก็ยังรัน AI scanner ภายในองค์กรได้ไม่ใช่หรือ?
      แค่ปิดต่อคนนอก แต่ไม่ได้ปิดต่อทีมพัฒนาภายใน
    • อาจไม่ได้รับรายงานจากตัวสแกน repo อัตโนมัติ แต่ โปรแกรม bug bounty ก็ยังสร้างรายงานได้เยอะอยู่ดี
      เพียงแต่พอมีเครื่องมือ AI ก็เริ่มเกิดปัญหาที่มือใหม่ส่งรายงานหลอน ๆ ที่ AI ปั้นขึ้นมา
      บริษัทซอฟต์แวร์ปิดก็ควรทำ security audit ด้วยความสมัครใจเช่นกัน
    • ในมุมของผู้โจมตี การใช้ AI โจมตีคลังโอเพนซอร์สนั้นคุ้มกว่ามาก
      ฉันพอเข้าใจที่ Cal.com เปลี่ยนไปเป็นแบบปิด แต่สุดท้ายมันก็ดูเหมือน การตลาดของ Strix
      บริษัทโอเพนซอร์สยิ่งเปิดต่อไปนานเท่าไร ก็ยิ่งเสียเปรียบมากขึ้น
    • ฉันเองก็ตั้งค่า การทดสอบเจาะระบบอัตโนมัติช่วงกลางคืน ให้กับโปรเจ็กต์โอเพนซอร์สของตัวเองแล้ว
      ถ้าเผยแพร่รายงานพวกนี้เป็นระยะ ๆ ก็น่าจะช่วยพิสูจน์ความน่าเชื่อถือด้านความปลอดภัยได้
      แต่โปรเจ็กต์เดิมมีปัญหาระดับกลางถึงต่ำสะสมอยู่ เลยน่าจะต้องใช้เวลาแก้อีกพอสมควร
    • บริษัทของเราทำทั้ง AI scanner และการทดสอบเจาะระบบแบบแมนนวล ควบคู่กันภายใน
      กล่าวคือ เราใช้ทั้งการตรวจหาช่องโหว่ด้วย AI และการป้องกันหลายชั้น โดยที่โค้ดยังไม่เปิดเผยสู่ภายนอก

  • เหตุผลที่ CEO บอกว่า “AI ตรวจพบช่องโหว่ได้อัตโนมัติในวงกว้าง” ฟังดูเหมือน ข้ออ้าง
    เหตุผลจริงน่าจะเป็นเพราะโอเพนซอร์สทำ โมเดลธุรกิจที่ยั่งยืน ได้ยากมากกว่า

    • เห็นด้วย เข้าใจได้ถ้าจะเปลี่ยนเป็นแบบปิดเพื่อให้ทำกำไรได้ แต่การอ้าง เรื่องความปลอดภัย ไม่ค่อยตรงไปตรงมา
    • เราโต 300% และยังทำกำไรได้ตลอด 5 ปีในฐานะโอเพนซอร์ส
      การเปลี่ยนเป็นแบบปิดกลับไม่เป็นผลดีต่อธุรกิจ แต่เราตัดสินใจว่าการปกป้องข้อมูลลูกค้าสำคัญกว่า
    • ทุกวันนี้อะไรก็ โทษ AI กันหมด
      จะลดคนหรือเปลี่ยนไลเซนส์ก็ใช้ข้ออ้างว่า “เพราะ AI” กันได้สะดวก
    • ตอนนี้มันง่ายมากที่จะไม่ใช้โค้ดโอเพนซอร์สตรง ๆ แต่ หยิบเฉพาะส่วนที่ต้องการ ไปจัดใหม่
      เว็บไซต์อย่าง npmjs อาจกลายเป็นแค่ เว็บอ้างอิง ในไม่ช้า
    • การคง cal.diy ไว้ แล้วปิดส่วนสำหรับองค์กร เป็นกลยุทธ์ open core แบบคลาสสิก
      การโทษ AI scanner ก็เป็นแค่ การห่อด้วย PR เท่านั้น

  • บทความนี้เหมือน ตำรา content marketing จริง ๆ

    1. ใช้พาดหัวแรง ๆ ดึงความสนใจ
    2. ทำให้ผู้อ่านคล้อยตามจุดยืนของ Cal.com เพื่อสร้างความรู้สึกร่วม
    3. เสนอทางออกของปัญหาอย่างจริงจัง
    4. แล้วสุดท้ายก็พาไปสู่การโปรโมตสินค้าของตัวเองอย่างเป็นธรรมชาติ
      เป็นกรณีตัวอย่างที่ผสมความจริงใจกับการตลาดได้อย่างแนบเนียน
    • ฉันก็อ่านแบบนั้นเหมือนกัน บริษัทที่เขียนบทความนี้ขาย บริการสแกนหาช่องโหว่ด้วย AI อยู่แล้ว เลยสุดท้ายก็เพื่อชวนให้สมัคร
      ในความเป็นจริง Strix สแกนโค้ดของ Cal.com แล้ว แต่ พลาดช่องโหว่ไปหลายจุด
      ไม่มีแพลตฟอร์มไหนสมบูรณ์แบบ และแค่ AI scanner อย่างเดียวก็ไม่พอ
    • เสียดายที่บทความนี้ได้โหวตเยอะขนาดนี้ เพราะ ความหนาแน่นของเนื้อหา มีแค่ระดับคอมเมนต์เดียว
    • ส่วนตัวฉันไม่ใช้ AI เลย ณ ตอนนี้การเกาะกระแส กระแส AI เป็นเรื่องง่ายในเชิงการตลาด แต่ยังสงสัยว่ามีคุณค่าจริงหรือไม่

  • “Security through obscurity” (ความปลอดภัยด้วยการซ่อน) จะมีปัญหาก็ต่อเมื่อใช้มันเพียงอย่างเดียว
    แต่ถ้ามองเป็น ชั้นยับยั้งที่เพิ่มต้นทุน ให้ฝ่ายโจมตี มันก็ยังเป็นกลยุทธ์ที่ใช้ได้
    สุดท้ายความปลอดภัยคือเกมที่วัดกันว่าใครทุ่มทรัพยากรได้มากกว่า
    AI แค่มีประสิทธิภาพกว่ามนุษย์ แต่ สมการพื้นฐานระหว่างโอเพนกับปิด ไม่ได้เปลี่ยนไป

  • อยากรู้ว่า Cal.com กังวลเรื่องความปลอดภัยจริง ๆ หรือแค่ใช้เป็น ข้ออ้างเพื่อกลบความยากของ SaaS แบบโอเพนซอร์ส
    ตรรกะแบบนี้ถูกพิสูจน์มาหลายสิบปีแล้วว่าไม่ถูกต้อง

  • ฉันไม่เชื่อว่า “ความปลอดภัยด้วยการซ่อน” คือเหตุผลจริง
    แค่คิดว่าถ้าปิดโอเพนซอร์สแล้ว น่าจะทำเงินได้มากขึ้น เท่านั้นเอง

    • ใช่ มันเป็นผลิตภัณฑ์ของพวกเขา จะทำอย่างไรก็ได้
      ด้านที่น่าเกลียดอย่างหนึ่งของโอเพนซอร์สคือ ผู้คน มองแรงงานฟรีเป็นเรื่องปกติ
      แทนที่จะขอบคุณนักพัฒนาที่ทำงานให้ฟรีมาหลายปี กลับโกรธเมื่อเขาไม่ยอมทำฟรีต่อ
      ทั้งที่ตัวเองก็ไม่ได้ยอมทำงานโดยไม่รับเงินเดือน

  • จากบทความดูเหมือนว่า Cal.com เคยโดน ทดสอบช่องโหว่ด้วย red-team bot
    พอบั๊กถูกเจอเร็วเกินไป CEO อาจรู้สึกว่า ต้นทุนการแก้ไข สูงเกินรับไหว เลยปิดโค้ด
    มันแทบจะเหมือน การประกาศต่อสาธารณะว่าโค้ดของ Cal.com มีช่องโหว่เยอะ

    • หรืออีกทางหนึ่งอาจเป็นเพราะสแกนเนอร์ให้ false positive เยอะเกินไปก็ได้
      ถ้าปรับจูนก็เสี่ยงพลาดช่องโหว่จริง และสุดท้าย ต้นทุนการตรวจสอบ ก็สูงขึ้น
      โอเพนซอร์สมีรายงานพวกนี้เปิดเผยต่อสาธารณะจึงเกิด ความเสียหายต่อชื่อเสียง แต่ซอฟต์แวร์ปิดไม่เป็นแบบนั้น
      เลยอาจเป็นอีกเหตุผลที่เปลี่ยนเป็นแบบปิด

  • ความเสี่ยงที่แท้จริงไม่ใช่การตรวจหาช่องโหว่ แต่คือความสามารถของ LLM ในการเขียนโปรเจ็กต์โอเพนซอร์สขึ้นใหม่เป็นภาษาอื่น เพื่อเลี่ยงไลเซนส์

    • ในทางทฤษฎีสิ่งเดียวกันนี้ก็เกิดกับโปรเจ็กต์แบบปิดได้เหมือนกัน แต่ มีข้อจำกัดมากกว่า
    • เรื่องแบบนี้เกิดขึ้นบ่อยจริง AI สร้างโค้ดใหม่แทบจะเหมือนเดิมจนกลายเป็น โปรเจ็กต์โคลน
      ในทางกฎหมายยังคลุมเครือ ถ้าคนเรียนรู้แล้วเขียนใหม่เองก็มักไม่มีปัญหา แต่ถ้า AI ทำ มันแทบจะเป็น การคัดลอกวางแบบซับซ้อน
      จึงยังไม่ชัดว่าไลเซนส์จะถูกใช้บังคับอย่างไรในกรณีแบบนี้
    • ไลเซนส์โอเพนซอร์สจำนวนมากอนุญาตให้ fork และขายต่อ ได้
      การเปิดเผยโค้ดอย่างเดียวไม่ได้ทำให้ธุรกิจอยู่รอด และความสามารถในการดำเนินงานสำคัญกว่า

  • ฉันเห็นด้วยกับคำกล่าวที่ว่า “การทดสอบความปลอดภัยควร ทำให้เป็นอัตโนมัติใน CI/CD pipeline”
    แต่นั่นไม่ได้พิสูจน์ว่า โอเพนซอร์สมีความจำเป็น

  • สมดุลของโอเพนซอร์สพังไปนานแล้ว
    โครงสร้างที่บริษัทเอาโค้ดโอเพนซอร์สไปทำ ผลิตภัณฑ์เสียเงินโดยไม่คืนกลับมา มีมานานมากแล้ว
    ภาษาอย่าง PHP ที่ทั้งโลกใช้แต่กลับ มีงบประมาณไม่พอ ก็คือตัวอย่างหนึ่ง