SPACE กำหนดเส้นทางคำขอไปยัง execution ของแซนด์บ็อกซ์ที่ถูกต้องได้อย่างไร

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

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

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

เป็นเวลาหลายเดือนแล้วที่ SPACE รองรับการรันหลายล้านครั้งต่อวัน โดยแต่ละครั้งได้รับการปกป้องด้วยอัตลักษณ์เชิงการเข้ารหัสที่ไม่ซ้ำกัน มีอัตราข้อผิดพลาดต่ำกว่า 0.0002% และไม่มีการเชื่อมต่อหลุดเลยแม้แต่ครั้งเดียว

ปัญหาของการกำหนดเส้นทาง

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

การอ่านไฟล์ต้องเดินทางผ่านคอมโพเนนต์หลายตัว control plane ของ SPACE จะระบุว่าแซนด์บ็อกซ์นั้นตรงกับ execution และเวิร์กเกอร์ใด คำขอจะเข้ามาทาง node-api ส่งต่อไปยังตัวจัดการแซนด์บ็อกซ์ sbx-manager และข้ามซ็อกเก็ต Unix ไปยังบริดจ์ฝั่งโฮสต์ spaced-host จากนั้นบริดจ์จะส่งต่อคำขอผ่าน VSOCK ซึ่งเป็น transport ซ็อกเก็ตระหว่างโฮสต์กับ guest ไปยัง spaced-guest ภายใน Firecracker microVM

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

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

ขยาย

อัตลักษณ์ของแซนด์บ็อกซ์และอัตลักษณ์ของ execution

SPACE แยกสภาพแวดล้อมของผู้ใช้ออกจากรันไทม์ที่ให้บริการสภาพแวดล้อมนั้น:

• อัตลักษณ์ของแซนด์บ็อกซ์: ID ที่คงที่ของสภาพแวดล้อมเชิงตรรกะ การอนุญาตผู้เรียกจะกำหนดสิทธิ์การเข้าถึงแซนด์บ็อกซ์นี้
• อัตลักษณ์ของเส้นทาง/execution: incarnation ของรันไทม์ที่ถูกเลือกและตำแหน่งการวาง ซึ่งรวมถึงเวิร์กเกอร์ substrate และ activation ของ incarnation นั้น

generation ของ execution ใช้แยกแยะ incarnation ของรันไทม์ บน Kubernetes เส้นทางยังรวม UID ของพ็อดไว้ด้วย ที่อยู่ใช้ระบุตำแหน่งของเอนด์พอยต์ ส่วนอัตลักษณ์ของ execution จะกำหนดว่าเอนด์พอยต์เหล่านั้นสามารถให้บริการการดำเนินการได้หรือไม่

สมมติว่าแซนด์บ็อกซ์ S ทำงานเป็น execution 7 บนเวิร์กเกอร์ A จากนั้นกลับมาทำงานต่อเป็น execution 8 บนเวิร์กเกอร์ B คำขอที่ถูกเลือกให้ไปยัง execution 8 ต้องล้มเหลวหากไปถึง execution 7 การตรวจสอบเพียง ID ของแซนด์บ็อกซ์จะไม่สามารถตรวจพบความไม่ตรงกันนี้ได้

ขยาย

การเลือก execution แบบมีลายเซ็น

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

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

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

ทราฟฟิก ServicePort จะได้รับการตรวจสอบครั้งที่สองที่เกตเวย์เครือข่ายประจำแต่ละแซนด์บ็อกซ์ netgtw ก่อนที่จะเปิดการเชื่อมต่อไปยัง guest เกตเวย์จะเปรียบเทียบอัตลักษณ์กับสถานะ activation ที่เชื่อถือได้ และตรวจสอบพอร์ตและโปรโตคอล ส่วนการดำเนินการควบคุมจะเข้าสู่ขั้นตอนการตรวจสอบเอนด์พอยต์ของบริดจ์ต่อไป

SPACE ใช้ลายเซ็น Ed25519 คีย์การลงนามของ control plane ใช้ออก capability ส่วนคีย์ยืนยันสาธารณะบนเวิร์กเกอร์และเกตเวย์ไม่สามารถออก capability ได้

capability มีอายุ 120 วินาที โดยมีค่าเผื่อความคลาดเคลื่อนของนาฬิกา (clock skew) สำหรับการหมดอายุได้สูงสุด 15 วินาที ลายเซ็นที่ถูกต้องและโทเค็นที่ยังไม่หมดอายุยังไม่เพียงพอ หากอัตลักษณ์ที่ถูกเลือกและอัตลักษณ์ที่ติดตั้งอยู่ไม่ตรงกัน

