GitHub Agentic Autofix เปิดใช้ทั่วไปแล้ว: เปลี่ยน security alert ให้เป็นแพตช์ที่ตรวจทานได้

security alert บอกว่ามีบางอย่างต้องได้รับความสนใจ แต่ไม่ได้บอกเสมอไปว่าจะแก้แอปอย่างไรโดยไม่ทำให้ส่วนอื่นพัง สำหรับมือใหม่ที่ดูแลแอปขนาดเล็ก ช่องว่างตรงนี้อาจทำให้หยุดแก้ก่อนเริ่ม ส่วนผู้พัฒนาก็อาจปล่อยให้คำเตือนเดิม ๆ สะสมเป็น backlog มากขึ้นเรื่อย ๆ

GitHub ประกาศเปิดใช้ Agentic Autofix สำหรับ alert จาก code scanning โดยทั่วไปเมื่อวันที่ 15 ตุลาคม 2026 มอบหมาย alert ให้ Copilot แล้ว agent จะตรวจสอบโค้ด เสนอการเปลี่ยนแปลง พยายามตรวจสอบความถูกต้อง และเปิด draft pull request จุดเปลี่ยนที่เป็นประโยชน์คือจุดเริ่มต้น: มีแพตช์เสนอมาให้ตรวจ แทนที่จะเจอเพียงหน้าต่างแก้ไขว่าง ๆ ประกาศ GA ของ GitHub วันที่ 15 ตุลาคม 2026

คู่มือนี้พาคุณจาก repository ที่เข้าเกณฑ์ไปจนถึงการแก้ไขครั้งแรกที่ผ่านการตรวจทาน แล้วอธิบายการจัดการ alert ที่เกี่ยวข้อง scanner แบบกำหนดเอง ค่าใช้จ่าย และกรณีที่พยายามแล้วไม่สำเร็จ ข้อเสนอแนะของเรา: มอง agent เป็นผู้เขียนแพตช์ ไม่ใช่ผู้อนุมัติการปล่อยงาน คุณยังต้องเข้าใจการเปลี่ยนแปลงก่อนนำเข้าแอปของคุณ

แผนภาพเปิดเรื่องแยกแพตช์ที่ agent เสนอออกจากการตัดสินใจ merge ของคน

เริ่มจาก alert เดียว ไม่ใช่ทั้ง backlog

ความสำเร็จครั้งแรกควรเป็นการเปลี่ยนแปลงเล็ก ๆ ที่คุณอธิบาย ทดสอบ และตรวจทานได้ pull request คือข้อเสนอให้นำการเปลี่ยนแปลงไปรวมกับสาขาหลักของโครงการ ส่วนสถานะ draft ระบุว่าข้อเสนอนั้นยังไม่พร้อม CodeQL คือ engine วิเคราะห์โค้ดของ GitHub ซึ่งสร้าง alert เกี่ยวกับโค้ดที่อาจมีช่องโหว่

ใช้ลำดับนี้ก่อนลองเก็บกวาดครั้งใหญ่:

1. เลือก repository ที่คุณดูแล ยืนยันว่าเข้าเกณฑ์ด้านล่าง การอนุมัติการเข้าถึง และผู้รับผิดชอบค่าใช้จ่าย ก่อนเริ่มเซสชัน agent
2. ยืนยันว่า CodeQL วิเคราะห์ได้ก่อน หาก repository มีการวิเคราะห์ที่ทำงานอยู่แล้ว ให้คงการตั้งค่านั้นและตรวจรอบล่าสุดที่สำเร็จ หากจะตั้งค่าใหม่ ให้ไปที่ Settings > Advanced Security > Code Security ของ repository หา CodeQL analysis เลือก Set up > Default ตรวจการตั้งค่า แล้วเลือก Enable CodeQL รอให้วิเคราะห์สำเร็จ วิธีตั้งค่าของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026
3. เปิดใช้ Agentic Autofix ผ่านนโยบายที่เกี่ยวข้อง สวิตช์ใน repository ไม่สามารถข้ามการห้ามขององค์กรหรือ enterprise ได้
4. เลือก alert เดียวที่มีอยู่บน default branch เปิด Security and quality > Code scanning เปิด alert แล้วเลือก Assign to Copilot ในส่วน Assignees ขั้นตอนจัดการ alert ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026
5. ตรวจ draft pull request และ session log อ่าน diff รันทดสอบที่เกี่ยวข้อง แล้วสแกนซ้ำด้วยการตั้งค่าที่รายงานปัญหา
6. merge หลังจากคนตรวจและ checks ที่จำเป็นผ่านแล้วเท่านั้น จากนั้นตรวจสถานะ alert หลังวิเคราะห์ default branch ที่อัปเดตแล้ว

