6 GitHub Security Settings ที่ maintainer ควรเปิดก่อน merge ครั้งถัดไป

AI ช่วยเขียนโค้ดได้เร็วขึ้นครับ

แต่ AI ไม่ได้เปิด secret scanning ให้เรา ไม่ได้สร้าง SECURITY.md ให้ถูกช่องทาง และไม่ได้บังคับว่า main ต้องผ่าน review ก่อน merge

นี่คือช่องว่างที่หลายทีมมองข้าม

GitHub Security Lab จึงอัปเดตบทความแนะนำ 6 จุดพื้นฐานที่ maintainer เปิดได้ในเวลาประมาณ 10 ถึง 15 นาที พร้อม guided flow ชื่อ Protect Your Project

บทความต้นทางพูดชัดว่า หกจุดนี้ไม่ได้ทำให้โครงการแฮกไม่ได้ แต่ช่วยปิดประตูง่ายที่ผู้โจมตีใช้ซ้ำในวงกว้าง

ผมมองว่านี่เป็นงาน 15 นาทีที่คุ้มกว่าการรอให้ incident บังคับเรามานั่งแก้ทั้งคืนครับ

1) ทำไมเรื่องนี้สำคัญขึ้นในยุค AI coding

GitGuardian ระบุใน State of Secrets Sprawl 2026 ว่า public GitHub commits ในปี 2025 มี secret ใหม่รั่วประมาณ 29 ล้านรายการ

รายงานเดียวกันพบว่า Claude Code co-authored commits มีอัตรา secret leak ราว 2 เท่าของ baseline ใน public GitHub commits

ต้องอ่านตัวเลขนี้อย่างระวังครับ

มันเป็น vendor research และ correlation signal ไม่ใช่หลักฐานว่า AI เป็นสาเหตุเดียว แต่บอกเราได้ว่าเมื่อ code velocity เพิ่มขึ้น ความผิดพลาดเรื่อง credential ก็ไม่ได้หายไปเอง

ตัวอย่างที่เจอบ่อย:

• AI เขียนตัวอย่าง .env แล้วมี key จริงติดมาด้วย
• developer วาง token ลงไฟล์ config เพื่อให้ทดสอบผ่านก่อน
• dependency ใหม่เข้ามาพร้อมช่องโหว่ที่ทีมไม่เห็นใน diff
• คนรีบ push ตรงเข้า main เพราะแก้แค่ “บรรทัดเดียว”

ปัญหาไม่ได้อยู่ที่ AI อย่างเดียวครับ

ปัญหาคือ workflow ของเรายังเปิดทางให้ความผิดพลาดเล็ก ๆ กลายเป็น incident ใหญ่

2) หกจุดที่ GitHub แนะนำ

ก่อนเริ่ม มีข้อจำกัดสำคัญที่ต้องรู้ครับ ตัวเลือกของ public และ private repository อาจไม่เหมือนกัน และ availability ของแต่ละ control ยังขึ้นกับ GitHub plan, organization policy และ language support ด้วย ถ้าหน้า Security ของ repo ไม่แสดงตัวเลือกตามรายการนี้ ให้ตรวจ documentation และ plan ของ repository นั้นก่อน อย่าเพิ่งสรุปว่าตั้งค่าผิด

1. เพิ่ม SECURITY.md

ไฟล์นี้บอกผู้พบช่องโหว่ว่าควรรายงานที่ไหน อะไรอยู่ในขอบเขต และทีมคาดหวังข้อมูลแบบใด

ถ้าไม่มีช่องทางชัด คนที่หวังดีอาจเปิด public issue ซึ่งทำให้รายละเอียดช่องโหว่กลายเป็นข้อมูลสาธารณะก่อนทีมพร้อมแก้

ขั้นต่ำที่ควรมี:

• ช่องทางติดต่อด้าน security
• เวอร์ชันหรือระบบที่ยังรับรายงาน
• ข้อมูลที่ผู้รายงานควรแนบ
• เวลาตอบรับโดยประมาณตามกำลังจริงของทีม

อย่าเขียน SLA ใหญ่เกินทีมครับ ถ้าไม่มีคนเฝ้า 24 ชั่วโมง ก็ไม่ควรทำเหมือนมี

2. เปิด private vulnerability reporting

SECURITY.md บอกทาง ส่วน private vulnerability reporting ให้ห้องคุยแบบ confidential

เมื่อเปิดแล้ว researcher สามารถส่ง private advisory ให้ทีม triage และแก้ไขนอก public issue ก่อนเปิดเผยตามเวลาที่เหมาะสม

สองข้อนี้ควรทำคู่กัน:

• policy บอกว่ารายงานอย่างไร
• private reporting ให้พื้นที่รายงานจริง

3. เปิด secret scanning พร้อม push protection

สองคำนี้เกี่ยวกันแต่ไม่เหมือนกันครับ

