ZCode ลบข้อมูลหลังข้อครหาอัปโหลด repository: เปิดซอร์สช่วยตรวจอนาคต แต่ไม่ย้อนยืนยันอดีต

Zhipu AI หรือแบรนด์ Z.ai ระบุว่าได้ลบข้อมูล repository ที่เกี่ยวข้อง ลบ object-storage bucket ถอดเส้นทางอัปโหลดของฟีเจอร์ Repo Wiki ออกจาก ZCode และประกาศชดเชยผู้ใช้ หลังเกิดข้อครหาว่าเครื่องมือ coding agent ส่ง snapshot ของ repository ขึ้น cloud โดยการเปิดเผยและการขอความยินยอมไม่ชัดพอ ต่อมาบริษัทเปิดซอร์ส ZCode ให้ตรวจได้ใน GitHub repository ทางการ

ข่าวนี้มีสองเรื่องที่ต้องแยกกันครับ เรื่องแรกคือ การเยียวยาและสถาปัตยกรรมปัจจุบัน ซึ่งการถอดทางอัปโหลด ลบข้อมูล และเปิดซอร์สเป็นการเปลี่ยนแปลงที่มีความหมาย เรื่องที่สองคือ หลักฐานของสิ่งที่เกิดก่อนเปิดซอร์ส ซึ่ง repository ปัจจุบันไม่สามารถย้อนเวลาไปพิสูจน์ว่าบinary รุ่นก่อนส่งไฟล์อะไรบ้าง หรือสำเนาถูกลบครบทุกระบบจริงหรือไม่

TechNode รายงานว่าบริษัทลบ objects และ bucket แล้ว พร้อมอ้างการตรวจโดย CAICT และ NSFOCUS และประกาศแนวทางชดเชย ขณะที่ The Frontier ติดตามคำขอโทษและการเปิดซอร์ส ส่วน Locsic เน้นปัญหาการส่งข้อมูลโดยไม่มี disclosure ที่ผู้ใช้เข้าใจได้ก่อนใช้งาน ทั้งสามแหล่งช่วยให้เห็นคนละด้าน แต่รายงานการตรวจฉบับเต็มและหลักฐานการลบระดับ object/log/backup ยังไม่ได้อยู่ในแหล่งสาธารณะที่เราตรวจ

ดังนั้นบทความนี้ไม่ใช่ตรารับรองว่า “ปลอดภัยแล้ว” และไม่นับ ZCode เป็นหนึ่งในเครื่องมือ agent ใหม่ที่ผ่าน safety gate ของรอบนี้ เรากำลังวิเคราะห์ incident, การแก้ไข และสิ่งที่องค์กรควรตรวจเองก่อนพิจารณาใช้อีกครั้ง

เกิดอะไรขึ้น (สรุป 30 วินาที)

ผู้ใช้และนักวิเคราะห์ตั้งข้อสังเกตว่า Repo Wiki ของ ZCode สร้าง/ส่ง snapshot ของ repository ไปยัง cloud โดย UI และ disclosure ก่อนส่งไม่ชัดพอ ประเด็นหลักจึงเป็น informed consent และขอบเขตข้อมูล ไม่ใช่เพียงว่าฟีเจอร์ cloud มีอยู่หรือไม่
ตามไทม์ไลน์ที่ TechNode รายงาน บริษัทออกคำชี้แจงเมื่อ 18 กันยายน จากนั้นรุ่น 3.14.0 วันที่ 19 กันยายนถอดเส้นทาง snapshot/upload ของ Repo Wiki และวันที่ 21 กันยายนเปิดซอร์ส ก่อนอัปเดต repository ปัจจุบันเป็น 3.14.3
บริษัทบอกว่าลบข้อมูลที่เกี่ยวข้องและลบ OSS bucket แล้ว พร้อมอ้างการตรวจจาก CAICT และ NSFOCUS และประกาศชดเชย แต่บทความสาธารณะที่ตรวจไม่แนบรายงาน forensic ฉบับเต็ม จึงยังยืนยันขอบเขตการลบอย่างอิสระไม่ได้
Repository ทางการ เป็น public, ใช้ Apache-2.0 และมีส่วน client, backend, UI, CLI และ runtime ให้ตรวจโค้ดปัจจุบันได้ การเปิดซอร์สช่วยเพิ่ม auditability จากวันนี้เป็นต้นไป
อย่างไรก็ตาม history ของ repository สาธารณะมีไม่มากและเริ่มหลังเหตุการณ์ การไม่พบเส้นทางเก่าใน source ปัจจุบันจึงยืนยันได้เพียงว่าโค้ดที่เผยแพร่ตอนนี้ไม่เหมือน binary เก่าตามข้อกล่าวหา ไม่ใช่หลักฐานว่าสิ่งเก่าไม่เคยเกิด
ข้อสรุปที่รับผิดชอบคือ “มี remediation ที่ตรวจบางส่วนได้ แต่หลักฐานสาธารณะยังไม่พอให้ผ่านเกณฑ์คัดกรองเป็นเครื่องมือแนะนำ ณ วันที่ตรวจ”

