การทดสอบความปลอดภัยด้วย AI แทน SAST, DAST และ pentest ได้หรือไม่?

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

การรีวิวด้วยเอเจนต์คือตัวตีความ ไม่ใช่ประเภทการทดสอบใหม่

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

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

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

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

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

SAST ยังเป็นเจ้าของการครอบคลุมซอร์สที่ทำซ้ำได้

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

เอเจนต์เพิ่มบริบทที่เอนจินกฎมักไม่มี มันตามตัวห่อเฉพาะของโปรเจกต์ อ่านคอมเมนต์อย่างไม่เชื่อทันที เปรียบเทียบตัวจัดการคำขอกับตัวอื่นข้างเคียง และเสนอคิวรีหาแพตเทิร์นใหม่ได้ มันเห็นการละเว้นที่น่าสงสัย เช่น มีเก้า endpoint เรียก authorizeProject() แต่ endpoint ที่สิบโหลดเรคอร์ดโดยตรง มันยังมีประโยชน์เมื่อโค้ดที่สร้างขึ้นหรือเฟรมเวิร์กที่ไม่คุ้นเคยทำให้ชุดกฎมาตรฐานใช้ไม่ได้ผล

แต่การพิสูจน์ความครอบคลุมซอร์สของเอเจนต์มักยากกว่า หน้าต่างบริบท ลำดับความสำคัญของการค้นคืน ไฟล์ที่ละเว้น อาร์ติแฟกต์ที่สร้างขึ้น และเวลาหมดของเครื่องมืออาจทำให้โค้ดบางส่วนไม่ถูกอ่าน การบอกว่า «รีวิวรีโพซิทอรีนี้เพื่อหา injection» ไม่ได้ยืนยันว่าเข้าถึงทุกจุดรับข้อมูลแล้ว รายงาน SAST อย่างน้อยระบุได้ว่าไฟล์ กฎ และรีวิชันใดถูกวิเคราะห์ เอเจนต์ต้องมีบัญชีความครอบคลุมที่เทียบเท่ากันก่อนจะรับหน้าที่เกตที่บังคับใช้

NIST SP 800-218 แนะนำอย่างสมเหตุสมผลให้ใช้การวิเคราะห์โค้ดตั้งแต่ต้น และให้มนุษย์ตรวจยืนยันฟีเจอร์ความปลอดภัยกับมาตรการบรรเทาด้วยตนเอง คุณค่ามาจากการทำงานร่วมกัน กฎที่คงที่จับรูปแบบข้อบกพร่องที่รู้จักในทุกคอมมิต เอเจนต์ตรวจข้อยกเว้น เขียนการทดสอบถดถอยที่ตรงจุด และช่วยปรับกฎเมื่อแพตเทิร์นเดิมเกิดซ้ำ การถอด SAST ออกเพราะเอเจนต์พบบั๊กฉลาด ๆ หลายตัว คือการแลกความกว้างที่วัดได้กับเรื่องเล่าที่น่าประทับใจ

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

มีกำหนดว่าข้อใดควรอยู่ในกฎ SAST ที่บล็อกได้ แพตเทิร์นที่แม่นยำสำหรับ primitive การเข้ารหัสที่ห้ามใช้ควรบล็อกทันที ฮิวริสติกกว้าง ๆ ที่ถามว่าการตรวจสิทธิ์ «ดูใกล้เคียงพอหรือไม่» มักควรสร้างงานรีวิวจนกว่าทีมจะวัดความแม่นยำได้ เอเจนต์ช่วยยกระดับฮิวริสติกเป็นกฎได้ด้วยการเก็บตัวอย่างจริง ตัวอย่างโต้แย้ง และฟังก์ชันตัวห่อที่ใช้บ่อยในโค้ดเบสนั้น วิธีนี้ทำให้เกตเข้มงวดโดยไม่สอนให้นักพัฒนามองข้ามมัน

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

DAST พิสูจน์พฤติกรรมที่รีโพซิทอรีเปิดเผยไม่ได้

DAST มองเห็นแอปที่ทำงานอยู่จริง รวมถึงกฎพร็อกซี header การแปลงข้อมูลเป็นรูปแบบส่งต่อ middleware ยืนยันตัวตน ค่าเริ่มต้นของเฟรมเวิร์ก และความผิดพลาดตอนปรับใช้ การรีวิวซอร์สบอกได้ว่า endpoint ดูเหมือนมีการป้องกัน การทดสอบแบบไดนามิกแสดงได้ว่าเส้นทางในระบบจริงข้าม middleware เพราะเกตเวย์เขียน path ใหม่

