맞춤형 코딩 프로젝트에서 비즈니스 보호

2019 년 7 월 19 일, 계약 프로그래머 David Tinley는 Siemens Corporation에 속한 컴퓨터를 의도적으로 손상 시켰다는 고발을 유죄로 인정했습니다. 이 사례에 따르면 Tinley는 펜실베이니아 주 Monroeville에있는 Siemens를 위해 개발중인 코드에 논리 폭탄을 설치했습니다. 프로젝트가 완료된 후 몇 주 또는 몇 달 동안 중단을 일으키기 위해 예정된 코드 섹션 인 논리 폭탄은 Tinsley가 버그로 간주되는 문제를 해결해야하는 지속적인 수입원을 확보하기위한 것입니다. Tinsley는 문제를 해결하기 위해 전화를 받았을 때 로직 폭탄의 날짜를 변경하여 나중에 다시 시작되도록했습니다.

결국 휴가 중일 때 Tinsley의 코드를 수정하기 위해 다른 프로그래머가 호출되어 음모가 밝혀졌습니다. 62 세인 Tinsley는 체포되기 전에 약 12 ​​년 동안 Siemens에서 근무했지만 그 기간 동안 그는 전혀 의심을받지 않았습니다. Sensencing은 2019 년 11 월 8 일로 예정되어 있으며 Tinsley는 최대 10 년의 징역형과 최대 250, 000 달러의 벌금을 지불 할 수 있습니다.

백업 코더 채용

왜 내가이 모든 것을 말해 줄까요? 결국, 의도적으로 사용자 정의 코드에 논리 폭탄을 넣는 프로그래머를 고용 할 가능성은 크지 않습니다. 이러한 기회는 0이 아니지만 다른 사람이 조직의 코드를 작성할 때 잘못 될 수있는 다른 여러 가지가 있습니다.

"사람이 떠나거나 죽으면 어떻게됩니까?" J. Gold Associates의 수석 분석가 인 Jack Gold에게 문의합니다. Gold는 개발을 위해 누군가를 고용 할 때는 항상 백업이 필요하다고 제안합니다. 결국, 사용자 정의 코드는 코드입니다. 계획을 세우지 않는 한 무언가 잘못되었을 때 돌이킬 수있는 제삼자는 없습니다. 또한 개발 과정에서 회사가 스스로를 보호하기 위해 수행해야하는 몇 가지 다른 단계가 있으며 그 중 가장 중요한 단계는 코드 검토가 필요하다고 제안했습니다.

Camden Associates의 수석 분석가 인 Alan Zeichick은 "코드 검토는 코드에 무엇이 들어 있는지 확인하는 가장 좋은 방법 일 것"이라고 말했다. "논리 폭탄, 보안 취약점 또는 멍청한 오류 등을 포함하여"

Zeichick는 "코드 리뷰를해야 할 다른 이유가있다"고 덧붙였다. "이는 개발 팀이 개발 작동 방식을 더 잘 이해하도록 돕고, 주니어 프로그래머가 더 잘 이해하도록 돕습니다. 코드 검토는 팀 관리자가 개발 팀의 품질을 처리하고 시간을 추정하는 데 도움이됩니다. 작업을 마치려면 시간이 걸립니다.

코드 검토 수행

Zeichick은 코드 검토를 수행하는 몇 가지 방법이 있다고 말했다. "두 사람이 작업하는 팀이 있거나 회의실에서 만나 코드를 검토 할 수 있습니다."

프로그래머가 찾기가 어려워 짐에 따라 각 구성원이 다른 사람의 코드를 검토하는 팀의 인기가 높아지고 있습니다. 그러나 규모가 큰 조직에서는 정기적으로 회의를 통해 코드를 검토하는 것이 유용합니다. 여러 차례의 시선이 검토 프로세스에 도움을주기 때문입니다. Zeichick는 최고급 프로그래머조차도 코드를 검토해야한다고 말했다.

그렇다면 왜 Siemens는 Tinley가 코드 검토없이 몇 년 동안 갈 수 있었습니까? 재판에서 변호사의 의견에 따르면 Tinley는 자신의 코드를 독점으로 간주하고 코드를 검토하지 않는 변명으로 사용했습니다.

이것이 가능한 이유는 확실하지 않지만 Zeichick과 Gold는 코드 검토에 대한 요구 사항이 비즈니스와 독립적 인 프로그래밍 방식 간의 계약의 일부 여야한다고 지적합니다. Gold는 계약서에서 코드 검토를 언급 할뿐만 아니라 언제 어떻게 발생하는지 명시 할 것을 제안합니다.

Zeichick은 일부 대형 개발 상점에서 자체 코드 검토를 수행 할 수 있다고 지적했습니다. "코드 검토를 수행하는 가장 좋은 사람들은 개발 팀의 사람들입니다."

악성 코더 피하기

코드 검토는 거의 영원히 지속되었습니다. 대규모 정부 시설의 프로그래머 팀을 관리 할 때 매주 금요일 오후마다 수많은 코볼 라인을 조사했습니다. 지루한 동안 우리는 종종 감독, 실수, 잘못된 참조 또는 기타 코딩 오류를 발견했습니다. 사실, 우리 모두 실수를 저지르고 현명한 검토를 통해 모든 사람에게 더 나은 코드를 만들 수 있습니다.

불행하게도, 프로그래머는 때때로 시간 낭비라고 생각하여 코드 검토를 다시 보냅니다. 다른 사람들은 사람들이 코드를 추측하는 것을 원하지 않는다고 말합니다. 그러나 코드 검토를 거부하는 것은 적신호 여야합니다. 코드 작성 비용을 지불하는 경우 계약서에 검토 요구 사항이 합리적으로 포함될 수 있습니다. 그렇게 거부하면 해고의 원인이됩니다.

불행히도 요즘 좋은 프로그래머를 찾는 것은 어렵습니다. 수요는 높으며, 어떤 경우에는 계약 프로그래머는 연락 담당자가 요구한다고하더라도 코드를 검토하도록 제출할 필요가 없다고 명시 할 수 있다고 생각합니다.

이러한 문제를 피하는 가장 좋은 방법은 먼저 이전 작업에 대한 참조를 요청한 다음 참조를 요청하는 것입니다. 둘째, 첫날부터 코드 검토를 시행하십시오. 그렇게하면 습관이되고, 개발 과정에 결정적이되기 전에 검토를 거부하는 프로그래머는 즉시 해고 될 수 있습니다.

• 해킹 당했을 때해야 할 일 해킹 당했을 때해야 할 일
• 데이터 유출 후하지 말아야 할 6 가지 데이터 유출 후하지 말아야 할 6 가지
• 랜섬웨어 공격 후 해커에게 60 만 달러를 지불하는 플로리다시 랜섬웨어 공격 후 해커에게 60 만 달러를 지불하는 플로리다시

불행히도 개발 프로세스의 위험은 클 수 있습니다. Gold는 비 윤리적 인 프로그래머가 코드에 백도어를 삽입하거나 고객 데이터 나 지적 재산을 훔치는 방법을 찾거나 중요한 데이터를 다른 회사 나 외국에 전달할 수 있다고 지적합니다.

이를 방지하는 방법은 지속적으로 관리하고 프로그래밍 직원의 작업 제품을 검토하며 코드 관리 시스템에서 코드를 승인하기 전에 코드를 검토하는 것입니다.