ทำไมเรื่องนี้เกี่ยวกับคุณ

repository ไม่ใช่แค่ไฟล์โค้ด ตัวมันอาจมี architecture, business rules, ชื่อลูกค้าใน fixture, internal URL, commit metadata, prompt, issue context และบางครั้งมี secret ที่ไม่ควรอยู่ตั้งแต่แรก การส่ง snapshot ขึ้น cloud โดยผู้ใช้ไม่เห็นขอบเขตชัด จึงไม่เท่ากับส่งข้อความถาม AI หนึ่งย่อหน้า ความเสียหายอาจครอบคลุมทรัพย์สินทางปัญญา สัญญากับลูกค้า และข้อมูลส่วนบุคคลพร้อมกัน

สำหรับนักพัฒนา เหตุการณ์นี้เตือนว่า feature ที่ฟังดูเป็น “สร้าง wiki อัตโนมัติ” อาจต้องอ่านหลายไฟล์เพื่อสร้างภาพรวม การทำงานแบบ cloud จึงมักต้องอัปโหลดมากกว่าบรรทัดที่เปิดอยู่ หากหน้าจอมีเพียงปุ่มเปิดฟีเจอร์แต่ไม่แสดง file list, ignore rules, destination, retention และวิธีลบ เราไม่มีข้อมูลพอตัดสินใจอย่างรู้เท่าทัน

สำหรับทีม security ประเด็นนี้ไม่ควรถูกลดเป็นการตามหา secret อย่างเดียว ต่อให้ scanner ไม่พบ API key โค้ด private ก็ยังเป็นข้อมูลที่มี classification และ contractual boundary ต้องถามว่าใครเป็น controller/processor, data อยู่ region ใด, model training ถูกแยกหรือไม่, log/backup ถูกเก็บนานเท่าไร และ deletion ครอบคลุม replica หรือไม่

สำหรับผู้ดูแลเครื่องมือ AI เหตุการณ์นี้ชี้ให้เห็นช่องว่างระหว่าง permission ของระบบปฏิบัติการ กับ ความยินยอมทางผลิตภัณฑ์ แอปที่เปิดโฟลเดอร์ repository ได้อาจมีสิทธิ์อ่านไฟล์ตาม OS อยู่แล้ว แต่สิทธิ์อ่านเพื่อช่วยแก้โค้ดไม่ได้แปลว่าผู้ใช้ยินยอมให้อัปโหลดทั้ง snapshot ไปยังบริการภายนอก การออกแบบที่ดีต้องถามแยกตาม purpose และแสดงขอบเขตก่อน side effect

สำหรับผู้บริหาร การเปิดซอร์สหลัง incident เป็นสัญญาณบวกแต่ไม่ควรกลายเป็นทางลัดผ่าน due diligence Open source ช่วยให้ทีมอ่าน implementation ที่เผยแพร่ได้ ทว่า binary distribution, build pipeline, update server, hosted backend และ data deletion เป็นคนละชั้นกับ source license ต้องตรวจ provenance และ reproducible relationship ระหว่าง source กับของที่ติดตั้งด้วย

สำหรับผู้ใช้เครื่องมืออื่น ข่าวนี้เป็นแบบทดสอบที่ใช้ได้ทั่วไป: ก่อนเปิด codebase indexing, repository map, semantic search หรือ cloud workspace ให้ถามว่า อะไรออกจากเครื่อง เมื่อไร ไปไหน เพื่ออะไร และลบอย่างไร ถ้าผู้ขายตอบได้เฉพาะประโยชน์ แต่ตอบ data flow ไม่ได้ ให้ถือว่ายังไม่พร้อมใช้กับ private code