ตรงนี้เอเจนต์ช่วยให้การทดสอบไดนามิกแม่นยำขึ้นมาก ให้คำอธิบาย API ตัวตนทดสอบ ขอบเขตที่อนุญาต และสภาพแวดล้อมที่ทิ้งได้ แล้วมันสร้างลำดับคำขอแทนการส่ง payload ทั่วไปแบบไม่เลือกได้ มันนำตัวระบุทรัพยากรจากคำตอบหนึ่งไปใช้กับคำขอถัดไป ต่ออายุเซสชัน เปรียบเทียบบทบาทสองแบบ และตรวจว่าการเขียนเปลี่ยนการอ่านภายหลังหรือไม่ DAST แบบเดิมมักมีปัญหากับโฟลว์ที่มีสถานะเช่นนี้

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

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

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

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

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

การทดสอบสิทธิ์ต้องมีตัวตนและผลลัพธ์ต้องห้าม

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

OWASP ASVS ระบุว่าแอปควรบังคับใช้การควบคุมการเข้าถึงในชั้นบริการที่เชื่อถือได้ และใช้หลักสิทธิ์น้อยที่สุดกับฟังก์ชันและข้อมูล ผมเห็นด้วยกับข้อกำหนดเรื่องชั้นบริการ แต่ทีมมักตรวจมันแคบเกินไป พวกเขาทดสอบตัวจัดการ HTTP ที่มองเห็นได้ แล้วลืมงานเบื้องหลัง การส่งออก ดัชนีค้นหา การสมัคร websocket และ URL ไปยัง object storage โดยตรง นโยบายเดียวกันต้องอยู่รอดในทุกเส้นทางไปยังวัตถุ

เมทริกซ์ขนาดเล็กที่รันได้เผยให้เห็นมากกว่าคำสั่งกว้าง ๆ ว่า «ทดสอบ IDOR» shell fragment ต่อไปนี้สมมติว่ามีสภาพแวดล้อมที่ทิ้งได้ โทเค็น bearer สองชุด และเอกสารของผู้ใช้ A มันตรวจทั้งสถานะและการไม่มีเครื่องหมายลับของ A ในคำตอบของ B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

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

จากนั้นเปลี่ยนทีละมิติ การอ่านเทียบกับการอัปเดต ID โดยตรงเทียบกับการค้นหา สมาชิกภาพที่ใช้งานเทียบกับถูกเพิกถอน เส้นทางปกติเทียบกับการส่งออก และโทเค็นผู้ใช้เทียบกับโทเค็นบริการ เอเจนต์สร้างและรันกรณีเหล่านี้ได้อย่างมีประสิทธิภาพ มนุษย์ต้องรีวิวว่าเมทริกซ์ตรงกับนโยบายหรือไม่ และ 404, 403, ผลลัพธ์ว่าง หรือวัตถุที่ปกปิดข้อมูลคือผลลัพธ์ที่ตั้งใจไว้หรือไม่ มิฉะนั้นเอเจนต์อาจฉลองพฤติกรรมที่ธุรกิจมองว่าเป็นการละเมิด

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

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

การแยกเทนเนนต์ล้มเหลวนอกเส้นทางคำขอที่เห็นชัด

การแยกเทนเนนต์ต้องมีการทดสอบที่ขอบเขตของที่เก็บข้อมูล แคช คิว การค้นหา ไฟล์ การวิเคราะห์ และการดูแลระบบ ความล้มเหลวที่พบบ่อยไม่ใช่ไม่มี tenant_id ใน endpoint รายการหลัก แต่เป็นเส้นทางรองที่คัดลอก ทำดัชนี แคช หรือส่งออกข้อมูลโดยไม่ส่งต่อบริบทของเทนเนนต์

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

เอเจนต์ช่วยได้เพราะตามตัวระบุผ่านหลายชั้น และสร้างชุดสับเปลี่ยนที่มนุษย์เห็นว่าน่าเบื่อได้ มันสังเกตได้ว่าคีย์แคชใช้ document_id แต่คิวรีฐานข้อมูลใช้ทั้ง tenant_id และ document_id มันเปรียบเทียบ worker ส่งออกกับตัวจัดการแบบโต้ตอบ และถามได้ว่าทำไมมีเพียงตัวหนึ่งที่กำหนด row-level context นี่คือการรีวิวที่มีคุณค่าสูง

