OpenAI ปล่อย Codex Security CLI + TypeScript SDK เป็นโอเพนซอร์ส Apache-2.0 บน npm — สแกน–ยืนยัน–แพตช์ช่องโหว่จากบรรทัดคำสั่ง แต่เครื่องยนต์ยังเป็นบริการบนคลาวด์

เมื่อปลายเดือนมิถุนายน OpenAI ประกาศขยายโครงการความปลอดภัย Daybreak โดยฝัง Codex Security เป็นปลั๊กอินอยู่ในเครื่องมือเขียนโค้ด Codex — ตอนนั้นมันคือฟีเจอร์ในผลิตภัณฑ์ ไม่ใช่ของที่คุณหยิบไปวางในไปป์ไลน์ของตัวเองได้ คราวนี้เปลี่ยนแล้ว

ตั้งแต่ 28 กรกฎาคม 2026 OpenAI เผยแพร่แพ็กเกจ @openai/codex-security ขึ้น npm ในฐานะ CLI และ TypeScript SDK โดยรีโปที่ github.com/openai/codex-security ใช้สัญญาอนุญาต Apache-2.0 เต็มรูปแบบ เวอร์ชันแรก 0.1.0 ขึ้นเมื่อ 28 ก.ค. เวลา 17:09 UTC และไล่ออกเวอร์ชันถี่มากจนถึง 0.1.4 เมื่อ 30 ก.ค. ปัจจุบันรีโปมีดาวราว 5,257 ดวง เขียนด้วย TypeScript

แต่มีจุดที่ต้องอ่านให้ขาดก่อนตื่นเต้น และผมจะพูดถึงในหัวข้อท้าย ๆ: สิ่งที่เปิดซอร์สคือไคลเอนต์ ไม่ใช่ตัวสแกน

ครบลูป find → validate → fix ในบรรทัดคำสั่งเดียว

จุดขายของ Codex Security ตั้งแต่แรกคือไม่หยุดที่การ “หาเจอ” แล้วโยนรายงานดิบให้ทีมความปลอดภัยไปตามแก้เอง ชุดคำสั่งใน CLI สะท้อนแนวคิดนี้ตรง ๆ — มีทั้งหมด 8 คำสั่งหลัก:

คำสั่ง	หน้าที่
scan	สแกนหาช่องโหว่ในรีโป
validate	ยืนยันว่า finding ที่เจอเป็นของจริงไม่ใช่ false positive
patch	สร้างแพตช์แก้ไข
findings	ดูและอัปเดตสถานะ finding
scans	จัดการประวัติการสแกน (list/show/rerun/match/compare)
export	ส่งออกผลเป็น CSV, JSON หรือ SARIF
install-hook	ติดตั้ง Git pre-commit hook
bulk-scan	สแกนหลายรีโปรวดเดียว

การเริ่มใช้งานสั้นมาก:

npm install @openai/codex-security
npx @openai/codex-security login
npx @openai/codex-security scan .
npx @openai/codex-security scan . --model gpt-5.6-terra --effort high

ตัวเลือกที่น่าจะได้ใช้จริงในงานประจำวันคือกลุ่มที่กำหนดขอบเขตการสแกน ซึ่งเลือกได้อย่างใดอย่างหนึ่ง: --path ระบุพาธเจาะจง, --diff BASE สแกนเฉพาะการเปลี่ยนแปลงที่คอมมิตแล้วเทียบกับ base และ --working-tree สแกนเฉพาะไฟล์ที่ staged/unstaged อยู่ ส่วนโหมดมีสองระดับคือ --mode standard (ค่าเริ่มต้น) และ --mode deep ที่ไล่อ่านรีโปละเอียดกว่า

สำหรับคนที่จะเอาไปต่อกับ CI จุดที่ออกแบบมาดีคือ --fail-on-severity ซึ่งกำหนดเพดานความรุนแรง (critical/high/medium/low) ให้ build แดงเองได้ ประกอบกับ exit code ที่แยกความหมายชัด: 0 = ผ่าน, 1 = เจอ finding เกินเกณฑ์ที่ตั้งไว้, 2 = อินพุตผิด สแกนไม่ครบ หรือรีโปล้มเหลว ซึ่งต่างกันสำคัญมาก เพราะทำให้ pipeline แยกได้ว่า “เจอช่องโหว่” กับ “เครื่องมือพัง” ไม่ใช่เรื่องเดียวกัน