หากต้องการดูส่วนติดต่อ ให้ดู ตัวอย่างสาธิต UI อย่างเป็นทางการในประกาศ GA ของ GitHub ใช้เป็นข้อมูลประกอบคู่กับ repository ของคุณ อย่าคิดว่าแผนภาพจะตรงกับทุกหน้าจอปัจจุบัน

repository สาธารณะหรือส่วนตัวของคุณใช้ได้หรือไม่?

ประกาศเปิดตัวเน้นลูกค้าระดับ enterprise แต่เอกสารการเข้าถึงปัจจุบันของ GitHub ครอบคลุมกว่านั้น: รวม repository สาธารณะบน GitHub.com และ repository ที่องค์กรเป็นเจ้าของซึ่งมี GitHub Code Security หรือ GitHub Advanced Security ไม่จำเป็นต้องมีไลเซนส์ Copilot เอกสารสิทธิ์เข้าถึงของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

การเข้าถึง repository สาธารณะ ไม่ได้แปลว่าเซสชัน agent ฟรี ให้แยกตรวจสิทธิ์ repository ออกจากค่าใช้จ่ายตามการใช้งาน ก่อนเชิญผู้ร่วมงานมาลองฟีเจอร์นี้

เปิดสิทธิ์จากนโยบายระดับสูงสุดลงมา

สำหรับองค์กรที่เป็นของ enterprise เจ้าของ enterprise หรือ security manager ต้องอนุญาตฟีเจอร์นี้ก่อนที่ Policies > Advanced Security > Agentic Autofix แต่การอนุญาตนั้นอย่างเดียวไม่ได้เปิดใช้ จากนั้นเจ้าขององค์กรหรือ security manager ต้องเปิดฟีเจอร์ใน Settings > Advanced Security > Global settings repository ที่เข้าเกณฑ์จะรับการเปิดใช้นี้ต่อมา ผู้ดูแล repository เลือกปิดหรือเปิดใหม่ได้เฉพาะเมื่อสอดคล้องกับนโยบายระดับสูงกว่า องค์กรเดี่ยวข้ามขั้น enterprise ได้ ส่วน repository ส่วนตัวสาธารณะที่เข้าเกณฑ์จะใช้การตั้งค่าของ repository โดยตรง ผู้ใช้รุ่นพรีวิวต้องเปิดใช้อีกครั้ง ขั้นตอนนโยบายของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

แผนภาพการเข้าถึง: การอนุญาต การเปิดใช้ และการเลือก repository เป็นการตัดสินใจคนละขั้น แหล่งข้อมูล: เอกสารการเข้าถึงของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ก่อนเปิดใช้ทั่วทั้งองค์กร ให้ระบุ repository ที่ควรคงสถานะไม่เข้าร่วม และตกลงกันว่าใครตรวจแพตช์ที่สร้างขึ้น โครงการนำร่องที่สมเหตุสมผลจับคู่ผู้ดูแล repository หนึ่งคนกับผู้ตรวจความปลอดภัยหนึ่งคน บันทึก alert พฤติกรรมที่คาดหวัง ผู้ตรวจ และผู้รับผิดชอบงบประมาณ เพื่อไม่ให้ draft ที่ไม่มีคนดูแลกลายเป็นความรับผิดชอบที่ไม่มีใครเข้าใจ

