GitHub Copilot CLI 1.0.91 ปรับ sandbox CA และ network bypass—ทำไมคำเตือนเครือข่ายต้องเป็น gate ไม่ใช่ banner

GitHub Copilot CLI 1.0.91 ออกวันที่ 1 ตุลาคม 2026 โดยแตะจุดที่เกี่ยวกับ sandbox โดยตรง: คำสั่งจัดการ certificate authority, คำเตือนเมื่อใช้ network bypass บน Windows, การตรวจหลักฐานของ read-only shell pipeline และการ flush telemetry แบบมีขอบเขต ฟังเหมือนงานเก็บรายละเอียด แต่ทั้งหมดอยู่ตรงเส้นแบ่งว่า agent เชื่อมเครือข่าย รันคำสั่ง และส่งข้อมูลอย่างไรครับ

ผมตรวจ release ทางการ, metadata ของ npm package, SHA256SUMS.txt และ security advisories แบบอ่านอย่างเดียว ไม่ติดตั้ง ไม่รัน binary และไม่ทดสอบกับ credential รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ แต่ network bypass กับ trust store เป็นสิทธิ์ระดับโครงสร้างพื้นฐานที่ต้องมี policy มากกว่าคำเตือนบนจอครับ

สรุป 30 วินาที

• 1.0.91 เพิ่มคำสั่งเกี่ยวกับ CA สำหรับ sandbox และเพิ่มคำเตือนในกรณี Windows npm socket เจอ EACCES แล้วมีเส้นทาง network bypass การแก้ปัญหาเชื่อมต่อไม่ควรเปลี่ยนเป็นช่องทางออกนอกการควบคุมโดยเงียบ
• release ปรับการ review หลักฐานสำหรับ read-only shell pipeline คำว่า read-only ต้องพิจารณาทั้ง pipeline เพราะคำสั่งต้นทางอาจอ่านข้อมูลลับและปลายทางอาจส่งออก แม้ไม่เขียนไฟล์
• bounded telemetry flush ลดโอกาสรอไม่จบหรือค้างตอนปิด แต่ทีมยังต้องรู้ว่า telemetry เก็บ field ใด ส่งไปไหน และ redaction secret อย่างไร
• asset copilot-darwin-arm64.tar.gz มี SHA-256 b29e…847b และ release มี SHA256SUMS.txt; npm มี integrity/signature สำหรับช่องทาง registry
• advisory ระดับสูง CVE-2026-29783 กระทบถึง 0.0.422 และแก้ 0.0.423; advisory ระดับกลาง CVE-2026-45033 กระทบถึง 1.0.42 และแก้ 1.0.43 รุ่น 1.0.91 อยู่นอกช่วงทั้งคู่ตามข้อมูลวันที่ตรวจ
• การอัปเดตควร pin version, ตรวจ digest, ทดลอง proxy/CA/bypass ใน network จำลอง, ปิด production secret และบังคับ approval สำหรับ egress หรือ shell pipeline ที่แตะข้อมูลสำคัญ

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

ในองค์กรจำนวนมาก developer ออกอินเทอร์เน็ตผ่าน proxy ที่ตรวจ TLS และใช้ CA ภายใน เมื่อ sandbox ไม่รู้จัก CA การติดตั้ง package หรือเรียก API จะล้ม ทีมจึงอยากเพิ่มใบรับรองหรือเปิด bypass ให้ทำงานต่อ จุดนี้เหมือนด่านตรวจรถ: ถ้าเครื่องอ่านบัตรเสีย ทางออกเร็วที่สุดคือเปิดไม้กั้น แต่การเปิดไม้กั้นทำให้รถทุกคันผ่านโดยไม่มีหลักฐานด้วย

