ชีวิตหลังเปิดตัว: ส่วนของซอฟต์แวร์ที่ไม่มีใครตั้งงบไว้

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

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

ส่วนใหญ่ของซอฟต์แวร์คุณ คุณไม่ได้เขียนเอง และนั่นคือปัญหา

เว็บแอปสมัยใหม่ส่วนใหญ่คือโค้ดของคนอื่น ส่วนใหญ่ของแอปทั่วไปคือ dependencies, frameworks, libraries แบบ open-source และ library ที่ library พวกนั้นดึงตามมาอีกที ข้อมูลจากรายงาน 2024 State of the Software Supply Chain พบว่า 86% ของโค้ดเบสองค์กรมีคอมโพเนนต์ open-source ที่มีช่องโหว่อย่างน้อยหนึ่งตัว และมากกว่าเก้าในสิบโค้ดเบสมีคอมโพเนนต์ที่เก่าล้าหลังไปหลายปี

dependencies เหล่านี้ไม่ได้อยู่นิ่ง มันออก security patch แก้บั๊ก และบางครั้งก็มีการเปลี่ยนแปลงที่ทำให้ของเดิมพัง ข้าม update ไปสักปี คุณก็ไม่ได้รันซอฟต์แวร์ที่เสร็จสมบูรณ์และเสถียร แต่กำลังรันของในพิพิธภัณฑ์ที่ผู้โจมตีมีแผนที่อยู่ในมือแล้ว เฉพาะช่วงปลายปี 2024 มีการค้นพบ malicious package ราว 14,000 ตัวใน registry ยอดนิยม เพิ่มขึ้นมากในปีเดียว supply chain ที่คุณรับมาตอนเปิดตัวเคลื่อนไหวตลอด ไม่ว่าคุณจะมองมันหรือไม่

เวลาเดินเร็วกว่าที่คุณคิด

นี่คือจังหวะเวลาที่น่าอึดอัด ค่ามัธยฐานของเวลาที่ผู้โจมตีใช้เจาะช่องโหว่ที่เพิ่งถูกเปิดเผย ลดลงเหลือราวหนึ่งวันในปี 2024 ขณะที่องค์กรโดยเฉลี่ยใช้เวลาราว 58 วันในการแก้ไข และในบางอุตสาหกรรมการแก้ช่องโหว่ระดับวิกฤตยืดยาวเกิน 130 วัน อ่านสองตัวเลขนี้ด้วยกัน ผู้โจมตีเคลื่อนไหวใน 24 ชั่วโมง ฝ่ายป้องกันใช้สองเดือน ช่องว่างนั้นคือที่ที่การถูกเจาะระบบอาศัยอยู่ และมันกว้างขึ้นทุกวันที่ระบบถูกปล่อยทิ้งไว้

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

การละเลยมีต้นทุนเท่าไหร่จริง ๆ

ค่าใช้จ่ายของการเพิกเฉยต่อทั้งหมดนี้ไม่ใช่เรื่องในทฤษฎี ระบบล่มเพียงหนึ่งชั่วโมงมีต้นทุนสูงสำหรับองค์กรขนาดกลางและใหญ่ และสำหรับหลายองค์กรต้นทุนอยู่ในระดับหลายล้าน การล่มส่วนใหญ่ไม่ใช่การโจมตีที่ดราม่า แต่คือ certificate หมดอายุ library ที่ไม่ได้ patch จนทนไม่ไหว หรือ dependency ที่ขัดแย้งกันโดยไม่มีใครคอยดู

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

ที่ True Dev เรามองเรื่องนี้อย่างไร

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

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