ทำงานยังไง

ฟีเจอร์ repository wiki ต้องสร้างความเข้าใจข้ามไฟล์ สมมติเราให้พนักงานใหม่ทำคู่มือร้านอาหาร เขาต้องเดินดูเมนู สูตร สต็อก หน้าที่พนักงาน และทางเดินหลังร้าน จากนั้นสรุปความสัมพันธ์ หากพนักงานทำงานบนเครื่องเรา ข้อมูลอยู่ในร้าน แต่ถ้าเขาถ่ายเอกสารทั้งหมดส่งไปสำนักงานใหญ่เพื่อประมวลผล นั่นคือการเคลื่อนข้อมูลข้าม boundary แม้ผลลัพธ์สุดท้ายเป็น wiki หน้าเดียว

ทางเทคนิค pipeline มักมีหลายช่วง: enumerate ไฟล์, ใช้ ignore rule, ตัดไฟล์ binary/ใหญ่, สร้าง chunks หรือ representation, ส่งไป backend, ประมวลผลด้วยโมเดล/บริการค้นหา, เก็บ cache/index และคืนเอกสาร ความเสี่ยงไม่ได้อยู่เฉพาะ HTTP request แรก แต่อยู่ทุกจุดที่มีสำเนา เช่น upload object, queue payload, processing disk, log, index, backup และ telemetry

ปัญหา “silent upload” จึงไม่จำเป็นต้องหมายถึงซอฟต์แวร์แอบทำแบบ malware เสมอไป แค่ disclosure อยู่ลึก อ่านไม่ทัน หรือปุ่มชื่อท้องถิ่นแต่มีผล cloud ก็เพียงพอให้ consent ไม่สมบูรณ์ ในผลิตภัณฑ์ developer tool คำว่า “Generate Wiki” ไม่บอกโดยตัวมันเองว่า repository จะถูกส่งทั้งชุด ผู้ใช้ควรเห็น preview ของไฟล์/ขนาด/ปลายทางและต้อง opt in ก่อนเริ่ม

ตามรายงาน บริษัทถอดเส้นทาง snapshot และ upload ของ Repo Wiki ใน 3.14.0 นี่เป็น control ที่แข็งแรงกว่าการแก้ข้อความ consent อย่างเดียว เพราะตัด data path ออกจาก feature แต่ผู้ประเมินยังต้องถามว่า feature ใหม่ทำงาน local ทั้งหมดหรือเปลี่ยนวิธีส่ง และ component hosted ตัวอื่นมีเส้นทาง repository access หรือไม่ คำตอบต้องมาจาก architecture กับ traffic test ใน sandbox ไม่ใช่จาก release note บรรทัดเดียว

การลบ bucket เป็นอีกชั้นหนึ่ง ถัง object storage เปรียบเหมือนห้องเก็บสำเนา การลบห้องและของข้างในลดโอกาสเข้าถึงต่อ แต่ระบบจริงอาจมี versioning, replication, access log, cache, backup หรือ derived index อยู่ที่อื่น การรับรอง deletion ที่ดีควรบอก asset inventory, เวลา, scope, retention exception, ผู้ตรวจ และผลทดสอบ ไม่ใช่บอกเพียงว่า “ลบแล้ว”

การเปิดซอร์สช่วยตรงไหน? ช่วยให้ชุมชนค้นหา endpoint, telemetry, filesystem scope, default config และ permission flow ของ โค้ดที่เผยแพร่ ได้ ช่วยให้สร้าง binary เองและเปรียบเทียบ behavior ได้หาก build instructions เพียงพอ แต่ถ้า history เริ่มหลัง patch เราจะไม่เห็น implementation ก่อนหน้า และ source ฝั่ง client ไม่ได้เปิดกระจกเข้า hosted service ทุกส่วนโดยอัตโนมัติ

สุดท้าย compensation เป็นการยอมรับผลกระทบเชิงลูกค้า แต่ไม่ใช่ security control เงินชดเชยไม่ลดสิทธิ์ ไม่ลบ backup และไม่ป้องกัน incident รอบหน้า สิ่งที่ต้องดูต่อคือ defaults รุ่นใหม่, regression tests, transparency report, independent assessment และการสื่อสารกับผู้ใช้ก่อน data movement

เรื่องเงินและผลกระทบ