ผู้ใช้ทั่วไปอาจเห็นเพียงคำเตือนหนึ่งบรรทัดแล้วกดต่อเพราะต้องส่งงาน ทีม security กลับเห็นช่องทางที่ข้อมูล source, token หรือ prompt อาจออกจากเครือข่ายโดยไม่ผ่าน proxy ดังนั้น UI warning ช่วยเรื่องการรับรู้ แต่การตัดสินใจระดับนี้ควรถูกบังคับจาก policy กลาง เช่น deny ใน production workspace หรือ require administrator-approved exception ที่หมดอายุ

read-only pipeline ก็เกี่ยวข้องมากกว่าชื่อ สมมติคำสั่งแรกอ่านไฟล์ .env และคำสั่งถัดไปส่งข้อความไป endpoint ภายนอก ไม่มีไฟล์ใดถูกเขียน แต่ secret หายไปแล้ว การจัดประเภท command ต้องดู source, transformation และ sink ทั้งสาย ไม่ใช่ดูแค่คำสุดท้าย

ทำงานยังไง: ใบรับรองคือรายชื่อคนที่ด่านไว้ใจ

TLS certificate ช่วยให้ client ตรวจว่ากำลังคุยกับ server ที่ถูกต้อง CA คือผู้ออกใบรับรองที่ client ยอมรับ เปรียบเหมือนรายชื่อหน่วยงานที่ด่านเชื่อว่าออกบัตรพนักงานจริง การเพิ่ม CA ภายในอาจจำเป็นในบริษัท แต่ถ้าเพิ่มผิดตัว ผู้ที่ถือกุญแจของ CA นั้นอาจออกบัตรให้โดเมนใดก็ได้ในขอบเขตที่ client ยอมรับ

ดังนั้นคำสั่งจัดการ CA ต้องมีสามหลักฐาน: CA มาจากทีมไหน fingerprint เท่าไร และใช้กับ sandbox/profile ใด ห้ามคัดลอก certificate จากข้อความแชตหรือ URL ที่ไม่ได้ยืนยัน และไม่ควรเพิ่มลง trust store ทั้งระบบถ้า workspace-level store พอใช้

Network bypass คือการให้ traffic ไม่ผ่านเส้นทางควบคุมปกติ อาจแก้ socket permission หรือ proxy incompatibility ได้ แต่ทำให้ domain allowlist, DLP, logging หรือ TLS inspection ใช้ไม่ได้บางส่วน Bypass ที่ปลอดภัยกว่าต้องจำกัด process, destination, port, เวลา และ identity พร้อม log เหตุผล หากทำไม่ได้ ควร fail closed และแก้ root cause แทน

Shell pipeline เชื่อม stdout ของคำสั่งหนึ่งเป็น stdin ของอีกคำสั่ง เครื่องมืออาจเห็น cat file | parser ว่าอ่านอย่างเดียว แต่ parser อาจโหลด plugin หรือคำสั่งท้ายอาจเปิด network ระบบ review จึงควร normalize pipeline, redirection, subshell และ environment ก่อนตัดสินใจ ไม่ใช่หา keyword อันตรายด้วย string match อย่างเดียว

Telemetry flush คือการส่ง event ที่ค้างก่อน process จบ ถ้ารอไม่มีกำหนด CLI อาจ hang; ถ้าไม่รอเลย log อาจหาย การมีเวลาจำกัดเป็น reliability improvement แต่ privacy boundary อยู่ที่ event schema, redaction, destination และ retention ไม่ใช่ timeout ทีมจึงต้องตรวจสองเรื่องแยกกัน

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

ต้นทางหลักคือ release v1.0.91 ของ repository github/copilot-cli รายการเปลี่ยนแปลงตรงกับหัวข้อ sandbox CA, network bypass warning, pipeline evidence และ telemetry ต้นทาง supply chain คือ npm @github/copilot รุ่น 1.0.91 ซึ่งเผย integrity และ signature metadata

