Cal.com เปลี่ยนจากโอเพนซอร์สเป็นโคลสซอร์สเพราะภัยคุกคามด้านความปลอดภัยจาก AI

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

การยุติโอเพนซอร์สของ Cal.com และภัยคุกคามด้านความปลอดภัยจาก AI

  • Cal.com ดำเนินงานแบบโอเพนซอร์สมาตลอด 5 ปี แต่ตัดสินใจ เปลี่ยนเป็นโคลสซอร์ส (Closed Source) เนื่องจาก ภัยคุกคามด้านความปลอดภัยจาก AI ที่เพิ่มขึ้นอย่างรวดเร็ว
    • บริษัทให้ความสำคัญสูงสุดกับการปกป้องข้อมูลลูกค้า และเห็นว่าการคงสถานะโอเพนซอร์สไว้ไม่ปลอดภัยอีกต่อไป
    • ระบุว่า “นี่ไม่ใช่การตัดสินใจที่ง่าย”
  • ในอดีต การโจมตีผ่านช่องโหว่ของแอปพลิเคชันต้องอาศัยเวลาและความเชี่ยวชาญจากแฮ็กเกอร์ แต่ตอนนี้ได้เปลี่ยนเข้าสู่ ยุคที่ AI สามารถสแกนโค้ดเบสอัตโนมัติเพื่อหาช่องโหว่ได้
    • บริษัทอธิบายว่าโค้ดโอเพนซอร์สเปรียบเสมือน “การมอบแบบแปลนตู้เซฟให้ผู้โจมตี”
    • เมื่อสตาร์ทอัพด้านความปลอดภัย AI นำความสามารถนี้ไปเชิงพาณิชย์ แต่ละรายก็ตรวจพบช่องโหว่ต่างกัน ทำให้ ยากต่อการสร้างมาตรฐานความปลอดภัยเดียวที่เชื่อถือได้
  • Cal.com ระบุว่าต้องเลือกหนึ่งในสองทาง
    • คงโอเพนซอร์สไว้และยอมรับความเสี่ยงต่อข้อมูลลูกค้า หรือ
    • เปลี่ยนเป็นโคลสซอร์สเพื่อลดความเสี่ยง
    • แม้จะไม่ใช่ทางออกที่สมบูรณ์แบบ แต่บริษัทมองว่าเป็น การตัดสินใจที่หลีกเลี่ยงไม่ได้เพื่อปกป้องผู้ใช้
  • เพื่อสืบต่อจิตวิญญาณของโอเพนซอร์ส บริษัทได้เปิดโครงการแยกชื่อ Cal.diy ภายใต้ ไลเซนส์ MIT
    • Cal.diy เป็นเวอร์ชันที่เปิดกว้างสำหรับนักพัฒนาและผู้ใช้สายงานอดิเรก โดยเป็น เวอร์ชันที่โฮสต์เองได้และเน้นคอมมูนิตี้
    • โค้ดเบสของบริการหลักมีการเปลี่ยนแปลงโครงสร้างสำคัญอย่างมาก เช่น ระบบยืนยันตัวตนและระบบประมวลผลข้อมูล ทำให้ ถูกแยกออกจาก Cal.diy ทางเทคนิคแล้ว
  • AI กำลังเปลี่ยนแปลงสภาพแวดล้อมด้านความปลอดภัยอย่างรวดเร็ว และยังมีการยกตัวอย่างว่า AI สามารถค้นพบช่องโหว่อายุ 27 ปีในเคอร์เนล BSD และสร้างเอ็กซ์พลอยต์ได้ภายในไม่กี่ชั่วโมง
    • ความเร็วและความแม่นยำเช่นนี้กำลังกดดันระบบรับมือด้านความปลอดภัยแบบเดิมอย่างหนัก
    • Cal.com ระบุว่ากำลังใช้ทุกมาตรการที่เป็นไปได้เพื่อปกป้องลูกค้า แอปพลิเคชัน และข้อมูลอ่อนไหว และแสดงเจตนาว่าอยากกลับไปเป็นโอเพนซอร์สอีกครั้งเมื่อสภาพแวดล้อมด้านความปลอดภัยมีเสถียรภาพมากขึ้น

