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

ปฏิเสธไม่ได้เลยว่าแหล่งข้อมูล สำหรับนักพัฒนานั้นกำลังถูกโจมตีโดยผู้ประสงค์ร้ายซึ่งตระหนักอยู่เต็มอกว่าแค่การจดชื่อโดเมนเนมแบบสะกดผิดๆ แบบง่ายๆ ก็สามารถแจกจ่ายโค้ดแบบพังๆ ไปยังโปรเจ็กต์นับพันทั่วโลกได้แล้ว แต่เหตุการณ์ที่ซัพพลายเชนต้องเผชิญกับมัลแวร์แบบรุนแรงส่วนใหญ่นั้นมักไม่มีการแจ้งรายงาน ซึ่งก็อาจเพราะว่ามีจำนวนมากจนนับไม่ถ้วน การสแกนอย่างต่อเนื่องโดยผู้ให้บริการความปลอดภัยไซเบอร์สำหรับซัพพลายเชน OSS ชื่อ Sonatype พบ 102,930 เหตุการณ์ที่เป็นอันตรายหรืออาจเป็นอันตรายของโค้ดทั่วระบบนิเวศ npm โดยเมื่อผสานเข้ากับไปป์ไลน์การพัฒนาแล้ว แอปพลิเคชันที่เป็นภัยเหล่านี้จะเข้าสู่ขั้นตอน QA, การทดสอบ หรือแม้แต่การผลิตได้ง่ายๆ จากนั้นก็สามารถล้วงข้อมูลยืนยันตัวตนบนคลาวด์ ควบคุมรอบการทำงานของโปรเซสเซอร์เพื่อทำเหมืองคริปโต เจาะที่อยู่ IP ของบริษัท และกิจกรรมอื่นๆ ที่ไม่พึงประสงค์ที่พบได้บ่อยๆ อีกนับไม่ถ้วนจากมัลแวร์

ชุมชนนักพัฒนาได้โพสต์แหล่งข้อมูลและโค้ดเพื่อให้สาธารณชนทั่วไปใช้งาน ตั้งแต่มีประเด็นกรรมสิทธิ์ UIX ที่กลายเป็นฟางเส้นสุดท้ายที่เกิดจากการที่นำ Linux kernel เวอร์ชันแรกๆ มาใช้ ถึงแม้อุดมคติของ OSS (Open Source Software หรือซอฟต์แวร์โอเพ่นซอร์ส) จะยังคงอยู่ต่อไปเพราะประโยชน์ที่ เหลือคณานับ มากมายสำหรับนักพัฒนาและซอฟต์แวร์ทั้งหมด แต่ตัวกลางในการส่งมอบคุณประโยชน์ที่ว่านั้นกลับกำลังถูกองค์ประกอบมุ่งร้ายเข้าครอบงำ นี่เป็นด้านมืดของพฤติกรรมมนุษย์และคงหลีกเลี่ยงไม่ได้ นอกเสียจากว่าทุกโปรเจ็กต์จะถูกเขียนอยู่ใหม่ตั้งแต่แรกเริ่มโดยไม่มีการอ้างอิงถึงไลบราลี่ เฟรมเวิร์ก หรือโค้ดที่ใช้ร่วมกันเลย

องค์กรต่างๆ ได้แก้ไขปัญหาความปลอดภัยและการควบคุมคุณภาพหลายๆ ปัญหาด้วยการสร้างคลังของตัวเองที่ประกอบด้วยองค์ประกอบ “ที่ผ่านการอนุมัติแล้ว” สำหรับใช้ภายใน หรืออย่างน้อยๆ ก็เป็นการยืนยันความปลอดภัยของแพ็กเกจทั้งหมดที่เข้ามาในไปป์ไลน์ CI/CD ของตน การควบคุมนั้นเรียกได้ว่าเป็นข้อดีสำหรับการผลิตซอฟต์แวร์โดยรวม ซึ่งรวมถึงการควบคุมเวอร์ชันและการเข้ากันได้, อัตราความละเอียดของ Dependency, การทำงานอัตโนมัติของ CI/CD และผลิตที่ค่อนข้างง่ายของ BOM (Bills of Material หรือ รายการส่วนประกอบหรือสูตรการผลิต) ทั้งหมดสำหรับแอปพลิเคชันใดๆ ก็ตาม และนี่เป็นเพียงตัวอย่างส่วนหนึ่งเท่านั้น คลังส่วนตัวของบริษัทนั้นเริ่มกลายเป็นส่วนสำคัญที่ขาดไม่ได้ในการบริหารการเปลี่ยนแปลง การพัฒนาใหม่ และทุกสิ่งที่เกี่ยวข้องอย่างรวดเร็ว แต่ก็แน่นอนว่า การบริหารจัดการด้านความปลอดภัยของแหล่งข้อมูลเช่นนี้ต้องอาศัยการทำงานที่ซับซ้อนซึ่งต้องใช้ทรัพยากรบุคคล (ค่าแรงสูง) ตามไปด้วย