release มี asset สำหรับแต่ละ platform และไฟล์ SHA256SUMS.txt; asset macOS arm64 แสดง digest b29e…847b ใน metadata ผมไม่ได้ดาวน์โหลดหรือ execute การตรวจ checksum หลังดาวน์โหลดจริงยังเป็นหน้าที่ install pipeline

หน้า advisories แสดง CVE-2026-29783 ระดับสูงในรุ่นเก่าถึง 0.0.422 แก้ที่ 0.0.423 และ CVE-2026-45033 ระดับกลางถึง 1.0.42 แก้ที่ 1.0.43 รุ่น 1.0.91 สูงกว่าช่วง patched ทั้งสอง แต่ advisory ที่เปิดเผยไม่ครอบคลุมปัญหาที่ยังไม่รายงาน

เอกสาร GitHub ใช้ประกอบการตีความ capability และขอบเขต CLI ร่วมกับ release note จากหลักฐาน publisher, tag, registry provenance, checksums และ patch status รุ่นนี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-02 ภายใต้เงื่อนไขว่าองค์กรไม่เปิด network bypass กว้างและตรวจ CA ที่เพิ่มทุกตัว

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

การรองรับ CA และแก้ network friction ลดเวลาที่นักพัฒนาติด proxy แต่ bypass ที่ไม่มีขอบเขตอาจสร้างต้นทุน incident, audit finding และการรั่วข้อมูลสูงกว่านาทีที่ประหยัดได้ metric จึงควรรวมจำนวน bypass request, domain ที่ออกจริง, CA change, denied egress, pipeline escalation และ secret canary event

ทีมควรแยก availability issue จาก policy exception หาก npm socket ล้มเพราะ permission ให้แก้ permission หรือ packaging ก่อน ไม่ควรทำ bypass เป็นค่าถาวร ค่าใช้จ่ายในการทำ proxy compatibility ครั้งเดียวมักต่ำกว่าการตามตรวจ traffic ที่หลุดด่านตลอดปี

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

release note บอกว่ามีคำเตือน network bypass แต่ไม่ได้หมายความว่าทุกองค์กรจะบล็อกได้จาก policy เดียวกัน Configuration, Windows sandbox และ network stack ต่างกัน ทีมต้องทดสอบบน image จริงของตัวเอง

คำว่า read-only shell pipeline อาจมีนิยามต่างระหว่างเครื่องมือกับ policy ภายในองค์กร สิ่งที่ core อนุญาตอาจยังขัดกฎข้อมูลของบริษัท เช่นอ่านไฟล์ลูกค้าแล้วส่งเข้า local model ที่มี telemetry ทีมต้องสร้าง policy ที่เข้มกว่า default ได้

npm signature กับ SHA256SUMS.txt เป็นหลักฐานคนละช่องทาง หากติดตั้งผ่าน npm ควรตรวจ integrity ของ tarball registry หากใช้ binary release ควรตรวจ digest จาก release อย่าอ้างการตรวจช่องทางหนึ่งแทนอีกช่องทาง

advisory ปัจจุบันบอกว่า 1.0.91 อยู่นอก affected range ที่รู้ แต่ dependency, platform-specific bug และ zero-day ยังเป็นความเสี่ยง เราไม่พบหลักฐาน high/critical advisory ที่กระทบรุ่นนี้โดยไม่มี mitigation ณ วันที่ตรวจ ไม่ได้แปลว่าไม่มีความเสี่ยงเลย

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