ฝั่ง bulk-scan รับไฟล์ CSV ที่มีคอลัมน์ id, repository, revision (พร้อมคอลัมน์เสริม scope และ mode) แล้วยิงขนานด้วย --workers ซึ่งค่าเริ่มต้นอยู่ที่ 4 — เหมาะกับทีมแพลตฟอร์มที่ต้องกวาดรีโปทั้งองค์กร ไม่ใช่แค่โปรเจกต์เดียว

ส่วน SDK ใช้ง่ายพอ ๆ กัน:

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();
const result = await security.run(".");

console.log(result.reportPath);
await security.close();

เรื่องคีย์และการยืนยันตัวตน — จุดที่ทีม DevSecOps ต้องอ่าน

ข้อกำหนดของระบบคือ Node.js 22.13.0 ขึ้นไปในสาย 22.x, หรือ 24.x, หรือ 26.x และ Python 3.10 ขึ้นไป

เรื่องเครดิเชียลมีรายละเอียดที่ทำมาถูกทาง: บนเครื่องนักพัฒนาใช้ล็อกอินผ่านบัญชี ChatGPT ได้ ส่วนบน CI ให้ตั้ง OPENAI_API_KEY หรือ CODEX_API_KEY แทน โดย README ระบุชัดว่า API key จากตัวแปรสภาพแวดล้อมจะถูกส่งตรงไปยังการสแกนครั้งนั้น และไม่เคยถูกเก็บลง credential home ของ Codex หรือ system keyring — เป็นรายละเอียดเล็กที่สำคัญ เพราะคีย์ที่ค้างอยู่ในไฟล์สถานะบนรันเนอร์คือช่องทางรั่วที่คลาสสิกที่สุดช่องหนึ่ง

ถ้ามีทั้งล็อกอิน ChatGPT และ API key อยู่พร้อมกัน การสแกนแบบโต้ตอบจะถามว่าจะใช้อันไหน ส่วนโหมดที่ไม่โต้ตอบ (CI) จะยึด API key ก่อนตามเดิม และเลือกเองได้ด้วย --auth chatgpt หรือ --auth api-key

อีกจุดที่ควรตั้งแต่แรกคือ CODEX_SECURITY_STATE_DIR — ประวัติการสแกนถูกเก็บใน state directory ของ workbench ถ้าเขียนไม่ได้ต้องชี้ไปโฟลเดอร์อื่น และควรตั้งให้ อยู่นอกรีโป อยู่แล้ว จะได้ไม่เผลอคอมมิตผลสแกนช่องโหว่ของตัวเองขึ้น public repo

”โอเพนซอร์ส” ตรงไหน และไม่ใช่ตรงไหน

นี่คือประเด็นที่สื่อหลายเจ้ารายงานคลาดเคลื่อน (บางเจ้าถึงกับชี้ไปที่ GitHub org ผิดตัว) และเป็นจุดที่ควรพูดให้ตรง

สิ่งที่เป็น Apache-2.0 จริง คือซอร์สโค้ดของ CLI และ TypeScript SDK ในรีโป openai/codex-security คุณอ่านได้ แก้ได้ ฟอร์กได้ เอาไปห่อในเครื่องมือภายในองค์กรได้ ตรวจสอบได้ว่ามันส่งอะไรออกไปบ้าง

สิ่งที่ไม่ได้เปิด คือเครื่องยนต์ที่วิเคราะห์โค้ดจริง ๆ README ระบุเงื่อนไขไว้ตรงไปตรงมาว่าต้องมี “access to Codex Security” และแนะนำว่าบัญชีควรผ่านการยืนยัน Trusted Access จึงจะได้ผลดีที่สุด ตัวบริการยังอยู่ในสถานะ เบตา และ flag อย่าง --model gpt-5.6-terra ก็บอกชัดว่างานวิเคราะห์เกิดขึ้นฝั่งโมเดลของ OpenAI ไม่ใช่ในเครื่องคุณ

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

มุมมอง AI Curator

ผมคิดว่าการเปิดซอร์สรอบนี้มีค่ามากกว่าที่ตัวเลขดาวบน GitHub บอก แต่ด้วยเหตุผลที่ต่างจากที่คนส่วนใหญ่พูดถึง

