<div class="key-takeaways"><ul><li>ตรวจสอบระบบ CI ทั้งหมด 2,864 รายการจาก 9 คลังโค้ด</li><li>กฎ Vale ตรวจจับ Em Dash ล้มเหลวโดยสิ้นเชิงเนื่องจากปัญหา Regular Expression</li><li>ระบบรายงานผลถูกตั้งค่าให้ไม่ส่งสัญญาณเตือนแม้พบข้อผิดพลาด</li><li>พบเครื่องมือรักษาความปลอดภัย Semgrep ไม่ได้เชื่อมต่อกับเวิร์กโฟลว์ใดๆ</li></ul></div><p>คำถามสั้นๆ บน Hacker News เกี่ยวกับระบบตรวจสอบความปลอดภัยที่รันในทุก Pull Request กลายเป็นจุดเริ่มต้นให้ผู้พัฒนาท่านหนึ่งตัดสินใจนับจำนวนการตรวจสอบ CI ทั้งหมดที่เคยรันมาในชีวิตการทำงาน ซึ่งได้ตัวเลขรวมถึง 2,864 รายการ ครอบคลุมคลังโค้ด (Repositories) ทั้งหมด 9 แห่ง แม้คำตอบแรกจะดูเรียบง่าย แต่สิ่งที่ค้นพบระหว่างทางกลับน่าตกใจกว่ามาก</p><p>ตัวเลขความล้มเหลวไม่ได้กระจายตัวอย่างสม่ำเสมอ แต่จะเกิดขึ้นในรูปแบบกลุ่มก้อนช่วง 3 ถึง 4 วัน สลับกับความเงียบสงบยาวนานหลายเดือน เช่น ในช่วงปลายเดือนเมษายนเมื่อมีการดึงการตรวจสอบเหล่านี้เข้าไปใช้ในรีใช้เบิลเวิร์กโฟลว์ร่วมกัน เกิดความล้มเหลวของ cost-gate ถึง 18 ครั้งภายใน 4 วัน ระหว่างที่กำลังแก้ไขบั๊กเกี่ยวกับการดึงข้อมูลและการตรวจสอบข้อมูลรับรอง</p><p>คลังโค้ดที่มีอัตราความล้มเหลวสูงสุดในองค์กรคือคลังโค้ดที่อยู่ในขั้นตอนการตั้งค่าเท่านั้น โดยไม่มีสถานะปกติให้นำมาเฉลี่ย โดยจุดสูงสุดอยู่ที่ 57% ซึ่งเป็นเทมเพลตที่ถูกนำไปใช้โคลนต่อสำหรับโปรเจกต์อื่นๆ บริบทเหล่านี้ไม่ได้แสดงอยู่บนตัวเลขดิบ แต่มันอยู่ในความทรงจำของผู้พัฒนาเอง</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ci_2_864_ms7ekks6_inline_1_7c98241128.jpg" alt="code audit pipeline" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><div class="ai-insight"><p>เหตุการณ์นี้ชี้ให้เห็นถึงปัญหาคลาสสิกในกระบวนการ DevOps ที่เรียกว่า 'Silent Failures' หรือความล้มเหลวที่ไม่มีการแจ้งเตือน ซึ่งระบบอัตโนมัติอาจรายงานสถานะว่าปกติ (Green) เสมอ แม้ว่าตัวระบบตรวจสอบจะทำงานผิดพลาด ตั้งค่าไม่ถูกต้อง หรือไม่ได้รันเลยก็ตาม การตรวจสอบโค้ดแบบเจาะลึก (Audit) เป็นระยะจึงเป็นสิ่งสำคัญที่จะช่วยเปิดโปงข้อบกพร่องที่ซ่อนอยู่หลังหน้าจอแดชบอร์ดที่เขียวขจี</p></div><p>จุดเปลี่ยนที่ทำให้ต้องขุดคุ้ยลึกกว่าเดิมเริ่มต้นจากกฎ Vale ในไพป์ไลน์เนื้อหาที่ชื่อว่า EmDashes ซึ่งตั้งค่าระดับไว้ที่ error เพื่อป้องกันไม่ให้เครื่องหมาย Em Dash เล็ดลอดขึ้นไปบนเว็บไซต์ เนื่องจากระบบร่างบทความผ่าน Claude ที่มักใส่เครื่องหมายนี้เข้ามาเสมอ แต่ในบทความล่าสุดที่มีเครื่องหมาย Em Dash ถึง 15 ตัว ระบบ Vale กลับรายงานว่าพบข้อผิดพลาดเป็นศูนย์</p><blockquote class="pull-quote"><p>"Here is why. Vale's existence check compiles a tokens list into a regex with word boundaries wrapped around it."</p><cite>ผู้พัฒนา</cite></blockquote><p>สาเหตุมาจาก Regular Expression ที่ใช้ขอบเขตคำ b ซึ่งไม่สามารถจับคู่กับเครื่องหมายวรรคตอนได้ ทำให้กฎนี้รันผ่านและแสดงผลเป็นสีเขียวมาตลอดตั้งแต่วันแรกที่เขียนขึ้นมา โดยไม่มีความแตกต่างใดๆ ระหว่างกฎที่ทำงานได้จริงกับกฎที่เสีย นอกจากนี้ เมื่อแก้เรกซ์ได้แล้ว ปรากฏว่าคำสั่ง vale --no-exit ถูกตั้งค่าให้บังคับออกด้วยสถานะ 0 เสมอ และคำสั่ง grep ก็ค้นหาฟิลด์ severity ที่รูปแบบรายงานของ Vale ไม่มีอยู่จริง ทำให้การตรวจสอบนี้ไม่เคยบล็อกการสร้างใดๆ เลยในประวัติศาสตร์</p><p>ความผิดพลาดซ้อนกันสามชั้นยังเกิดขึ้นเมื่อ Vale ไปตรวจสอบเครื่องหมายในบล็อกโค้ด เนื่องจากไม่ได้กำหนดค่าแมปส่วนขยาย .mdx ทำให้ระบบปฏิบัติกับไฟล์เหมือนเป็นข้อความธรรมดา นอกจากนี้ยังพบว่า Semgrep เครื่องมือรักษาความปลอดภัยที่ถูกกำหนดในนโยบาย แท้จริงแล้วไม่ได้ถูกเชื่อมต่อเข้ากับเวิร์กโฟลว์ใดเลยในทุกคลังโค้ด รวมถึง cost-gate ที่ล้มเหลวมานานหลายเดือนเพราะไม่ได้ระบุโทเค็น GitHub App</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/earnestamateur/i-audited-2864-ci-checks-several-had-never-run-and-green-never-told-me-1abb" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Audited a total of 2,864 CI checks across nine repositories</li><li>A Vale rule for em dashes completely failed due to regex word boundaries</li><li>Report settings suppressed exit codes, hiding failures from builds</li><li>Semgrep security checks were never actually wired into any workflows</li></ul></div><p>A simple one-line question on Hacker News about security checks run on every pull request prompted a developer to count every single CI check they had ever executed. The total reached 2,864 checks distributed across nine repositories. While the direct answer to the question turned out to be straightforward, what was uncovered along the way was far more surprising.</p><p>Failure rates were not spread evenly throughout the timeline. Instead, they appeared in tight three- or four-day clusters separated by months of complete silence. For instance, in late April when these checks were integrated into a shared reusable workflow, eighteen cost-gate failures occurred over four days while sorting out credential and fetch-depth bugs, followed by ten weeks of nothing.</p><p>Repositories with the highest failure rates in the entire organization were those stuck permanently in the setup phase without any steady state for baseline comparison. The worst repository sat at a 57% failure rate, serving as the template cloned by others. None of this context existed within the raw numbers alone; it lived entirely in the developer's memory.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ci_2_864_ms7ekks6_inline_1_7c98241128.jpg" alt="code audit pipeline" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><div class="ai-insight"><p>This case study highlights a classic DevOps dilemma known as 'silent failures,' where automation pipelines continuously report a healthy green status even when individual checks are misconfigured, broken, or not executing at all. Periodic deep audits remain critical for uncovering hidden flaws masked by superficial dashboard metrics.</p></div><p>The deeper investigation kicked off when a Vale rule named EmDashes in the content pipeline failed to catch fifteen em dashes present in a newly shipped post, reporting zero errors instead. The root cause lay in the regular expression wrapping word boundaries around punctuation marks that lacked adjacent word characters to anchor against.</p><blockquote class="pull-quote"><p>"Here is why. Vale's existence check compiles a tokens list into a regex with word boundaries wrapped around it."</p><cite>The Developer</cite><cite></cite></blockquote><p>Compounding the issue, the execution command utilized --no-exit to force a zero exit code regardless of findings, paired with a grep command searching for a severity field that did not exist in the output format. Consequently, the check had passed every single build it ever ran without doing any actual gating. Further inspection revealed missing .mdx file mapping causing false alerts in code blocks, an unlinked Semgrep security tool, and an unprovisioned GitHub App token causing persistent cost-gate failures.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/earnestamateur/i-audited-2864-ci-checks-several-had-never-run-and-green-never-told-me-1abb" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_ci-2-864-ms7ekks6.jpg

small_ci-2-864-ms7ekks6.jpg

thumbnail_ci-2-864-ms7ekks6.jpg

Inewgen

Inewgen

#Vale

I Audited 2,864 CI Checks and Found Silent Failures

Inewgen