ทีมคุณใช้ AI เขียนโค้ดแล้ว แต่ยังไม่มีใครตรวจว่าโค้ดนั้นปลอดภัยไหม
สำหรับองค์กรที่ทีมพัฒนาเริ่มใช้ AI ช่วยเขียนโค้ดจริงจัง และต้องการรู้ว่าโค้ดที่ส่งขึ้น production มีช่องโหว่หรือความลับหลุดอยู่หรือเปล่า ก่อนที่ผู้ตรวจสอบหรือผู้ไม่หวังดีจะเจอก่อน
ไม่ใช่โค้ดผิด แต่เป็นโค้ดที่ดู 'ผ่าน' ทั้งที่ยังไม่ปลอดภัย
ความลับหลุดอยู่ในโค้ดโดยไม่มีใครสังเกต
connection string รหัสผ่าน หรือ API key ที่ถูกใส่ไว้ตอนทดสอบแล้วลืมเอาออก มักหลุดเข้าไปอยู่ใน git history ซึ่งลบยากกว่าที่คิด
ไลบรารีที่มีช่องโหว่ประกาศแล้ว
AI มักเลือกไลบรารีเวอร์ชันที่เคยเห็นบ่อยตอนฝึก ซึ่งอาจเป็นเวอร์ชันเก่าที่มี CVE ประกาศแล้ว และไม่มีใครตรวจตอน merge
การตรวจสิทธิ์ที่ดูเหมือนมี แต่ไม่ครบทุกทาง
โค้ดตรวจสิทธิ์ที่ endpoint หลัก แต่ลืมตรวจที่ endpoint รอง หรือตรวจว่าล็อกอินแล้วแต่ไม่ตรวจว่าข้อมูลนั้นเป็นของผู้ใช้คนนั้นจริงหรือไม่
โค้ดที่ไม่มีใครในทีมเข้าใจจริง ๆ
เมื่อโค้ดถูกสร้างเร็วกว่าที่คนอ่านทัน จะเกิดส่วนที่ไม่มีใครกล้าแก้ พอเกิดปัญหาใน production จึงแก้ไม่ทัน
ตรวจ แล้ววาง guardrail ให้ทีมทำต่อเองได้
เป้าหมายไม่ใช่ให้เราตรวจให้ตลอดไป แต่คือทำให้ pipeline ของคุณจับปัญหาเหล่านี้ได้เองตั้งแต่ก่อน merge
ตรวจ repository ที่เสี่ยงที่สุดก่อน 1 ตัว
เลือก repository ที่แตะข้อมูลลูกค้าหรือเงินมากที่สุด ตรวจทั้งโค้ดปัจจุบันและ git history ย้อนหลัง
จัดลำดับตามความเสี่ยงจริง ไม่ใช่จำนวนคำเตือน
เครื่องมืออัตโนมัติมักคายคำเตือนหลายร้อยรายการจนทีมเลิกอ่าน เราคัดเฉพาะรายการที่มีผลจริงพร้อมอธิบายว่าถูกโจมตีได้อย่างไร
วาง guardrail ใน pipeline
ตั้งการตรวจความลับในโค้ด การตรวจไลบรารีที่มีช่องโหว่ และเกณฑ์ที่ทำให้ merge ไม่ผ่านเมื่อพบปัญหาระดับสูง
เขียนกติกาการใช้ AI เขียนโค้ดให้ทีม
ระบุให้ชัดว่าอะไรห้ามวางลงเครื่องมือ AI เช่น ข้อมูลลูกค้าจริงหรือคีย์ และงานประเภทไหนต้องมีคนรีวิวก่อนเสมอ
รายงานที่ระบุไฟล์และบรรทัด ไม่ใช่คำแนะนำลอย ๆ
รายการปัญหาระบุไฟล์และบรรทัด
แต่ละรายการระบุไฟล์ บรรทัด ระดับความรุนแรง สถานการณ์ที่ถูกโจมตีได้ และวิธีแก้ที่แนะนำ พร้อมประเมินแรงงานคร่าว ๆ
การตรวจอัตโนมัติที่ทำงานต่อเองได้
ตั้งค่าให้ pipeline ตรวจความลับในโค้ดและไลบรารีที่มีช่องโหว่ทุกครั้งก่อน merge โดยไม่ต้องพึ่งการตรวจด้วยมือ
นโยบายการใช้ AI เขียนโค้ดที่ทำตามได้จริง
เอกสารสรุปข้อห้ามและจุดที่ต้องมีคนรีวิว โดยความยาวและรายละเอียดขึ้นกับขอบเขตและกระบวนการของทีม
ถ้าทีมพัฒนาของคุณตรงกับข้อเหล่านี้
- ทีมพัฒนาใช้เครื่องมือ AI ช่วยเขียนโค้ดเป็นประจำแล้ว
- มีระบบที่แตะข้อมูลลูกค้า ข้อมูลพนักงาน หรือธุรกรรมทางการเงิน
- ยังไม่มีการตรวจความลับในโค้ดหรือไลบรารีที่มีช่องโหว่ใน pipeline
- กำลังจะถูกตรวจสอบจากลูกค้าองค์กรหรือผู้ตรวจภายนอก
เราจะบอกตรง ๆ ถ้ายังไม่ต้องใช้บริการนี้
- มีทีมความปลอดภัยภายในที่ตรวจเรื่องเหล่านี้อยู่แล้ว
- ระบบยังไม่ขึ้น production และไม่มีข้อมูลจริงอยู่ในนั้น
- ต้องการเพียงใบรับรองมาตรฐาน ไม่ได้ต้องการให้แก้จริง
คำถามที่ CTO และหัวหน้าทีมถามก่อนเสมอ
ต้องให้เราเข้าถึง source code ทั้งหมดไหม
ไม่จำเป็น สามารถเริ่มประเมินจาก repository ที่เลือกได้ โดยเงื่อนไข NDA สถานที่ตรวจ และสิทธิ์เข้าถึงต้องยืนยันก่อนเริ่มงาน หากโค้ดออกนอกองค์กรไม่ได้ ทีมจะประเมินความเป็นไปได้ของการตรวจในสภาพแวดล้อมลูกค้า
ต่างจากการรันเครื่องมือ scan อัตโนมัติอย่างไร
เครื่องมืออัตโนมัติบอกว่าอะไร 'อาจ' เป็นปัญหา แต่ไม่บอกว่าปัญหาไหนถูกใช้โจมตีได้จริงในบริบทของระบบคุณ เราคัดกรองให้เหลือเฉพาะรายการที่มีผลจริง อธิบายสถานการณ์การโจมตี และช่วยวาง guardrail ให้ทีมทำต่อเองได้
ทีมเราจะถูกตำหนิจากรายงานนี้ไหม
รายงานเขียนในเชิงระบบ ไม่ระบุว่าใครเขียนโค้ดส่วนไหน เพราะเป้าหมายคือลดความเสี่ยงและปรับกระบวนการ ไม่ใช่ประเมินผลรายบุคคล เราส่งมอบให้ผู้ที่คุณกำหนดเท่านั้น
หลังตรวจเสร็จ ต้องจ้างต่อไหม
ไม่ต้อง รายงานและ guardrail ที่วางไว้ใช้ต่อเองได้ทันที หากต้องการให้ดูแลต่อเนื่องและตรวจซ้ำเป็นรอบ จึงค่อยพิจารณาบริการดูแลรายเดือน
ให้เราตรวจ 1 repository แล้วดูว่าเจออะไรบ้าง
ทีมจะประเมินขอบเขต repository และแจ้งวิธีตรวจ ระยะเวลา ค่าใช้จ่าย และรูปแบบรายงานก่อนเริ่มดำเนินการ