• Secret scanning ตรวจหา credential ที่หลุดเข้า repository
• Push protection พยายามบล็อก secret pattern ที่ระบบรู้จักก่อนมันเข้า Git history

ทำไมต้องบล็อกก่อน?

เพราะลบไฟล์ใน commit ถัดไปไม่ได้แปลว่า secret หายจากประวัติ Git และถ้า key ออกนอกเครื่องแล้ว สิ่งแรกที่ต้องทำคือ rotate หรือ revoke ไม่ใช่แค่ลบบรรทัด

Tips:

ใช้ fake key ที่จงใจสร้างเพื่อทดสอบ policy อย่าใช้ credential จริงเป็นตัวลอง

4. เปิด Dependabot และ dependency review

โครงการไม่ได้มีแค่โค้ดที่ทีมเขียนเองครับ

มันมี package, library, GitHub Action และ dependency จำนวนมากที่เปลี่ยนตลอดเวลา

Dependabot alerts ช่วยแจ้งเมื่อ dependency ที่ใช้มี known vulnerability ส่วน security updates ช่วยเปิด pull request สำหรับเวอร์ชันที่แก้ไขเมื่อทำได้

Dependency review ช่วยให้ทีมเห็นใน pull request ว่ากำลังเพิ่มหรือเปลี่ยน package อะไร และมี advisory ที่ควรรู้หรือไม่

เป้าหมายไม่ใช่เปิด bot แล้ว merge ทุก PR อัตโนมัติ แต่คือทำให้ความเสี่ยงของ dependency เข้ามาอยู่ใน review flow

5. เปิด code scanning ด้วย CodeQL

Code scanning ตรวจ pattern ที่นำไปสู่ช่องโหว่ เช่น SQL injection, command injection หรือ unsafe deserialization

GitHub แนะนำ CodeQL default setup เพราะระบบเลือก query pack ให้ตามภาษาและรันใน pull request ได้โดยไม่ต้องเริ่มจาก workflow ซับซ้อน

จุดสำคัญคือ alert ต้องมี owner

ถ้าเปิด scan แล้วไม่มีใครดู triage หรือไม่มีเกณฑ์ว่าอะไรบล็อก merge หน้า Security ก็จะกลายเป็นที่เก็บคำเตือนอีกแห่งหนึ่ง

6. ป้องกัน default branch

อย่างน้อยควรบังคับ:

• เปลี่ยนแปลงผ่าน pull request
• มี approval ก่อน merge
• status checks สำคัญต้องผ่าน
• จำกัดการ bypass ให้เหลือน้อยที่สุด

GitHub แนะนำ minimum one approval สำหรับ main

ในทีมเล็กมากที่มี developer คนเดียว อาจใช้ independent review จาก code owner, external maintainer หรือ review checklist ที่บังคับผ่าน pull request แทนการ push ตรง แต่ไม่ควรสร้างกฎปลอมที่ทุกคนกดผ่านเองโดยไม่มีการตรวจจริง

branch protection หรือ ruleset ที่ดีทำให้การตั้งค่าอื่นมีแรงขึ้น เพราะ Dependabot, CodeQL และ test checks สามารถมีผลต่อการ merge แทนการนอนอยู่ในแท็บที่ไม่มีคนเปิด

3) เปิดแล้ว อย่าเพิ่งถือว่าเสร็จ

คำว่า enabled เป็นแค่สถานะของ setting ครับ ไม่ใช่หลักฐานว่า workflow ทำงาน

ตัวอย่าง:

• มี SECURITY.md แต่ contact ใช้งานไม่ได้
• เปิด private reporting แต่ไม่มีคนรับผิดชอบแจ้งเตือน
• เปิด push protection แต่ bypass ได้ง่ายและไม่มี review
• เปิด Dependabot แต่ PR ค้างจนไม่มีใครกล้าอัปเดต
• เปิด CodeQL แต่ทุก alert ถูก ignore
• เปิด branch protection แต่ admin bypass ได้ตลอด

ดังนั้นทุก control ควรมีสามอย่าง:

1. Owner: ใครดูแล
2. Trigger: เมื่อไรต้องตอบสนอง
3. Proof: เรารู้ได้อย่างไรว่ามันทำงานจริง

Operator Kit: Repo Security 15-Minute Checklist

ใช้เช็กลิสต์นี้กับ repository สำคัญหนึ่งแห่งก่อนครับ

นาที 0 ถึง 3: ช่องทางรับรายงาน

• [ ] สร้างหรือทบทวน .github/SECURITY.md
• [ ] ระบุช่องทางติดต่อที่ใช้งานได้จริง
• [ ] ระบุขอบเขตและข้อมูลที่ต้องแนบ
• [ ] เปิด private vulnerability reporting
• Owner: maintainer หรือ security contact
• Proof: เปิดหน้า Security policy และทดสอบว่า private reporting route ปรากฏ