1. pin 1.0.91 และบันทึก npm integrity หรือ SHA-256 ตาม install channel จริง
2. รับ CA เฉพาะจากช่องทาง IT ที่ยืนยันได้ ตรวจ fingerprint แบบ out-of-band และจำกัด trust store ให้อยู่ใน sandbox/profile ที่จำเป็น
3. ตั้ง network bypass เป็น deny by default ถ้าต้องยกเว้นให้จำกัด process/domain/port/เวลา พร้อม ticket และ owner
4. ทดสอบด้วย proxy จำลองและ canary secret ตรวจว่า bypass ไม่พาข้อมูลออกไป domain นอก allowlist
5. วิเคราะห์ shell pipeline ทั้งเส้น รวม redirection, subshell, command substitution และ sink ที่เปิด network
6. แยก credential ต่อเครื่องมือ ใช้ token อายุสั้น scope แคบ และไม่วาง production secret ใน environment ที่ agent อ่านได้
7. ตรวจ telemetry schema, redaction, endpoint และ retention หลังอัปเดต อย่าถือ bounded flush เป็น privacy control
8. ให้ git push, PR mutation, package publish และ deploy ต้องผ่าน human approval กับ CI เดิม

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

CA ภายในที่ถูกต้องก็อาจถูก compromise ได้ Proxy อาจ log ข้อมูลมากเกินไป และ bypass แบบจำกัดอาจมีช่องจาก DNS, redirect หรือ child process ทีมต้องเฝ้าระวัง runtime ไม่ใช่ตรวจ config ครั้งเดียว

pipeline classifier อาจตีความ shell edge case ผิด โดยเฉพาะ alias, script ที่เปลี่ยนหลัง review หรือ executable จาก repository Prompt injection อาจเลือกคำสั่งที่ดู read-only แต่ส่งข้อมูลผ่าน side channel เช่น DNS หรือ error report

human approval ยังเสี่ยงจาก fatigue และข้อความเตือนที่ไม่บอกผลกระทบครบ ทีมควรให้ policy engine บล็อกสิ่งที่ไม่ยอมรับแทนการโยนทุกครั้งให้ผู้ใช้ตัดสินใจ และเก็บ manual fallback เมื่อ CLI ใช้งานผ่าน network ที่ปลอดภัยไม่ได้

ควรทำอะไร

ผู้ใช้เดี่ยวอัปเดตได้ใน workspace ทดลองโดยยังไม่เปิด bypass ทีม enterprise ควรให้ endpoint engineering ทดสอบ CA/proxy บน image มาตรฐานก่อน rollout security team ควรทำ egress test และ review exception path ส่วนทีมพัฒนาควรถือ output ของ CLI เป็นข้อเสนอที่ต้องผ่าน test/review ไม่ให้ agent ใช้ credential push หรือ deploy โดยตรง

หากกำลังใช้รุ่นก่อน patched range ของ advisories ให้จัดลำดับอัปเดตสูงขึ้น แต่ยังคงตรวจ provenance ถ้า network ใช้งานไม่ได้หลังอัปเดต ให้เก็บ PR หรือ patch ไว้และแก้ policy compatibility ไม่ควรเปิดช่องทางกว้างเพื่อให้ automation ผ่านเร็ว

Recap

• ตรวจ Copilot CLI 1.0.91 จาก tag, npm integrity/signature, SHA256SUMS และ advisories แล้ว
• รุ่นนี้ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ ไม่ใช่คำรับรองว่าปลอดภัยแน่นอน
• CA ทุกตัวต้องมี owner, fingerprint และ scope ที่บันทึกได้
• network bypass ต้อง deny by default และข้อยกเว้นต้องแคบ/หมดอายุ
• ตรวจ shell pipeline ตั้งแต่แหล่งข้อมูลถึงปลายทาง ไม่ดูแค่คำว่า read-only
• แยก telemetry reliability ออกจาก privacy/redaction review
• จำกัด secret, filesystem, network และ side effect คนละชั้น
• rollout แบบ canary พร้อม egress test, kill switch และ manual fallback

1.0.91 ปรับจุดที่ควรปรับครับ แต่คำเตือนที่ดีไม่ควรเป็นกำแพงชั้นสุดท้าย ถ้าองค์กรบังคับ trust store, egress และ pipeline policy จากส่วนกลาง ต่อให้ผู้ใช้รีบส่งงาน ระบบก็ยังไม่เปิดไม้กั้นทั้งด่านเพราะปุ่มเดียวครับ