กระทรวงกลาโหมมีคำแนะนำเกือบ 90 หน้าที่กำหนด DevSecOps สำหรับ DoD เมื่อเร็วๆ นี้ บริษัทที่ปรึกษาภาครัฐของ Red Hat ได้นำคำแนะนำนี้ไปใช้และพัฒนา REDSORD ซึ่งเป็นการนำอ้างอิงของ DoD Enterprise DevSecOps Reference Design REDSORD มาจากคำถามภายใน “แทนที่จะเป็นชุดไฟฉายที่สร้างขึ้นเอง แนวทางบริการ ‘ไฟฉายพร้อมแบตเตอรี่’ จะเป็นอย่างไรสำหรับลูกค้าของ DoD เพื่อช่วยให้บรรลุแนวทางของ DoD DevSecOps
“เมื่อหลายคนนึกถึงปัญหาของ DevSecOps พวกเขาคิดในแง่ของชุดเครื่องมือ
เรากำลังเปลี่ยนกระบวนทัศน์นั้นและคิดถึงเวิร์กโฟลว์เป็นอันดับแรก” บิล เบนซิง สถาปนิกผู้จัดการของ Red HatⓇ Software Factory กล่าว “ทำไม? มันเป็นปัญหาของป่าทะลุต้นไม้ แนวทางแรกสำหรับเวิร์กโฟลว์จะระบุพฤติกรรมขององค์กรและผลลัพธ์ที่คาดหวังเพื่อกำหนดคุณภาพ เวิร์กโฟลว์ประมวลและบังคับใช้พฤติกรรมและผลลัพธ์เหล่านี้เพื่อให้แน่ใจว่าทุกแง่มุมของการรักษาความปลอดภัย การปฏิบัติตามข้อกำหนด ความไว้วางใจ และความเป็นส่วนตัวได้รับการระบุ เครื่องมือและเครื่องมือถูกเลือกเพื่อใช้เวิร์กโฟลว์ แนวทางของเราทำให้มั่นใจได้ว่าเครื่องมือจะไม่เป็นปัจจัยจำกัดการเดินทางขององค์กรไปสู่วัฒนธรรม DevSecOps ผลข้างเคียงที่ดีบางประการของแนวทางเวิร์กโฟลว์อันดับแรกคือทำให้สิ่งที่ครั้งหนึ่งเคยยาก เช่น ความสามารถในการตรวจสอบตามเวลาจริงสำหรับผู้มีอำนาจดำเนินการง่ายขึ้น
การเปลี่ยนแปลงของ DevSecOps เริ่มต้นด้วยการพิจารณาในส่วนของ DoD องค์กรต้องเข้าใจสิ่งที่ทำและไม่เข้าใจเกี่ยวกับ DevSecOps องค์กรจำเป็นต้องมีวิสัยทัศน์ และจำเป็นต้องทราบพื้นฐานที่เริ่มต้น ทั้งหมดที่จำเป็นก่อนที่จะรู้ว่าจะไปที่ไหนต่อไป
Bensing กล่าวว่าแม้จะมีขนาดและความแปรปรวนภายใน DoD และส่วนประกอบที่แตกต่างกันทั้งหมด แต่ก็มีประเด็นทั่วไปบางประการ การกำจัด “กำแพงแห่งความสับสน” นั้นตามที่อ้างถึงใน DevOps นั้นมีแนวโน้มที่จะเป็นจุดเริ่มต้น นั่นเป็นคำถามเกี่ยวกับวิธีนำองค์กรแบบแยกส่วนแบบดั้งเดิมมารวมเข้าด้วยกันอย่างเหมาะสม แต่นั่นคือการเปลี่ยนแปลงทางวัฒนธรรมมากกว่าสิ่งอื่นใด และองค์กรต่างๆ มักจะมองหาโซลูชันทางเทคโนโลยีก่อนที่จะมองหาวัฒนธรรมของตนเอง
“ผู้คนมักให้ความสำคัญกับเครื่องมือ และนั่นคือจุดที่พวกเขาจมดิ่งลงไป
เป็นเรื่องปกติที่องค์กรจะหมกมุ่นอยู่กับการทะเลาะเบาะแว้งทางศาสนาที่ใช้เครื่องมือเหล่านี้ ซึ่งทำให้ภาพรวมของพฤติกรรมและผลลัพธ์ของ DevSecOps ที่คาดหวังนั้นคลุมเครือมาก” Bensing กล่าว “ไม่สำคัญว่าเครื่องมือนั้นคืออะไร ขั้นตอนการทำงานเป็นสิ่งสำคัญที่สุด เป็นกฎ นโยบาย และวิธีการที่กำหนดวิธีที่เราได้รับจากแนวคิดไปสู่การผลิต นั่นเป็นเหตุผลที่เราสร้าง
เรดซอร์ด REDSORD ช่วยให้ DoD เปิดใช้งาน เร่งความเร็ว และบังคับใช้กระบวนการและพฤติกรรมที่คาดหวังสำหรับการพัฒนาซอฟต์แวร์และปรับใช้เพื่อเปิดใช้งานวัฒนธรรม DoD DevSecOps เครื่องมือเป็นเพียงรายละเอียดการใช้งาน”
และเป้าหมายของระบบอัตโนมัติคือการขจัดความเป็นตัวตนและความแปรปรวนที่นำไปสู่ความแปรปรวนด้านคุณภาพที่เกิดจากการปฏิสัมพันธ์ของมนุษย์ แต่นั่นถือว่าองค์กรเริ่มต้นด้วยแนวทางปฏิบัติร่วมกันตั้งแต่แรก และการกำหนดมาตรฐานอาจเป็นปัญหาสำหรับองค์กรซอฟต์แวร์หลายแห่ง
“ระบบจะดูเวิร์กโฟลว์ของคุณและประเมินพฤติกรรมที่สำคัญเหล่านั้นสำหรับคุณภาพ ฟังก์ชันการทำงาน และการตรวจสอบการปฏิบัติตามข้อกำหนดที่คุณต้องการเพื่อนำซอฟต์แวร์ของคุณจากแนวคิดไปสู่การผลิต การสร้างและการทดสอบอัตโนมัติเป็นเดิมพันสำหรับ DevSecOps มันเกี่ยวกับการปฏิบัติตามข้อกำหนดโดยอัตโนมัติและการสแกนช่องโหว่ระหว่างเวลาสร้างและรันไทม์ เป็นเรื่องเกี่ยวกับการตรวจสอบการปรับใช้งานโดยอัตโนมัติเพื่อให้แน่ใจว่าซอฟต์แวร์ได้รับการปรับใช้ตามที่คาดไว้ มันเกี่ยวกับการสร้างที่มาและการตรวจสอบข้อมูลทางประวัติศาสตร์เพื่อให้แน่ใจว่ามีความโปร่งใสอย่างสมบูรณ์ เบ็นซิ่งระบุ “DevSecOps ต้องการให้เรายอมรับกฎชุดใหม่เพื่อดำเนินการ ชุดกฎเดิมคือ ‘ให้ผู้เชี่ยวชาญโดเมนของคุณทำการตรวจสอบด้วยตนเอง’ ในขณะที่ชุดกฎใหม่คือ ‘ให้ผู้เชี่ยวชาญโดเมนของคุณเข้ารหัสการตรวจสอบเพื่อให้ระบบอัตโนมัติสามารถดำเนินการตรวจสอบได้แบบเรียลไทม์ ‘ ทรัพย์สินที่ใหญ่ที่สุดของระบบอัตโนมัติกำลังขจัดความแปรปรวนออกจากกระบวนการโดยนำแนวทางเดิมมาใช้ใหม่ ด้วยวิธีเดิมทุกครั้ง ซึ่งส่งผลให้ประหยัดเวลา เพราะตอนนี้สิ่งที่ครั้งหนึ่งเคยเป็นกระบวนการแบบแมนนวลที่ใช้เวลานานเนื่องจากการรอคิวเป็นหลัก เพียงแค่รอให้ใครสักคนทำการตรวจสอบ ตอนนี้เกือบจะเป็นเรียลไทม์แล้ว นี่คือวิธีที่คุณมั่นใจได้ว่าซอฟต์แวร์คุณภาพสูงสุดออกสู่ตลาดโดยใช้เวลาน้อยที่สุด