ตรวจให้แน่ใจว่า CodeQL วิเคราะห์โค้ดจริง

การตั้งค่าแบบ Default ต้องใช้ GitHub Actions และ repository ต้องเป็นสาธารณะหรือมี Code Security ตรวจภาษาและชุด query ที่เลือก ไม่ใช่ดูแค่สวิตช์เปิดใช้ หาก advanced setup เดิมทำงานอยู่ อย่าเปลี่ยนอย่างไม่ระวัง: default setup จะเขียนทับการตั้งค่าที่มีอยู่ ปิด workflow เดิม และบล็อกการอัปโหลดผ่าน CodeQL analysis API เอกสาร default setup ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ตรวจผลวิเคราะห์ล่าสุดก่อนเลือก alert ถามว่าบริการที่ได้รับผลกระทบถูกรวมไว้หรือไม่ และ build หรือ dependency ทำให้วิเคราะห์ล้มเหลวหรือไม่ สถานะ enabled ไม่ใช่หลักฐานว่าไฟล์ที่เกี่ยวข้องได้รับการวิเคราะห์สำเร็จ แก้ปัญหาการตั้งค่าก่อนขอให้ agent ซ่อม finding จาก baseline ที่ไม่น่าเชื่อถือ

ความพยายามแรกควรเลือกปัญหาที่มีขอบเขตชัดและมีพฤติกรรมที่คาดหวังแน่นอน เช่น การค้นฐานข้อมูลหรือเส้นทางแสดงผลเฉพาะ อย่าเริ่มจากการรื้อระบบ authorization ทั้งชุด หากไม่มี alert ที่เกี่ยวข้อง อย่าจงใจเพิ่มช่องโหว่ลงใน repository ที่ใช้งานจริงเพื่อสร้างตัวอย่าง

เกิดอะไรขึ้นระหว่างมอบหมาย alert กับเปิด draft pull request?

GitHub อธิบายว่า agent จะสำรวจไฟล์ที่เกี่ยวข้อง สร้างแพตช์ รัน CodeQL ซ้ำ และปรับแก้ก่อนเปิด draft pull request ข้อเสนอจะมีสรุปการซ่อมและรายละเอียดการตรวจสอบ นี่คือเวิร์กโฟลว์ Agentic Autofix ไม่ใช่การ merge เข้า default branch โดยอัตโนมัติ เวิร์กโฟลว์ GA ของ GitHub วันที่ 15 ตุลาคม 2026

หลังมอบหมาย alert ให้ตรวจตามลำดับนี้:

1. อ่าน finding ต้นฉบับอีกครั้ง ระบุอินพุตที่ไม่น่าเชื่อถือ การทำงานที่ละเอียดอ่อน และการป้องกันที่คาดหวัง จดรหัส alert และการตั้งค่าที่ใช้รายงาน
2. อ่านทุกไฟล์ที่เปลี่ยน มองหาการแก้ที่ไม่เกี่ยวข้อง การลบ checks การปิด tests การเพิ่ม dependency และพฤติกรรมข้อผิดพลาดที่เปลี่ยนไป
3. ตรวจหลักฐานของเซสชัน แยกการสแกนที่เสร็จแล้วออกจากคำสั่งที่ล้มเหลวหรือข้อความว่าตรวจสอบไม่ได้ คุณขอให้ agent ทำซ้ำผ่านเซสชันหรือ mention Copilot ในคอมเมนต์ pull request ได้ คำแนะนำเซสชันของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026
4. รันทดสอบแอปและ scanner ที่เกี่ยวข้อง ใช้คำสั่งทดสอบที่โครงการบันทึกไว้ในสภาพแวดล้อมพัฒนา ตรวจ setup scripts และการเปลี่ยน workflow ก่อนรันโค้ดที่ไม่คุ้นเคย
5. ขอการอนุมัติจากคน คงสถานะ draft ไว้หากพฤติกรรม ความครอบคลุมการสแกน หรือผู้รับผิดชอบยังไม่ชัด เปลี่ยนเป็น ready ก็ต่อเมื่อหลักฐานตรวจทานได้

