GitHub Agentic Autofix Workshop: ให้ AI Agent ตรวจสอบและแก้ไขช่องโหว่ของโค้ด

• 1. บทนำ
  • GitHub Agentic Autofix ทำอะไรได้บ้าง?
  • แนวคิดแบบ Agentic ต่างจากการสร้าง Code Suggestion อย่างไร?
• 2. สถาปัตยกรรมการทำงาน
• 3. ข้อกำหนดและสิทธิ์ใช้งาน (อัปเดตหลัง GA)
  • 3.1 ผู้ดูแล Enterprise เปิดนโยบาย
  • 3.2 ผู้ดูแล Organization เปิดฟีเจอร์
  • 3.3 ผู้ดูแล Repository ตรวจสอบฟีเจอร์
• 4. เตรียมห้องปฏิบัติการ (Workshop Setup)
  • 4.1 วัตถุประสงค์การเรียนรู้
  • 4.2 สิ่งที่ต้องติดตั้ง
• 5. Workshop Part A — สร้างโปรเจกต์ Node.js ที่มี SQL Injection
  • Step 1: สร้างโปรเจกต์
  • Step 2: สร้าง app.js (โค้ดไม่ปลอดภัยสำหรับการทดลอง)
  • Step 3: รันและทดสอบเฉพาะเครื่องตนเอง
• 6. Workshop Part B — Push ไป GitHub และเปิด CodeQL
  • Step 4: สร้าง repository สำหรับทดลอง
  • Step 5: เปิด CodeQL Code Scanning
  • Step 6: อ่านและวิเคราะห์ Alert
• 7. Workshop Part C — Assign Alert ให้ GitHub Agentic Autofix
  • Step 7: มอบหมายงานให้ Copilot
  • Step 8: Checklist ตรวจสอบ Draft Pull Request
• 8. Workshop Part D — วิเคราะห์ Patch ที่ถูกต้อง
• 9. Workshop Part E — สร้าง Automated Regression Tests
• 10. Workshop Part F — รัน CI ด้วย GitHub Actions
• 11. Workshop Part G — แก้หลาย Alerts และ Code Quality Findings
  • 11.1 Code Scanning Bulk Remediation
  • 11.2 GitHub Code Quality (Public Preview)
• 12. Workshop Part H — เรียกใช้งานผ่าน GitHub REST API
• 13. กำหนด Repository Custom Instructions
• 14. Troubleshooting ที่พบบ่อย
• 15. แนวทางนำไปใช้ใน DevSecOps จริง
• 16. ตัวชี้วัดสำหรับการเรียนการสอนและการวิจัย
• 17. แบบฝึกหัดและเกณฑ์ประเมิน
  • แบบฝึกหัด 1 — วิเคราะห์ Security Alert
  • แบบฝึกหัด 2 — Agentic Autofix / Manual Fix
  • แบบฝึกหัด 3 — Regression Testing และ PR Review
  • เกณฑ์คะแนน (100 คะแนน)
• 18. สรุป
• แหล่งอ้างอิง (GitHub Official Sources)

ข่าวสำคัญ: GitHub Agentic Autofix สำหรับ Code Scanning Alerts เป็น General Availability (GA) ตั้งแต่ 15 ตุลาคม 2026 ส่วน Agentic Autofix สำหรับ GitHub Code Quality backlog ยังอยู่ใน Public Preview ตามเอกสารที่ตรวจสอบ ณ วันที่เขียนบทความ ทั้งสองส่วนมีเงื่อนไขการเปิดใช้งานต่างกัน

#1. บทนำ

การสแกนโค้ดอัตโนมัติช่วยให้ทีมพบปัญหาด้านความปลอดภัย แต่การแก้ช่องโหว่ยังต้องอาศัยเวลาในการวิเคราะห์สาเหตุ (root cause) อ่านโค้ดหลายไฟล์ พัฒนา patch เพิ่ม regression tests และเปิด Pull Request (PR) เพื่อให้ทีมพิจารณา

GitHub Agentic Autofix เพิ่มการทำงานแบบ agentic remediation เข้าไปในขั้นตอนนี้: เมื่อผู้พัฒนาเลือก Assign to Copilot จาก Code Scanning Alert ระบบจะเริ่มเซสชันของ AI Agent เพื่อสำรวจ repository สร้างการแก้ไข ตรวจสอบผลเท่าที่รองรับ และเปิด Draft Pull Request ให้ผู้พัฒนาตรวจทาน

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