ต้นทุนตรงสำหรับผู้ขายมีทั้งการลบข้อมูล การตรวจระบบ การออก release เร่งด่วน การเปิดซอร์ส การสนับสนุนลูกค้า และชดเชย แต่ต้นทุนที่ใหญ่กว่าคือ trust debt นักพัฒนามอบ codebase ให้เครื่องมือเพราะคาดหวังให้ช่วยเพิ่มผลผลิต เมื่อขอบเขตข้อมูลไม่ชัด ทีมจะต้องใช้เวลาตรวจ network, package และ policy เพิ่มก่อนอัปเดตทุกครั้ง

สำหรับองค์กรที่ใช้ ZCode แล้ว งานแรกไม่ใช่คำนวณค่าเสียหายจาก headline แต่ทำ inventory: เวอร์ชันใดติดตั้งเมื่อไร, ใครเปิด Repo Wiki, repository ใดถูกเปิด, outbound destination ใดปรากฏใน proxy/EDR และข้อมูลชั้นใดอยู่ใน repo เหล่านั้น ถ้าไม่มี telemetry ย้อนหลัง ให้บันทึกว่า “ไม่ทราบ” แทนการสรุปว่าไม่เคยส่ง

ผลกระทบทางสัญญาขึ้นกับข้อมูลและข้อตกลง ลูกค้าอาจห้ามส่ง source ให้ subprocessors หรือกำหนด region; โค้ดบางส่วนอาจมีใบอนุญาตที่ห้ามแจกจ่าย; test fixture อาจมีข้อมูลส่วนบุคคล เรื่องนี้จึงต้องให้ legal/privacy ร่วม triage ไม่ใช่ security ทีมเดียว และไม่ควรส่งประกาศกว้างก่อนรู้ asset scope

องค์กรที่ไม่เคยใช้ ZCode ก็ยังมีต้นทุนป้องกันที่คุ้มค่า: กำหนด approved AI tools, egress control, code classification และ procurement checklist ล่วงหน้า ค่าใช้จ่ายนี้ดูเหมือน friction แต่ถูกกว่าการไล่ถามทีหลังว่าใครกด index repo ใดไปแล้วบ้าง

สำหรับตลาด การเปิดซอร์สอาจกดดันเครื่องมือ agent รายอื่นให้เผย data flow และ defaults ชัดขึ้น นี่เป็นผลดี แต่ถ้าอุตสาหกรรมใช้ “เรา open source แล้ว” เป็นคำตอบสำเร็จรูป จะเกิด blind spot ใหม่ เพราะบริการ cloud, model endpoint และ release artifact อาจยังตรวจไม่ได้ครบ Open source เป็นหลักฐานหนึ่งชิ้น ไม่ใช่ใบรับรองทั้งระบบ

ข้อมูลที่ยังไม่ชัดและจุดที่แหล่งพูดไม่ตรงกัน

ขอบเขตข้อมูลเดิม: Locsic เน้นการส่ง snapshot โดย disclosure ไม่เพียงพอ ส่วนคำอธิบายการเยียวยาที่ TechNode รายงานพูดถึง data objects และ bucket แต่แหล่งสาธารณะที่ตรวจไม่ได้ให้ manifest ว่าแต่ละ repository ส่งไฟล์ชนิดใด ถูกตัดด้วย ignore rule อะไร หรือมี metadata ใดร่วมไปด้วย

จำนวนผู้ได้รับผลกระทบ: ข่าวอธิบายมาตรการชดเชย แต่ยังไม่มีตัวเลขฐานผู้ใช้และ repository ที่ตรวจสอบอิสระได้ เราจึงไม่ควรแปลงจำนวนผู้ร้องเรียนในสังคมออนไลน์เป็นจำนวน incident ทั้งหมด หรือสรุปกลับว่าไม่มีผู้ร้องเรียนเพิ่มแปลว่า scope เล็ก

การลบครบถ้วน: บริษัทอ้างการตรวจโดย CAICT และ NSFOCUS ตาม TechNode แต่งานที่เราเข้าถึงไม่ได้แนบรายงานเต็ม วิธีทดสอบ chain of custody หรือรายการ backup/derived data ที่ครอบคลุม การกล่าวว่า “มี third-party verification” จึงต่างจากการที่สาธารณะสามารถตรวจ methodology และ finding ได้เอง

