- Joshua Rogers ค้นพบรายการปัญหาที่อาจเกิดขึ้นจำนวนมากในโค้ดเบสของ curl โดยใช้ ชุดเครื่องมือที่ขับเคลื่อนด้วย AI ของเขาเอง
- รายการนี้มีทั้งข้อบกพร่องด้านสไตล์โค้ดเล็กน้อย ไปจนถึงบั๊กเล็ก ๆ และ ช่องโหว่ด้านความปลอดภัยที่อาจเกิดขึ้น
- ปัญหาที่พบส่วนใหญ่เป็น บั๊กขนาดเล็ก แต่ก็อาจมีข้อบกพร่องด้านความปลอดภัยที่ร้ายแรงถึงขั้นวิกฤตอยู่ 1~2 รายการ
- เนื่องจากเป็นปัญหาที่ไม่เคยถูกค้นพบมาก่อน จึงถือเป็นผลลัพธ์ที่มีคุณค่ามาก
- จากรายงานดังกล่าว มีการแก้ไขบั๊กไปแล้ว 22 รายการ
- ยังเหลือประเด็นที่ยังไม่ได้ยืนยันอีกมากกว่าสองเท่า ทำให้ยังคงมีการตรวจทานและแก้ไขอย่างต่อเนื่อง
- ปัญหาโดยละเอียดถูกระบุว่าเป็น "Reported in Joshua's sarif data" และหากสนใจก็สามารถเข้าไปตรวจสอบข้อมูลดังกล่าวได้โดยตรง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
แทนที่จะลงมือเขียนหรือแก้โค้ดเอง ผมอยากให้มันทำหน้าที่ชี้จุดน่าสงสัยในโค้ดและบอกว่าควรไปตรวจดูตรงไหนให้ละเอียดขึ้น
พอลองขอให้ Claude หาบั๊กในไลบรารี C ของผมที่มี 20,000 บรรทัด มันกลับแบ่งไฟล์แล้ว grep หาแพตเทิร์นโค้ดบางอย่าง สุดท้ายก็แค่ไล่รายการคอมเมนต์ FIXME ของผมออกมาให้ดู (ฮา)
เอาจริง ๆ ระดับนี้ bash script ธรรมดาก็ทำได้ เลยค่อนข้างน่าผิดหวัง
ส่วน ChatGPT ยิ่งมีประโยชน์น้อยกว่าอีก เอาแต่พูดว่า "ทุกอย่างดูดีมาก! เยี่ยมไปเลย! ไฮไฟว์~" ซ้ำ ๆ
จนถึงตอนนี้ การหาบั๊กจริง ๆ ยังเป็นเรื่องที่การวิเคราะห์แบบ static analysis ดั้งเดิมช่วยได้มากกว่า แต่การที่ static analysis ไม่เจออะไร ก็ไม่ได้แปลว่าไม่มีบั๊กเชิงตรรกะ
และผมคิดว่านี่แหละคือจุดที่ LLM ควรจะเปล่งประกาย
ถ้าจะให้ LLM ให้ข้อมูลบั๊กที่อาจมีอยู่ได้มีประโยชน์มากขึ้น แล้วต้องไปสร้างสภาพแวดล้อมที่ปรับแต่งเฉพาะทางอย่างมาก สุดท้ายมันก็คงถูกใช้น้อยลง เหมือนเครื่องมือ static analysis ที่คนมักไม่ใช้ถ้าต้องตั้งค่าอะไรซับซ้อน
แนวทางที่ให้ AI เขียนโค้ด แล้วให้โปรแกรมเมอร์มีหน้าที่แค่รีวิว ดูเป็นทิศทางที่ผิดเพี้ยนไปหน่อย
แน่นอน ผมก็เข้าใจเหตุผลว่าทำไมถึงขายกันด้วยแนวคิดแบบ "จำนวนบรรทัดโค้ดเพิ่มขึ้นนะ~"
เช่นถามว่า "ถ้าจะให้ Claude Code วางแผนรีวิวบั๊กเชิงตรรกะอย่างมีประสิทธิภาพ โดยไม่สนใจคอมเมนต์อย่าง FIXME, TODO ควรใช้พรอมป์ต์แบบไหน?"
พรอมป์ต์ที่ได้ยาวเกินกว่าจะใส่ไว้ตรงนี้ แต่ดูตัวอย่างที่เผยแพร่เป็น gist ได้
แล้วก็เอาผลที่ได้มาปรับปรุงต่อจนทำเป็นเอเจนต์ได้ด้วย
หลังหมดช่วงทดลองใช้ฟรี มันได้รับความนิยมในทีมพัฒนาของเรา เลยตัดสินใจนำมาใช้แบบจริงจัง
นอกจากกรณีที่ตรวจจับผิดบ้างเป็นครั้งคราวแล้ว โดยรวมมีประโยชน์มาก
ทั้งคนเขียน PR และคนรีวิวต่างก็ประหยัดเวลาได้มาก
ปัญหาที่ปกติอาจต้องใช้เวลาหลายชั่วโมง ผมกลับแก้ได้เพราะได้เบาะแส
ผมเลยค่อนข้างคาดหวังกับศักยภาพของ AI ในการใช้งานลักษณะนี้
เลยค่อนข้างแปลกใจที่ยังได้คำตอบแนว "ทุกอย่างดูดีหมด"
เวลาใช้ผ่าน Codex CLI มันมักจะตั้งคำถามกลับมาบ้าง
Gemini 2.5 Pro ก็ทำส่วนนี้ได้โอเคเหมือนกัน
ถ้าย้อนไปดูประวัติก็น่าจะช่วยได้ ลิงก์ค้นหา HN เกี่ยวกับ curl+AI
สุดท้ายแล้วมุมมองที่น่าจะตรงกว่าคือ ความต่างระหว่างคนที่เข้าใจและใช้มันอย่างถูกต้อง กับคนที่แค่เขียนโค้ดตามกระแส
มันตัดกันชัดกับช่วงก่อนที่ Daniel Stenberg ต้องรับมือกับรายงานปัญหาความปลอดภัยปลอม ๆ คุณภาพต่ำที่ AI สร้างขึ้น
เกี่ยวกับ HackerOne เขาเคยบอกว่า: "คนที่ส่ง issue ขยะที่สร้างโดย AI จะโดนแบนทันที มันแทบจะเป็นการโจมตีแบบ DDoS อยู่แล้ว อยากจะเรียกเก็บเงินค่าเสียเวลาด้วยซ้ำ"
ลองดูโพสต์บล็อกของ Daniel เมื่อเดือนมกราคมปีนี้ด้วย: The I in LLM stands for Intelligence?
ถ้า AI ช่วยแนะนำได้ว่า "คุณยังขาด compiler warning flags สำคัญบางตัวนะ" แบบนี้จะมีประโยชน์มาก
PR บางส่วนก็น่าจะเป็นแค่ dependabot match และถ้าค้นด้วย "Joshua sarif data" ก็จะเห็นรายการ PR ที่เฉพาะเจาะจงมากขึ้น ลิงก์
เดาว่านี่อาจเป็นเหตุผลที่ทำให้ความประทับใจของ Daniel เปลี่ยนไป
มีคนผลักดันกันมากให้เอาเทคโนโลยี SAST ที่อิง AI มาใช้ และก็มีผลิตภัณฑ์ที่ออกมาจริง แต่ส่วนมากยังต่ำกว่าความคาดหวัง
แค่ทำให้ผิดหวังก็ยังถือว่าโชคดี เพราะที่แย่กว่าคือมันอาจสร้างความเชื่อผิด ๆ ว่าระบบปลอดภัยแล้ว ซึ่งอันตรายมาก
มุมมองเชิงวิจารณ์และเหตุผลเกี่ยวกับ AI-based SAST scanner มี อธิบายไว้ที่นี่
เลยสงสัยว่าทำไมกลยุทธ์นี้ถึงมีประสิทธิภาพมากกว่า ในเมื่อก่อนหน้านี้เครื่องมือหลายตัวก็หาบั๊กไม่เจอ
ส่วนลิงก์ Mastodon น่าจะใช้ยืนยันว่า ถึงจะมีโค้ดสไนเป็ตที่ผิดอยู่ แต่บั๊กนั้นเป็นของจริง