โค้ดที่สร้างโดย AI ปลอดภัยจริงหรือไม่? คำถามที่พบบ่อยของนักสร้าง

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

โค้ดที่เขียนโดย AI ปลอดภัยน้อยกว่าโค้ดที่เขียนโดยมนุษย์หรือไม่?

โดยเฉลี่ยแล้ว และถ้าปล่อยไว้โดยไม่ตรวจสอบ ใช่ — เล็กน้อย งานวิจัยจาก Stanford เมื่อไม่กี่ปีก่อน (Perry et al. ซึ่งมักถูกอ้างถึงว่าเป็นการศึกษาเรื่องนี้อย่างจริงจังครั้งแรก) พบว่านักพัฒนาที่ใช้ผู้ช่วยเขียนโค้ด AI ผลิตโค้ดที่ปลอดภัยน้อยกว่ากลุ่มควบคุม และ — ส่วนนี้ควรทำให้คุณกังวลมากกว่า — ประเมินโค้ดของตัวเองว่าปลอดภัยมากกว่าความเป็นจริง ความมั่นใจเพิ่มขึ้นในขณะที่คุณภาพลดลง ผลสแกนความปลอดภัยโค้ด GenAI ล่าสุดของ Veracode ก็ให้ตัวเลขคร่าวๆ เช่นกัน — ประมาณ 4 ใน 10 ของตัวอย่างโค้ดที่สร้างโดย AI ที่พวกเขาทดสอบมีช่องโหว่ที่สามารถถูกโจมตีได้อย่างน้อยหนึ่งจุด มักเป็นเรื่องธรรมดาอย่างการขาดการตรวจสอบข้อมูลนำเข้า หรือค่าเริ่มต้นที่อ่อนแอ ทั้งหมดนี้ไม่ได้หมายความว่าโค้ดที่เขียนโดย AI จะต้องล้มเหลวโดยธรรมชาติ แต่หมายความว่าโค้ดที่เขียนโดย AI ที่ไม่ผ่านการตรวจสอบมีความเสี่ยงเช่นเดียวกับโค้ดที่มนุษย์เขียนโดยไม่ผ่านการตรวจสอบ และส่วน "ไม่ผ่านการตรวจสอบ" นี่แหละคือจุดที่อันตรายอยู่จริง โมเดลที่เขียนเร็วและไม่เคยถูกตรวจสอบจะส่งมอบข้อผิดพลาดแบบเดียวกับที่นักพัฒนาจูเนียร์ทำในบ่ายวันศุกร์ — เพียงแต่เร็วกว่าและมากกว่า

จะเกิดอะไรขึ้นกับ API key และข้อมูลลับของฉัน?

นี่คือเรื่องที่ผมนอนไม่หลับจริงๆ เพราะเป็นความผิดพลาดที่มองไม่เห็นจนกว่าจะสายเกินไป รูปแบบความล้มเหลวนี้ไม่ได้ดูน่าตื่นเต้น — ไม่มีเซิร์ฟเวอร์ไหนถูกเจาะแบบในหนัง มันคือคีย์ที่ถูกวางลงในแชท ถูกสะท้อนกลับเข้าไปในไฟล์ที่สร้างขึ้น ถูก commit และนอนนิ่งอยู่แบบ plaintext ในรีโพหกเดือนต่อมา เมื่อมีคนรัน secret scanner ไปลองดูเล่นๆ บนแพลตฟอร์มนี้ ข้อมูลลับจะไม่ปรากฏอยู่ในซอร์สโค้ดที่สร้างขึ้นเลย — มันถูกฉีดเข้าไปตอนรันไทม์จากที่เก็บที่เข้ารหัส ผูกขอบเขตไว้กับ tenant ของคุณ และ build agent ถูกสั่งให้อ้างอิงโดยใช้ชื่อ ไม่ใช่ค่าจริง แต่ถ้าคุณกำลังสร้างที่อื่น หรือวางข้อมูลรับรองลงในหน้าต่างแชทของเครื่องมือใดๆ โดยตรง ให้สมมติว่าข้อความนั้นกลายเป็นส่วนหนึ่งของ log ที่เกี่ยวข้องกับการเทรนที่ไหนสักแห่งแล้ว เว้นแต่ผู้ให้บริการจะระบุไว้อย่างชัดเจนว่าไม่ใช่ หมุนเวียน (rotate) ทุกอย่างที่คุณเคยพิมพ์ลงในกล่องแชท เป็นหลักการ ในวันเดียวกับที่คุณทดสอบเสร็จ

มีใครแฮกเว็บไซต์ของฉันผ่าน prompt ได้ไหม แบบการโจมตี prompt injection?

