กุญแจโลหะถูกเก็บหลังผนึกข้างกล่อง shell sandbox ขณะที่ทางอนุมัติชัดเจนมีสลักอำพันหนึ่งจุด

GitHub Copilot CLI 1.0.92 ไม่ส่ง GITHUB_TOKEN เข้า sandbox อัตโนมัติ—explicit credential ยังต้องแคบ

พี่โชว์Engineering

GitHub Copilot CLI 1.0.92 ออกคืนวันที่ 5 ตุลาคม 2026 UTC พร้อมการเปลี่ยนที่ควรสนใจมากที่สุด: sandboxed shell จะไม่รับ ambient GITHUB_TOKEN โดยอัตโนมัติ เว้นแต่กำหนดชัด รุ่นนี้ยังเพิ่ม copilot config, ตัวเลือก local/cloud ก่อนเริ่มสนทนา, การต่ออายุ Entra MCP credential, bounded timeout สำหรับ legacy SSE MCP และแก้ auth ตอน remote resume ครับ

ผมตรวจ release v1.0.92, npm package, SHA256SUMS, เอกสาร Copilot CLI และ advisories แบบอ่านอย่างเดียว ไม่ติดตั้ง ไม่รัน binary/MCP หรือใช้ credential รุ่นนี้ ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ แต่ explicit token, network bypass และ remote auth ยังเป็น authority ที่ผู้ดูแลต้องคุม

สรุป 30 วินาที

  • ambient GITHUB_TOKEN ไม่ไหลเข้า sandboxed shell โดยปริยาย ลดกรณี command จาก prompt injection หยิบ token ที่ process แม่มีอยู่ทันที
  • ถ้า workflow ต้องใช้ GitHub auth ยังตั้ง explicit ได้ นั่นจึงเป็น secure default ไม่ใช่การเอาความสามารถออก ต้องจำกัด scope/repository/expiry และ approval
  • copilot config เพิ่มช่อง list/read/set/remove settings ช่วย automation แต่ config mutation ต้องถูก audit เพราะเปลี่ยน sandbox/network/UX behavior ได้
  • pre-conversation environment picker แยก local กับ cloud ชัดขึ้น แต่ข้อมูลและ credential ของสอง environment ไม่ควรถูกถือว่าเท่ากัน
  • Entra-protected MCP ต่ออายุ access-token-only credential เงียบได้ และ remote session ใช้ configured GitHub auth ตอน resume/connect ความต่อเนื่องดีขึ้นแต่ token lifecycle ยาวขึ้นในทางปฏิบัติ
  • macOS arm64 asset SHA-256 คือ 6aa2af1d…9f905c5b; release มี SHA256SUMS.txt digest 0b46f44b…02d04c49

ทำไมเกี่ยวกับคุณ

Environment variable เป็น ambient authority: code ไม่ต้องขอ token จาก user ใหม่ เพียงอ่านชื่อตัวแปรก็ใช้สิทธิ์ได้ หาก shell ถูกชักด้วยข้อความใน issue หรือไฟล์ README ผลกระทบอาจไปถึง repository mutation, private code หรือ workflow secret ตาม scope ของ token

การไม่ส่ง token อัตโนมัติเหมือนพนักงานเข้าห้องช่างโดยไม่พก master key ติดกระเป๋า ถ้างานต้องเปิดตู้จริง เขาขอคีย์ชั่วคราวเฉพาะตู้ได้ ความต่างนี้ลด blast radius แต่ต้องมั่นใจว่ากระบวนการขอ explicit credential ไม่ออก master key เหมือนเดิม

ทำงานยังไง: ambient กับ explicit authority

ambient credential มากับ process environment โดย caller อาจไม่รู้ว่า child process มองเห็นอะไร Sandboxed shell ที่ inherit env จึงสามารถอ่าน GITHUB_TOKEN และเรียก API/git ได้ทันที รุ่น 1.0.92 เปลี่ยน default ให้ withhold ค่า เว้นแต่ config ระบุ explicit

Explicit ไม่ได้แปลว่าปลอดภัยเอง ค่าที่กำหนดควรเป็น installation/user token อายุสั้น จำกัด repo และ permission เช่น contents read แทน classic PAT กว้าง หากต้อง push ให้แยก step, branch และ human approval ไม่ให้ agent งานอ่าน issue ถือ write tokenตลอด session

MCP OAuth/Entra token renewal เพิ่มความพร้อมใช้งาน แต่ session ที่ยาวอาจรักษาสิทธิ์ต่อเนื่องเกินที่ผู้ใช้คาด ต้องมี revocation, audience validation, inactivity timeout และ indicator ว่ากำลังใช้ identity ใด Remote resume หลัง credential ถูกเปลี่ยนก็ต้อง re-check repo/branch/intent ไม่ใช่เดิน action เก่าต่อทันที

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

Release v1.0.92 ของ repository github/copilot-cli ระบุ behavior withholding GITHUB_TOKEN, config subcommands, environment picker, MCP renewal/timeouts, network bypass prompt, masked credentials สำหรับ sandboxed git และ remote auth/resume ไว้ชัด เราแยก change ที่ลด ambient authority ออกจาก change ที่เพิ่ม convenience

GitHub assets มี digest ต่อไฟล์ และ SHA256SUMS.txt สำหรับตรวจหลังดาวน์โหลด ตัวอย่าง copilot-darwin-arm64.tar.gz เป็น 6aa2af1d0436b23c92810f11ea35a3d1c2b36b716d3e6d7c44299d199f905c5b ส่วน npm channel ต้องตรวจ integrity/signature ของ package ที่ registry แจกจริง

