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

เมื่อทำการตรวจสอบซอฟต์แวร์ ควรตรวจสอบส่วนประกอบที่สำคัญแต่ละส่วนแยกกันและร่วมกับโปรแกรมทั้งหมด ควรค้นหาช่องโหว่ที่ มีความเสี่ยงสูง ก่อนแล้วค่อยตรวจสอบช่องโหว่ที่มีความเสี่ยงต่ำ โดยทั่วไปแล้วช่องโหว่ที่อยู่ระหว่างความเสี่ยงสูงและความเสี่ยงต่ำมักเกิดขึ้นขึ้นอยู่กับสถานการณ์และวิธีการใช้งานซอร์สโค้ด การทดสอบการเจาะระบบแอปพลิเคชันพยายามระบุช่องโหว่ในซอฟต์แวร์โดยการใช้เทคนิคการโจมตีที่รู้จักให้มากที่สุดเท่าที่จะเป็นไปได้ในจุดเข้าถึงที่เป็นไปได้เพื่อพยายามทำให้แอปพลิเคชันล่ม^{[ 1 ]}นี่เป็นวิธีการตรวจสอบทั่วไปและสามารถใช้เพื่อค้นหาว่ามีช่องโหว่เฉพาะใดอยู่หรือไม่ แต่ไม่สามารถระบุตำแหน่งในซอร์สโค้ดได้ บางคนอ้างว่าวิธีการตรวจสอบเมื่อสิ้นสุดรอบการทำงานมักจะทำให้ผู้พัฒนาทำงานหนักเกินไป จนสุดท้ายทีมมีรายการปัญหาที่ทราบจำนวนมาก แต่มีการปรับปรุงเพียงเล็กน้อย ในกรณีเหล่านี้ แนะนำให้ใช้วิธีการตรวจสอบแบบอินไลน์เป็นทางเลือก ตัวอย่างของแนวทางเชิงรุกคือบริการตรวจสอบโค้ดฟรีที่ GooApps นำเสนอ ซึ่งมีเป้าหมายเพื่อระบุและลดช่องโหว่ตั้งแต่เนิ่นๆ ในกระบวนการพัฒนาเพื่อให้มั่นใจถึงความสำเร็จของแอปพลิเคชันมือถือ^{[ 2 ]}

ช่องโหว่ที่มีความเสี่ยงสูงทั่วไปบางประการอาจเกิดขึ้นเนื่องจากการใช้งาน:

• ฟังก์ชันที่ไม่ตรวจสอบขอบเขต (เช่นstrcpy , sprintf , vsprintf และsscanf ) ที่อาจนำไปสู่ ช่องโหว่ บัฟเฟอร์โอเวอร์โฟลว์^{[ 3 ]}
• การจัดการตัวชี้ของบัฟเฟอร์ที่อาจรบกวนการตรวจสอบขอบเขตในภายหลัง เช่นif ((bytesread = net_read(buf,len)) > 0) buf += bytesread;^{[ 3 ]}
• การเรียกใช้เช่นexecve (), execution pipes, system() และสิ่งต่างๆ ที่คล้ายกัน โดยเฉพาะอย่างยิ่งเมื่อเรียกใช้ด้วยอาร์กิวเมนต์ที่ไม่ใช่แบบคงที่^{[ 3 ]}
• การตรวจสอบความถูกต้องของข้อมูลขาเข้า เช่น (ใน SQL) statement := "SELECT * FROM users WHERE name = '" + userName + "';"เป็นตัวอย่างหนึ่งของช่องโหว่การโจมตีแบบ SQL injection
• ฟังก์ชันการรวมไฟล์ เช่น (ใน PHP): include($page . '.php');เป็นตัวอย่างหนึ่งของช่องโหว่การรวมไฟล์ระยะไกล (Remote File Inclusion)
• สำหรับไลบรารีที่อาจเชื่อมโยงกับโค้ดที่เป็นอันตราย การส่งคืนค่าอ้างอิงไปยังโครงสร้างข้อมูล ที่เปลี่ยนแปลงได้ภายใน (เรคอร์ด อาร์เรย์) โค้ดที่เป็นอันตรายอาจพยายามแก้ไขโครงสร้างหรือเก็บค่าอ้างอิงไว้เพื่อสังเกตการเปลี่ยนแปลงในอนาคต

ต่อไปนี้คือรายการช่องโหว่ที่มีความเสี่ยงต่ำ ซึ่งควรตรวจพบเมื่อตรวจสอบโค้ด แต่ไม่ได้ก่อให้เกิดสถานการณ์ที่มีความเสี่ยงสูง

• ช่องโหว่ของโค้ดฝั่งไคลเอ็นต์ที่ไม่ส่งผลกระทบต่อฝั่งเซิร์ฟเวอร์ (เช่น ช่องโหว่การโจมตีแบบ Cross-site scripting )
• การแจงนับชื่อผู้ใช้
• การสำรวจไดเร็กทอรี
• คีย์ API ที่มีความละเอียดอ่อน

โดยทั่วไปแล้ว เครื่องมือตรวจสอบซอร์สโค้ดจะมองหาช่องโหว่ทั่วไปและใช้งานได้เฉพาะกับภาษาโปรแกรม บางภาษา เท่านั้น เครื่องมืออัตโนมัติดังกล่าวสามารถใช้เพื่อประหยัดเวลาได้ แต่ไม่ควรพึ่งพาสำหรับการตรวจสอบเชิงลึก แนะนำให้ใช้เครื่องมือดังกล่าวเป็นส่วนหนึ่งของแนวทางตามนโยบาย^{[ 4 ​​]}

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

• การตรวจสอบเทคโนโลยีสารสนเทศ
• การเขียนโปรแกรมเชิงป้องกัน
• การรวมไฟล์ระยะไกล
• การโจมตีแบบ SQL injection
• บัฟเฟอร์ล้น
• รายชื่อเครื่องมือสำหรับการวิเคราะห์โค้ดแบบคงที่