source ปัจจุบันกับ binary ในอดีต: GitHub ทางการ เปิดโค้ดภายใต้ Apache-2.0 และระบุเวอร์ชันปัจจุบัน แต่ commit history ที่เผยแพร่มีน้อย The Frontier จึงมองการเปิดซอร์สเป็นขั้นฟื้นความเชื่อมั่น ขณะที่ผู้ตรวจต้องรักษาข้อจำกัดไว้ว่า repo นี้ไม่ใช่หลักฐาน forensic ของรุ่นก่อนเปิดซอร์ส

เส้นทาง cloud อื่น: การถอด Repo Wiki upload ไม่ได้ตอบอัตโนมัติว่า completion, chat, telemetry หรือ component อื่นส่งบริบทอะไร เอกสาร data-flow รายฟีเจอร์ยังจำเป็น และองค์กรควรตรวจ traffic ใน environment ที่ไม่มี secret แทนการเดา

เงื่อนไขชดเชยและผู้ใช้ไทย: แหล่งข่าวรายงานการประกาศ compensation แต่รายละเอียด eligibility, ช่องทาง, เขตอำนาจ และกำหนดเวลาสำหรับผู้ใช้ต่างประเทศอาจไม่เหมือนกัน ผู้ได้รับผลกระทบควรอ้างประกาศทางการ/สัญญาของบัญชีตน ไม่อาศัยบทความสรุปแทน

training และ retention: จากแหล่งที่ตรวจยังไม่มีข้อมูลพอให้สรุปครอบคลุมว่าข้อมูล incident ถูกใช้ฝึกโมเดลหรือไม่ และ derived artifact ทุกชนิดมี retention เท่าไร การไม่มีหลักฐานว่าใช้ฝึก ไม่เท่ากับมีหลักฐานว่าไม่ใช้ จึงต้องคงสถานะ “ยังไม่ยืนยัน”

หลักฐานที่ตรวจ

ณ วันที่ 30 กันยายน 2026 ผมตรวจ repository ทางการว่าเป็น public, มีไฟล์ license Apache-2.0 และมีโครงสร้าง client/backend/UI/CLI/runtime ที่อ่านต่อได้ ตรวจข้อความเวอร์ชัน 3.14.3 ในหน้าโครงการ และตรวจ commit history สาธารณะที่มีขนาดเล็ก หลักฐานนี้รองรับข้อสรุปว่า ZCode เปิด source ปัจจุบันจริง แต่ไม่รองรับข้อสรุปว่า source นี้ตรงกับ binary ก่อน incident

ผมเทียบรายงานอิสระสามแหล่ง: TechNode ให้ไทม์ไลน์ remediation, deletion, third-party names และ compensation; The Frontier ให้บริบท apology/open-source; Locsic วิเคราะห์ behavior และ disclosure ของ upload ข้อมูลที่ซ้ำกันช่วยยืนยันว่ามี controversy และการตอบสนองต่อเนื่อง ส่วนรายละเอียดที่มีเพียงคำกล่าวของบริษัทถูกระบุเป็นคำกล่าว ไม่ยกระดับเป็นผลตรวจอิสระ

ผม ไม่ได้ ดาวน์โหลด binary, ไม่รัน installer, ไม่เชื่อมบัญชี, ไม่เปิด repository จริงให้ ZCode และไม่ส่ง traffic ไป backend เพราะการทดสอบเครื่องมือที่มีข้อครหา data upload ด้วย credential/codebase จริงจะขัด safety boundary การตรวจรอบนี้จึงเป็น source/document review แบบอ่านอย่างเดียว

ไม่พบ advisory CVE ทางการที่ให้ใช้แทน incident นี้ และ incident ด้าน privacy/data flow อาจไม่มี CVE อยู่แล้ว การไม่มี CVE จึงไม่ใช่หลักฐานว่าความเสี่ยงต่ำ นอกจากนี้ยังไม่มี signature/checksum/reproducible-build evidence ที่เรายืนยันความสัมพันธ์ระหว่าง source กับ distribution ได้ครบจากแหล่งที่ตรวจ

ผล safety gate: ไม่ผ่านเกณฑ์คัดกรองสำหรับบทความแนะนำเครื่องมือ ณ วันที่ตรวจ เพราะ provenance ของ source ปัจจุบันชัดขึ้น แต่หลักฐานสาธารณะเรื่อง binary เดิม, deletion scope, hosted components และ independent report ยังไม่พอ ประโยคนี้ไม่ได้บอกว่าเครื่องมือเป็นอันตรายแน่นอน แต่บอกว่าหลักฐานยังไม่ถึงระดับที่ automation นี้ต้องการ