วงจรตรวจทาน: draft จาก agent เป็นสิ่งส่งมอบระหว่างทาง ไม่ใช่หลักฐานว่าแอปปลอดภัย แหล่งข้อมูล: ประกาศและเอกสารแก้ alert ของ GitHub

pull request ของ GitHub แสดง diff ใน Files changed และผลอัตโนมัติใน Checks ให้ใช้ทั้งคู่: สรุปสีเขียวอธิบายไม่ได้ว่าเงื่อนไข permission ที่เปลี่ยนยังบังคับใช้กติกาของแอปคุณหรือไม่ แนวคิด pull request ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

เวิร์กโฟลว์ 1: ซ่อมคำค้นฐานข้อมูลเล็ก ๆ โดยไม่เปลี่ยนความหมาย

ลองนึกถึงบริการ Python สมมติที่ค้นหารายการสินค้าคงคลังด้วยป้ายชื่อ implementation เดิมแทรกป้ายชื่อที่รับเข้ามาใน SQL ด้วย string formatting และ code-scanning alert แจ้งเตือนการประกอบ query วิธีแก้ที่มีประโยชน์คือแยกคำสั่ง SQL ออกจากค่า แทนการพยายามลบเครื่องหมายวรรคตอนทีละตัว

ตัวอย่าง implementation ที่ปลอดภัยขึ้นด้วยส่วนติดต่อ sqlite3 ของ Python:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

placeholder จะ bind ค่าแยกจากข้อความ SQL ตาม คำแนะนำทางการของ Python เรื่องการ bind ค่าด้วย placeholder ตรวจสอบเมื่อ 18 ตุลาคม 2026 นี่เป็นรูปแบบการแก้สมมติ ไม่ใช่ผลลัพธ์จาก Agentic Autofix หรือรายงานการทดลองจริง query, schema และกติกาการอนุญาตในบริการจริงยังต้องตรวจทานแยกกัน

สำหรับตัวอย่างนี้ ขอ tests ที่ครอบคลุมป้ายชื่อทั่วไป ป้ายที่มี apostrophe เช่น Maker's Kit และรายการที่ไม่พบ ตรวจว่าฟังก์ชันยังคงพฤติกรรมคืนแถวหรือ None ตามที่คาดไว้ จากนั้นทดสอบกติกาการเข้าถึงเดิมของ endpoint ที่เรียกใช้ด้วย query แบบ parameterized ไม่ได้ตัดสินว่าใครมีสิทธิ์อ่านข้อมูลสินค้า

คอมเมนต์ตรวจทานที่มีประโยชน์อาจเขียนว่า: "คงพฤติกรรมการค้นหาเดิม bind ป้ายชื่อเป็นข้อมูล และเพิ่ม regression coverage สำหรับ apostrophe กับรายการที่ไม่พบ" ข้อความนี้ระบุสัญญาของโค้ด แทนการสั่ง agent แค่ว่าทำให้คำเตือนหายไป สแกนแพตช์จริงซ้ำก่อนยอมรับ

เวิร์กโฟลว์ 2: จัดกลุ่ม alert ที่เกี่ยวข้อง ไม่ใช่คำเตือนใดก็ได้