#GitHub Agentic Autofix ทำอะไรได้บ้าง?

• วิเคราะห์หลายไฟล์ ไม่จำกัดการเสนอการแก้แค่บรรทัดที่เครื่องมือสแกนแจ้งเตือน
• สร้าง patch แล้วพยายามยืนยันผลด้วย CodeQL ในขอบเขตที่รองรับ
• ปรับแก้ซ้ำได้เมื่อผลตรวจสอบยังไม่เพียงพอ
• เปิด Draft PR พร้อมสรุปสิ่งที่แก้และขั้นตอน validation
• รองรับการเลือก สูงสุด 25 Code Scanning Alerts ในหนึ่ง assignment เพื่อสร้าง agent session และ PR สำหรับกลุ่ม alert ที่เลือก
• รองรับ GitHub Code Quality standard findings สูงสุด 25 findings ต่อหน้าสำหรับการแก้แบบกลุ่ม ภายใต้สถานะ Public Preview ของฟีเจอร์นั้น
• รองรับการมอบหมาย alert ผ่าน REST API โดยใช้ copilot-swe-agent[bot]

#แนวคิดแบบ Agentic ต่างจากการสร้าง Code Suggestion อย่างไร?

ไม่ควรสับสนระหว่าง Code Scanning (เน้นความปลอดภัย) กับ Code Quality (เน้นความน่าเชื่อถือและบำรุงรักษา): ใช้ผลิตภัณฑ์และนโยบายคนละส่วน แม้จะมีปุ่ม Assign to Copilot คล้ายกัน

#2. สถาปัตยกรรมการทำงาน

flowchart TD
    A[Developer pushes code to default branch] --> B[CodeQL / Code Scanning]
    B --> C[Code Scanning Alert]
    C --> D[Developer selects Assign to Copilot]
    D --> E[GitHub Agentic Autofix session]
    E --> F[Read relevant files and identify root cause]
    F --> G[Generate and refine patch]
    G --> H[Re-run supported CodeQL checks]
    H --> I{Validation satisfactory?}
    I -- No / iterate when possible --> G
    I -- Yes or best effort --> J[Draft Pull Request]
    J --> K[Human review + CI + regression tests]
    K --> L{Approve?}
    L -- Request changes --> E
    L -- Yes --> M[Merge]
    M --> N[Re-scan and verify alerts]

ข้อจำกัดสำคัญของ validation: GitHub ระบุว่า Agentic Autofix ใช้ CodeQL code-scanning query suite เพื่อพยายามยืนยันการแก้ จึง ไม่สามารถยืนยันการปิด alert ได้ครบถ้วน สำหรับ custom CodeQL queries, ชุด security-extended และ third-party scanner แม้ agent อาจเสนอ patch ให้ได้ การตรวจสอบโดยมนุษย์และการรันเครื่องมือสแกนต้นทางจึงจำเป็น

#3. ข้อกำหนดและสิทธิ์ใช้งาน (อัปเดตหลัง GA)

สำหรับ Code Scanning Agentic Autofix ให้ตรวจสอบสิ่งต่อไปนี้:

1. Repository อยู่ในประเภทที่ GitHub รองรับ เช่น public repository บน GitHub.com หรือ repository ขององค์กรที่มี GitHub Code Security / GitHub Advanced Security ตามสิทธิ์ผลิตภัณฑ์
2. ฟีเจอร์ Agentic Autofix เปิดอยู่สำหรับ repository และไม่ถูกปิดโดยนโยบายระดับองค์กรหรือ enterprise
3. ใช้ Code Scanning เพื่อสร้าง alert และเลือก alert ที่มีอยู่ใน default branch (main หรือชื่อ branch เริ่มต้นของ repository)
4. ผู้สั่งมอบหมายมีอย่างน้อย Write access ใน repository
5. มีวิธีเรียกเก็บเงิน/งบประมาณ AI Credits ที่เกี่ยวข้องตามข้อกำหนด และตรวจสอบ GitHub Actions minutes

