GitLab เปิดตัว Dependency Firewall สกัดแพ็กเกจอันตรายก่อนเข้า build ของ CI
GitLab เปิด Dependency Firewall รุ่น early access ในงาน Transcend 6 ต.ค. 2026 บล็อกแพ็กเกจที่มีมัลแวร์ ช่องโหว่ หรือไลเซนส์ต้องห้ามก่อนเข้า build ของ CI
โดย กองบรรณาธิการ THAI DATA อ่าน 6 นาที
สรุปประเด็นสำคัญ
- GitLab เปิดตัว Dependency Firewall ในงาน Transcend เมื่อ 6 ตุลาคม 2026 เป็นรุ่น early access สำหรับลูกค้า GitLab.com และ GitLab Self-Managed ระดับ Premium และ Ultimate
- นโยบายตั้งได้ 4 เกณฑ์ คือ สถานะมัลแวร์ ระดับความรุนแรงของช่องโหว่ ไลเซนส์ และอายุขั้นต่ำของแพ็กเกจ เลือกได้ว่าจะเตือน (warn) หรือบล็อก (block) และใช้ร่วมกับ JFrog Artifactory หรือ Sonatype Nexus Repository ได้
- GitLab Artifact Central รีจิสทรีแพ็กเกจระดับองค์กร เปิด beta ฟรีบน GitLab.com รองรับ Maven, npm, Docker และ OCI ส่วน Self-Managed มีแผนตามมาภายในเดือนตุลาคม 2026
- GitLab ยกเหตุการณ์เดือน มิถุนายน 2026 ที่นักวิจัยของบริษัทพบแพ็กเกจ PyPI อันตราย 5 รายการ โดย 4 รายการปลอมชื่อ Flask, Requests และ NumPy เพื่อขโมย credential ของ CI/CD
- งานเดียวกันประกาศ GitLab Secrets Manager ที่จะ GA ภายในเดือนนี้ และการตั้งเพดานเครดิต AI พร้อมแจ้งเตือนที่ 50%, 80% และ 100% ของงบ
GitLab เปิดตัว Dependency Firewall ในงาน Transcend เมื่อวันที่ 6 ตุลาคม 2026 เป็นเครื่องมือที่ตรวจแพ็กเกจโอเพนซอร์สตามนโยบายขององค์กรก่อนติดตั้งเข้า build และบล็อกแพ็กเกจที่มีมัลแวร์ ช่องโหว่ หรือไลเซนส์ต้องห้ามได้ทันที รุ่นแรกเป็น early access สำหรับลูกค้าแผน Premium และ Ultimate
งานเดียวกัน GitLab ประกาศรีจิสทรีระดับองค์กร Artifact Central รุ่น beta, Secrets Manager และตัวคุมงบ AI ซึ่งบริษัทระบุว่าเป็นประกาศรวมกว่า 12 รายการสำหรับงานพัฒนาซอฟต์แวร์ที่ใช้เอเจนต์ AI
Dependency Firewall ตรวจอะไร และบล็อกอย่างไร
GitLab อธิบายปัญหาว่าการสแกนแบบ software composition analysis (SCA) ตรวจของที่ดึงเข้ามาแล้ว กว่าจะพบแพ็กเกจอันตราย แพ็กเกจนั้นอาจติดตั้งไปและอยู่ใน artifact ที่ส่งออกแล้ว Dependency Firewall ย้ายจุดตรวจมาไว้ก่อนการติดตั้ง โดยให้ตั้งนโยบายได้ 4 เกณฑ์
- สถานะมัลแวร์ ตามฐานข้อมูล malware advisory ของ GitLab
- ระดับความรุนแรงของช่องโหว่ (critical, high, medium, low) และจำนวนที่ยอมรับได้ ตั้งเป็นศูนย์ได้
- ไลเซนส์ ที่อนุญาตหรือห้าม และวิธีจัดการแพ็กเกจที่ระบุไลเซนส์ไม่ได้
- อายุขั้นต่ำของแพ็กเกจ เพื่อไม่ให้เวอร์ชันที่เพิ่งเผยแพร่ไม่กี่นาทีเข้าสู่ build ก่อนมีใครตรวจ
การเริ่มใช้แนะนำให้เปิดโหมด warn ก่อน ระบบจะบันทึกสิ่งที่นโยบายจับได้ลง audit event แดชบอร์ด และสรุปใน CI แต่ปล่อยให้ build ทำต่อ เมื่อมั่นใจแล้วค่อยเปลี่ยนเป็นโหมด block ซึ่งหยุดไปป์ไลน์พร้อมเหตุผล หากจำเป็นต้องใช้แพ็กเกจที่ถูกบล็อกจริง ผู้ใช้หรือโทเคนที่กำหนดไว้ข้ามนโยบายได้โดยมีบันทึกทุกครั้ง
นโยบายเก็บเป็นโค้ดใน security policy project แก้ไขผ่าน merge request ตั้งครั้งเดียวที่กลุ่มระดับบนแล้วทุกโปรเจกต์รับสืบทอด ทีมที่ต้องการกติกาเข้มกว่าตั้งเพิ่มเฉพาะกลุ่มหรือโปรเจกต์ได้ และเมื่อกฎซ้อนกันจะใช้ข้อที่เข้มที่สุด นอกจากนี้ยังบังคับที่ระดับรีจิสทรีได้ เพื่อให้ทุกการดึงแพ็กเกจถูกตรวจ ไม่ใช่เฉพาะการดึงจากไปป์ไลน์
ตรวจก่อนเพิ่ม dependency และมีหลักฐานให้ผู้ตรวจสอบ
นักพัฒนาหรือเอเจนต์ที่ทำงานแทนสามารถเช็กผ่าน GitLab CLI ได้ก่อนว่าแพ็กเกจที่จะเพิ่มผ่านนโยบายหรือไม่ รองรับ npm, pip, Poetry, Maven, Gradle และ Bundler ทำให้ไม่ต้องรอให้ไปป์ไลน์ล้มแล้วค่อยรู้
ฝั่งทีมความปลอดภัยมีแดชบอร์ดรวมสิ่งที่ Dependency Firewall อนุญาต เตือน และบล็อก ทุกครั้งที่เตือน บล็อก หรือมีการข้ามนโยบาย ระบบเขียน audit event ระบุกฎที่ตรง นโยบายต้นทาง และแพ็กเกจที่เกี่ยวข้อง ซึ่ง GitLab ระบุว่าเป็นบันทึกที่แก้ไขไม่ได้ สำหรับใช้ตอบผู้ตรวจสอบ
Dependency Firewall ใช้ได้กับ GitLab Artifact Central และรีจิสทรีภายนอกจาก JFrog Artifactory และ Sonatype Nexus Repository โดยไม่ต้องตั้งเครื่องมือแยกข้าง GitLab
Artifact Central และ Secrets Manager ปิดช่องที่เหลือของ build
GitLab Artifact Central คือรีจิสทรีระดับองค์กรที่มาแทน package และ container registry แยกรายโปรเจกต์ ผู้ดูแลตั้งนโยบายเก็บรักษา โควตา และสิทธิ์ได้ครั้งเดียว ทุก repository ปิดไว้ก่อนจนกว่าจะได้รับบทบาท ซึ่งมี 4 แบบคือ Admin, Manager, Contributor และ Viewer
repository มี 3 แบบ ได้แก่ Hosted สำหรับแพ็กเกจที่องค์กรสร้างเอง Remote ที่เป็นพร็อกซีไปยัง Docker Hub หรือ Maven Central และ Virtual ที่รวมสองแบบไว้ใน URL เดียวและแคชแพ็กเกจจากภายนอกหลังดึงครั้งแรก แพ็กเกจที่เผยแพร่จาก CI จะมีข้อมูลไปป์ไลน์ branch commit และผู้สั่งงานติดมาด้วย และใช้ CI_JOB_TOKEN เป็นตัวตนทั้งคนและเอเจนต์
ช่วง beta รองรับ Maven, npm, Docker และ OCI ส่วน PyPI และ NuGet จะตามมาเมื่อ GA เปิดให้ใช้ฟรีบน GitLab.com และมีแผนขยายไป Self-Managed ภายในเดือนนี้ GitLab อ้างผลช่วงแรกว่าต้นทุนรวมต่ำกว่าเครื่องมืออื่นราว 50% ส่วน GitLab Secrets Manager ซึ่งจะ GA ภายในเดือนนี้ ผูก secret ที่ใช้ตอน build เข้ากับ job ที่ต้องใช้ และเพิกถอนได้ในคลิกเดียวเมื่อรั่ว
ประกาศอื่นในงาน GitLab Transcend
| ประกาศ | สถานะ | สาระสำคัญ |
|---|---|---|
Goal-driven flows (/goal) |
GA เดือนนี้ | สั่งเป้าหมายแล้วให้เอเจนต์พางานผ่านรีวิว ทดสอบ สแกน และขออนุมัติ |
| MCP Server | GA เดือนนี้ | ให้เครื่องมือ AI ภายนอกเข้าถึง GitLab ภายใต้นโยบายเดียวกัน |
| โมเดล open-weight ที่ GitLab โฮสต์ | GA | GLM 5.3, Kimi K3 และ MiniMax 3 บางคู่การใช้งานเรียกโมเดลได้มากกว่าโมเดลระดับ frontier สูงสุด 8 เท่าต่อเครดิต |
| GitLab Orbit | GA เดือนหน้า | context graph ของวงจรพัฒนา ช่วง beta มีผู้ใช้กว่า 3,500 องค์กร |
| Credit and usage controls | GA | ตั้งเพดานงบ AI ระดับ subscription กลุ่ม หรือผู้ใช้ แจ้งเตือนที่ 50%, 80%, 100% และหยุดเมื่อถึงเพดาน |
| Duo Agent Platform Impact Analytics | early access | วัดต้นทุนและผลของ AI แยกตามทีม งาน และโมเดล |
GitLab ยังระบุว่าโมเดล Claude Mythos 5 และ 5.1 ของ Anthropic จะขับเคลื่อน security flows ใหม่สำหรับค้นหาและแก้ช่องโหว่ โดยมีกำหนด GA เดือนหน้า
ทำไม Dependency Firewall จึงสำคัญ
ซอฟต์แวร์ส่วนใหญ่ที่องค์กรส่งขึ้นระบบจริงประกอบจากแพ็กเกจโอเพนซอร์ส base image และไลบรารีจากภายนอก GitLab ชี้ว่าความเสี่ยงสูงขึ้นเมื่อเอเจนต์เขียนโค้ดเพิ่ม dependency เองโดยไม่มีคนรีวิว และยกตัวอย่างว่าในเดือนมิถุนายน 2026 นักวิจัยของบริษัทพบแพ็กเกจ PyPI อันตราย 5 รายการ โดย 4 รายการตั้งชื่อเลียนแบบ Flask, Requests และ NumPy ซึ่งรันโค้ดตอนติดตั้งเพื่อขโมย credential ของ CI/CD
เมื่อแพ็กเกจแบบนี้เข้า build ได้ โค้ดของมันจะรันด้วยสิทธิ์เดียวกับไปป์ไลน์และเข้าถึงทุกระบบที่ไปป์ไลน์แตะได้ การบล็อกตั้งแต่ก่อนติดตั้งจึงช่วยลดงานไล่ตามลบและ build ใหม่ ส่วนเกณฑ์อายุขั้นต่ำช่วยให้มีช่วงเวลาตรวจสอบเวอร์ชันใหม่ก่อนที่มันจะถูกดึงเข้า build สำหรับการคุมสิทธิ์ของเอเจนต์ AI ฝั่งเครื่องนักพัฒนา อ่านเพิ่มได้ที่ข่าว Microsoft เปิดใช้ MXC คอนเทนเนอร์จำกัดสิทธิ์เอเจนต์ AI
ผลต่อองค์กรไทย
- องค์กรที่ใช้ GitLab แผน Premium หรือ Ultimate ทั้งบน GitLab.com และ Self-Managed ขอ early access ของ Dependency Firewall ได้แล้ว ควรเริ่มที่โปรเจกต์ที่ใช้แพ็กเกจจาก npm และ PyPI มากที่สุด
- เริ่มใช้ Dependency Firewall จากโหมด warn และนโยบายพื้นฐาน เช่น บล็อกแพ็กเกจที่ถูกระบุว่าเป็นมัลแวร์ และตั้งอายุขั้นต่ำของแพ็กเกจ แล้วดูผลจากแดชบอร์ดสักระยะก่อนเปลี่ยนเป็น block จะได้ไม่กระทบรอบส่งงาน
- ใช้ audit event เป็นหลักฐานการควบคุม องค์กรที่ต้องผ่านการตรวจด้านความปลอดภัยหรือการจัดการความเสี่ยงของผู้ให้บริการ เก็บบันทึกการบล็อกและการข้ามนโยบายเป็นหลักฐานได้
- ทบทวน secret ในไปป์ไลน์ โดยเฉพาะ credential ที่เอเจนต์หรือสคริปต์ build เข้าถึงได้ เพราะเป้าหมายของแพ็กเกจปลอมที่ GitLab ยกตัวอย่างคือ credential ของ CI/CD
- ตั้งเพดานงบ AI ก่อนขยายการใช้เอเจนต์ ใช้ credit and usage controls กำหนดเพดานรายกลุ่มหรือรายผู้ใช้ และทดสอบโมเดล open-weight กับงานที่ไม่ต้องใช้โมเดลระดับสูงสุด ติดตามข่าวเครื่องมือ DevOps เพิ่มเติมได้ที่หมวดซอฟต์แวร์
คำถามที่พบบ่อย
GitLab Dependency Firewall คืออะไร?
Dependency Firewall คือฟีเจอร์ของ GitLab ที่ตรวจแพ็กเกจโอเพนซอร์สก่อนติดตั้งเข้า build ตามนโยบายที่องค์กรกำหนด ได้แก่ สถานะมัลแวร์ ระดับช่องโหว่ ไลเซนส์ และอายุของแพ็กเกจ แล้วเตือนหรือบล็อกงาน CI ทันที ต่างจากการสแกนแบบ SCA ที่ตรวจหลังแพ็กเกจถูกดึงเข้ามาแล้ว
ใครใช้ Dependency Firewall ได้บ้าง?
GitLab ระบุว่า Dependency Firewall อยู่ในสถานะ early access ตั้งแต่ 6 ตุลาคม 2026 สำหรับลูกค้า GitLab.com และ GitLab Self-Managed ที่ใช้แผน Premium หรือ Ultimate ผู้สนใจต้องขอสิทธิ์ใช้งานล่วงหน้ากับ GitLab และยังไม่มีการประกาศวันใช้งานทั่วไป
Dependency Firewall ใช้กับรีจิสทรีเดิมขององค์กรได้หรือไม่?
ได้ GitLab ระบุว่า Dependency Firewall ทำงานกับ GitLab Artifact Central และรีจิสทรีภายนอกอย่าง JFrog Artifactory และ Sonatype Nexus Repository โดยไม่ต้องตั้งเครื่องมือแยก การตรวจในไปป์ไลน์ใช้คำสั่งของ glab CLI รองรับ npm, pip, Poetry, Maven, Gradle และ Bundler
GitLab Artifact Central ต่างจาก package registry เดิมอย่างไร?
registry เดิมของ GitLab ตั้งค่าแยกรายโปรเจกต์ ส่วน Artifact Central เป็นรีจิสทรีระดับองค์กรที่ตั้งนโยบายเก็บรักษา โควตา และสิทธิ์ได้ครั้งเดียว มี repository 3 แบบคือ Hosted, Remote และ Virtual และแนบข้อมูลไปป์ไลน์ commit และผู้สั่ง build ให้ทุกแพ็กเกจที่เผยแพร่จาก CI
แหล่งอ้างอิง
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- GitLab2Anthropic10
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