มีสองเรื่องที่ถูกปนกันตรงนี้ และความแตกต่างนั้นสำคัญ Prompt injection ต่อตัวสร้าง (builder) — คนที่หลอกให้ AI ที่กำลังสร้างแอปของคุณทำสิ่งที่คุณไม่ได้ขอ — เป็นความเสี่ยงจริงที่ผ่านการศึกษามาแล้ว และนี่คือเหตุผลที่ build agent ทำงานด้วยสิทธิ์เครื่องมือที่จำกัดขอบเขต แทนที่จะให้สิทธิ์ shell แบบไม่จำกัด และทำไมทุกอย่างที่แตะต้องไฟล์ระบบหรือ deploy pipeline ของคุณจึงต้องผ่าน action log ที่ชัดเจนซึ่งคุณตรวจสอบย้อนหลังได้ ส่วน prompt injection ต่อแอปที่คุณเปิดตัวไปแล้ว เป็นเรื่องแยกต่างหากที่เกี่ยวข้องเฉพาะเมื่อแอปของคุณเองฝัง LLM ไว้ตอนรันไทม์ — เช่น แชทบอทช่วยเหลือลูกค้า ฟีเจอร์ค้นหาด้วย AI อะไรทำนองนั้น ถ้าเป็นเช่นนั้น ให้ปฏิบัติกับข้อความใดๆ ที่ผู้ใช้พิมพ์เข้ามาเป็นข้อมูลนำเข้าที่ไม่น่าเชื่อถือสำหรับโมเดลนั้น เหมือนกับที่คุณปฏิบัติกับมันในฐานะข้อมูลนำเข้าที่ไม่น่าเชื่อถือสำหรับ SQL query กฎเดิมยังใช้ได้ สิ่งใหม่คือแค่ระบบไหนที่กำลังตีความสตริงนั้น

ตัวสร้างตรวจสอบช่องโหว่ในโค้ดของตัวเองก่อนส่งมอบหรือไม่?

การตรวจสอบอัตโนมัติจับสิ่งพื้นฐานที่พบบ่อยได้อย่างน่าเชื่อถือ: ข้อมูลลับที่ฝังตายตัวในโค้ด การขาดระบบยืนยันตัวตนใน endpoint ที่ชัดเจนว่าต้องมี SQL ที่สร้างด้วยการต่อสตริงแทนที่จะใช้พารามิเตอร์ dependency ที่มี CVE ที่รู้จักอยู่แล้ว แต่สิ่งที่มันจับได้ไม่ดีคือข้อบกพร่องด้าน business logic — ประเภทที่โค้ดแต่ละบรรทัดดูปกติดี แต่ช่องโหว่อยู่ตรงช่องว่างระหว่างสองฟีเจอร์ที่ไม่มีใครคิดจะตรวจสอบร่วมกัน เช่น โค้ดส่วนลดที่ซ้อนกันได้ไม่จำกัดกับโบนัสแนะนำเพื่อน หรือขั้นตอนรีเซ็ตรหัสผ่านที่รั่วไหลว่าอีเมลนี้มีอยู่ในระบบหรือไม่ สิ่งเหล่านี้ต้องการคนที่เข้าใจว่าแอปมีไว้เพื่ออะไร ไม่ใช่แค่โค้ดทำอะไร และยังไม่มีสแกนเนอร์ตัวไหน — ไม่ว่าจะเป็น AI หรืออื่นๆ — ที่หาช่องโหว่แบบนี้เจอได้อย่างน่าเชื่อถือ การตรวจสอบอัตโนมัติเป็นเพียงพื้นฐาน ไม่ใช่เพดานสูงสุด

แล้วแพ็กเกจของบุคคลที่สามที่มันติดตั้งล่ะ — นั่นคือความเสี่ยงด้าน supply-chain หรือเปล่า?

ใช่ และตามตรงมันเป็นความเสี่ยงในโลกจริงที่ใหญ่กว่าโค้ดที่เขียนโดย AI เองเสียอีก แอปส่วนใหญ่ประกอบด้วย dependency ถึง 80-95% ของจำนวนบรรทัดโค้ด ส่วนโค้ดที่ตัวสร้างเขียนขึ้นเป็นเพียงชั้นบางๆ ด้านบนของ npm, PyPI หรือระบบนิเวศอื่นใดที่สแต็กนั้นใช้ แพ็กเกจที่เป็นอันตรายหรือถูกยึดครองสามารถทำให้คุณเสี่ยงได้ไม่ว่าใครหรืออะไรจะเขียนโค้ดเชื่อมต่อรอบๆ มัน — ดูเหตุการณ์ event-stream และ colors.js เป็นตัวอย่างว่ามันเกิดขึ้นจริงอย่างไร วิธีป้องกันนั้นเรียบง่ายและได้ผล: ล็อกเวอร์ชันแทนการติดตามเวอร์ชันล่าสุดเสมอ เลือกแพ็กเกจที่มีประวัติการดูแลรักษาจริงมากกว่าที่เพิ่งเผยแพร่เมื่อสัปดาห์ที่แล้ว และรัน dependency audit (`npm audit`, `pip-audit` หรืออะไรก็ตามที่เข้ากับสแต็กของคุณ) เป็นนิสัยประจำ ไม่ใช่ขั้นตอนเดียวก่อนเปิดตัว

ใครต้องรับผิดชอบหากเกิดการรั่วไหลของข้อมูล?