ขยาย

การปฏิเสธ ณ ปลายทางที่ไม่ถูกต้อง

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

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

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

ขยาย

การตรวจสอบเอนด์พอยต์ของบริดจ์

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

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

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

การตรวจสอบนี้ครอบคลุมบริดจ์ควบคุมของ Firecracker ทั้งบน Kubernetes และบนโฮสต์ที่จัดการโดยตรง ทราฟฟิก ServicePort ใช้การตรวจสอบ execution และพอร์ตที่เกตเวย์ของตน โดยไม่ได้รับรองอัตลักษณ์ของแอปพลิเคชันใด ๆ ที่ทำงานอยู่ภายใน guest

ขยาย

อายุการใช้งานของสตรีมและการกู้คืนเส้นทาง

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

เทอร์มินัลและการเฝ้าดูไฟล์ (file watch) อาจมีอายุยาวนานกว่าคำขอที่เปิดขึ้นมา SPACE จึงผูกสตรีมแบ็กเอนด์เข้ากับ epoch ของอัตลักษณ์ เพื่อไม่ให้สตรีมยังคงเชื่อมต่ออยู่กับ execution ก่อนหน้าหลังจากที่ผู้รับติดตั้ง execution ที่มาแทนที่แล้ว

SPACE จะตรวจสอบอัตลักษณ์แบบถาวรซ้ำอีกครั้งก่อนเปิดสตรีม การแทนที่เส้นทางหรือ execution ของสตรีมจะยกเลิก lease ของสตรีมนั้น ซึ่งทำให้อินพุตและเอาต์พุตหยุดลง

การเปลี่ยนแปลงความเป็นเจ้าของแตกต่างจากการแทนที่ execution การส่งต่อการดำเนินการด้านวงจรชีวิต (lifecycle operation) บน resident ของ Kubernetes ที่ไม่มีการเปลี่ยนแปลง จะยังคงรักษาอัตลักษณ์ของเส้นทาง capability ที่ยังไม่หมดอายุ และสตรีมไว้ เกตเวย์ยังคงรักษาสตรีมที่สร้างไว้แล้วสำหรับการเปลี่ยนแปลงที่เกิดขึ้นเฉพาะกับ activation attempt ภายในเส้นทางและ generation ของ execution เดียวกัน ส่วนการเปิดใหม่จะต้องใช้อัตลักษณ์ที่อัปเดตแล้ว

การกู้คืนยังคงรักษาการตรวจสอบเหล่านี้ไว้ครบถ้วน ตัวเปรียบเทียบอัตลักษณ์สามารถส่งคืน RefreshRoute เมื่อ incarnation ไม่ตรงกันภายในแซนด์บ็อกซ์เดียวกัน หรือส่งคืน Deny เมื่อเป็นแซนด์บ็อกซ์อื่น มีเพียงสัญญาณรีเฟรชที่ระบบรู้จักเท่านั้นที่จะทริกเกอร์การซ่อมแซมเส้นทางหลังจากอัตลักษณ์ถูกปฏิเสธ ความล้มเหลวของ transport จะเป็นไปตามกฎการกู้คืนแยกต่างหากที่เฉพาะเจาะจงตามแต่ละการดำเนินการ ส่วนลายเซ็น วัตถุประสงค์ (purpose) หรือโปรไฟล์พอร์ตที่ไม่ถูกต้องจะยังคงถูกปฏิเสธ

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

กฎการเล่นซ้ำ (replay) ยังคงเฉพาะเจาะจงตามแต่ละการดำเนินการ แบ็กเอนด์ที่มาแทนที่ต้องผ่านการรับเข้า (admission) อีกครั้ง แม้ว่า WebSocket ฝั่งไคลเอนต์จะยังเปิดอยู่ก็ตาม

ขยาย

ข้อแลกเปลี่ยนและขอบเขตความไว้วางใจ

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