ข้อมูลใหม่หลัง GA: ตาม GitHub Docs ปัจจุบัน ผู้ใช้ไม่จำเป็นต้องมี GitHub Copilot License รายบุคคล เพื่อใช้ Code Scanning Agentic Autofix หาก repository เข้าเกณฑ์และผู้ดูแลเปิดใช้งานอย่างถูกต้อง ดังนั้นเอกสารเก่าที่ระบุว่าต้องมี Copilot License สะท้อนเงื่อนไขของช่วง Public Preview ไม่ใช่เงื่อนไขล่าสุด

ข้อยกเว้น: ไม่รองรับ user-owned repository ภายใน enterprise ที่ใช้ Enterprise Managed Users และ alert ที่พบเฉพาะบน PR หรือ non-default branch ไม่สามารถนำไป assign ด้วยฟีเจอร์นี้ได้

#3.1 ผู้ดูแล Enterprise เปิดนโยบาย

สำหรับ enterprise ที่ต้องควบคุมสิทธิ์การใช้งาน:

1. ไปที่ Enterprise → Policies → Advanced Security
2. ที่ Agentic Autofix เลือก All organizations: Allowed
3. แจ้งให้ผู้ดูแล organization เปิดฟีเจอร์ต่อ เพราะ Allowed ไม่เท่ากับ Enabled

#3.2 ผู้ดูแล Organization เปิดฟีเจอร์

1. ไปที่ Organization → Settings
2. เลือก Security and quality → Advanced Security → Global settings
3. ในส่วน Code scanning ตั้งค่า Agentic Autofix = On
4. ตรวจสอบ repositories ที่ต้อง opt out ตามนโยบายองค์กร

#3.3 ผู้ดูแล Repository ตรวจสอบฟีเจอร์

1. ไปที่ Repository → Settings
2. เลือก Security and quality → Advanced Security
3. ในส่วน Code Security ตรวจสอบสวิตช์ Agentic Autofix = On

สำหรับ public repository ของบัญชีส่วนบุคคลที่เข้าเกณฑ์ สามารถจัดการสวิตช์นี้ได้ที่ระดับ repository ตามเอกสารล่าสุด

สำคัญ: หากเคยใช้ฟีเจอร์ช่วง Public Preview ภายในองค์กร GitHub ระบุว่าอาจต้อง เปิดใช้งานใหม่ หลังการเปลี่ยนเป็น GA

#4. เตรียมห้องปฏิบัติการ (Workshop Setup)

#4.1 วัตถุประสงค์การเรียนรู้

หลังจบ Workshop ผู้เรียนควรสามารถ

1. เปิดการสแกน CodeQL สำหรับ repository ที่สร้างขึ้น
2. วิเคราะห์ SQL Injection จาก input ที่ผู้ใช้ควบคุมได้
3. มอบหมาย Code Scanning Alert ให้ GitHub Agentic Autofix เมื่อมีสิทธิ์ใช้งาน
4. ตรวจสอบ Draft PR เทียบกับแนวทางแก้ด้วย Parameterized Query
5. เขียนและรัน Regression Tests สำหรับกรณีที่เคยทำให้เกิดช่องโหว่
6. วิเคราะห์ต้นทุน ข้อจำกัด และความเสี่ยงก่อน Merge

#4.2 สิ่งที่ต้องติดตั้ง

• Git และ GitHub Account
• Node.js รุ่น LTS (แนะนำ Node.js 22 หรือรุ่น LTS ที่เข้ากันได้) และ npm
• GitHub CLI (gh) เฉพาะส่วน API ขั้นสูง
• GitHub repository สำหรับการทดลองเท่านั้น
• สิทธิ์ใช้งาน CodeQL / Agentic Autofix ตามข้อ 3 สำหรับส่วนที่ทำบน GitHub

ความปลอดภัยของ Lab: ตัวอย่างต่อไปนี้ จงใจสร้าง SQL Injection เพื่อใช้เรียนรู้ ห้ามนำไป deploy บนระบบที่เปิดรับผู้ใช้จริง ห้ามใช้ฐานข้อมูลจริง ข้อมูลสำคัญ หรือ secrets และให้รัน HTTP server บน 127.0.0.1 เท่านั้น หากจำเป็นต้องเผยแพร่ repository ให้แสดงชัดว่าเป็นโค้ดสำหรับการศึกษา