แต่มันมีสมมติฐานอันตราย คือชื่อบอกขอบเขต ฟังก์ชันชื่อ getTenantDocument อาจรับอาร์กิวเมนต์เทนเนนต์ตามอำเภอใจจากคำขอ นโยบายฐานข้อมูลอาจมีใน migration แต่ไม่อยู่บนตารางใหม่ ตัวกรองค้นหาอาจถูกใช้หลังนับผลแล้ว จึงรั่วกิจกรรมของเทนเนนต์อื่น การตรวจพิสูจน์ต้องดู predicate ที่บังคับใช้ แล้วพยายามอ่านและเขียนข้ามเทนเนนต์

อย่าให้เอเจนต์สร้าง oracle ของตัวเองด้วยการอ่านโค้ดเดียวกับที่มันทดสอบ สร้างการเข้าถึงที่คาดหวังจากตารางนโยบายอิสระซึ่งดูแลพร้อมข้อกำหนดผลิตภัณฑ์ หาก implementation และการทดสอบเข้าใจกฎเดียวกันผิด ทั้งคู่จะเห็นพ้องอย่างสมบูรณ์ทั้งที่ข้อมูลกำลังรั่ว

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

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

ตรรกะธุรกิจต้องมีเรื่องราวของการใช้งานในทางที่ผิด

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

OWASP Web Security Testing Guide ขอให้ผู้ทดสอบลองข้ามขั้นตอนเวิร์กโฟลว์ ทำฟังก์ชันซ้ำ ปลอมคำขอ เปลี่ยนจังหวะเวลา และใช้ฟีเจอร์ที่ถูกต้องในทางผิด บทนำเรื่องตรรกะธุรกิจฉบับเก่าระบุชัดว่าระบบอัตโนมัติของสแกนเนอร์ให้ความรู้หรือความคิดสร้างสรรค์เฉพาะแอปไม่ได้ เอเจนต์สมัยใหม่ช่วยงานอัตโนมัติได้ดีขึ้น แต่ไม่ได้ปิดช่องว่างด้านความรู้ โมเดลอาจเสนอว่าคูปองใช้ซ้ำได้ แต่มันไม่รู้ว่าการใช้ซ้ำคือโปรโมชันหรือทุจริตจนกว่าจะมีคนระบุกฎ

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

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

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

ความเสี่ยงจากไลบรารีมากกว่าเวอร์ชันที่มีช่องโหว่

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

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

อย่าขอให้โมเดลจดจำข้อมูลช่องโหว่ปัจจุบัน ให้แหล่งข้อมูล advisory ที่มีเวลาอ้างอิง ไฟล์ล็อกที่ resolve แล้ว และรายการอาร์ติแฟกต์ที่บิลด์แล้วแก่โมเดล ความจำของโมเดลไม่ใช่ฐานข้อมูลช่องโหว่ และ manifest ของแพ็กเกจไม่ใช่หลักฐานของสิ่งที่ส่งออกจริง SLSA provenance แยกเรื่องที่เกี่ยวข้องไว้ว่า provenance อธิบายว่าอาร์ติแฟกต์ถูกผลิตที่ใด เมื่อใด และอย่างไร ไม่ได้ประกาศว่าอาร์ติแฟกต์ปลอดภัย

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

ชื่อแพ็กเกจยังสร้างกับดักเรื่องตัวตนได้ ไลบรารีที่มีชื่อถูกต้องอาจมาจาก registry ผิดแห่ง ไฟล์ล็อกอาจชี้ไปยังตำแหน่งที่เปลี่ยนแปลงได้ หรือขั้นตอนบิลด์อาจดาวน์โหลดโค้ดที่ไม่มีใน manifest ตรวจแหล่งที่ resolve แล้ว hash ลายเซ็นใน ecosystem ที่รองรับ และการเข้าถึงเครือข่ายของการบิลด์ เอเจนต์อธิบายความไม่ตรงกันได้ แต่ระบบบิลด์ต้องบังคับใช้ว่าแหล่งใดรับได้