การออกแบบนี้ตั้งสมมติฐานว่ามีการเปิดใช้การบังคับใช้อัตลักษณ์ และเชื่อถือผู้ลงนามของ control plane เคอร์เนลของเวิร์กเกอร์ และบริการจัดการภายในโหนด การถูกเจาะระบบในระดับ root ของเวิร์กเกอร์หรือในระดับผู้ดูแลคลัสเตอร์ที่มีสิทธิ์พิเศษอยู่นอกขอบเขตของโมเดลภัยคุกคาม การตรวจสอบบริดจ์เป็นการตรวจสอบโปรเซสและ transport ภายในเครื่อง ไม่ใช่การรับรองระยะไกล (remote attestation) ที่อาศัยฮาร์ดแวร์

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

การเปรียบเทียบในอุตสาหกรรม

ประเด็นที่ควรนำมาเปรียบเทียบคือวิธีที่แพลตฟอร์มต่าง ๆ จัดการกับคำขอที่ได้รับอนุญาตซึ่งไปถึง execution ที่ไม่ถูกต้องของแซนด์บ็อกซ์ที่ถูกต้อง ข้อค้นพบเหล่านี้เกี่ยวข้องกับ implementation ที่ได้ตรวจสอบเท่านั้น ไม่ใช่ความปลอดภัยโดยรวมของแพลตฟอร์ม โดย SPACE, OpenShell และ E2B ได้รับการตรวจสอบเมื่อวันที่ 8 ตุลาคม 2026:

• OpenShell: มีกลไกการเลือก execution สำหรับการเรียกใหม่และการผูก supervisor เข้ากับรันไทม์ในระดับที่เทียบเคียงได้ ผ่านการตรวจสอบ generation และการอนุญาตที่เกตเวย์ การตรวจสอบความถูกต้องของอัตลักษณ์แบ็กเอนด์ และการเชื่อมต่อ supervisor ที่ยืนยันแล้วว่ายังทำงานอยู่ (การรับคำขอเข้าที่เกตเวย์, การยืนยันตัวตนและการผูกรันไทม์) SPACE ส่งต่อผลการเลือกที่มีลายเซ็นไปตลอดเส้นทางการให้บริการ และเพิ่มการตรวจสอบโปรเซสและ transport ภายในเวิร์กเกอร์ ส่วน OpenShell กระจายการตรวจสอบที่สอดคล้องกันไว้ที่เกตเวย์ อัตลักษณ์ขณะเริ่มทำงาน (launch identity) และโปรโตคอลรันไทม์ที่ผ่านการยืนยันตัวตน (การออกแบบรันไทม์)
• E2B: ติดตาม ID ของ execution และแยกพูลพร็อกซีตามวงจรชีวิตของ Firecracker แต่พร็อกซีขาเข้าของ E2B เลือกแซนด์บ็อกซ์เชิงตรรกะและพอร์ตโดยไม่มีอัตลักษณ์ของ execution ที่คาดหวังไว้ให้ผู้รับใช้เปรียบเทียบ (การเผยแพร่เส้นทาง, การรับคำขอเข้าที่พร็อกซี) execution รุ่นเก่าที่ยังลงทะเบียนว่าทำงานอยู่บนผู้รับที่ล้าสมัยและมีข้อมูลประจำตัวที่ตรงกัน จึงไม่สามารถแยกแยะออกจาก execution รุ่นใหม่กว่าที่ถูกเลือกได้ด้วยการตรวจสอบเหล่านั้น แม้ว่าการยุติการทำงาน (teardown) ตามปกติจะลบเส้นทางและปิดการเชื่อมต่อที่ผูกกับวงจรชีวิตก็ตาม (ข้อมูลประจำตัว, การยุติการทำงาน)
• CubeSandbox: ซ่อมแซมการกำหนดเส้นทางเมื่อกลับมาทำงานต่อและทำให้แคชเดิมใช้ไม่ได้ แต่ ingress แบบส่วนตัวใช้ข้อมูลประจำตัวที่มีขอบเขตระดับแซนด์บ็อกซ์ และส่งต่อคำขอโดยไม่มี incarnation ของรันไทม์ที่คาดหวังไว้ (การกำหนดเส้นทางเมื่อกลับมาทำงานต่อ, การกำหนดเส้นทาง ingress) การซ่อมแซมเส้นทางช่วยลดช่วงเวลาที่เส้นทางล้าสมัย ส่วน capability ที่ผูกกับ execution ของ SPACE ยังช่วยให้ผู้รับมีเกณฑ์ที่เป็นอิสระในการปฏิเสธ incarnation ที่ไม่ถูกต้องอีกด้วย

อัตลักษณ์ในฐานะขอบเขตการแยกส่วน

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

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

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