ทิศทางต่อจากนี้และสารที่ต้องการสื่อ

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

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

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

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

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

    • บทความนั้นถูกนำมาโพสต์อีกครั้งที่นี่ ใช้ชื่อว่า Cybersecurity looks like proof of work now
    • เหตุผลจริงน่าจะเป็นการป้องกันไม่ให้ AI ฟอกลิขสิทธิ์ (copyright-wash) ตัวผลิตภัณฑ์ โดยใช้เรื่องความปลอดภัยเป็นข้ออ้าง
    • ข้อสรุปนี้ฟังดูน่าเชื่อถือกว่า Mythos เพิ่งเปิดตัวได้แค่ไม่กี่สัปดาห์ แต่กลับเปลี่ยนหลักการเร็วขนาดนี้มันแปลก น่าจะมี เหตุผลทางธุรกิจ อยู่แล้ว และตอนนี้แค่หาคำอธิบายที่ขายกับสาธารณะได้
    • ในเชิงเศรษฐกิจก็สมเหตุสมผล สุดท้ายต้องสร้างมูลค่าให้มากพอจะรับต้นทุนโทเค็นได้ หรือไม่ก็ลดผลตอบแทนทางเศรษฐกิจจากการค้นพบช่องโหว่
      ทำได้ด้วยการลดขอบเขตการเผยแพร่หรือจำกัดสิทธิ์ของระบบให้ต่ำลง
      ต่อไปน่าจะพัฒนาไปเป็นรูปแบบ "สเปกเปิด + การสร้างโค้ดด้วยโมเดล" โดยความปลอดภัยและการกำกับดูแลจะไปอยู่ที่เลเยอร์ของโมเดล
    • คำพูดที่ว่า “ถ้าจะทำให้ระบบแข็งแกร่งขึ้น เราต้องใช้โทเค็นมากกว่าผู้โจมตี” ฟังดูแปลก ถ้าซอฟต์แวร์มีเสถียรภาพ พื้นที่โจมตีก็ควรลดลง และ Mythos ก็ไม่ได้ สร้าง ช่องโหว่ใหม่ ฝั่งป้องกันควรได้เปรียบในแง่โทเค็น

  • ผมเป็นผู้รับผิดชอบโปรเจกต์ Thunderbird เครื่องมือจัดการนัดหมายของเรา Thunderbird Appointment จะยังคงเป็นโอเพนซอร์สตลอดไป
    ขอเชิญมาร่วมสร้างด้วยกันที่GitHub repository เราจะช่วยทำให้มันเป็นตัวแทน Cal.com ได้

    • น่าจะดีถ้าเพิ่ม ภาพหน้าจอ ใน README หรือหน้าแรกก่อนล็อกอิน ตัวเครื่องมือดูดี แต่ก็อยากรู้ราคาเวอร์ชันโฮสต์
    • แต่บนโน้ตบุ๊ก Linux เก่า ๆ Thunderbird หนักเกินไป หวังว่าจะคำนึงถึง ผู้ใช้เครื่องสเปกต่ำ ด้วย เป็นการขอให้ทำให้อินเทอร์เน็ตยังคงเบาและเข้าถึงได้
    • พอเข้าเว็บแล้วกรอกอีเมล ก็โดนส่งเข้ารายชื่อรอ สุดท้ายยังบล็อกอีเมลอีกด้วย ประสบการณ์ใช้งานไม่ค่อยดี
    • มีมุกตอบคำว่า “มาร่วมสร้างกับเรา” ว่า “งั้นต้องมี appointment ก่อนหรือเปล่า?”
    • ก็มีคนตอบรับในเชิงบวกว่า ดูเป็นทางเลือกที่ดี

  • ถ้า LLM เก่งในการหาช่องโหว่ของโค้ดขนาดนั้น ก่อนปล่อยเวอร์ชันก็น่าจะรัน LLM pentest ภายใน ได้ไม่ใช่หรือ?
    รู้สึกเหมือนกฎของ Linus(ลิงก์) เพิ่งกลายเป็นจริงเสียที

    • แต่หลังจากปล่อยแล้ว ฝั่งโจมตีสามารถวิเคราะห์โค้ดได้ด้วยเวลาไม่จำกัดและ LLM ที่ฉลาดขึ้นเรื่อย ๆ
      ถ้าจะป้องกัน ก็ต้อง ทำทุกอย่างที่ผู้โจมตีจะทำล่วงหน้าในทุกรีลีส
    • เมื่อ LLM พัฒนาไป การดูแลรักษา FOSS ก็มี ต้นทุนด้านเวลาและกำลังคน พุ่งสูงขึ้น
      issue หรือ PR คุณภาพต่ำที่ AI สร้างขึ้นมีมากขึ้น ทำให้แรงจูงใจในการรักษาโอเพนซอร์สน้อยลง
      ถ้าผลิตภัณฑ์เชิงพาณิชย์สร้างบน FOSS core การเปลี่ยนแบบนี้ก็น่าจะเกิดมากขึ้น
    • ในโคลสซอร์สก็สามารถใช้ LLM ภายในเพื่อเสริมความปลอดภัยได้
      แต่ก็เข้าใจได้ว่าทำไมถึงอยากปิดไว้เพื่อไม่ เปิดโอกาสให้เกิดการโจมตีจากภายนอก
    • ในสภาพแวดล้อมที่มี commit บ่อย ต้องสแกนโค้ดทั้งโค้ดเบสด้วย LLM ทุกครั้ง ทำให้ ต้นทุนพุ่งกระฉูด
      แม้แต่ที่อย่าง GitHub เอง ต้นทุน static analysis ก็สูงอยู่แล้ว
    • สุดท้ายก็มีความเห็นว่าควรเขียน โค้ดที่เรียบง่าย และทำการทดสอบความปลอดภัยด้วย LLM ตั้งแต่ระดับคอมไพเลอร์ด้วย

  • การตัดสินใจครั้งนี้ดูเป็น การตัดสินใจทางธุรกิจมากกว่าความปลอดภัย
    เพราะ AI ทำให้ self-hosting ง่ายขึ้น รายได้จากโฮสติ้งแบบเสียเงินของโปรเจกต์โอเพนซอร์สจึงลดลง

    • ผู้คนใช้ LLM เพื่อทำ “ฟีเจอร์โปร” เอง หรือหาจุดต่อขยายได้ เรื่องความปลอดภัยเป็นแค่ ฉากบังหน้า
    • การโทษ AI เป็นข้ออ้างอยู่แล้ว เพราะ AI เรียนรู้จากโค้ดไปแล้ว ถ้าเอา genetic algorithm + fuzzing มารวมกัน ก็เรียนรู้ได้เร็วกว่ามนุษย์มาก
    • ช่วงนี้อะไรก็โยนความผิดให้ AI ทั้งการลดคน การยุติผลิตภัณฑ์ หรือการปิดซอร์สโค้ด ทุกอย่างถูกบอกว่าเป็นเพราะ AI
    • ผลิตภัณฑ์แนวนี้กำลัง กลายเป็นสินค้าโภคภัณฑ์ (commoditized) อยู่แล้ว เช่นเครื่องมือนัดหมายของ Google Workspace
    • สุดท้ายก็มีเสียงวิจารณ์ว่าเป็นพวก “sellout”

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

  • “ถ้า AI สแกนโค้ดโอเพนซอร์สได้ล่ะ?” → งั้นก็แค่ แก้บั๊กสิ
    ตรรกะนี้ไม่น่าเชื่อถือเลย

  • การบอกว่า “จะปิดเพราะ AI เข้าถึงโค้ดได้” เป็นแค่ ข้ออ้าง

    • เหตุผลจริงไม่ใช่ AI หรือความปลอดภัย แต่เป็นเพราะมี โปรเจกต์โคลน มากเกินไปจนรายได้ลดลง

  • การตัดสินใจแบบนี้สุดท้ายก็ดูเป็น Security through obscurity
    น่าสงสัยว่าตั้งแต่เมื่อไรโมเดลแบบนั้นถึงกลายเป็นสิ่งที่ถูกต้อง

    • การปกปิดจะมีผลก็ต่อเมื่อไม่ได้เป็นแนวป้องกันหลัก แต่เป็นเพียง มาตรการยับยั้งเสริม
    • การลดพื้นที่โจมตีไม่ใช่การปกปิด แต่เป็นกลยุทธ์ ลด attack vector ให้น้อยที่สุด
    • ถึงอย่างนั้นก็ยังมีคนเห็นว่า “ความปลอดภัยแบบมีการปกปิด” ก็ยังดีกว่าไม่มีเลย
    • มีผู้ร่วมก่อตั้งคนหนึ่งพูดว่า “เด็กอายุ 16 ข้างบ้านใช้เวลา 15 นาที กับเงิน 100 ดอลลาร์ก็แฮ็กได้”
    • เหมือนจะลืมไปแล้วว่าทำไมแนวคิด “อย่าทำความปลอดภัยด้วยการปกปิด” ถึงเกิดขึ้นมา
      ไม่ใช่เพราะคนรุ่นก่อนโง่ แต่เพราะมันเป็น แนวทางที่ดูดีภายนอกแต่สุดท้ายล้มเหลว

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

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