นาที 3 ถึง 6: Secret

• [ ] เปิด secret scanning
• [ ] เปิด push protection
• [ ] กำหนดว่าการ bypass ต้องมีเหตุผลและใคร review
• [ ] เตรียมขั้น rotate และ revoke เมื่อพบ secret จริง
• Owner: repo admin หรือ platform owner
• Proof: ใช้ test pattern ที่ปลอดภัยหรือหน้าสถานะของ GitHub เพื่อยืนยันว่าการป้องกันทำงาน

นาที 6 ถึง 9: Dependency

• [ ] เปิด Dependabot alerts
• [ ] เปิด Dependabot security updates เมื่อเหมาะกับ repo
• [ ] เปิด dependency review ใน pull request
• [ ] กำหนดคน triage และรอบเวลาตรวจ alert
• Owner: dependency owner หรือทีมพัฒนา
• Proof: มี alert queue ที่มี owner และ pull request แสดง dependency changes

นาที 9 ถึง 12: Code scanning

• [ ] เปิด CodeQL default setup
• [ ] ตรวจว่าภาษาใน repo รองรับและ workflow รันจริง
• [ ] กำหนด severity ที่ต้องแก้ก่อน merge
• [ ] กำหนดวิธี dismiss alert พร้อมเหตุผล
• Owner: tech lead หรือ code owner
• Proof: มี code scanning check บน pull request หรือผล scan ล่าสุดที่ระบุ commit ชัดเจน

นาที 12 ถึง 15: Default branch

• [ ] เปิด branch protection หรือ repository ruleset
• [ ] Require pull request before merging
• [ ] Require อย่างน้อยหนึ่ง approval เมื่อโครงทีมรองรับ
• [ ] Require status checks ที่สำคัญ
• [ ] ปิด direct push และลด bypass
• Owner: repo admin
• Proof: ทดสอบด้วย disposable branch หรือ pull request ว่า merge ตรงไม่ได้เมื่อ check หรือ review ยังไม่ครบ

บันทึกผลหนึ่งแถวต่อ repo

คัดลอก template นี้ไปใช้ได้เลย:

• Repository:
• Visibility / Plan:
• Security owner:
• Six controls checked at:
• Missing controls:
• Bypass exceptions:
• Next review date:
• Evidence links or screenshots:

อย่าใส่ secret, vulnerability detail หรือข้อมูลลูกค้าลงใน evidence ครับ เก็บเฉพาะ settings state, check name, timestamp และ owner ที่จำเป็น

4) ข้อจำกัดที่ต้องรู้

Availability เป็นข้อจำกัดแรกที่ต้องเช็กตามหมายเหตุข้างรายการทั้งหก และถึงเปิด control ได้แล้ว เครื่องมือเหล่านี้ก็ยังไม่แทน process ทั้งหมด:

• SECURITY.md ไม่แทน incident response
• push protection ไม่แทน secret rotation
• Dependabot ไม่รับประกันว่า update จะไม่ทำระบบพัง
• CodeQL ไม่จับทุก bug class
• branch protection ไม่ช่วยถ้าทุกคน bypass ได้

หกจุดนี้คือ baseline ที่ดี ไม่ใช่เส้นชัย

5) เริ่มอย่างไรวันนี้

ถ้ามีหลาย repository อย่าเปิดพร้อมกันทั้งองค์กรจนไม่มีใครดูผลครับ

เริ่มจาก repo ที่มีผลกระทบสูงหนึ่งแห่ง:

1. เลือก production repo หรือ package ที่ผู้ใช้อื่นพึ่งพา
2. ทำ Repo Security 15-Minute Checklist
3. บันทึก missing control และ owner
4. ทดสอบ control ที่เสี่ยงต่อ false confidence
5. นัดทบทวนอีกครั้งใน 30 วัน

เมื่อเส้นทางแรกทำงาน ค่อยนำ template เดิมไปใช้กับ repo ถัดไป

สรุป

GitHub Security Lab ไม่ได้เสนอเครื่องมือใหม่หวือหวาครับ

แต่เสนอสิ่งที่หลายทีมยังไม่ได้ทำครบ: ช่องทางรายงานที่เป็นส่วนตัว, การกัน secret ก่อนเข้า history, dependency และ code scan ที่เข้า review flow และ default branch ที่ห้ามเปลี่ยนแบบไร้การตรวจ

ในความเห็นของผม ประเด็นสำคัญไม่ใช่ว่าเปิดครบหกปุ่มหรือยัง

แต่คือแต่ละปุ่มมี owner, trigger และ proof หรือยัง

ก่อนให้ AI ช่วยทีมเขียนโค้ดเร็วขึ้น ลองให้ repository พร้อมรับความเร็วนั้นก่อนครับ เริ่มจาก 15 นาทีใน repo สำคัญที่สุดหนึ่งแห่งก็พอ