วิธีใช้ให้ปลอดภัยขึ้น

ถ้าองค์กรจำเป็นต้องประเมินต่อ ให้ทำในเครื่องเสมือนหรือ container แยกที่ไม่มี credential, SSH key, cloud config, browser profile หรือ private network สร้าง repository สังเคราะห์ที่ไม่มีโค้ดจริง ใส่ canary strings ในไฟล์แต่ละชนิด แล้วบล็อก egress เป็นค่าเริ่มต้น เปิดเฉพาะ domain ที่บันทึกได้ผ่าน proxy เพื่อดูว่าฟีเจอร์ใดร้องขอปลายทางอะไร

สร้างจาก source ที่ pin commit หลัง review dependency lockfile และ build scripts เปรียบเทียบ hash ของ artifact ที่สร้างเองกับ distribution เฉพาะเมื่อผู้ขายมีวิธีอ้างอิงที่ตรวจได้ ห้ามใช้ remote installer แบบ curl | sh และห้ามล็อกอินด้วยบัญชีองค์กรระหว่าง sandbox trial

ปิด Repo Wiki/cloud indexing และ telemetry ที่ไม่จำเป็น ตรวจ setting หลัง update ทุกครั้งเพราะ default อาจเปลี่ยน Mount repository แบบ read-only จำกัด path ให้เป็น fixture เดียว และใช้ filesystem monitor ดูไฟล์ที่ process เปิด การเห็น process อ่านทั้ง home directory เป็นเหตุหยุดทดสอบทันที

ด้าน network ให้ใช้ DNS/proxy allowlist, บันทึก method/host/size โดยไม่เก็บ secret และทดสอบตอน offline ถ้า editor ใช้งานพื้นฐานไม่ได้เมื่อไม่มี network ให้บันทึก dependency นั้นอย่างตรงไปตรงมา อย่าฝืนเปิด private network เพื่อ “ให้ผ่าน”

ถ้ามีผู้ใช้รุ่นก่อนในองค์กร ให้ preserve log ที่มีอยู่ก่อน cleanup, ระบุ version/time/repository, rotate credential ที่อาจอยู่ใน repo, ตรวจ provider logs และแจ้ง security/privacy/legal ตาม classification ติดต่อผู้ขายขอ export/deletion evidence และ case number อย่าอัปโหลด repo ซ้ำเพื่อพิสูจน์ incident

สร้าง policy ที่บังคับให้เครื่องมือ AI แสดง file manifest, estimated bytes, destination, purpose และ retention ก่อน upload พร้อมปุ่ม cancel ที่หยุดจริง การ consent ควรเป็นราย repository/feature และหมดอายุ ไม่ใช่ checkbox ครั้งเดียวตอนติดตั้ง

ความเสี่ยงคงเหลือ

แม้ build จาก source ปัจจุบัน ความเสี่ยงยังมีใน dependency, update channel, hosted backend และ configuration ที่อาจชี้ไปบริการภายนอก Source review หนึ่งครั้งไม่ครอบคลุม release ถัดไป และโค้ดจำนวนมากเกินกว่าจะตีความว่าผ่านเพียงเพราะค้นคำว่า upload ไม่พบ

การทดสอบ network ด้วย fixture บอก behavior ที่เราเรียกใช้ แต่ไม่ครอบคลุม feature flag, account tier, region หรือเส้นทางที่ทำงานตามเวลา การไม่เห็น traffic ในหนึ่ง session ไม่ใช่หลักฐานว่าไม่มี traffic ทุกกรณี

การยืนยัน deletion จากภายนอกมีข้อจำกัดโดยธรรมชาติ ผู้ใช้มองไม่เห็น backup และ derived data ทั้งหมด ต้องอาศัยรายงาน audit, contractual commitment และ retention controls เพิ่ม การประกาศลบ bucket จึงลดความเสี่ยงแต่ไม่ทำให้ residual risk เป็นศูนย์

