โปรแกรมเมอร์ที่มีประสบการณ์สักหน่อยคงเข้าใจได้ไม่ยากว่าซอฟต์แวร์ที่ไม่มีบั๊กนั้นแทบไม่มีจริงอยู่ในโลก หนังสือ Code Complete ของ Steve McConnell ระบุว่าโดยทั่วไปแล้วโค้ดทุกๆ 1000 บรรทัด (KLOC: kilo lines of code) จะมีข้อผิดพลาดประมาณ 15-50 จุด ซอฟต์แวร์ที่คุณภาพสูงมากๆ อาจจะมีกระบวนการตรวจสอบที่รัดกุม อาจจะทำให้คุณภาพซอฟต์แวร์ดีขึ้น จุดผิดพลาดต่ำลงต่ำ แต่ซอฟต์แวร์สมัยใหม่ที่มีความซับซ้อนสูง พึ่งพิงกับไลบรารีภายนอกจำนวนมาก แทบเป็นไปไม่ได้ที่จะอ้างว่าซอฟต์แวร์เหล่านี้ไม่มีความผิดพลาดอยู่เลย ในบางกรณีอาจมีผู้อ้างว่าทำได้เช่นในโครงการอวกาศบางโครงการ แต่ซอฟต์แวร์เหล่านั้นมักเป็นงานเฉพาะทาง ไม่ต้องรองรับฮาร์ดแวร์ที่หลากหมายและมาตรฐานการเชื่อมต่อกับภายนอกจำนวนมาก

ระยะเวลาซัพพอร์ต

การส่งมอบซอฟต์แวร์ที่ไร้ความผิดพลาดอาจจะเป็นไปได้ยาก การพัฒนาซอฟต์แวร์จึงมักจะมีช่วงที่ผู้ผลิตประกาศว่าจะ "ดูแล" ซอฟต์แวร์ของตัวเองต่อไปเมื่อมีปัญหา ช่วงเวลานี้เรียกว่าช่วงเวลาซัพพอร์ต (ซึ่งอาจจะสับสนกับการขอคำแนะนำสำหรับซอฟต์แวร์จริงๆ) ซอฟต์แวร์ที่มีผู้ใช้จำนวนมากส่งผลกระทบต่อผู้ใช้เป็นวงกว้าง มักจะประกาศช่วงเวลาซัพพอร์ตให้กับลูกค้าไว้ล่วงหน้า ตัวอย่างเช่น วินโดวส์นั้นทางไมโครซอฟต์จะแบ่งช่วงเวลาซัพพอร์ตออกเป็นสองช่วง คือ ช่วงซัพพอร์ตหลัก (mainstream support) ที่จะมีอัพเดตให้รวมถึงมีฟีเจอร์ใหม่ๆ ที่สำคัญให้อยู่เสมอๆ เช่น เบราว์เซอร์รุ่นใหม่ หรือรองรับมาตรฐานใหม่ๆ และหลังจากช่วงนั้นไปแล้วจะเป็นช่วงซัพพอร์ตระยะยาว (extended support) ที่มีเฉพาะแพตช์ความปลอดภัย ในกรณีของ Windows 7 เพิ่มหมดซัพพอร์ตหลักไปเมื่อเดือนมกราคมที่ผ่านมา และจะหมดซัพพอร์ตทั้งหมดในวันที่ 14 มกราคม 2020 หรืออีกประมาณ 5 ปีข้างหน้า

ในโลกของลินุกซ์ก็คล้ายกัน Red Hat Enterprise Linux (RHEL) ที่นิยมใช้งานกันในองค์กรแบ่งช่วงซัพพอร์ตออกเป็นสี่ช่วง ได้แก่ Production 1 แก้ปัญหาความปลอดภัย, แก้ไขปัญหา, และรองรับฮาร์ดแวร์ใหม่ๆ Production 2 แก้ปัญหาความปลอดภัย และรองรับฮาร์ดแวร์ใหม่เฉพาะกรณีที่ไม่ต้องเปลี่ยนซอฟต์แวร์มากนัก, Production 3 แก้ไขเฉพาะปัญหาความปลอดภัยระดับวิกฤติ (Critical) และระดับเร่งด่วน (Urgent) เท่านั้น ไม่มีแผนการรองรับฮาร์ดแวร์ใหม่ๆ หลังจากพ้นช่วง Production 3 ไปแล้วจะเป็นช่วง Extended Life Cycle Support (ELS) ที่จะแก้ปัญหาความปลอดภัยระดับวิกฤติเท่านั้นและซัพพอร์ตชนิดนี้ต้องซื้อเพิ่มเติม