สมมติว่าบริการเว็บในตัวอย่างมี alert สามรายการที่เกี่ยวกับ helper แสดงผลเดียวกัน ตรวจร่วมกันเพื่อพิจารณาว่าควรแก้ส่วนกลางครั้งเดียวหรือไม่ GitHub อนุญาตให้เลือก alert ใน backlog ได้สูงสุด 25 รายการ จากรายการ alert หรือ security campaign การมอบหมายหนึ่งครั้งจะสร้างหนึ่งเซสชันและหนึ่ง pull request คำแนะนำการมอบหมายหลายรายการของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ขีดจำกัดนี้คือเพดานความจุ ไม่ใช่ขนาดชุดที่แนะนำ finding สามรายการที่เกี่ยวข้องและมีเจ้าของเดียวอาจตรวจง่ายกว่า 20 รายการที่ไม่เกี่ยวกัน ซึ่งครอบคลุม authentication การจัดการไฟล์ และการเข้าถึงฐานข้อมูล ก่อนมอบหมาย ให้จด endpoint ที่ได้รับผลกระทบแต่ละจุดและพฤติกรรมปกติที่ต้องคงไว้

ในเวิร์กโฟลว์ตัวอย่างนี้ ให้ตรวจ helper ส่วนกลางและทดสอบผู้เรียกใช้ทุกจุด หากแพตช์เปลี่ยน output escaping ให้ตรวจบริบท output ที่ต้องการ อย่าอนุมัติเพียงเพราะตัวอย่างเดียวดูถูกต้อง แยกงานเมื่อ finding ต่างกันต้องใช้ผู้ตรวจหรือกำหนดการปล่อยคนละชุด อย่าปล่อยให้ alert ที่ยังไม่คลี่คลายบดบังว่าแพตช์ใดมีหลักฐานรองรับแล้ว

เวิร์กโฟลว์ 3: scanner แบบกำหนดเองต้องยืนยันด้วยตัวเอง

Agentic Autofix ใช้ได้กับ backlog บน default branch เท่านั้น alert ที่ปรากฏเฉพาะใน pull request หรือ branch อื่นอยู่นอกขั้นตอนมอบหมายนี้ หาก pull request ใหม่ทำให้เกิด finding ให้แก้ที่นั่น อย่า merge โค้ดที่มีช่องโหว่เพียงเพื่อทำให้มอบหมาย alert ได้ ขอบเขตที่ GitHub ระบุ วันที่ 15 ตุลาคม 2026

ยังมีอีกข้อจำกัด: GitHub ระบุว่าการตรวจสอบของ agent ยืนยันการแก้ไขสำหรับ custom CodeQL queries, ชุด query security-extended ของ CodeQL หรือ alert จาก code scanning ของผู้ให้บริการรายอื่นไม่ได้ การตรวจสอบในตัวจะรัน code-scanning query suite ซ้ำตามความพยายามที่ดีที่สุด ข้อจำกัดการตรวจสอบของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ลองนึกถึงองค์กรสมมติที่มี query เฉพาะสำหรับบังคับใช้กฎการจัดการข้อมูลภายใน แม้ agent เสนอแพตช์ที่ดูเข้าท่า ผู้ตรวจยังต้องรันการวิเคราะห์แบบกำหนดเองและตรวจผล จดเวอร์ชัน query การตั้งค่า revision ที่วิเคราะห์ และผลลัพธ์ การรัน default suite สำเร็จใช้แทน query ที่รายงานปัญหาไม่ได้

คง scanner ที่เข้มงวดกว่าไว้ การลดความครอบคลุมเพื่อให้ได้สถานะเขียวเป็นการเปลี่ยนวิธีวัด ไม่ได้เปลี่ยนความปลอดภัยของแอป หากทำซ้ำการวิเคราะห์ที่ต้องการไม่ได้ ให้คงข้อเสนอไว้รอการตรวจสอบและระบุชื่อผู้ที่รันได้

ไม่มีไลเซนส์ Copilot ไม่ได้แปลว่าไม่มีบิล

Agentic Autofix ใช้ Code Security AI Credits และ GitHub Actions minutes เอกสารเรียกเก็บเงินของ GitHub ระบุชัดว่าใช้ AI credits แม้ใน repository สาธารณะที่ไม่ต้องมี active-committer licenses หากบัญชีที่ถูกเรียกเก็บมีสิทธิ์ได้รับ AI credits ที่รวมมา เครดิตดังกล่าวจะถูกใช้ก่อน จากนั้นจึงคิดตามการใช้งานเพิ่มเติม ส่วนบัญชีที่ไม่มีเครดิตรวมจะถูกคิดตามการใช้งานตั้งแต่แรก การเรียกเก็บ AI credits ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