#5. Workshop Part A — สร้างโปรเจกต์ Node.js ที่มี SQL Injection

#Step 1: สร้างโปรเจกต์

mkdir github-agentic-autofix-lab
cd github-agentic-autofix-lab
npm init -y
npm install express sqlite3
npm pkg set 'scripts.start=node app.js'
npm pkg set 'scripts.test=node --test'

โครงสร้างเริ่มต้น:

github-agentic-autofix-lab/
├── app.js
├── package.json
├── package-lock.json
└── .gitignore

สร้าง .gitignore:

node_modules/
.env
*.db
coverage/

#Step 2: สร้าง app.js (โค้ดไม่ปลอดภัยสำหรับการทดลอง)

// VULNERABLE LAB ONLY — Do not deploy to the public internet.
const express = require('express');
const sqlite3 = require('sqlite3').verbose();

const app = express();
const db = new sqlite3.Database(':memory:');

db.serialize(() => {
  db.run('CREATE TABLE users (id INTEGER PRIMARY KEY, email TEXT)');
  db.run('INSERT INTO users (email) VALUES (?)', ['demo@example.com']);
});

app.get('/users', (req, res) => {
  const email = String(req.query.email ?? '');

  // VULNERABILITY: user input is concatenated into the SQL statement.
  const sql = "SELECT id, email FROM users WHERE email = '" + email + "'";

  db.all(sql, (error, rows) => {
    if (error) return res.status(500).json({ error: 'Query failed' });
    return res.json(rows);
  });
});

if (require.main === module) {
  app.listen(3000, '127.0.0.1', () => {
    console.log('Lab: http://127.0.0.1:3000');
  });
}

module.exports = { app };

ทำไมโค้ดนี้ไม่ปลอดภัย? เพราะข้อความ email จาก HTTP request ถูกนำมาต่อเป็นส่วนหนึ่งของ SQL โดยตรง ทำให้ข้อมูลอินพุตอาจถูกตีความเป็นคำสั่ง SQL แทนที่จะเป็นแค่ค่าข้อมูล

#Step 3: รันและทดสอบเฉพาะเครื่องตนเอง

npm start

เปิด Terminal อีกหน้าต่างและทดสอบคำขอปกติ:

curl 'http://127.0.0.1:3000/users?email=demo%40example.com'

ผลที่คาดหวัง:

[{"id":1,"email":"demo@example.com"}]

ลองอินพุตทดสอบที่ออกแบบให้สังเกตพฤติกรรมของ SQL Injection เฉพาะ localhost:

curl --get \
  --data-urlencode "email=' OR '1'='1" \
  'http://127.0.0.1:3000/users'

หาก API คืนข้อมูลผู้ใช้ทั้งที่ไม่ได้ระบุ email ที่ถูกต้อง แสดงถึงพฤติกรรมที่ควรได้รับการแก้ไข (ใน lab นี้มีข้อมูลเพียงหนึ่งแถว) หยุดเซิร์ฟเวอร์ด้วย Ctrl+C เมื่อทดลองเสร็จ

#6. Workshop Part B — Push ไป GitHub และเปิด CodeQL

#Step 4: สร้าง repository สำหรับทดลอง

สร้าง repository เปล่าชื่อ github-agentic-autofix-lab ผ่าน GitHub หรือ GitHub CLI โดยพิจารณาเลือก Private เมื่อสิทธิ์ Code Security ขององค์กรรองรับ

git init
git add .gitignore package.json package-lock.json app.js
git commit -m "lab: add intentionally vulnerable sqlite query"
git branch -M main
git remote add origin https://github.com/OWNER/github-agentic-autofix-lab.git
git push -u origin main

เปลี่ยน OWNER เป็นชื่อบัญชีหรือ organization จริง และใช้ repository ที่ได้รับอนุญาตเท่านั้น

#Step 5: เปิด CodeQL Code Scanning

1. เปิด repository บน GitHub
2. เข้า Settings → Advanced Security (ภายใต้ส่วน Security and quality)
3. ในหัวข้อ CodeQL analysis / Code scanning เลือก Set up → Default ตาม UI ที่ปรากฏ
4. ตรวจสอบให้มีการวิเคราะห์ภาษา JavaScript/TypeScript แล้วเปิดการสแกน
5. รอผลการทำงานจาก GitHub Actions / CodeQL
6. ไปที่ Security and quality → Code scanning เพื่อดูรายการ alert