Advisory ที่เปิดเผยก่อนหน้า ได้แก่ CVE-2026-29783 ระดับสูงแก้ตั้งแต่ 0.0.423 และ CVE-2026-45033 ระดับกลางแก้ตั้งแต่ 1.0.43 รุ่น 1.0.92 อยู่นอกช่วง affected ที่ประกาศ ณ วันที่ตรวจ แต่ advisory ไม่ครอบคลุม dependency หรือ zero-day ที่ยังไม่รายงาน

จาก publisher, repository, tag/changelog, SHA256SUMS, registry provenance, docs และ advisory range รุ่นนี้จึง ผ่านเกณฑ์คัดกรอง ณ วันที่ตรวจ 2026-10-06 โดยมีเงื่อนไขว่า explicit credentials กับ bypass ถูกจำกัดจริง

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

Secure default อาจทำให้ script เดิมที่พึ่ง ambient token ล้ม ทีมควรถือ failure นี้เป็นโอกาส inventory สิทธิ์ ไม่ใช่รีบ inject token กลับทุก session แยกงาน read-only, PR creation และ deploy ใช้ credential คนละตัวเพื่อลดค่าความเสียหายเมื่อหนึ่ง step ถูกยึด

วัด denied token access, explicit credential requests, repo scope, network bypass, MCP refresh, failed resume และ human approval การลด failure rateอย่างเดียวอาจผลักทีมให้เปิดสิทธิ์กว้างจนความปลอดภัยถอย

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

Release note บอกว่า token ถูก withhold เว้นแต่ explicit แต่ไม่ได้แจกแจงทุกช่องทางที่ credential อาจเข้ามา เช่น git credential helper, SSH agent, keychain, mounted config หรือ cloud identity การทดสอบต้องครอบช่องทางเหล่านี้ ไม่ใช่เช็ก env อย่างเดียว

คำว่า masked credentials สำหรับ sandboxed scripts ช่วยลดการแสดงค่า แต่ masking ไม่ลด permission ของ token และอาจพลาด encoding/derived value Network bypass prompt ยังอนุญาตผู้ใช้เปิดทางเมื่อ proxy บล็อก จึงต้องมี managed deny หรือ allowlist ถ้าองค์กรไม่ยอมรับ bypass

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

  1. pin 1.0.92 และตรวจ SHA256SUMS หรือนpm integrity ตาม install channel
  2. ลบการพึ่ง ambient token จาก workflow สร้าง explicit token ต่อ step/repo อายุสั้นและ permission ต่ำสุด
  3. ทดสอบ env, git helper, SSH agent, keychain และ mounted files ว่า sandbox มองเห็น credential อะไรจริง
  4. deny network bypass เป็นค่าเริ่มต้น จำกัด destination/port/time เมื่อมี exception
  5. pin MCP server, ตรวจ OAuth audience/scope, ตั้ง inactivity expiry และทดสอบ revoke ระหว่าง session
  6. เก็บ config change audit เพราะ copilot config set/remove เปลี่ยน behavior ระยะยาวได้
  7. บังคับ human approval กับ push, publish, deploy, secret/permission change และตรวจ SHA ก่อน side effect

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

เริ่มจาก inventory ทุกทางที่ Copilot CLI รับ credential แล้วปิด ambient path ที่ไม่จำเป็น ทดสอบด้วย repository และบัญชีทดลองว่า shell, git, MCP และ network เห็นสิทธิ์เท่าใด จากนั้นออก token อายุสั้นต่อ step พร้อม repository scope แคบ และให้ CI เป็นผู้ทำ side effect ที่ตรวจซ้ำได้ เช่น push, release หรือ deploy

ทีม platform ควรประกาศ policy ของ network bypass, config mutation และ remote session ให้ชัด ส่วนทีม application ต้องยืนยัน input/output ของ tool ทุกตัวก่อนเปิดใช้ production ถ้า rollout ทำให้ script เดิมล้ม ให้แก้ ownership ของ credential ที่ต้นเหตุ ไม่เพิ่ม master token กลับเข้าทุก process เพื่อให้กราฟเขียวเร็วขึ้น

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

แม้ไม่มี GITHUB_TOKEN shell อาจใช้ SSH key, credential helper หรือ cloud session identity Prompt injection ยังเรียก network/MCP หรืออ่านไฟล์ลับได้ถ้าสิทธิ์เหล่านั้นเปิด Token refresh ทำให้ credential ที่คิดว่าจะหมดอายุยังใช้งานต่อผ่าน refresh path

Remote session steering และ context rollover ที่เก็บคำขอล่าสุดช่วย continuity แต่ stale instruction กับ changed repo state ยังเสี่ยง ต้องตรวจ precondition ใหม่ก่อน action ที่ย้อนกลับยาก และมี kill switch หยุด session/connection ได้จริง

Recap

  • ตรวจ release, digest/npm provenance และ advisory range
  • ไม่พึ่ง ambient token; ออก explicit credential ที่แคบและสั้น
  • ตรวจ credential side channels นอก environment ด้วย
  • คุม config, network bypass, MCP refresh และ remote resume
  • ให้ side effect ผ่าน approval/CI และยืนยัน state ใหม่
  • monitor runtime และเก็บ kill switch หลัง rollout

การเอา master key ออกจากกระเป๋าเริ่มต้นเป็นทิศทางที่ถูกครับ ขั้นต่อไปคืออย่าแก้ความไม่สะดวกด้วยการวาง master key ไว้หน้าประตูแทน