คุณค่าจริงไม่ได้อยู่ที่ “ได้ของฟรี” — เพราะการสแกนยังต้องจ่ายผ่านบัญชี OpenAI อยู่ดี คุณค่าอยู่ที่ การตรวจสอบได้ เครื่องมือความปลอดภัยเป็นสินค้าประเภทที่ย้อนแย้งที่สุด: คุณต้องยอมให้มันอ่านซอร์สโค้ดทั้งหมดขององค์กร เพื่อแลกกับการที่มันจะบอกว่าโค้ดคุณไม่ปลอดภัยตรงไหน ถ้าไคลเอนต์เป็นกล่องดำ คุณกำลังเชื่อคำสัญญาล้วน ๆ ว่ามันส่งอะไรออกไปบ้าง แต่พอไคลเอนต์เป็น Apache-2.0 ทีมความปลอดภัยขององค์กรอ่านเองได้ว่าอะไรถูกส่งขึ้นคลาวด์ อะไรอยู่ในเครื่อง คีย์ถูกเก็บที่ไหน — และนั่นคือสิ่งที่ทำให้ผ่านการอนุมัติในองค์กรที่มีกระบวนการจริงจังได้ ต่างจากไบนารีปิดที่ต้องเถียงกันเป็นเดือน

สำหรับทีมไทย ผมมองว่าจุดที่ควรพิจารณาก่อนอย่างอื่นคือ โค้ดของคุณจะออกนอกประเทศ งานที่รับจ้างพัฒนาให้ลูกค้าองค์กร โดยเฉพาะภาคธนาคาร ประกัน และหน่วยงานรัฐ มักมีข้อสัญญาที่ห้ามส่งซอร์สโค้ดออกนอกสภาพแวดล้อมที่ตกลงกันไว้ การรัน codex-security scan . บนรีโปแบบนั้นอาจเป็นการผิดสัญญาโดยไม่ตั้งใจ — และการที่ CLI เป็นโอเพนซอร์สไม่ได้ช่วยอะไรตรงนี้เลย เพราะปัญหาอยู่ที่ปลายทางไม่ใช่ที่ไคลเอนต์ ทีมที่จะใช้ควรเริ่มจากรีโปภายในของตัวเองก่อน แล้วค่อยคุยเรื่องข้อสัญญาทีหลัง ไม่ใช่กลับกัน

ประเด็นที่สองที่ผมอยากให้ระวังคือ อย่าเอา --fail-on-severity ไปวางใน CI ของทีมทันทีในวันแรก เครื่องมือประเภทนี้ในช่วงเบตามักให้ finding ที่ต้องใช้วิจารณญาณเยอะ ถ้าตั้งให้ build แดงตั้งแต่ต้น สิ่งที่จะเกิดขึ้นไม่ใช่โค้ดปลอดภัยขึ้น แต่คือทีมเรียนรู้ที่จะกด override จนกลายเป็นนิสัย แล้วเครื่องมือก็ตายไปในเชิงวัฒนธรรม วิธีที่ได้ผลกว่าคือรันแบบรายงานอย่างเดียวสัก 2-3 สปรินต์ ใช้ export --export-format sarif ส่งเข้าระบบที่ทีมดูอยู่แล้ว ดูอัตรา false positive กับโค้ดเบสจริงของตัวเอง แล้วค่อยขยับมาบังคับเฉพาะระดับ critical

สุดท้าย ในสัปดาห์ที่ข่าว AI ด้านความปลอดภัยเต็มไปด้วยเรื่องที่ agent ทำตัวเป็นผู้บุกรุกเสียเอง — ทั้งเหตุการณ์ที่ Hugging Face และเวิร์มในเอกสาร Word — การมีเครื่องมือฝั่งตั้งรับที่นักพัฒนาหยิบใช้ได้จริงจากเทอร์มินัลถือเป็นความสมดุลที่ควรเกิดขึ้นนานแล้ว แต่ก็อย่าลืมความย้อนแย้งที่ซ่อนอยู่: เรากำลังแก้ปัญหาที่ AI สร้าง ด้วยการให้ AI อีกตัวอ่านโค้ดทั้งหมดของเรา ความไว้วางใจนั้นควรมาจากการตรวจสอบได้ ไม่ใช่จากพาดหัวข่าว — และอย่างน้อยรอบนี้ OpenAI ก็เปิดส่วนที่ตรวจสอบได้ให้แล้วจริง

แหล่งข่าว

• openai/codex-security — GitHub (Apache-2.0)
• Codex Security CLI documentation — OpenAI
• Codex Security CLI reference
• OpenAI open-sources Codex Security CLI — The Decoder