การอัปเกรดไม่ใช่การเปลี่ยนแปลงที่ปลอดภัยโดยอัตโนมัติ รีลีสความปลอดภัยอาจเปลี่ยนการแยกวิเคราะห์ ค่าเริ่มต้นของการอนุญาต หรือการแปลงข้อมูลจนแอปเสีย สร้างตัวอย่างทำซ้ำขั้นต่ำสำหรับ advisory ใช้การอัปเกรดใน branch แยก และรันทั้งหลักฐานด้านความปลอดภัยกับการทดสอบฟังก์ชัน หลักฐานที่ได้ช่วยตัดสินใจได้ โมเดลที่บอกว่าเวอร์ชันใหม่ «น่าจะเข้ากันได้» ช่วยไม่ได้

ผลบวกลวงคือปัญหาการออกแบบหลักฐาน

ผลการค้นหาสมควรใช้เวลานักพัฒนาเมื่อมีข้ออ้าง หลักฐาน ผลกระทบ และเส้นทางทำซ้ำได้ รายงานที่สร้างด้วย AI มักฟังดูครบถ้วนทั้งที่ขาดส่วนใดส่วนหนึ่ง ข้อความแก้ไขที่ลื่นไหลทำให้สังเกตหลักฐานอ่อน ๆ ยากขึ้น

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

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

AI ลดสัญญาณรบกวนได้ด้วยการจัดกลุ่มร่องรอยซ้ำ ตรวจ sanitizer และทดสอบซ้ำหลังแก้ไข แต่มันก็ขยายเสียงรบกวนได้ด้วยการสร้างข้อสงสัยอ่อน ๆ รูปแบบโน้มน้าวสิบแบบ คัดซ้ำตามต้นตอสาเหตุและขอบเขต ไม่ใช่ตาม URL การตรวจเจ้าของที่ขาดหนึ่งจุดซึ่งใช้ในแปด endpoint คือข้อบกพร่องทางวิศวกรรมหนึ่งเรื่องที่มีจุดเปิดเผยแปดจุด

ติดตามความแม่นยำตามหมวดหมู่และแหล่งทดสอบ หากรายงาน cross-site scripting ที่เอเจนต์สร้างมักถูกต้อง แต่ข้ออ้างเรื่อง race condition ทำซ้ำได้น้อย ให้ส่งไปคนละเส้นทาง อย่าลดประสิทธิภาพเป็นคะแนนเดียวข้ามข้อบกพร่องคนละชนิด เกตควรล้มเหลวตามหลักฐานและนโยบาย ไม่ใช่ตามคำคุณศัพท์บอกความมั่นใจของโมเดล

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

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

การทดสอบเจาะระบบโดยมนุษย์ทดสอบสมมติฐานรอบการทดสอบ

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

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

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

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

ระวังคำกล่าวอ้างเรื่อง «pentest อัตโนมัติ» ที่วัดจากจำนวนผลการค้นหา ผลการค้นหา injection ที่คุ้นเคยสิบเรื่องมีค่าไม่เท่ากับเส้นทางที่พิสูจน์ได้หนึ่งเส้นทางซึ่งข้ามการกำหนดบทบาท การอนุญาตที่ค้าง และที่เก็บข้อมูลส่งออก ตัดสินงานจากขอบเขตที่ทดสอบ คุณภาพหลักฐาน และสมมติฐานสำคัญที่ถูกท้าทาย

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

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

สร้างเกตเดียวจากหลักฐานหลายประเภท

โปรแกรมที่เหมาะสมกำหนดหน้าที่ให้แต่ละวิธี และทำให้ผลลัพธ์มาพบกันที่ข้อกำหนดความปลอดภัยเดียวกัน ใช้ SAST สำหรับแพตเทิร์นซอร์สแบบกำหนดแน่นอนและการครอบคลุมการเปลี่ยนแปลงในวงกว้าง ใช้ SCA และ provenance สำหรับข้อเท็จจริงด้านไลบรารีและบิลด์ ใช้ DAST สำหรับพฤติกรรมที่ปรับใช้แล้วและการตรวจขณะรันพื้นฐาน ใช้เอเจนต์เชื่อมหลักฐาน สำรวจโฟลว์ที่ยืนยันตัวตนแล้ว สร้างการทดสอบ และปรับการคัดแยกผล ใช้มนุษย์กำหนดนโยบาย ท้าทายสมมติฐานธุรกิจ และตรวจสอบการเปลี่ยนแปลงที่มีผลกระทบรุนแรง

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

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

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

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

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