ในแวดวงการพัฒนาซอฟต์แวร์ การละเมิดความปลอดภัยไม่ได้เกี่ยวข้องกับไฟร์วอลล์มากนัก แต่เกี่ยวข้องกับข้อบกพร่องในโครงสร้างพื้นฐานของโค้ดมากกว่า pipelineดังนั้น จากมุมมองของนักพัฒนา ข้อมูลรั่วไหลคืออะไร? มันคือการเปิดเผยหรือการขโมยข้อมูลที่สำคัญ ซึ่งไม่ได้เกิดจากข้อบกพร่องของโครงสร้างพื้นฐานเพียงอย่างเดียว แต่ยังเกิดจากบั๊ก การตั้งค่าที่ไม่ถูกต้อง และแนวทางการเขียนโค้ดที่ไม่ดีด้วย CI/CD pipelineและการบูรณาการ มาดูกันว่าสาเหตุใดบ้างที่ทำให้เกิดการละเมิดข้อมูล และเจาะลึกถึงสาเหตุใดบ้างที่ทำให้เกิดการละเมิดข้อมูล
การรั่วไหลของข้อมูลคืออะไร? คำจำกัดความจากมุมมองของนักพัฒนา
คำจำกัดความแบบดั้งเดิมมักเน้นไปที่โครงสร้างพื้นฐานที่ถูกบุกรุก อย่างไรก็ตาม สำหรับนักพัฒนาแล้ว การรั่วไหลของข้อมูลหมายถึงความล้มเหลวในการรักษาความปลอดภัยของแอปพลิเคชัน เวิร์กโฟลว์ที่กำหนดค่าไม่ถูกต้อง หรือการเขียนโค้ดที่ไม่ระมัดระวังซึ่งทำให้ข้อมูลที่ละเอียดอ่อนรั่วไหล ตัวอย่างเช่น ข้อมูลประจำตัวที่เขียนไว้ในโค้ดโดยตรง (Hardcoded credentials) commitเชื่อมโยงไปยังที่เก็บ Git หรือ CI/CD งานที่มีสิทธิ์การเข้าถึงกว้างเกินไป
In CI/CDการพัฒนาที่ขับเคลื่อนด้วย - pipelineโค้ดและไฟล์ s คือช่องทางการโจมตีใหม่ ดังนั้นการ "เปลี่ยนทิศทางไปทางซ้าย" จึงมีความสำคัญอย่างยิ่ง โดยการจัดการ "โค้ดและไฟล์ s" ให้ปลอดภัยจากภัยคุกคาม pipeline โค้ด (เช่น) การกระทำของ GitHub หรือการกำหนดค่า GitLab CI) เป็นส่วนหนึ่งของแอปพลิเคชันและเสริมความปลอดภัยให้เหมาะสม ในทางปฏิบัติ นักพัฒนาจำเป็นต้องเข้าใจว่าการละเมิดข้อมูลคืออะไรในบริบทของทุกๆ กรณี commitกระบวนการทำงาน และการพึ่งพาบุคคลที่สาม
ข้อใดต่อไปนี้เป็นสาเหตุทั่วไปของการละเมิดความปลอดภัยในสภาพแวดล้อมการพัฒนาสมัยใหม่
- ค่าเริ่มต้นที่ไม่ปลอดภัยใน CI/CD Pipelines. เครื่องมือ CI เช่น Jenkins, GitHub Actions หรือ GitLab CI มักใช้ค่าเริ่มต้นที่อนุญาตอย่างกว้างขวาง เวิร์กโฟลว์ที่มีสิทธิ์ในการเขียนอย่างกว้างขวาง (เช่น สิทธิ์การเขียน: เขียนได้ทั้งหมดอาจถูกแฮ็กได้หากมีการอนุมัติคำขอแก้ไขข้อความที่เป็นอันตราย นี่เป็นตัวอย่างที่ชัดเจนของสาเหตุทั่วไปของการละเมิดข้อมูลดังต่อไปนี้
- ความลับที่ถูกเปิดเผยในคลังเก็บข้อมูล ข้อมูลลับต่างๆ เช่น ข้อมูลประจำตัวของ AWS รหัสผ่านฐานข้อมูล หรือโทเค็น API มักจะพบได้ในไฟล์ YAML, Dockerfile หรือซอร์สโค้ด ซึ่งอาจรั่วไหลได้เมื่อมีการเปิดเผยที่เก็บโค้ดโดยไม่ได้ตั้งใจ หรือเมื่อผู้โจมตีทำการสแกน ในเหตุการณ์การรั่วไหลของข้อมูลของ Uber ในปี 2022 ข้อมูลประจำตัวที่ถูกเขียนไว้ในโค้ดโดยตรงนำไปสู่การรั่วไหลครั้งร้ายแรง
- ความสับสนในการพึ่งพา และ แพ็กเกจที่เป็นอันตราย. แอปพลิเคชันในปัจจุบันพึ่งพาไลบรารีของบุคคลที่สามเป็นอย่างมาก การจดทะเบียนชื่อโดเมนโดยมิชอบ การปล่อยแพ็กเกจที่ไม่ได้รับการดูแลรักษา และโค้ดที่เป็นอันตรายที่ซ่อนอยู่ในส่วนประกอบต่างๆ ทำให้สิ่งนี้เป็นหนึ่งในสาเหตุทั่วไปที่ร้ายแรงแต่ไม่ค่อยชัดเจนนักของการละเมิดความปลอดภัย SBOM การจัดทำรายการส่วนประกอบซอฟต์แวร์ (Software Bill of Materials) และการสแกนความสัมพันธ์ระหว่างส่วนประกอบต่างๆ อย่างต่อเนื่อง เป็นกุญแจสำคัญในการป้องกันการรั่วไหลของข้อมูล
- การตั้งค่า IAM และการควบคุมการเข้าถึงไม่ถูกต้อง การกำหนดบทบาท IAM ที่อนุญาตมากเกินไปในโค้ด (เช่น การอนุญาตให้...) s3:*ช่องโหว่ดังกล่าวอาจทำให้ผู้โจมตีสามารถเคลื่อนที่ไปมาภายในโครงสร้างพื้นฐานคลาวด์ได้ การควบคุมการเข้าถึงที่ฝังอยู่ในโค้ด (ตัวแปรสภาพแวดล้อม โทเค็น) มักขาดการตรวจสอบอย่างเข้มงวดและการตรวจสอบความถูกต้องโดยอัตโนมัติ
- โทเค็นที่ใช้ซ้ำและการเข้าถึง CI สาธารณะ โทเค็นที่ไม่มีวันหมดอายุหรือ CI dashboardการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาตถือเป็นช่องทางโจมตีที่แนบเนียนแต่ส่งผลกระทบอย่างมาก การทิ้งบันทึกการสร้างหรือโทเค็น CI ไว้ใน URL สาธารณะก็เหมือนกับการทิ้งกุญแจไว้ที่ประตูในยุคปัจจุบัน นี่ก็เป็นอีกหนึ่งคำตอบสำคัญสำหรับคำถามที่ว่า สาเหตุใดต่อไปนี้เป็นสาเหตุทั่วไปของการโจมตี
CI/CD: พื้นผิวการแตกใหม่
CI/CD pipelineปัจจุบันช่องโหว่เหล่านี้เป็นช่องทางโจมตีที่สำคัญ ผู้ไม่ประสงค์ดีใช้ประโยชน์จากงานที่ตั้งค่าไม่ถูกต้อง ไฟล์ YAML ที่อนุญาตมากเกินไป คำขอแก้ไขโค้ดที่ถูกแทรกเข้ามา และขอบเขตการเข้าถึงที่ได้รับสืบทอดมาโดยไม่เคยได้รับการตรวจสอบมาก่อน ช่องโหว่เหล่านี้ pipelineคำสั่งเหล่านี้ทำงานด้วยสิทธิ์ระดับอัตโนมัติ ซึ่งหากถูกบุกรุก อาจแพร่กระจายมัลแวร์ รั่วไหลข้อมูลประจำตัว หรือเปิดเผยข้อมูลสำคัญ การเปลี่ยนแปลงของช่องทางการโจมตีนี้หมายความว่านักพัฒนาต้องประเมินใหม่ว่าอะไรคือการละเมิดข้อมูล CI/CD ยุค.
นอกเหนือจากการตั้งค่าเริ่มต้นแล้ว ประเด็นสำคัญอีกประการหนึ่งคือขอบเขตความไว้วางใจ: pipelineโดยทั่วไปแล้ว โปรแกรมมักจะผสานรวมโค้ดภายนอก เช่น แพ็กเกจโอเพนซอร์ส หรือสคริปต์จากบุคคลที่สาม หากการตรวจสอบความถูกต้องอ่อนแอหรือไม่มีอยู่เลย ก็จะเปิดช่องโหว่ให้เกิดช่องโหว่ได้ การโจมตีห่วงโซ่อุปทานซอฟต์แวร์ตัวอย่างเช่น การติดตั้งส่วนประกอบที่เป็นอันตรายในระหว่างขั้นตอนการสร้าง อาจทำให้ผู้โจมตีเข้าถึงข้อมูลประจำตัวในการลงนามหรือไฟล์ที่ใช้ในกระบวนการผลิตได้
นอกจากนี้ pipelineไฟล์บันทึกการทำงานมักไม่ได้รับการตรวจสอบอย่างเข้มงวดเท่ากับโค้ดแอปพลิเคชัน ไฟล์บันทึกอาจมีข้อมูลลับ สิ่งประดิษฐ์อาจถูกจัดเก็บโดยไม่มีการเข้ารหัส ตัวแปรสภาพแวดล้อมที่มีสิทธิ์สูงอาจคงอยู่ข้ามงานต่างๆ แม้แต่การขาดการแบ่งส่วนการทำงานในขณะรันไทม์ ซึ่งงานที่ถูกบุกรุกสามารถเข้าถึงพื้นที่ทำงานของงานอื่นได้ ก็อาจนำไปสู่การเคลื่อนย้ายภายในระบบได้ pipeline.
วิธีการป้องกันการรั่วไหลของข้อมูลที่มีประสิทธิภาพต้องรวมถึง: pipeline security การทดสอบ การบังคับใช้นโยบายอัตโนมัติ และการจำกัดขอบเขตงาน นักพัฒนาควรปฏิบัติต่อสิ่งเหล่านี้ CI/CD คำจำกัดความต่างๆ เช่น รหัสที่ต้องผ่านการตรวจสอบ การสแกน และการรักษาความปลอดภัยด้านสิทธิ์การเข้าถึง
สุดท้ายก็รักษา. pipelineการให้ความสำคัญกับส่วนประกอบสำคัญในสถาปัตยกรรมซอฟต์แวร์และการรักษาความปลอดภัยอย่างเข้มงวดเช่นเดียวกับตัวแอปพลิเคชันเองนั้นมีความสำคัญอย่างยิ่ง ไม่ใช่แค่ว่าคุณสร้างอะไร แต่เป็นวิธีการสร้างด้วย
กลยุทธ์ที่เน้นการพัฒนาเป็นหลักเพื่อป้องกันการรั่วไหลของข้อมูล
เพื่อให้เข้าใจวิธีการป้องกันการรั่วไหลของข้อมูลจากมุมมองของนักพัฒนา จำเป็นอย่างยิ่งที่จะต้องก้าวข้ามการแก้ไขแบบแก้ปัญหาเฉพาะหน้า และนำมาตรการควบคุมความปลอดภัยมาใช้โดยตรงในขั้นตอนการพัฒนา การรักษาความปลอดภัยแบบ Dev-first หมายถึงการบูรณาการแนวทางการป้องกันในที่ที่นักพัฒนาทำงาน: ในโค้ด ใน CI pipelineและในระบบการจัดการการพึ่งพา
เริ่มต้นด้วยการฝังการตรวจสอบสิทธิ์ลงในการกำหนดค่า CI ของคุณ ใช้ระบบอัตโนมัติในการสแกนคำจำกัดความของเวิร์กโฟลว์เพื่อหาการตั้งค่าที่อนุญาตมากเกินไป และป้องกันการรวมเข้าด้วยกันเว้นแต่จะผ่านทุกขั้นตอน ปฏิบัติตามหลักการของสิทธิพิเศษน้อยที่สุดการดำเนินการเชิงป้องกันนี้เป็นการแก้ไขปัญหาโดยตรงเกี่ยวกับวิธีการป้องกันการรั่วไหลของข้อมูลผ่านการเสริมความแข็งแกร่งของกระบวนการทำงาน
การจัดการความลับ เป็นอีกด้านหนึ่งที่นักพัฒนาต้องควบคุม ควรหลีกเลี่ยงการจัดเก็บข้อมูลประจำตัวหรือโทเค็นในซอร์สโค้ด ควรติดตั้งเครื่องมือตรวจจับความลับในระบบ pre-commit hooks และใช้การตรวจสอบ CI เพื่อตรวจจับข้อผิดพลาดก่อนที่จะเข้าสู่ที่เก็บข้อมูล ควบคู่ไปกับโซลูชันการจัดเก็บความลับ เช่น AWS Secrets Manager หรือ HashiCorp Vault และผสานการหมุนเวียนความลับเข้ากับกระบวนการปรับใช้ของคุณ
สคริปต์ภายใน ไม่ว่าจะเป็น bash, Python หรืออื่นๆ Node.jsควรได้รับการปฏิบัติเสมือนเป็นสินทรัพย์ที่สำคัญ ตรวจสอบการทำงานที่มีความเสี่ยง เช่น การโจมตีแบบ Shell Injection การจัดการไฟล์ที่ไม่ถูกต้อง หรือการใช้ตัวแปรสภาพแวดล้อมที่ไม่ปลอดภัย ใช้เครื่องมือวิเคราะห์แบบคงที่ และบังคับใช้การตรวจสอบโดยเพื่อนร่วมงานสำหรับสคริปต์การทำงานหรือการติดตั้งทั้งหมด
นโยบายการควบคุมการเข้าถึงควรเขียนไว้ดังนี้ โครงสร้างพื้นฐานในรูปแบบโค้ด (IaCเครื่องมือไม่ใช่การกำหนดค่าด้วยตนเองในคอนโซลบนคลาวด์ วิธีนี้ช่วยให้สามารถควบคุมเวอร์ชัน ตรวจสอบได้ และตรวจสอบความถูกต้องโดยอัตโนมัติ เครื่องมืออย่าง AWS IAM Access Analyzer หรือ Open Policy Agent สามารถช่วยตรวจสอบสิทธิ์เหล่านี้ในระดับโค้ดก่อนการปรับใช้ นี่เป็นอีกตัวอย่างหนึ่งของวิธีการป้องกันการรั่วไหลของข้อมูลผ่านการตรวจสอบ IAM ในระดับโค้ด
สุดท้ายนี้ การมองเห็นความสัมพันธ์ระหว่างซอฟต์แวร์ต่างๆ นั้นมีความสำคัญอย่างยิ่ง ผลิต SBOMs โดยอัตโนมัติ เป็นส่วนหนึ่งของกระบวนการสร้างซอฟต์แวร์ของคุณและติดตามอย่างต่อเนื่อง วิธีนี้ช่วยให้ระบุแพ็กเกจที่ไม่ได้รับการดูแลรักษาหรือเป็นอันตรายได้อย่างรวดเร็ว เสริมการสแกนช่องโหว่ด้วยเครื่องมือที่แจ้งเตือนพฤติกรรมที่น่าสงสัย เช่น การเรียกใช้เครือข่ายหรือโค้ดที่ถูกเข้ารหัสในไลบรารีของบุคคลที่สาม
ด้วยการผนวกแนวปฏิบัติดังกล่าวเข้ากับขั้นตอนการทำงานประจำวันของนักพัฒนา คุณไม่เพียงแต่จะตอบคำถามเกี่ยวกับวิธีการป้องกันการรั่วไหลของข้อมูลเท่านั้น แต่ยังช่วยลดอุปสรรคและส่งเสริมพฤติกรรมการเขียนโค้ดที่ปลอดภัยอีกด้วย ความปลอดภัยจะกลายเป็นส่วนขยายตามธรรมชาติของการพัฒนา ไม่ใช่อุปสรรค แนวปฏิบัติทั้งหมดนี้ช่วยลดสาเหตุทั่วไปของการรั่วไหลของข้อมูลได้โดยตรง
การละเมิดข้อมูลในโลกแห่งความเป็นจริงจาก Pipelines และรหัส
- Uber 2022: ผู้โจมตีสามารถเข้าถึงระบบภายในของ Uber ได้หลังจากค้นพบข้อมูลประจำตัว AWS ที่ถูกเขียนไว้ในโค้ดโดยตรง ซึ่งถูกเปิดเผยในที่เก็บ GitHub ส่วนตัว เมื่อเข้าไปได้แล้ว พวกเขาก็สามารถเคลื่อนย้ายไปยังบริการต่างๆ ได้โดยใช้โทเค็นการเข้าถึงที่ใช้ซ้ำและบทบาท IAM ที่กำหนดขอบเขตไม่ชัดเจน กรณีนี้แสดงให้เห็นว่าความผิดพลาดเพียงเล็กน้อยในการเปิดเผยโค้ดสามารถลุกลามไปสู่การถูกโจมตีอย่างเต็มรูปแบบได้อย่างไร และเป็นตัวอย่างที่ชัดเจนของการรั่วไหลของข้อมูลที่เกิดจากความประมาทเลินเล่อในการพัฒนาซอฟต์แวร์ทั่วไป
- Equifaxหนึ่งในเหตุการณ์การละเมิดข้อมูลที่โด่งดังที่สุดในประวัติศาสตร์ Equifax ประสบเนื่องจากล้มเหลวในการแก้ไขช่องโหว่ที่ทราบกันดีใน Apache Struts แม้ว่าหมายเลข CVE จะเป็นสาธารณะ แต่... CI/CD pipeline ขาดกระบวนการสแกนอัตโนมัติและการจัดการแพตช์ ทำให้เกิดช่องโหว่ที่ไม่ได้แก้ไขเป็นเวลาหลายเดือน ผู้โจมตีใช้ช่องโหว่นี้เพื่อเข้าถึงข้อมูลส่วนบุคคลที่ละเอียดอ่อนของคนนับล้าน ซึ่งแสดงให้เห็นว่าสาเหตุใดต่อไปนี้เป็นสาเหตุทั่วไปของการละเมิดในโค้ดเก่า pipelines.
- โคเดคอฟ 2021ผู้ไม่ประสงค์ดีได้แก้ไขสคริปต์อัปโหลด Bash ของ Codecov ซึ่งมีการใช้งานอย่างแพร่หลายในระบบ CI pipelineโดยการแทรกโค้ดเข้าไปในสคริปต์ พวกเขาได้ขโมยตัวแปรสภาพแวดล้อม (ซึ่งมักรวมถึงโทเค็นและข้อมูลประจำตัว) จากสภาพแวดล้อมของลูกค้าหลายพันราย การละเมิดข้อมูลครั้งนี้เน้นให้เห็นถึงความเสี่ยงของการดึงสคริปต์จากแหล่งภายนอกโดยไม่ตรวจสอบความถูกต้อง และให้ข้อมูลเชิงลึกเกี่ยวกับวิธีการป้องกันการรั่วไหลของข้อมูลโดยการตรวจสอบความถูกต้องของส่วนประกอบภายนอก
- SolarWinds: การโจมตีห่วงโซ่อุปทานที่อื้อฉาวนั้นมุ่งเป้าไปที่... CI/CD ระบบของ SolarWinds ผู้โจมตีได้แทรกมัลแวร์เข้าไปในไฟล์สร้างซอฟต์แวร์ Orion ซึ่งจากนั้นได้ถูกแจกจ่ายให้กับลูกค้าในรูปแบบของการอัปเดตที่เชื่อถือได้ การละเมิดข้อมูลครั้งนี้เผยให้เห็นปัญหาที่ร้ายแรงเกี่ยวกับความสมบูรณ์ของไฟล์สร้างซอฟต์แวร์และการขาดการตรวจสอบพฤติกรรมในระหว่างการสร้างไฟล์ ซึ่งเป็นอีกตัวอย่างที่ชัดเจนของการละเมิดข้อมูลที่เกิดขึ้นจากภายในระบบเอง pipeline ตัวเอง
- การใช้ GitHub Actions ในทางที่ผิด: เหตุการณ์หลายครั้งแสดงให้เห็นว่าผู้โจมตีสามารถใช้ประโยชน์จากเวิร์กโฟลว์ GitHub Actions ที่อนุญาตมากเกินไปได้อย่างไร ตัวอย่างเช่น ผู้โจมตีส่ง Pull Request (PR) ที่มีโค้ดที่เป็นอันตรายซึ่งทำงานด้วยสิทธิ์ที่สูงขึ้นเนื่องจากการกำหนดขอบเขตที่ไม่ดี สิทธิ์: กรณีเหล่านี้เน้นย้ำถึงความสำคัญของการแยกงานและการตรวจสอบความถูกต้องของเวิร์กโฟลว์ และแสดงให้เห็นว่าสาเหตุใดต่อไปนี้เป็นสาเหตุทั่วไปของการละเมิดที่เกี่ยวข้องกับการกำหนดค่าความปลอดภัยของ CI ที่ไม่ถูกต้อง
ตัวอย่างในโลกแห่งความเป็นจริงเหล่านี้แต่ละตัวอย่างแสดงให้เห็นว่าสาเหตุใดบ้างที่เป็นสาเหตุทั่วไปของการละเมิดข้อมูล ตั้งแต่ความลับในโค้ดและช่องโหว่ที่ยังไม่ได้รับการแก้ไข ไปจนถึง... pipeline การใช้ในทางที่ผิดและการบิดเบือนความสัมพันธ์ นอกจากนี้ยังเน้นย้ำถึงความเร่งด่วนในการนำมาตรการควบคุมที่แข็งแกร่งมาใช้เป็นส่วนหนึ่งของกลยุทธ์การป้องกันการรั่วไหลของข้อมูลอย่างครอบคลุม
Xygeni ช่วยป้องกันการรั่วไหลของข้อมูลที่เกิดจากนักพัฒนาได้อย่างไร
ไซเกนี ให้เรียลไทม์ pipeline security ด้วยการผสานรวมเข้ากับ GitHub Actions, GitLab CI และ Jenkins โดยตรง มันจะสแกนไฟล์ YAML เพื่อหาค่าเริ่มต้นที่ไม่ปลอดภัย ตรวจสอบขอบเขตสิทธิ์ และตรวจจับข้อมูลลับก่อนที่จะส่งไปยังเครื่องระยะไกล เครื่องมือตรวจสอบ IAM ของมันจะตรวจสอบการใช้งานสิทธิ์จากภายในโค้ดเบส ไม่ใช่แค่ในคอนโซลบนคลาวด์เท่านั้น
สำหรับความสัมพันธ์ระหว่างส่วนประกอบต่างๆ Xygeni นำเสนอการทำงานอย่างต่อเนื่อง SBOM ระบบจะติดตามและแจ้งเตือนแพ็กเกจที่เป็นอันตรายหรือมีช่องโหว่ก่อนที่จะเข้าสู่ระบบการผลิต โดยจะตรวจสอบการใช้งานโทเค็น แจ้งเตือนเมื่อมีการนำโทเค็นกลับมาใช้ใหม่ และ... ระบุการเปิดเผยต่อสาธารณะใน CI/CD สภาพแวดล้อม
กล่าวโดยสรุป Xygeni ช่วยให้สามารถใช้แนวทางที่เน้นนักพัฒนาเป็นหลักในการป้องกันภัยคุกคามจากการรั่วไหลของข้อมูล โดยการตรวจจับปัญหาตั้งแต่เนิ่นๆ และแก้ไขที่ต้นตอของปัญหา นั่นคือในโค้ด ระบบอัตโนมัติของ Xygeni ถูกสร้างขึ้นเพื่อรับมือกับสาเหตุทั่วไปของการรั่วไหลของข้อมูล โดยการตรวจจับค่าเริ่มต้นที่ไม่ปลอดภัยและความเสี่ยงที่ซ่อนอยู่
รหัสที่ปลอดภัย ปลอดภัย Pipelineป้องกันการละเมิด
เพื่อให้เข้าใจอย่างแท้จริงว่าการละเมิดข้อมูลคืออะไร นักพัฒนาต้องมองข้ามไฟร์วอลล์และมุ่งเน้นไปที่โค้ด pipelineและเลเยอร์การเข้าถึง การทำความเข้าใจว่าสาเหตุใดต่อไปนี้เป็นสาเหตุทั่วไปของการละเมิด จะช่วยให้ทีมงานสามารถย้ายการรักษาความปลอดภัยไปทางซ้ายและสร้างความยืดหยุ่นโดยตรงในขั้นตอนการทำงานของตนได้
ไม่ว่าจะผ่านการจัดการการพึ่งพาของไลบรารีที่ดีขึ้น การตรวจสอบสิทธิ์อัตโนมัติ หรือการสแกนข้อมูลลับ เส้นทางสู่การป้องกันการรั่วไหลของข้อมูลเริ่มต้นที่ IDE และ CI ของนักพัฒนา pipelineเครื่องมืออย่าง Xygeni ทำให้เรื่องนี้เป็นไปได้จริงและมีประสิทธิภาพ เปลี่ยน... pipelineเปลี่ยนจุดอ่อนให้กลายเป็นจุดแข็ง ด้วยวิธีนี้ พวกเขาจึงช่วยกำจัดสาเหตุที่พบบ่อยที่สุดของการละเมิดข้อมูลในห่วงโซ่อุปทานซอฟต์แวร์ในปัจจุบัน