คุณเองคือคนรับผิดชอบ — ในทางกฎหมาย เกือบทุกครั้ง ถ้ามันเป็นแอปของคุณและเป็นข้อมูลของลูกค้าคุณ เรื่องนี้ทำให้หลายคนแปลกใจเพราะคิดว่า "AI เป็นคนเขียน" จะช่วยโยกย้ายความรับผิดชอบไปที่อื่น แต่ไม่ใช่ เหมือนกับการจ้างผู้รับเหมาก่อสร้างไม่ได้ทำให้เจ้าของอาคารพ้นความรับผิดจากการละเมิดกฎหมายอาคาร แพลตฟอร์มรับผิดชอบต่อโครงสร้างพื้นฐานที่ตนควบคุม: วิธีเก็บข้อมูลลับ วิธีแยกข้อมูลของแต่ละ tenant ว่าชั้น hosting เองได้รับการแพตช์แล้วหรือไม่ แต่ตรรกะของแอปพลิเคชันที่คุณกำหนด ข้อมูลที่คุณเลือกจะเก็บรวบรวม และข้อกำหนดที่คุณเสนอให้ผู้ใช้ ล้วนเป็นความรับผิดชอบของคุณ หากคุณกำลังจัดการข้อมูลที่ละเอียดอ่อน — รายละเอียดการชำระเงิน ข้อมูลสุขภาพ หรือสิ่งใดก็ตามภายใต้ GDPR หรือ CCPA — ให้อ่านข้อตกลงการประมวลผลข้อมูลจริงของแพลตฟอร์มที่คุณใช้ แทนที่จะสมมติว่า "สร้างโดย AI" หมายถึงมีชั้นความคุ้มครองทางกฎหมายเพิ่มเติม เพราะมันไม่มี

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

ฉันควรจ่ายเงินเพื่อทำ security audit จริงๆ ก่อนเปิดตัวไหม?

หากคุณกำลังรับการชำระเงิน เก็บข้อมูลอะไรก็ตามที่หน่วยงานกำกับดูแลจะเรียกว่า PII หรือกำลังสร้างสำหรับลูกค้าธุรกิจที่จะขอรายงาน SOC 2 อยู่ดี — ใช่ และอย่าให้ค่าใช้จ่ายทำให้คุณเปลี่ยนใจ การตรวจสอบแบบเจาะจงสำหรับแอปขนาดเล็กมีค่าใช้จ่ายตั้งแต่ไม่กี่ร้อยไปจนถึงหลักพันดอลลาร์ต้นๆ ขึ้นอยู่กับขอบเขต ซึ่งถูกกว่าจดหมายแจ้งเตือนการรั่วไหลของข้อมูลมาก หากคุณกำลังสร้างโปรเจกต์งานอดิเรก เครื่องมือภายในองค์กร หรือสิ่งที่ไม่มีข้อมูลผู้ใช้จริงเป็นเดิมพัน การจ้าง audit นั้นเกินความจำเป็น ให้ใช้ชั้นการตรวจสอบแบบฟรีและราคาถูกแทน — การสแกน dependency การคลิกตรวจสอบด้วยมือทุกจุดตรวจสอบสิทธิ์ (ผู้ใช้ A เห็นข้อมูลของผู้ใช้ B ได้ไหมด้วยการเปลี่ยน URL?) และให้มนุษย์อีกคู่ตาช่วยตรวจสอบทุกอย่างที่เกี่ยวข้องกับเงินหรือรหัสผ่าน

ความผิดพลาดด้านความปลอดภัยที่พบบ่อยที่สุดคืออะไร และมันมักเกิดขึ้นเมื่อไหร่?

ไม่ใช่ตอนเปิดตัว แต่เป็นสามเดือนหลังจากนั้น เมื่อแอปทำงานได้ดีและไม่มีใครสนใจดูมันอีกแล้ว มันคือเส้นทาง admin ที่ถูกปล่อยไว้โดยไม่มีการป้องกัน เพราะถูกทดสอบแค่โดยคนที่สร้างมันในขณะที่ล็อกอินเป็นตัวเอง มันคือ debug endpoint ที่คืน stack trace เต็มรูปแบบในระบบจริง มันคือรหัสผ่านเริ่มต้นในฐานข้อมูลที่ควรจะ "ใช้ทดสอบเท่านั้น" แต่ไม่เคยถูกเปลี่ยน ไม่มีสิ่งใดในนี้แปลกใหม่ มันเป็นเสมือนการวางกุญแจสำรองไว้ใต้พรมประตูเพราะรีบร้อนครั้งหนึ่ง แล้วก็ลืมไปว่ามันอยู่ตรงนั้น วิธีแก้ไม่ใช่เครื่องมือที่ดีกว่า แต่เป็นนิสัยที่ใช้เวลาห้านาที: เดือนละครั้ง ลองมองแอปของคุณในมุมมองของผู้โจมตีสักห้านาที ก่อนจะมองมันในมุมมองของผู้สร้างที่ภูมิใจ