การซัพพอร์ตระบบปฎิบัติการส่วนมากจะรวมถึงไลบรารีต่างๆ ที่มาพร้อมกับระบบปฎิบัติการด้วย ในกรณีของลินุกซ์ ดิสโทรต่างๆ มักรวมเอาไลบรารีและซอฟต์แวร์จำนวนมากเข้าเป็นส่วนหนึ่งของโครงการ ไลบรารีและซอฟต์แวร์ที่ได้รับการซัพพอร์ตจากลินุกซ์ดิสโทรต่างๆ อาจจะไม่ใช่รุ่นใหม่ที่สุด แต่นโยบายการซัพพอร์ตก็จะตรงตามรอบของดิสโทรนั้นๆ ไปด้วย หากไลบรารีหยุดซัพพอร์ตไปก่อนนักพัฒนาของดิสโทรก็มักจะกลับไปแก้ซอฟต์แวร์รุ่นเก่าให้ เช่น กรณี RedHat ที่มาพร้อมกับ PHP 5.3 เมื่อพบบั๊กแต่ทาง PHP เลิกซัพพอร์ตไปแล้ว ทาง RedHat ก็จะให้นักพัฒนาของตัวเองเข้ามาดูแลแพตช์นี้เอง เรียกว่า backporting ในกรณีเช่นนี้ต้องระวังว่าไม่ได้ใช้ซอฟต์แวร์ที่ติดตั้งได้แต่ไม่ได้ซัพพอร์ต เช่น EPEL ใน RedHat/CentOS, หรือ Universe และ Multiverse ใน Ubuntu ที่แม้จะติดตั้งได้สะดวก แต่ซอฟต์แวร์เหล่านี้ไม่ได้รับการซัพพอร์ตจากดิสโทรโดยตรง ทีมงานอาจจะปฎิเสธไม่แพตช์ซอฟต์แวร์ให้แม้มีปัญหา

แจ้งเตือนและแก้ไข

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

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

หลังจากนั้นนักพัฒนาจะส่งแพตช์ไปให้เจ้าของโครงการ ดิสโทรต่างๆ ก็จะปล่อยอัพเดตในเวลาไล่เลี่ยกัน สำหรับผู้ที่สนใจอ่านเพิ่มเติมอ่านได้ที่บล็อคของคุณเทพพิทักษ์ที่บันทึกประสบการณ์การแก้ช่องโหว่ความปลอดภัย CVE-2009-4012 ในฐานะนักพัฒนา

ทดสอบก่อนอัพเดต

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

แนวทางการปล่อยแพตช์สำคัญคือ Patch Tuesday ของไมโครซอฟท์ โดยกำหนดเป็นวันอังคารที่สองของทุกเดือน (ดู Microsoft Security Bulletin สังเกตวันที่ปล่อยอัพเดต) แนวทางนี้ทำให้ฝ่ายไอทีสามารถเตรียมบุคลากร เพื่อทดสอบซอฟต์แวร์ทันทีหลังแพตช์ปล่อยออกมา และนำระบบที่แพตช์แล้วขึ้นได้อย่างรวดเร็ว บริษัทซอฟต์แวร์ขนาดใหญ่มีแนวโน้มจะปล่อยแพตช์ในช่วงเวลาที่คาดเดาได้เช่นนี้มากขึ้น เช่นทุกวันนี้ออราเคิลก็มีนโยบายปล่อยแพตช์ความปลอดภัยวันอังคารที่ใกล้กับวันที่ 17 ของทุกเดือน

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

แนวทางโดยรวม

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

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