การตรวจจับจะขึ้นอยู่กับ CodeQL รุ่นปัจจุบัน การตั้งค่า query suite และรูปแบบการเขียนโปรแกรม ไม่รับประกันว่า SQL Injection ในโค้ดตัวอย่างจะปรากฏเป็น alert ทุกสภาพแวดล้อม หากไม่มี alert ให้ใช้ alert อื่นที่ตรวจพบจริงจาก repository ที่ผู้เรียนมีสิทธิ์ หรือใช้ขั้นตอนแก้ด้วยตนเองใน Part D เพื่อฝึก review และ regression testing

#Step 6: อ่านและวิเคราะห์ Alert

บันทึกรายละเอียดลงใบงาน:

#7. Workshop Part C — Assign Alert ให้ GitHub Agentic Autofix

#Step 7: มอบหมายงานให้ Copilot

1. ไปที่ Security and quality → Code scanning
2. เลือก Open Alert ที่อยู่ใน default branch
3. เปิดรายละเอียดของ alert และอ่าน Data Flow / Code Locations
4. ในส่วน Assignees กด Assign to Copilot
5. รอให้ระบบสร้าง agent session และ Draft Pull Request
6. เปิด PR แล้วดูแท็บ Files changed, รายละเอียดการแก้ และผล validation
7. หากต้องให้ agent ปรับแก้ ให้ส่งความคิดเห็นใน PR หรือจาก agent session ตามเมนูที่มี

หากปุ่ม Assign to Copilot ไม่แสดง: ตรวจว่าผู้ดูแลเปิด Agentic Autofix แล้วหรือยัง, repository เข้าเกณฑ์หรือไม่, เป็น alert บน default branch หรือไม่, สิทธิ์ผู้ใช้เพียงพอหรือไม่ และตั้งค่า budget/billing เรียบร้อยหรือไม่ หากมีแต่ Generate fix อาจเป็นประสบการณ์ Copilot Autofix แบบเดิม ไม่ใช่ Agentic Autofix

กรณีไม่สามารถใช้บริการจริง: ผู้เรียนยังทำ Lab ส่วน CodeQL, root-cause analysis และการสร้าง patch ด้วยตนเองได้ ไม่จำเป็นต้องมีปุ่ม Agentic Autofix จึงจะฝึกทักษะด้าน Secure Coding ได้

#Step 8: Checklist ตรวจสอบ Draft Pull Request

• [ ] การแก้ไขจัดการ root cause ของช่องโหว่ ไม่ใช่แค่ปิดบัง alert
• [ ] ไม่มีการต่อ SQL string จากข้อมูลที่ไม่เชื่อถือ
• [ ] API ยังส่งคืนผลลัพธ์ปกติได้ถูกต้อง
• [ ] มีการเพิ่ม test สำหรับข้อมูลที่เคยทำให้เกิดปัญหา
• [ ] ไม่เปลี่ยนแปลงฟังก์ชันอื่นโดยไม่จำเป็น
• [ ] ไม่มีการเพิ่ม package, การเข้าถึง secrets หรือ permission ที่ไม่เกี่ยวข้อง
• [ ] มีหลักฐาน validation จริง ไม่ใช่อาศัยคำกล่าวของ agent เพียงอย่างเดียว
• [ ] CI ผ่าน และมีผู้พัฒนาตรวจทานก่อน Merge

#8. Workshop Part D — วิเคราะห์ Patch ที่ถูกต้อง

ตัวอย่างที่เหมาะสมคือการใช้ Parameterized Query โดยแทนที่โค้ดที่นำ input ไปต่อกับข้อความ SQL ดังนี้:

app.get('/users', (req, res) => {
  const email = String(req.query.email ?? '');

  const sql = 'SELECT id, email FROM users WHERE email = ?';

  db.all(sql, [email], (error, rows) => {
    if (error) return res.status(500).json({ error: 'Query failed' });
    return res.json(rows);
  });
});

เครื่องหมาย ? เป็น placeholder และค่า email ถูกส่งแยกเป็น parameter ทำให้ฐานข้อมูลตีความค่าที่รับจากผู้ใช้เป็นข้อมูล ไม่ใช่โครงสร้างของ SQL