Source: Shutterstock

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

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

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

Sonatype

ตัวเลขที่ยกมาข้างต้น (แพ็กเกจที่มุ่งร้าย 192,000+ ที่แพร่กระจายอยู่ทั่วไป) ถูกรวบรวมโดยนักวิเคราะห์พฤติกรรมและการสแกนความปลอดภัยอัตโนมัติ Nexus Firewall จาก Sonatype นี่เป็นวิธีที่แผนกพัฒนาขององค์กรจะสามารถปกป้องตัวเองจากความเสี่ยงต่างๆ อาทิจากกรณีเหตุการณ์ Log4J ซึ่งยังส่งผลกระทบอยู่จนถึงทุกวันนี้ โดย SCA (Software Composition Analysis หรือการวิเคราะห์องค์ประกอบซอฟต์แวร์) เป็นกระบวนการที่องค์กรสามารถนำไปใช้เพื่อประเมินความปลอดภัยขององค์ประกอบซอฟต์แวร์ จัดการเวอร์ชัน ช่วยลดปัญหา Dependency และดูแลจัดการประเภทการให้สิทธิ์ใช้งานต่างๆ เป็นไปอย่างถูกต้อง

Nexus Firewall จะทำการ quarantine (และปล่อยออก หลังตรวจสอบแล้ว) ส่วนประกอบ ต่างๆ ที่ดาวน์โหลดมา เพื่อให้บริษัทสามารถควบคุมได้อย่างเต็มที่ว่าอะไรบ้างที่อนุญาตให้เข้าสู่ SDLC (Software Development Lifecycle หรือ วงจรชีวิตการพัฒนาซอฟต์แวร์) สามารถปรับนโยบายให้เบาลงตามความต้องการ และสามารถใส่ระดับการควบคุมโดยอิงตามความนิยม อายุ แหล่งที่มา เวอร์ชัน และสิทธิ์การใช้งานของแพ็กเกจหรือไลบราลี่ได้ (โดยสิทธิ์การใช้งานยังมีประโยชน์ในการช่วยให้แน่ใจว่าจะไม่มีการละเมิดที่อาจกลายเป็นปัญหาทางกฎหมายในภายหลังอีกด้วย)

Source: Shutterstock

นักพัฒนาจะสามารถใช้ได้เฉพาะองค์ประกอบที่ปลอดภัยภายในขอบเขตเวอร์ชันที่กำหนดไว้เท่าน้น ทำให้ตัวเลือกของเวอร์ชันน้อยลงและการละเมิด Dependency ลดลงด้วย เวอร์ชันใหม่จะถูกบล็อกโดยค่าเริ่มต้น จนกว่าจะได้รับการตรวจสอบและปล่อยออกมาโดยคลังของตน ไม่ว่าจะเป็น Nexus Repository หรือ JFrog Artifactory Enterprise

Nexus Firewall นั้นยังรองรับหลายภาษา (Java, JS, Ruby, .NET, Python, Go) จึงเป็นวิธีที่ดีที่สุดในการยกระดับไปสู่เป้าหมายการผสานรวมการรักษาความปลอดภัย การดำเนินงาน และการพัฒนา หรือ DevSecOps ที่ใครๆ ก็มักจะกล่าวถึง หากต้องการข้อมูลเพิ่มเติม ดูราคา และแหล่งข้อมูลที่เฉพาะเจาะจง โปรดนัดหมายการสาธิตกับ Sonatype

Qualys

Qualys เป็นที่รู้จักกันดีในฐานะผู้ให้บริการด้านความปลอดภัยของข้อมูลและการปฏิบัติตามสำหรับโซลูชันการพัฒนา โดยสามารถทำงานร่วมกันได้ดีกับแพลตฟอร์ม CI/CD ที่ใช้กันทั่วไป เช่น Jenkins และ Puppet ทั้งยังสามารถเชื่อมต่อเข้ากับแพลตฟอร์ม SIEM ยอดนิยม เช่น Splunk ได้อีกด้วย

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

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

อ่านข้อมูลเพิ่มเติมที่นี่เกี่ยวกับโซลูชันการรักษาความปลอดภัย DevOps โดย Qualys

Micro Focus

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

Micro Focus Fortify ช่วยมอบความสามารถให้บริษัทต่างๆ สามารถย้อนกลับผ่านแต่ละขั้นตอนของ CI/CD ที่มีอยู่เดิมเพื่อให้วิศวกรสามารถตรวจสอบความปลอดภัยในแต่ละขั้นตอนของ SDLC ได้ดีขึ้น

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

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

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

คลิกที่นี่เพื่อดูเพิ่มเติมว่า Micro Focus Fortify สามารถช่วยให้องค์กรต่างๆ รักษาความปลอดภัยซอฟต์แวร์ซัพพลายเชนได้อย่างไร