สำหรับ repository ขององค์กร ค่าใช้จ่ายจะตกกับบัญชีองค์กรหรือ enterprise ที่ชำระเงิน ตรวจ allowance และงบ Code Security AI Credits ของบัญชีนั้นก่อนเปิดใช้ในวงกว้าง ประกาศยังระบุให้ตั้งค่าวิธีชำระเงิน Copilot ไว้ ซึ่งต่างจากการกำหนดให้ผู้ใช้ทุกคนถือไลเซนส์ Copilot ข้อกำหนดการเรียกเก็บเงินในประกาศเปิดตัว GitHub วันที่ 15 ตุลาคม 2026

สำหรับโครงการนำร่อง ให้บันทึกการใช้ต่อเซสชัน การใช้ Actions เวลาผู้ตรวจ และแพตช์ได้รับการยอมรับหรือไม่ อย่ารับปากราคาตายตัวต่อ alert ที่ซ่อมแล้ว: การทำเป็นชุด การวนแก้ หรือข้อเสนอที่ไม่สำเร็จก็ต้องตรวจต้นทุน เปรียบเทียบค่าซ่อมที่ยอมรับแล้วกับเวิร์กโฟลว์เดิม อย่านับจำนวน pull request ที่สร้างเป็นจำนวนงานแก้ไขที่เสร็จแล้ว

Copilot Autofix แบบดั้งเดิม ต่างออกไป: เสนอการเปลี่ยนแปลงขั้นเดียว แทนเวิร์กโฟลว์ agent ที่ตรวจสอบและเปิด draft และคำแนะนำของมันไม่ใช้ AI credits หากรองรับ ก็ยังเป็นทางเลือกเมื่อไม่ได้เปิด Agentic Autofix การเปรียบเทียบของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ตอบคำถามทั้งเจ็ดข้อนี้ก่อน merge

รายการตรวจทานของเราเน้นรักษาพฤติกรรมเดิมควบคู่กับการลบจุดอ่อนที่รายงาน:

• ต้นเหตุ: แพตช์แก้การทำงานที่ไม่ปลอดภัยจริง หรือแค่ปิดคำเตือน?
• ขอบเขต: refactor ที่ไม่เกี่ยว dependency ใหม่ และการเปลี่ยนการตั้งค่ามีเหตุผลรองรับหรือไม่?
• พฤติกรรม: อินพุตที่ถูกต้องและผิดพลาด ข้อผิดพลาด และ permission ยังทำงานถูกต้องหรือไม่?
• Tests: มี regression test ที่จับปัญหาเดิมได้หรือไม่?
• การวิเคราะห์: scanner ที่รายงานได้วิเคราะห์ revision ที่เสนอด้วยการตั้งค่าที่จำเป็นหรือไม่?
• การอนุมัติ: มีคนที่รับผิดชอบตรวจ diff และบันทึกจาก agent ที่ยังไม่คลี่คลายแล้วหรือไม่?
• หลัง merge: การวิเคราะห์ default branch ยืนยันสถานะ alert ที่คาดหวังและไม่พบปัญหาใหม่หรือไม่?

ให้ถือ "ตรวจสอบไม่ได้" เป็นงานที่ยังไม่เสร็จ ไม่ใช่การอนุมัติ GitHub ระบุว่า agent อาจรายงานว่าตรวจสอบไม่ได้ หรือสงสัยว่าเป็น false positive ใน pull request ทั้งสองอย่างใช้แทนการประเมินของ maintainer ไม่ได้ พฤติกรรม best-effort ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

ถ้าไม่เห็นปุ่มหรือผลลัพธ์ผิดพลาด ควรทำอย่างไร?