ตัวอย่างนี้เป็น reference patch สำหรับใช้ตรวจคุณภาพ PR ไม่ได้คาดหมายว่า agent จะเขียนโค้ดเหมือนกันทุกตัวอักษร

#9. Workshop Part E — สร้าง Automated Regression Tests

หลังแก้ไขโค้ด ให้สร้างโฟลเดอร์ test และไฟล์ test/api.test.js ด้วย Node.js Test Runner (รองรับใน Node.js รุ่นที่ระบุ)

mkdir -p test

// test/api.test.js
const { before, after, test } = require('node:test');
const assert = require('node:assert/strict');
const { app } = require('../app');

let server;
let baseUrl;

before(async () => {
  await new Promise((resolve, reject) => {
    server = app.listen(0, '127.0.0.1', resolve);
    server.once('error', reject);
  });
  baseUrl = `http://127.0.0.1:${server.address().port}`;
});

after(async () => {
  if (server) {
    await new Promise((resolve, reject) => {
      server.close((error) => error ? reject(error) : resolve());
    });
  }
});

test('returns a user for the correct email', async () => {
  const url = `${baseUrl}/users?email=${encodeURIComponent('demo@example.com')}`;
  const response = await fetch(url);
  assert.equal(response.status, 200);
  const rows = await response.json();
  assert.equal(rows.length, 1);
  assert.equal(rows[0].email, 'demo@example.com');
});

test('does not treat input as SQL syntax', async () => {
  const probe = "' OR '1'='1";
  const url = `${baseUrl}/users?email=${encodeURIComponent(probe)}`;
  const response = await fetch(url);
  assert.equal(response.status, 200);
  const rows = await response.json();
  assert.deepEqual(rows, []);
});

รันคำสั่ง:

npm test

การแปลผล:

• หากใช้ app.js เวอร์ชันก่อนแก้ไข การทดสอบข้อ does not treat input as SQL syntax ควรล้มเหลว (Red)
• เมื่อใช้ Parameterized Query การทดสอบควรผ่านทั้งสองกรณี (Green)
• ผู้เรียนควรทดสอบอีกครั้งหลังปรับแก้เพิ่มเติม (Regression)

การสาธิต Red → Green ช่วยให้เห็นว่า test จับพฤติกรรมที่ไม่ปลอดภัยได้จริง ไม่ใช่เพียงแค่ยืนยันว่าโค้ดรันได้

#10. Workshop Part F — รัน CI ด้วย GitHub Actions

สร้างไฟล์ .github/workflows/ci.yml:

name: Node.js CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run regression tests
        run: npm test

ในระบบใช้งานจริง ควรพิจารณา pin GitHub Actions ด้วย commit SHA และจัดการ dependency scanning เพิ่มเติม การระบุเวอร์ชันด้วย tag ในตัวอย่างนี้เพื่อความอ่านง่ายของห้องปฏิบัติการ

รัน CI ที่ PR และตรวจสอบผลของงาน test ก่อนอนุมัติการแก้ไข

#11. Workshop Part G — แก้หลาย Alerts และ Code Quality Findings

#11.1 Code Scanning Bulk Remediation

GitHub รองรับการเลือก ได้สูงสุด 25 alerts ต่อหนึ่ง assignment จากรายการ backlog หรือ security campaign เมื่อเป็น alert บน default branch ที่เข้าเกณฑ์

1. ไปที่รายการ Code Scanning Alerts / Security Campaign
2. เลือก alert ที่เกี่ยวข้องกัน (สูงสุด 25 รายการ)
3. คลิก Assign to Copilot
4. ตรวจสอบหนึ่ง agent session และหนึ่ง PR ของกลุ่มที่เลือก
5. ประเมินทุก alert และทดสอบผลกระทบระหว่างกัน

ควรจัดกลุ่มตาม root cause หรือ subsystem แทนการรวมทุกปัญหาแบบสุ่ม เพราะ PR ขนาดใหญ่จะตรวจสอบได้ยาก

#11.2 GitHub Code Quality (Public Preview)

สำหรับองค์กรที่เปิด GitHub Code Quality อยู่แล้ว:

