เจาะลึกการตรวจสอบ CI กว่า 2,864 รายการ พบระบบสีเขียวจอมปลอม
บทเรียนจากการตรวจสอบระบบ CI กว่า 2,864 รายการที่เผยให้เห็นว่าสถานะสีเขียวไม่ได้หมายความว่าระบบทำงานจริงเสมอไป
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ตรวจสอบระบบ CI ทั้งหมด 2,864 รายการจาก 9 คลังโค้ด
- กฎ Vale ตรวจจับ Em Dash ล้มเหลวโดยสิ้นเชิงเนื่องจากปัญหา Regular Expression
- ระบบรายงานผลถูกตั้งค่าให้ไม่ส่งสัญญาณเตือนแม้พบข้อผิดพลาด
- พบเครื่องมือรักษาความปลอดภัย Semgrep ไม่ได้เชื่อมต่อกับเวิร์กโฟลว์ใดๆ
คำถามสั้นๆ บน Hacker News เกี่ยวกับระบบตรวจสอบความปลอดภัยที่รันในทุก Pull Request กลายเป็นจุดเริ่มต้นให้ผู้พัฒนาท่านหนึ่งตัดสินใจนับจำนวนการตรวจสอบ CI ทั้งหมดที่เคยรันมาในชีวิตการทำงาน ซึ่งได้ตัวเลขรวมถึง 2,864 รายการ ครอบคลุมคลังโค้ด (Repositories) ทั้งหมด 9 แห่ง แม้คำตอบแรกจะดูเรียบง่าย แต่สิ่งที่ค้นพบระหว่างทางกลับน่าตกใจกว่ามาก
ตัวเลขความล้มเหลวไม่ได้กระจายตัวอย่างสม่ำเสมอ แต่จะเกิดขึ้นในรูปแบบกลุ่มก้อนช่วง 3 ถึง 4 วัน สลับกับความเงียบสงบยาวนานหลายเดือน เช่น ในช่วงปลายเดือนเมษายนเมื่อมีการดึงการตรวจสอบเหล่านี้เข้าไปใช้ในรีใช้เบิลเวิร์กโฟลว์ร่วมกัน เกิดความล้มเหลวของ cost-gate ถึง 18 ครั้งภายใน 4 วัน ระหว่างที่กำลังแก้ไขบั๊กเกี่ยวกับการดึงข้อมูลและการตรวจสอบข้อมูลรับรอง
คลังโค้ดที่มีอัตราความล้มเหลวสูงสุดในองค์กรคือคลังโค้ดที่อยู่ในขั้นตอนการตั้งค่าเท่านั้น โดยไม่มีสถานะปกติให้นำมาเฉลี่ย โดยจุดสูงสุดอยู่ที่ 57% ซึ่งเป็นเทมเพลตที่ถูกนำไปใช้โคลนต่อสำหรับโปรเจกต์อื่นๆ บริบทเหล่านี้ไม่ได้แสดงอยู่บนตัวเลขดิบ แต่มันอยู่ในความทรงจำของผู้พัฒนาเอง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เหตุการณ์นี้ชี้ให้เห็นถึงปัญหาคลาสสิกในกระบวนการ DevOps ที่เรียกว่า 'Silent Failures' หรือความล้มเหลวที่ไม่มีการแจ้งเตือน ซึ่งระบบอัตโนมัติอาจรายงานสถานะว่าปกติ (Green) เสมอ แม้ว่าตัวระบบตรวจสอบจะทำงานผิดพลาด ตั้งค่าไม่ถูกต้อง หรือไม่ได้รันเลยก็ตาม การตรวจสอบโค้ดแบบเจาะลึก (Audit) เป็นระยะจึงเป็นสิ่งสำคัญที่จะช่วยเปิดโปงข้อบกพร่องที่ซ่อนอยู่หลังหน้าจอแดชบอร์ดที่เขียวขจี
จุดเปลี่ยนที่ทำให้ต้องขุดคุ้ยลึกกว่าเดิมเริ่มต้นจากกฎ Vale ในไพป์ไลน์เนื้อหาที่ชื่อว่า EmDashes ซึ่งตั้งค่าระดับไว้ที่ error เพื่อป้องกันไม่ให้เครื่องหมาย Em Dash เล็ดลอดขึ้นไปบนเว็บไซต์ เนื่องจากระบบร่างบทความผ่าน Claude ที่มักใส่เครื่องหมายนี้เข้ามาเสมอ แต่ในบทความล่าสุดที่มีเครื่องหมาย Em Dash ถึง 15 ตัว ระบบ Vale กลับรายงานว่าพบข้อผิดพลาดเป็นศูนย์
"Here is why. Vale's existence check compiles a tokens list into a regex with word boundaries wrapped around it."
ผู้พัฒนา
สาเหตุมาจาก Regular Expression ที่ใช้ขอบเขตคำ b ซึ่งไม่สามารถจับคู่กับเครื่องหมายวรรคตอนได้ ทำให้กฎนี้รันผ่านและแสดงผลเป็นสีเขียวมาตลอดตั้งแต่วันแรกที่เขียนขึ้นมา โดยไม่มีความแตกต่างใดๆ ระหว่างกฎที่ทำงานได้จริงกับกฎที่เสีย นอกจากนี้ เมื่อแก้เรกซ์ได้แล้ว ปรากฏว่าคำสั่ง vale --no-exit ถูกตั้งค่าให้บังคับออกด้วยสถานะ 0 เสมอ และคำสั่ง grep ก็ค้นหาฟิลด์ severity ที่รูปแบบรายงานของ Vale ไม่มีอยู่จริง ทำให้การตรวจสอบนี้ไม่เคยบล็อกการสร้างใดๆ เลยในประวัติศาสตร์
ความผิดพลาดซ้อนกันสามชั้นยังเกิดขึ้นเมื่อ Vale ไปตรวจสอบเครื่องหมายในบล็อกโค้ด เนื่องจากไม่ได้กำหนดค่าแมปส่วนขยาย .mdx ทำให้ระบบปฏิบัติกับไฟล์เหมือนเป็นข้อความธรรมดา นอกจากนี้ยังพบว่า Semgrep เครื่องมือรักษาความปลอดภัยที่ถูกกำหนดในนโยบาย แท้จริงแล้วไม่ได้ถูกเชื่อมต่อเข้ากับเวิร์กโฟลว์ใดเลยในทุกคลังโค้ด รวมถึง cost-gate ที่ล้มเหลวมานานหลายเดือนเพราะไม่ได้ระบุโทเค็น GitHub App
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น