ทำไมเห็น alert แต่ assign ไม่ได้? ตรวจว่าเป็น backlog ของ default branch repository เข้าเกณฑ์หรือไม่ เปิดฟีเจอร์แล้วหรือยัง และ permission ของคุณเพียงพอหรือไม่ การมอบหมายต้องมี write access หากการตั้งค่าถูกล็อก ให้สอบถามผู้ดูแลที่เกี่ยวข้อง แทนการสลับค่าของ repository ซ้ำ ๆ ข้อกำหนดก่อน assign ของ GitHub ตรวจสอบเมื่อ 18 ตุลาคม 2026

สแกนสะอาดแปลว่าแอปปลอดภัยแล้วหรือไม่? ไม่ใช่ ผลตอบเพียงคำถามที่ครอบคลุมโดยการวิเคราะห์และการตั้งค่านั้น กฎธุรกิจ authorization พฤติกรรมขณะรัน และ finding ที่ไม่รองรับยังต้องทดสอบและตรวจทานตามความเหมาะสม

ควรลองเซสชันที่ล้มเหลวซ้ำไหม? ตรวจ log และ diff ที่เสนอก่อน ระบุว่าสิ่งที่ขาดคือการตั้งค่าการวิเคราะห์ การรัน tests บริบทของโครงการ หรือแพตช์เอง ให้ข้อมูลแก้ไขที่เฉพาะเจาะจงหรือแก้ setup ต้นเหตุก่อนลองอีกครั้ง การ assign ซ้ำโดยไม่มีข้อมูลใหม่ไม่ใช่กลยุทธ์แก้ปัญหา

ยอมรับ false positive ที่สงสัยได้หรือไม่? ตรวจ finding ด้วยตัวเองและบันทึกเหตุผล อย่าสับสนการปิด alert กับการแก้โค้ดที่มีช่องโหว่ และอย่าปล่อยให้ความมั่นใจของ agent เป็นตัวตัดสินข้อยกเว้นด้านความเสี่ยง

บทสรุป: แพตช์ที่เสนอคือจุดเริ่มต้นของการตรวจทาน

Agentic Autofix ช่วยขยับงานที่มีประโยชน์มาไว้ต้นทาง: การตรวจสอบ แพตช์ตัวเลือก และการตรวจสอบที่มีอยู่รวมมาให้ จุดได้เปรียบในทางปฏิบัติคือช่องว่างระหว่างการพบช่องโหว่กับการได้ตรวจแพตช์ที่เป็นรูปธรรมหดลง เริ่มจากขอบเขตเล็ก คง scanner ไว้ และให้หลักฐานเป็นตัวตัดสินการยอมรับ ไม่ใช่ผู้เขียนแพตช์

แหล่งข้อมูล

แหล่งข้อมูลปฐมภูมิตรวจสอบเมื่อวันที่ 18 ตุลาคม 2026

ลิงก์ในคู่มือนี้ชี้ไปยัง ประกาศ GA วันที่ 15 ตุลาคมของ GitHub, นโยบายการเข้าถึงปัจจุบัน, แนวคิดและข้อจำกัดของ Autofix, ขั้นตอนแก้ alert, การตั้งค่า CodeQL และ เอกสารการเรียกเก็บเงิน เอกสารเป็นภาพสถานะการเข้าถึง ณ วันที่ระบุ ไม่ใช่การรับประกันการตั้งค่าของทุกบัญชี เวิร์กโฟลว์สามแบบเป็นตัวอย่างอธิบาย ไม่ใช่ผลจากการทดลองจริง

พื้นที่เก็บบันทึกการตรวจทาน: เก็บลิงก์แหล่งที่มา รหัส alert ผลทดสอบ และการตัดสินใจไว้ด้วยกันใน Telli.sh ช่วยจัดระเบียบบันทึกได้ แต่ไม่ได้สแกน repository หรืออนุมัติแพตช์ สร้างบัญชี Telli.sh