1. ไปที่ Security and quality → Code quality → Standard findings
2. เลือกกฎ/หมวดที่ควรแก้ เช่น category:reliability severity:error
3. เลือก findings สูงสุด 25 รายการต่อหน้า
4. คลิก Assign to Copilot
5. ตรวจสอบ Draft PR และการเปลี่ยนแปลง Reliability/Maintainability score หลัง merge

สถานะ ณ 16 ต.ค. 2026: การแก้ Code Scanning Alerts เป็น GA แล้ว แต่การแก้ Code Quality backlog findings ด้วย Agentic Autofix ยังเป็น Public Preview ตามเอกสารของ GitHub ไม่ควรอ้างว่าทั้งคู่ GA พร้อมกัน

#12. Workshop Part H — เรียกใช้งานผ่าน GitHub REST API

GitHub REST API รองรับการกำหนด assignee ให้ code scanning alert เป็น copilot-swe-agent[bot] ซึ่งอาจ เริ่มการทำงานจริงและมีค่าใช้จ่าย เมื่อมีสิทธิ์และฟีเจอร์พร้อม ดังนั้นอย่ารันโดยอัตโนมัติกับทุก alert โดยไม่มีขั้นอนุมัติ

ตรวจสอบการยืนยันตัวตน GitHub CLI:

gh auth status

ดูรายการ alerts เพื่อเลือกหมายเลขที่ถูกต้อง (ตัวอย่างใช้ OWNER/REPO):

gh api 'repos/OWNER/REPO/code-scanning/alerts?state=open'

จากนั้นจึงสั่ง Assign เฉพาะเมื่อได้รับอนุญาตให้เริ่ม agent session:

gh api \
  --method PATCH \
  -H 'Accept: application/vnd.github+json' \
  -f 'assignees[]=copilot-swe-agent[bot]' \
  'repos/OWNER/REPO/code-scanning/alerts/ALERT_NUMBER'

หรือส่งเป็น JSON โดยใช้ --input:

printf '%s\n' '{"assignees":["copilot-swe-agent[bot]"]}' > assign.json

gh api --method PATCH \
  -H 'Accept: application/vnd.github+json' \
  --input assign.json \
  'repos/OWNER/REPO/code-scanning/alerts/ALERT_NUMBER'

rm assign.json

สำหรับ Fine-grained token ต้องมีสิทธิ์ Code scanning alerts: write ตามเอกสาร REST API และ API ไม่สามารถข้ามข้อจำกัดของนโยบาย/ฟีเจอร์ได้

#13. กำหนด Repository Custom Instructions

สามารถจัดเตรียมไฟล์ .github/copilot-instructions.md เพื่อให้ AI Agent รับรู้มาตรฐานการพัฒนาของทีม (ใช้ได้ตามขอบเขตและการตั้งค่า custom instructions ของ GitHub)

# Repository instructions

- Use parameterized queries for all SQL operations.
- Preserve API response contracts and HTTP status codes.
- Add regression tests for security defects.
- Prefer the smallest safe patch.
- Avoid unrelated refactoring and new dependencies.
- Do not expose credentials, tokens, or production data.
- Document validation evidence in the pull request.

คำสั่งนี้เป็น guideline ไม่ใช่ security boundary: ยังต้องบังคับสิทธิ์, CI, branch protection และ human approval แยกต่างหาก

#14. Troubleshooting ที่พบบ่อย

#15. แนวทางนำไปใช้ใน DevSecOps จริง

โครงสร้างกระบวนการที่เหมาะสม:

Commit / Pull Request
    ↓
CI Tests + CodeQL / SAST
    ↓
Security Alert on Default Branch
    ↓
Alert Triage (severity, exploitability, priority)
    ↓
Assign to Copilot (human decision)
    ↓
Agent Patch + Draft PR
    ↓
Security Review + Regression Tests + CI
    ↓
Approved Merge
    ↓
Re-scan + Post-merge Monitoring

หลักปฏิบัติที่แนะนำ

• เปิด Branch Protection/Rulesets เพื่อบังคับ review และ required checks
• กำหนด Least Privilege สำหรับ secrets, GitHub Actions และ agent environment
• เริ่มจากความเสี่ยงปานกลางใน repository ทดลอง ก่อนใช้กับ production
• เก็บหลักฐาน source alert, PR diff, test log และผลสแกนหลังแก้
• ไม่ปิด/ยกเว้น alert เพียงเพื่อทำให้ dashboard ดูสะอาดขึ้น
• Review ข้อเสนอ AI โดยเทียบกับ behavior และ business requirements ที่ควรเป็น

