ปกป้องธุรกิจของคุณในระหว่างการเข้ารหัสโครงการ

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

ในที่สุดโปรแกรมเมอร์อีกคนหนึ่งถูกเรียกให้แก้ไขรหัสของ Tinsley ในขณะที่เขาพักร้อนและในตอนนั้นพล็อตก็ถูกเปิดออก Tinsley อายุ 62 ปีทำงานกับซีเมนส์ประมาณ 12 ปีก่อนที่เขาจะถูกจับได้ แต่ในช่วงเวลานั้นเขาไม่เคยสงสัยเลย การพิจารณาคดีตั้งขึ้นเมื่อวันที่ 8 พฤศจิกายน 2019 และ Tinsley อาจใช้เวลาถึง 10 ปีในคุกและจ่ายค่าปรับสูงถึง $ 250, 000

การจ้างตัวสำรองข้อมูล

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

"จะเกิดอะไรขึ้นหากบุคคลนั้นออกจากหรือลดความตาย" แจ็คโกลด์นักวิเคราะห์หลักที่ถามจาก J. Gold Associates Gold แนะนำว่าเมื่อคุณจ้างคนอื่นเพื่อทำการพัฒนาคุณต้องมีการสำรองข้อมูลเสมอ หลังจากทั้งหมดรหัสที่กำหนดเองเป็นรหัสของคุณ ไม่มีบุคคลที่สามที่คุณสามารถเปิดหากมีสิ่งผิดปกติเว้นแต่คุณจะวางแผน นอกจากนี้เขายังชี้ให้เห็นว่ามีอีกสองสามขั้นตอนที่ บริษัท ต้องทำเพื่อปกป้องตัวเองในระหว่างกระบวนการพัฒนาหัวหน้าในหมู่พวกเขาจำเป็นต้องมีการตรวจสอบโค้ด

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

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

การทำรีวิวรหัส

Zeichick กล่าวว่ามีวิธีการตรวจสอบโค้ดสองสามวิธี "คุณสามารถมีทีมงานที่มีคนสองคนกำลังทำงานอยู่หรือคุณสามารถพบกันในห้องประชุมเพื่อทบทวนรหัส"

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

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

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

Zeichick ตั้งข้อสังเกตว่าร้านค้าพัฒนาขนาดใหญ่บางแห่งอาจทำการตรวจสอบโค้ดของตนเองซึ่งเขากล่าวว่าสมเหตุสมผล “ คนที่ดีที่สุดในการตรวจสอบรหัสคือคนในทีมพัฒนา” เขากล่าว

หลีกเลี่ยงรหัสอันตราย

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

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

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

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

• จะทำอย่างไรเมื่อคุณถูกแฮ็กสิ่งที่ต้องทำเมื่อคุณถูกแฮ็ก
• 6 สิ่งที่ไม่ควรทำหลังจากการฝ่าฝืนข้อมูล 6 สิ่งที่ไม่ควรทำหลังจากการฝ่าฝืนข้อมูล
• Florida City จ่าย $ 600, 000 ให้แฮกเกอร์ After Ransomware Attack Florida City จ่าย $ 600, 000 ให้แฮกเกอร์ After Ransomware Attack

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

วิธีการป้องกันสิ่งนี้คือการจัดการอย่างต่อเนื่องตรวจสอบผลิตภัณฑ์งานของเจ้าหน้าที่การเขียนโปรแกรมของคุณและตรวจสอบรหัสก่อนที่จะได้รับการยอมรับจากระบบการจัดการรหัสของคุณ