การเปิดซอร์สอาจทำให้ชุมชนพบปัญหาเร็วขึ้น แต่ผู้ใช้ทั่วไปยังติดตั้ง binary ที่ผู้ขายแจก หากไม่มี signed release, checksum และ build provenance ที่ตรวจได้ supply-chain gap ยังคงอยู่ และแม้ artifact ตรง source การตั้งสิทธิ์ filesystem/network กว้างก็ยังสร้างความเสี่ยงจากบั๊กหรือ prompt injection ได้

ดังนั้นสถานะที่เหมาะสมคือ quarantine จาก private/production code จนกว่าจะมีหลักฐานเพิ่ม ไม่ควรใช้คำว่า “ปลอดภัยแน่นอน” และไม่ควรใช้คำว่า “อันตรายแน่นอน” เกินหลักฐาน รอบนี้สรุปได้เพียงว่า ยังไม่ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ

แล้วควรทำอะไร

ถ้าคุณเคยใช้ ZCode ก่อน 3.14.0

อย่าเริ่มด้วยการลบทุกอย่างจนหลักฐานหาย บันทึก version, เวลาติดตั้ง/ใช้งาน, repository ที่เปิด และผู้ใช้ที่เปิด Repo Wiki เก็บ proxy/EDR/application logs ตาม policy แล้วค่อยประเมิน data classification Rotate secret ที่พบใน repository แม้ไม่มีหลักฐานว่าถูกส่ง เพราะ secret ใน source เองเป็นหนี้ที่ควรแก้อยู่แล้ว

ติดต่อช่องทางทางการเพื่อถามว่า account/repository ของคุณอยู่ใน scope หรือไม่ ขอหลักฐาน deletion และเงื่อนไขชดเชยเป็นลายลักษณ์อักษร หากมีข้อมูลลูกค้าหรือข้อมูลส่วนบุคคล ให้ privacy/legal ตัดสิน notification ตามสัญญาและกฎหมาย ไม่ประกาศหรือปกปิดจากความรู้สึก

ถ้าคุณกำลังพิจารณารุ่นปัจจุบัน

อย่าเริ่มกับงานจริง ทำ sandbox review ตามหัวข้อก่อนหน้า อ่าน source และ dependency ของ commit ที่ pin ขอ signed artifact/checksum และเอกสาร architecture/data flow จากผู้ขาย ถ้าตอบ hosted components, retention หรือ update provenance ไม่ได้ ให้คงสถานะไม่อนุมัติ

ตั้ง success criteria ก่อนทดลอง เช่น ต้องทำงาน offline สำหรับ local edit, ไม่มี network นอก allowlist, ไม่อ่านไฟล์นอก fixture, uninstall/revoke ได้ครบ และ log ไม่เก็บเนื้อหา source หากข้อใดไม่ผ่าน หยุดโดยไม่ผ่อนเกณฑ์เพื่อให้ quota ครบ

ถ้าคุณดูแลเครื่องมือ AI ทั้งองค์กร

ทำ catalog ของ code assistants ทุกตัวพร้อม owner, version, update channel, file scope, network destinations, data use และ approval status บังคับ egress ผ่านจุดบันทึกกลาง และแยกเครื่องมือทดลองออกจาก developer workstation ที่มี production credentials

เพิ่มคำถาม procurement ว่า feature ใดอัปโหลดทั้ง repository, preview/consent อยู่ตรงไหน, ignore rules ทำงานก่อนหรือหลัง upload, deletion ครอบคลุม backup หรือไม่, incident notification SLA เท่าไร และมี independent report ที่ลูกค้าอ่านได้หรือไม่

มุมมองของผม

การถอด data path และเปิดซอร์สมีน้ำหนักมากกว่าคำขอโทษลอย ๆ จึงควรรับรู้ว่าเป็นก้าวที่ถูกทิศ แต่ความเชื่อมั่นไม่ควรถูกรีเซ็ตด้วย release เดียว ผู้ขายต้องสะสมหลักฐานต่อเนื่อง ส่วนผู้ใช้ต้องเปลี่ยนจาก “เชื่อแบรนด์หรือไม่” เป็น “ควบคุมขอบเขตและตรวจ behavior ได้หรือไม่”

บทเรียนใหญ่กว่าชื่อ ZCode คือความยินยอมต้องเกิด ก่อน data movement และต้องอธิบายผลทางเทคนิคได้ การสร้าง wiki ที่เก่งขึ้นไม่ใช่เหตุผลให้ข้าม boundary ของ repository ครับ