#16. ตัวชี้วัดสำหรับการเรียนการสอนและการวิจัย

สำหรับการทดลองเชิงประจักษ์: ควรแยก proposed patch, validation passed, alert closed, human accepted และ merged เป็นคนละสถานะ เนื่องจากไม่ได้มีความหมายเหมือนกัน

#17. แบบฝึกหัดและเกณฑ์ประเมิน

#แบบฝึกหัด 1 — วิเคราะห์ Security Alert

ถอดรหัสต้นเหตุของช่องโหว่ SQL Injection โดยระบุ source, sink, severity และแนวทางแก้ที่เหมาะสม

#แบบฝึกหัด 2 — Agentic Autofix / Manual Fix

เปรียบเทียบ patch ที่ได้จาก Agentic Autofix (ถ้าเข้าเกณฑ์ใช้งาน) กับ patch แบบ parameterized query ที่นักศึกษาทำเอง พร้อมอภิปรายข้อดีข้อเสีย

#แบบฝึกหัด 3 — Regression Testing และ PR Review

ทำให้ test กรณีโจมตีล้มเหลวในโค้ดก่อนแก้ จากนั้นแก้ให้ผ่านทั้งหมด สรุปผล CI และ CodeQL หลังแก้ไข

#เกณฑ์คะแนน (100 คะแนน)

#18. สรุป

GitHub Agentic Autofix เป็นแนวทาง AI-assisted vulnerability remediation ที่ทำให้การจัดการ Code Scanning Alert พัฒนาไปไกลกว่าการสร้างคำแนะนำโค้ดแบบครั้งเดียว โดย agent สามารถสำรวจ repository แก้ปัญหา ตรวจสอบผลแบบ best effort และเสนอการเปลี่ยนแปลงผ่าน Draft Pull Request อย่างไรก็ตาม ไม่ควรตีความว่า AI ทำให้โค้ดปลอดภัยโดยอัตโนมัติ เพราะความถูกต้องยังขึ้นกับ scanner coverage, test quality, code review, สิทธิ์ และกระบวนการอนุมัติของทีม

สำหรับ Workshop การใช้ SQL Injection → CodeQL → Assign to Copilot → Draft PR → Parameterized Query → Regression Test เป็นตัวอย่างที่ทำให้เห็นภาพ DevSecOps และ Agentic Software Engineering อย่างเป็นรูปธรรม

#แหล่งอ้างอิง (GitHub Official Sources)

1. GitHub Changelog. Agentic autofix for code scanning alerts general availability (15 October 2026). https://github.blog/changelog/2026-10-15-agentic-autofix-for-code-scanning-alerts-general-availability/
2. GitHub Docs. Managing access to agentic autofix for code scanning. https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/managing-access-to-agentic-autofix-for-code-scanning
3. GitHub Docs. Resolving code scanning alerts. https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/manage-security-alerts/manage-code-scanning-alerts/resolve-alerts
4. GitHub Docs. About autofix for code scanning. https://docs.github.com/en/enterprise-cloud@latest/code-security/concepts/code-scanning/autofix-for-code-scanning
5. GitHub Docs. Fixing code quality findings in your repository backlog. https://docs.github.com/en/enterprise-cloud@latest/code-security/how-tos/maintain-quality-code/fix-backlog-findings
6. GitHub Changelog. Remediate Code Quality findings with agentic autofix (9 September 2026). https://github.blog/changelog/2026-09-09-remediate-code-quality-findings-with-agentic-autofix/
7. GitHub Docs. REST API endpoints for code scanning. https://docs.github.com/en/rest/code-scanning/code-scanning
8. GitHub Docs. Configuring default setup for code scanning. https://docs.github.com/en/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning

หมายเหตุการเผยแพร่: เนื้อหาและเมนู GitHub เปลี่ยนแปลงได้ตามแผน การตั้งค่า และวันที่ใช้งาน ควรตรวจสอบเอกสาร Official Docs อีกครั้งก่อนนำไปอบรมหรือใช้งานจริง