สรุป
ในโมดูลนี้ คุณได้สํารวจว่าการพัฒนาซอฟต์แวร์สมัยใหม่ขึ้นอยู่กับส่วนประกอบโอเพ่นซอร์สและกลยุทธ์ที่เรียนรู้สําหรับการใช้ซอฟต์แวร์โอเพ่นซอร์สในขณะที่จัดการความเสี่ยงด้านความปลอดภัย การทําความเข้าใจแนวคิดเหล่านี้ช่วยให้คุณสามารถใช้ประโยชน์จากโอเพนซอร์สในขณะที่ปกป้ององค์กรของคุณจากหนี้สินที่อาจเกิดขึ้น
ซอฟต์แวร์ที่ทันสมัยถูกสร้างขึ้นอย่างไร
คุณได้เรียนรู้ว่า แอปพลิเคชันร่วมสมัยประกอบขึ้นจากส่วนประกอบ แทนที่จะสร้างขึ้นใหม่ทั้งหมด:
- องค์ประกอบส่วนประกอบ: แอปพลิเคชันสมัยใหม่ประกอบด้วยส่วนประกอบที่มีอยู่ประมาณ 80% ส่วนประกอบที่ได้รับการบํารุงรักษานอกโครงการ โดยมีเพียง 20% เท่านั้นที่เป็นรหัสตรรกะทางธุรกิจดั้งเดิม
- โอเพ่นซอร์สกับโอเพ่นซอร์ส: ส่วนประกอบโอเพนซอร์สให้ซอร์สโค้ดที่เปิดเผยต่อสาธารณะซึ่งทุกคนสามารถตรวจสอบ แก้ไข และแจกจ่ายได้ ในขณะที่ส่วนประกอบโอเพนซอร์สแจกจ่ายเฉพาะไบนารีที่ไม่มีการเข้าถึงแหล่งที่มา
- ระบบนิเวศแพ็คเกจ: ส่วนประกอบถูกแจกจ่ายผ่านตัวจัดการแพ็คเกจ เช่น npm, PyPI, NuGet และ Maven Central ซึ่งทําให้การจัดการการพึ่งพาเป็นไปโดยอัตโนมัติ
- ประโยชน์ของการพัฒนาตามส่วนประกอบ: การนําส่วนประกอบที่ได้รับการพิสูจน์แล้วกลับมาใช้ใหม่ช่วยเร่งการพัฒนาปรับปรุงคุณภาพผ่านการตรวจสอบของชุมชนลดต้นทุนโดยหลีกเลี่ยงค่าธรรมเนียมใบอนุญาตและให้การเข้าถึงนวัตกรรมที่ทันสมัย
- ความเร็วในการพัฒนา: การใช้ส่วนประกอบโอเพนซอร์สช่วยลดเวลาในการออกสู่ตลาดได้อย่างมากโดยอนุญาตให้ทีมมุ่งเน้นไปที่มูลค่าทางธุรกิจที่ไม่เหมือนใครแทนที่จะสร้างโครงสร้างพื้นฐานทั่วไปใหม่
ความกังวลขององค์กรเกี่ยวกับซอฟต์แวร์โอเพ่นซอร์ส
คุณได้ตรวจสอบ ความเสี่ยงที่สําคัญที่องค์กรต้องเผชิญ เมื่อนําส่วนประกอบโอเพนซอร์สมาใช้:
ข้อกังวลด้านความปลอดภัย:
- ช่องโหว่ที่ทราบ: มีการค้นพบช่องโหว่ด้านความปลอดภัยหลายพันรายการในส่วนประกอบโอเพนซอร์สทุกปี ซึ่งจําเป็นต้องมีการตรวจสอบอย่างต่อเนื่องและการแพตช์อย่างรวดเร็ว
- การโจมตีห่วงโซ่อุปทาน: ผู้โจมตีประนีประนอมบัญชีผู้ดูแลแพ็คเกจ ใช้การพิมพ์ผิด หรือใช้ประโยชน์จากความสับสนในการพึ่งพาเพื่อแทรกโค้ดที่เป็นอันตราย
- โครงการที่ไม่ได้บํารุงรักษา: โครงการโอเพ่นซอร์สจํานวนมากขาดการบํารุงรักษาที่ใช้งานอยู่ทําให้ช่องโหว่ไม่ได้รับการแก้ไขเมื่อผู้ดูแลละทิ้งโครงการ
ข้อกังวลด้านคุณภาพและความน่าเชื่อถือ:
- คุณภาพตัวแปร: ส่วนประกอบโอเพ่นซอร์สมีตั้งแต่โครงการที่ได้รับการบํารุงรักษาอย่างมืออาชีพไปจนถึงโค้ดงานอดิเรกที่ผ่านการทดสอบไม่ดี
- การเปลี่ยนแปลงที่ทําลาย: คอมโพเนนต์ไม่ได้จัดลําดับความสําคัญของความเข้ากันได้แบบย้อนหลังเสมอไป ซึ่งจําเป็นต้องมีการเปลี่ยนแปลงโค้ดเมื่ออัปเดต
- ช่องว่างของเอกสาร: เอกสารไม่เพียงพอจะเพิ่มข้อผิดพลาดในการผสานรวมและการใช้งานในทางที่ผิด
ข้อกังวลทางกฎหมายและการออกใบอนุญาต:
- ภาระผูกพันในการปฏิบัติตามใบอนุญาต: ใบอนุญาตโอเพ่นซอร์สแต่ละใบกําหนดข้อกําหนดตั้งแต่การระบุแหล่งที่มาอย่างง่ายไปจนถึงการบังคับโอเพ่นซอร์สของงานลอกเลียนแบบ
- การแพร่กระจาย Copyleft: ใบอนุญาต copyleft ที่แข็งแกร่ง เช่น GPL อาจต้องมีการโอเพ่นซอร์สแอปพลิเคชันทั้งหมดของคุณหากไม่ได้รับการจัดการอย่างระมัดระวัง
- การแพร่กระจายใบอนุญาต: แอปพลิเคชันอาจขึ้นอยู่กับแพ็คเกจหลายร้อยแพ็คเกจที่มีใบอนุญาตที่แตกต่างกันหลายสิบรายการ ซึ่งสร้างภาระการปฏิบัติตามข้อกําหนดที่ซับซ้อน
ข้อกังวลในการดําเนินงาน:
- การพึ่งพาโครงสร้างพื้นฐานภายนอก: แอปพลิเคชันอาศัยการลงทะเบียนแพ็คเกจสาธารณะที่อาจประสบปัญหาการหยุดทํางานหรือการลบแพ็คเกจ
- ภาระการจัดการการอัปเดต: การรักษาการขึ้นต่อกันให้เป็นปัจจุบันต้องใช้ความพยายาม การทดสอบ และการปรับใช้อย่างต่อเนื่อง
ซอฟต์แวร์โอเพ่นซอร์สคืออะไร
คุณได้เรียนรู้ ลักษณะพื้นฐานของซอฟต์แวร์โอเพ่นซอร์ส:
- นิยาม: ซอฟต์แวร์ที่มีซอร์สโค้ดเปิดเผยต่อสาธารณะสําหรับการตรวจสอบ แก้ไข และแจกจ่าย โดยอยู่ภายใต้ใบอนุญาตโอเพ่นซอร์ส
- การพัฒนาร่วมกัน: โครงการโอเพ่นซอร์สเกี่ยวข้องกับผู้มีส่วนร่วมแบบกระจายทั่วโลกที่เข้าร่วมโดยสมัครใจ โดยมีการพัฒนาเกิดขึ้นอย่างโปร่งใสในที่เก็บข้อมูลสาธารณะ
- การยอมรับอย่างแพร่หลาย: องค์กรกว่า 90% ใช้ซอฟต์แวร์โอเพ่นซอร์สในการผลิต และเทคโนโลยีโอเพ่นซอร์สขับเคลื่อนโครงสร้างพื้นฐานอินเทอร์เน็ต แพลตฟอร์มคลาวด์ และอุปกรณ์เคลื่อนที่
- การเปลี่ยนแปลงของ Microsoft: Microsoft เปลี่ยนจากการมองโอเพ่นซอร์สเป็นภัยคุกคามไปสู่การยอมรับอย่างครอบคลุม .NET แบบโอเพ่นซอร์ส มีส่วนร่วมใน Linux และ Kubernetes และสร้างเครื่องมือโอเพ่นซอร์สยอดนิยม เช่น Visual Studio Code และ TypeScript
- เหตุผลเชิงกลยุทธ์: องค์กรเลือกโอเพ่นซอร์สเพื่อประหยัดต้นทุน ความยืดหยุ่นและการควบคุม ความโปร่งใส และความปลอดภัยผ่านการตรวจสอบโค้ด หลีกเลี่ยงการล็อกอินของผู้ขาย การสนับสนุนจากชุมชน และการเข้าถึงนวัตกรรมก่อนใคร
พื้นฐานใบอนุญาตโอเพนซอร์ส
คุณได้สํารวจ ว่าสิทธิ์การใช้งานโอเพนซอร์สควบคุมการใช้ซอฟต์แวร์อย่างไร:
วัตถุประสงค์ของใบอนุญาต:
- กําหนดสิทธิ์: ใบอนุญาตให้สิทธิ์ในการใช้ แก้ไข และแจกจ่ายซอฟต์แวร์ที่กฎหมายลิขสิทธิ์จะห้ามไว้
- กําหนดภาระผูกพัน: ใบอนุญาตต้องมีการระบุแหล่งที่มา การเปิดเผยซอร์สโค้ด การรักษาใบอนุญาต และบางครั้งการปฏิบัติตาม copyleft
- ปฏิเสธความรับผิด: ผู้เขียนไม่ต้องรับผิดต่อความเสียหาย และซอฟต์แวร์มีให้ "ตามที่เป็น" โดยไม่มีการรับประกัน
เกณฑ์คําจํากัดความโอเพ่นซอร์ส:
- แจกจ่ายต่อฟรี: ไม่มีข้อจํากัดในการขายหรือแจกซอฟต์แวร์
- ความพร้อมใช้งานของซอร์สโค้ด: ต้องรวมแหล่งที่มาในรูปแบบที่ต้องการสําหรับการแก้ไข
- ผลงานที่ได้มาที่อนุญาต: ต้องอนุญาตให้ดัดแปลงและลอกเลียนแบบ
- ไม่มีการเลือกปฏิบัติ: ไม่สามารถเลือกปฏิบัติต่อบุคคล กลุ่ม หรือสาขาที่พยายาม
- เทคโนโลยีเป็นกลาง: ไม่สามารถต้องใช้เทคโนโลยีหรืออินเทอร์เฟซเฉพาะได้
ประเภทใบอนุญาต:
- ใบอนุญาตที่อนุญาต: อนุญาตให้รวมโค้ดเข้ากับซอฟต์แวร์ที่เป็นกรรมสิทธิ์โดยมีข้อจํากัดน้อยที่สุด (MIT, Apache 2.0, BSD)
- ใบอนุญาต Copyleft: กําหนดให้งานลอกเลียนแบบใช้ใบอนุญาตเดียวกัน เพื่อให้มั่นใจว่าซอฟต์แวร์ยังคงเป็นโอเพ่นซอร์ส (GPL, AGPL)
- ใบอนุญาต copyleft ที่อ่อนแอ: ต้องมีการปรับเปลี่ยนส่วนประกอบแบบโอเพ่นซอร์ส แต่อนุญาตให้ใช้เป็นกรรมสิทธิ์ (LGPL, MPL)
สิทธิ์การใช้งานโอเพนซอร์สทั่วไป
คุณตรวจสอบใบอนุญาตยอดนิยมและลักษณะสําคัญ:
ใบอนุญาตที่อนุญาต:
- ใบอนุญาต MIT: ใบอนุญาตที่อนุญาตง่ายที่สุดที่ต้องการเพียงการระบุแหล่งที่มาเพิ่มการนําไปใช้และการใช้งานเชิงพาณิชย์
- ใบอนุญาต Apache 2.0: ใบอนุญาตที่อนุญาตพร้อมการให้สิทธิบัตรที่ชัดเจนและการยุติการป้องกัน ให้ความชัดเจนของสิทธิบัตร
- ใบอนุญาต BSD: คล้ายกับ MIT โดยมี BSD 3 ข้อเพิ่มข้อจํากัดการใช้ชื่อสําหรับการคุ้มครองเครื่องหมายการค้า
ใบอนุญาต copyleft ที่แข็งแกร่ง:
- GPL v2 และ v3: กําหนดให้งานลอกเลียนแบบต้องได้รับอนุญาต GPL และแจกจ่ายซอร์สโค้ดด้วยไบนารี GPL v3 เพิ่มการคุ้มครองสิทธิบัตรและการปรับปรุงความเข้ากันได้ระหว่างประเทศ
- เอจีพีแอล: ขยาย GPL v3 ด้วยข้อกําหนดการใช้งานเครือข่ายที่กําหนดให้มีการเปิดเผยแหล่งที่มาสําหรับข้อเสนอ SaaS
ใบอนุญาต copyleft ที่อ่อนแอ:
- แอลจีพีแอล: อนุญาตให้เชื่อมโยงไปยังไลบรารีจากแอปพลิเคชันที่เป็นกรรมสิทธิ์ในขณะที่ต้องมีการแก้ไขไลบรารีเองให้เป็นโอเพ่นซอร์ส
- เอ็มพีแอล 2.0: ให้ copyleft ระดับไฟล์ โดยกําหนดให้มีการเปิดเผยแหล่งที่มาสําหรับไฟล์ที่ได้รับอนุญาต MPL เท่านั้น ไม่ใช่รหัสที่เป็นกรรมสิทธิ์ในแอปพลิเคชันเดียวกัน
ความเข้ากันได้ของใบอนุญาต:
- ชุดค่าผสมที่เข้ากันได้: MIT + Apache 2.0, MIT + GPL v3, Apache 2.0 + GPL v3, LGPL + GPL.
- ชุดค่าผสมที่เข้ากันไม่ได้: GPL v2 + Apache 2.0, GPL + กรรมสิทธิ์, ใบอนุญาต copyleft ที่แตกต่างกันรวมกัน
ผลกระทบของใบอนุญาตและการให้คะแนนความเสี่ยง
คุณได้เรียนรู้วิธี ประเมินความเสี่ยงของใบอนุญาตและใช้การปฏิบัติตามข้อกําหนด:
กรอบความเสี่ยงใบอนุญาต:
- ความเสี่ยงต่ํา (สีเขียว): ใบอนุญาตที่อนุญาต เช่น MIT, BSD, Apache 2.0 นั้นปลอดภัยสําหรับการใช้งานเชิงพาณิชย์
- ความเสี่ยงปานกลาง (สีเหลือง): ใบอนุญาต copyleft ที่อ่อนแอ เช่น LGPL, MPL อนุญาตให้ใช้กรรมสิทธิ์โดยมีข้อจํากัดในการปรับเปลี่ยน
- ความเสี่ยงสูง (สีแดง): ใบอนุญาต copyleft ที่แข็งแกร่ง เช่น GPL, AGPL เข้ากันไม่ได้กับการแจกจ่ายซอฟต์แวร์ที่เป็นกรรมสิทธิ์
- ความเสี่ยงที่ไม่ทราบ (สีส้ม): ใบอนุญาตที่กําหนดเองหรือไม่ชัดเจนต้องมีการตรวจสอบทางกฎหมายก่อนใช้งาน
ความหมายของซอฟต์แวร์เชิงพาณิชย์:
- ใบอนุญาตที่อนุญาต: เปิดใช้งานการแจกจ่ายที่เป็นกรรมสิทธิ์โดยมีข้อกําหนดการระบุแหล่งที่มาเท่านั้น
- copyleft ที่อ่อนแอ: อนุญาตให้ใช้ไลบรารีในแอปพลิเคชันที่เป็นกรรมสิทธิ์ แต่ต้องมีการปรับเปลี่ยนไลบรารีแบบโอเพ่นซอร์ส
- copyleft ที่แข็งแกร่ง: ต้องการงานลอกเลียนแบบโอเพ่นซอร์ส ทําให้เข้ากันไม่ได้กับซอฟต์แวร์ที่เป็นกรรมสิทธิ์
ข้อควรพิจารณาเกี่ยวกับทรัพย์สินทางปัญญา:
- การคุ้มครองทรัพย์สินทางปัญญาที่เป็นกรรมสิทธิ์: ใบอนุญาตที่อนุญาตรักษารหัสกรรมสิทธิ์ ใบอนุญาต copyleft ต้องมีการเปิดเผย
- บทบัญญัติสิทธิบัตร: Apache 2.0 และ GPL v3 รวมถึงการให้สิทธิบัตรที่ชัดเจน MIT/BSD ขาดความชัดเจนของสิทธิบัตร
- การสูญเสียความลับทางการค้า: การเปิดเผยซอร์สโค้ดช่วยขจัดการป้องกันความลับทางการค้า
การดําเนินการตามข้อกําหนด:
- พื้นที่โฆษณาการพึ่งพา: รักษารายการวัสดุที่ครอบคลุมเพื่อติดตามส่วนประกอบและเวอร์ชันโอเพนซอร์สทั้งหมด
- การตรวจสอบความเข้ากันได้ของใบอนุญาต: ใช้เครื่องมืออัตโนมัติเพื่อระบุความเข้ากันไม่ได้ของสิทธิ์การใช้งาน
- การปฏิบัติตามข้อกําหนดการระบุแหล่งที่มา: สร้างไฟล์การรวมสิทธิ์การใช้งาน รวมไว้ในกล่องโต้ตอบเกี่ยวกับ และบํารุงรักษาในเอกสารประกอบ
- การจัดเตรียมซอร์สโค้ด: สําหรับใบอนุญาต copyleft ให้ระบุซอร์สโค้ดที่สมบูรณ์พร้อมคําแนะนําในการสร้าง
ความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์:
- การสแกนช่องโหว่: สแกนการพึ่งพาอย่างต่อเนื่องเพื่อหาช่องโหว่ที่รู้จักโดยใช้เครื่องมือเช่น Snyk, Dependabot หรือ WhiteSource
- การบรรเทาการโจมตีห่วงโซ่อุปทาน: ตรวจสอบลายเซ็นแพ็คเกจ ชอบแหล่งที่มีชื่อเสียง ใช้รีจิสทรีส่วนตัว และเวอร์ชันการพึ่งพาพิน
- การประเมินคุณภาพ: ประเมินสถานะการบํารุงรักษา ขนาดชุมชน คุณภาพเอกสาร และแนวทางปฏิบัติด้านความปลอดภัย
นโยบายองค์กร:
- เวิร์กโฟลว์การอนุมัติ: ใช้การประเมินก่อนใช้งานเพื่อความปลอดภัย การให้สิทธิ์การใช้งาน และคุณภาพก่อนที่จะนําการขึ้นต่อกันใหม่มาใช้
- รายการแพ็คเกจที่ได้รับอนุมัติ: รักษารายการส่วนประกอบที่ผ่านการตรวจสอบไว้ล่วงหน้าซึ่งนักพัฒนาสามารถใช้ได้ทันที
- การศึกษาสําหรับนักพัฒนา: ฝึกอบรมนักพัฒนาเกี่ยวกับผลกระทบของสิทธิ์การใช้งาน แนวทางปฏิบัติด้านความปลอดภัย และกระบวนการปฏิบัติตามข้อกําหนด
- การตรวจสอบอย่างต่อเนื่อง: ติดตามการอัปเดตการพึ่งพา การเปลี่ยนแปลงใบอนุญาต และการเปิดเผยช่องโหว่
ประเด็นสำคัญ
เมื่อคุณใช้ซอฟต์แวร์โอเพนซอร์สในองค์กรของคุณ ให้จําหลักการสําคัญเหล่านี้:
เปิดรับโอเพ่นซอร์สอย่างมีกลยุทธ์: โอเพ่นซอร์สให้ประโยชน์มหาศาล รวมถึงความเร็วในการพัฒนา คุณภาพ การประหยัดต้นทุน และการเข้าถึงนวัตกรรม แทนที่จะหลีกเลี่ยงโอเพ่นซอร์สเนื่องจากความเสี่ยง ให้ใช้กระบวนการกํากับดูแลที่ช่วยให้สามารถนําไปใช้ได้อย่างปลอดภัย
รู้จักการพึ่งพาของคุณ: รักษาสินค้าคงคลังที่ครอบคลุมของส่วนประกอบโอเพนซอร์สทั้งหมดรวมถึงการพึ่งพาแบบสับเปลี่ยน คุณไม่สามารถจัดการความเสี่ยงที่คุณไม่รู้ได้ ทําให้การมองเห็นการพึ่งพาเป็นรากฐานของการจัดการโอเพนซอร์สที่มีประสิทธิภาพ
ทําความเข้าใจผลกระทบของใบอนุญาต: ใบอนุญาตที่แตกต่างกันมีนัยยะที่แตกต่างกันอย่างมากสําหรับซอฟต์แวร์เชิงพาณิชย์ ใบอนุญาตที่อนุญาตเช่น MIT นั้นปลอดภัยสําหรับซอฟต์แวร์ที่เป็นกรรมสิทธิ์ ใบอนุญาต copyleft เช่น GPL ต้องการงานลอกเลียนแบบโอเพ่นซอร์ส จับคู่การเลือกสิทธิ์การใช้งานกับโมเดลธุรกิจของคุณ
ประเมินความเข้ากันได้ของสิทธิ์การใช้งาน: ตรวจสอบว่าสิทธิ์การใช้งานของส่วนประกอบต่างๆ สามารถรวมกันได้ตามกฎหมาย สิทธิ์การใช้งานที่เข้ากันไม่ได้อาจสร้างปัญหาทางกฎหมายที่ต้องได้รับการแก้ไขที่มีค่าใช้จ่ายสูง รวมถึงการเปลี่ยนส่วนประกอบหรือการเขียนโค้ดใหม่
ใช้การปฏิบัติตามข้อกําหนดอัตโนมัติ: การติดตามสิทธิ์การใช้งานด้วยตนเองไม่ได้ปรับขนาดให้เข้ากับแอปพลิเคชันสมัยใหม่ที่มีการขึ้นต่อกันหลายร้อยรายการ ใช้เครื่องมืออัตโนมัติสําหรับการสแกนการขึ้นต่อกัน การตรวจจับใบอนุญาต และการตรวจสอบช่องโหว่
จัดลําดับความสําคัญของความปลอดภัย: ช่องโหว่ด้านความปลอดภัยในการขึ้นต่อกันส่งผลกระทบต่อแอปพลิเคชันของคุณไม่ว่าจะมาจากที่ใด ใช้การสแกนช่องโหว่อย่างต่อเนื่องและสร้างกระบวนการอัปเดตอย่างรวดเร็วสําหรับแพตช์ความปลอดภัยที่สําคัญ
จัดการความเสี่ยงของห่วงโซ่อุปทาน: นอกเหนือจากช่องโหว่ที่ทราบแล้ว ให้ป้องกันการโจมตีห่วงโซ่อุปทานผ่านการตรวจสอบแพ็คเกจ การประเมินชื่อเสียงของแหล่งที่มา การลงทะเบียนส่วนตัว และการปักหมุดการพึ่งพา
ควบคุมสมดุลด้วยอิสระ: นักพัฒนาต้องการอิสระในการใช้เครื่องมือและเฟรมเวิร์กที่ทันสมัย แทนที่จะบล็อกการนําโอเพนซอร์สไปใช้ ให้ใช้เวิร์กโฟลว์การอนุมัติและรายการแพ็คเกจที่ได้รับอนุมัติซึ่งช่วยให้ใช้งานได้อย่างปลอดภัย
ให้ความรู้แก่ทีมของคุณ: ความตระหนักของนักพัฒนาเกี่ยวกับข้อกังวลด้านใบอนุญาตและความปลอดภัยเป็นสิ่งสําคัญ โปรแกรมการฝึกอบรมช่วยให้นักพัฒนาตัดสินใจได้ดีเกี่ยวกับการเลือกส่วนประกอบและเข้าใจนโยบายขององค์กร
ตรวจสอบอย่างต่อเนื่อง: การจัดการโอเพนซอร์สไม่ใช่กิจกรรมแบบครั้งเดียว ช่องโหว่ใหม่ๆ ถูกเปิดเผยอย่างต่อเนื่อง บางครั้งใบอนุญาตก็เปลี่ยนแปลง และโครงการอาจถูกละทิ้งได้ การตรวจสอบอย่างต่อเนื่องช่วยให้มั่นใจได้ถึงการปฏิบัติตามข้อกําหนดและความปลอดภัยอย่างต่อเนื่อง
ด้วยการใช้หลักการเหล่านี้และใช้แนวทางปฏิบัติในการจัดการโอเพนซอร์สอย่างเป็นระบบ จะช่วยให้องค์กรของคุณสามารถใช้ประโยชน์จากประโยชน์มหาศาลของซอฟต์แวร์โอเพนซอร์ส ในขณะที่จัดการความเสี่ยงด้านความปลอดภัย กฎหมาย และการดําเนินงานได้อย่างมีประสิทธิภาพ