Astral กำลังสร้างเครื่องมือที่นักพัฒนาหลายล้านคนทั่วโลกพึ่งพาอยู่ (Ruff, uv, ty) และล่าสุดได้เปิดเผยแนวทางปฏิบัติด้านความปลอดภัยของตนเอง โดยมีจุดเริ่มต้นจากเหตุโจมตีซัพพลายเชนของ Trivy และ LiteLLM กลุ่มผู้อ่านเป้าหมายมี 3 กลุ่ม: ผู้ใช้, เมนเทนเนอร์โอเพนซอร์สรายอื่น, และนักพัฒนาระบบ CI/CD
1. ความปลอดภัยของ CI/CD
ค่าเริ่มต้นด้านความปลอดภัยของ GitHub Actions นั้นเปราะบาง และเหตุการณ์ถูกเจาะระบบของ Ultralytics·tj-actions·Nx ต่างก็มีต้นตอมาจากทริกเกอร์ที่เสี่ยงอย่าง pull_request_target เป็นต้น แนวทางรับมือของ Astral มีดังนี้:
ห้ามใช้ทริกเกอร์เสี่ยงทั้งหมด
Astral สั่งห้ามการใช้ทริกเกอร์อย่าง pull_request_target และ workflow_run ทั่วทั้งองค์กร เพราะแทบเป็นไปไม่ได้เลยที่จะใช้งานอย่างปลอดภัย หลายโปรเจ็กต์มักคิดว่าจำเป็นต้องใช้ทริกเกอร์เหล่านี้ แต่ในความเป็นจริง ส่วนใหญ่ใช้ทริกเกอร์ pull_request ที่สิทธิ์ต่ำกว่าหรือใช้เพียง workflow log แบบธรรมดาก็เพียงพอแล้ว
ตรึงแฮชคอมมิตของแอ็กชัน (Hash Pinning)
แทนที่จะอ้างอิงแท็กหรือบรांच์ที่เปลี่ยนแปลงได้ Astral จะตรึงไว้กับ commit SHA เฉพาะ และตรวจสอบไขว้ว่า commit นั้นตรงกับสถานะรีลีสจริงหรือไม่ เพื่อป้องกัน “คอมมิตปลอม” ใช้ทั้ง zizmor และนโยบายของ GitHub ร่วมกัน และครอบคลุมถึง nested action ที่ถูกเรียกทางอ้อมทั้งหมดด้วย
หลักการสิทธิ์เท่าที่จำเป็น
ตั้งค่าสิทธิ์เริ่มต้นระดับองค์กรเป็นแบบอ่านอย่างเดียว และทุก workflow เริ่มจาก permissions: {} ก่อน จากนั้นค่อยเพิ่มสิทธิ์เท่าที่จำเป็นในระดับ job เท่านั้น ส่วน Secret ก็แยกตามสภาพแวดล้อมการ deploy แทนการวางไว้ระดับองค์กรหรือรีโพซิทอรี เพื่อไม่ให้ job ทดสอบเข้าถึง Secret สำหรับรีลีสได้
2. ความปลอดภัยของรีโพซิทอรีและองค์กร
Astral ลดจำนวนผู้ดูแลและบัญชีที่มีสิทธิ์สูงให้เหลือน้อยที่สุด โดยสมาชิกส่วนใหญ่ในองค์กรจะมีเพียงสิทธิ์อ่านและเขียนในรีโพซิทอรีที่จำเป็นเท่านั้น 2FA ก็เข้มกว่าค่าเริ่มต้นของ GitHub ที่ยอมรับได้ทุกวิธี โดยกำหนดให้ใช้ตั้งแต่ TOTP ขึ้นไป และมีแผนจะเข้มงวดยิ่งขึ้นในอนาคตด้วยการอนุญาตเฉพาะ WebAuthn·passkey
สาขา main ถูกป้องกันด้วยกฎห้าม force push และบังคับให้ใช้ pull request ส่วนแท็กรีลีสก็ถูกป้องกันให้สร้างได้เฉพาะหลัง deploy สำเร็จแล้วเท่านั้น ที่สำคัญ Astral บังคับใช้กฎเหล่านี้ในระดับองค์กรเพื่อไม่ให้แม้แต่ผู้ดูแลรีโพซิทอรีสามารถข้ามได้
3. ระบบอัตโนมัติ (ใช้ GitHub App)
งานที่ทำอย่างปลอดภัยใน GitHub Actions ไม่ได้ เช่น การคอมเมนต์ใน PR จากบุคคลภายนอก Astral จะแยกออกไปให้ astral-sh-bot GitHub App ทำแทน อย่างไรก็ตาม Astral ก็ย้ำว่า GitHub App ไม่ได้ปลอดจากช่องโหว่เสมอไป และถ้าจำเป็นต้องรันโค้ดที่ไม่น่าเชื่อถือ ก็ต้องใช้ทริกเกอร์ pull_request เท่านั้น
4. ความปลอดภัยของรีลีส
สำหรับ PyPI·crates.io·NPM นั้น Astral ใช้ Trusted Publishing ซึ่งช่วย deploy ได้โดยไม่ต้องมี long-lived credential ส่วนไบนารีและ Docker image ก็แนบ attestation ที่อิง Sigstore เพื่อสร้างความเชื่อมโยงเชิงเข้ารหัสระหว่างอาร์ติแฟกต์ของรีลีสกับ workflow
Astral ใช้ฟีเจอร์ immutable releases ของ GitHub เพื่อป้องกันการแก้ไขบิลด์ที่เผยแพร่แล้วภายหลัง และห้ามใช้ cache ระหว่างการบิลด์รีลีสเพื่อปิดช่องทางโจมตีแบบ cache poisoning
ตัวกระบวนการรีลีสเองก็มีการป้องกันสองชั้นเช่นกัน: การเปิดใช้งาน environment สำหรับรีลีสต้องได้รับการอนุมัติด้วยมือจากสมาชิกที่มีสิทธิ์อีกอย่างน้อย 1 คนภายในองค์กร หมายความว่า หากจะปล่อยรีลีสที่เป็นอันตราย ผู้โจมตีต้องยึดบัญชี 2 บัญชีที่มี 2FA แข็งแรงพร้อมกัน
5. ความปลอดภัยของดีเพนเดนซี
Astral ใช้ Dependabot·Renovate เพื่อจัดการการอัปเดตดีเพนเดนซีและการแจ้งเตือนช่องโหว่ที่รู้จักอยู่แล้ว แต่ก็ใช้ร่วมกับนโยบาย “cooldown” ที่จะไม่อัปเดตทันทีหลังมีรีลีสใหม่ เพื่อลดผลกระทบจากดีเพนเดนซีที่อาจถูกเจาะระบบเพียงชั่วคราว โดยฟีเจอร์นี้มีอยู่ใน uv อยู่แล้ว
Astral ยังรักษาความเชื่อมโยงทางสังคมกับโปรเจ็กต์และ working group ที่เกี่ยวข้อง เช่น Python Packaging Authority (PyPA) และ Python Security Response Team เพื่อแบ่งปันข้อมูลกัน เช่น กรณีที่ปัญหาซึ่งถูกรายงานใน pip อาจส่งผลต่อ uv ด้วย การเพิ่มดีเพนเดนซีใหม่จะทำอย่างระมัดระวัง หลีกเลี่ยงดีเพนเดนซีที่มี binary blob และปิดฟังก์ชันที่ไม่จำเป็น
นอกจากนี้ Astral ยังสนับสนุนความยั่งยืนของโปรเจ็กต์ที่ตัวเองพึ่งพา ด้วยการช่วยสนับสนุนทางการเงินผ่าน OSS Fund
สรุปข้อแนะนำสำคัญ
Astral เน้น 4 หลักการสำคัญดังนี้: ต้องตระหนักถึงข้อจำกัดของ CI/CD และหากมีงานที่ทำให้ปลอดภัยไม่ได้ ก็ควรตัดทิ้งอย่างเด็ดขาดหรือแยกไปทำผ่าน GitHub App, ควรลดการใช้ long-lived credential ให้มากที่สุดและแยกขอบเขตให้แคบที่สุด, ควรเสริมความแข็งแรงให้กระบวนการรีลีสด้วย environment สำหรับ deploy, การอนุมัติ, และแท็กที่เปลี่ยนแปลงไม่ได้, และต้องติดตามสุขภาพของ dependency tree ทั้งหมดอย่างต่อเนื่อง
นัยสำคัญ
หากมองจากมุมของผู้ที่มีส่วนร่วมอย่างลึกซึ้งกับ PyPI และความปลอดภัยของซัพพลายเชน บทความนี้ไม่ใช่แค่คู่มือความปลอดภัยทั่วไป แต่เป็นกรณีศึกษาภาคปฏิบัติของคำถามว่า จะออกแบบโครงสร้างความเชื่อถือของระบบนิเวศโอเพนซอร์สทั้งหมดอย่างไร โดยเฉพาะ Trusted Publishing, นโยบาย cooldown และกระบวนการรีลีสแบบอนุมัติสองชั้น เป็นแนวทางที่โปรเจ็กต์โอเพนซอร์สขนาดใหญ่ควรนำไปอ้างอิง
ต้นฉบับ: Astral Blog, 2026.04.08
ยังไม่มีความคิดเห็น