カスタムコーディングプロジェクト中にビジネスを保護する

2019年7月19日、契約プログラマーのデイビッド・ティンリーは、シーメンス・コーポレーションに属するコンピューターを故意に損傷したという罪で有罪を認めました。 事件の提出によると、ティンリーはペンシルベニア州モンロービルのシーメンスのために開発していたコードに論理爆弾を植えました。 これらの論理爆弾は、プロジェクトが終了してから数週間または数か月後に混乱を引き起こすタイミングのコードの一部であり、バグと思われる問題を修正しなければならないことから、Tinsleyが一定の収入を得るためのものでした。 問題を修正するために彼が呼ばれたとき、ティンズリーは論理爆弾の日付を単に変更し、後で再び爆弾が消えるようにしました。

最終的に、別のプログラマーが休暇中にティンズリーのコードを修正するために呼び出され、そのときプロットが明らかになりました。 62歳のティンズリーは、逮捕されるまで約12年間シーメンスで働いていましたが、その間、彼は疑いの対象になりませんでした。 判決は2019年11月8日に設定されており、ティンズリーは最高10年の刑務所で過ごし、最高250, 000ドルの罰金を支払うことができます。

バックアップコーダーの採用

だから、なぜ私はこれをすべてあなたに言っているのですか？ 結局のところ、カスタムコードに意図的に論理爆弾を入れるプログラマを雇う可能性はあまりありません。 そして、これらのチャンスはゼロではありませんが、誰かがあなたの組織のためにコードを書いているときに間違った方向に進む可能性のあるものは他にもたくさんあります。

「その人が出て行ったり死んだりするとどうなりますか？」 J.ゴールドアソシエイツのプリンシパルアナリスト、ジャックゴールドに尋ねます。 ゴールドは、開発のために誰かを雇うときは、常にバックアップが必要であることを示唆しています。 結局のところ、カスタムコードはあなたのコードです。 あなたがそれを計画しない限り、何かがうまくいかない場合にあなたが回ることができる第三者はいません。 彼はまた、開発プロセス中に企業が自身を保護するために必要な他のいくつかの手順があることを提案しました。その主なものは、必要なコードレビューです。

「コードレビューは、おそらくコードの内容を見つけるための最良の方法です」と、Camden AssociatesのプリンシパルアナリストであるAlan Zeichick氏は言います。「論理爆弾、セキュリティの脆弱性、愚かなエラーなどを含む」

「コードレビューを行う理由は他にもあります」とZeichick氏は付け加えました。 「開発チームが開発の仕組みをよりよく理解できるようになり、ジュニアプログラマーがよりよく理解できるようになります。コードレビューは、チームマネージャーが開発チームの品質を把握し、推定期間を得るのにも役立ちます。ジョブを完了するには時間がかかります。

コードレビューの実施

Zeichickは、コードレビューを実施する方法がいくつかあると述べました。 「作業中のチームが2人いる場合や、会議室で会議を開いてコードを確認することもできます。」

プログラマーが見つけにくくなるにつれて、各メンバーが他の人のコードをレビューするチームの人気が高まっています。 しかし、大規模な組織では、コードをレビューするための定期的な会議が依然として有用です。その場合、いくつかの目がレビュープロセスに役立つからです。 Zeichickは、最も上級のプログラマでもコードをレビューする必要があると述べました。

それでは、なぜシーメンスは、コードレビューなしでティンリーがこれらすべての年を過ごすことを許可したのですか？ 裁判中の弁護士のコメントによると、ティンリーは自分のコードを所有権があると見なし、コードをレビューさせない言い訳として使用しました。

これが許可された理由は不明ですが、ZeichickとGoldの両方は、コードレビューの要件は、ビジネスと独立したプログラミング衣装との契約の一部であるべきだと指摘しています。 ゴールドは、契約がコードレビューに言及するだけでなく、それらが行われる方法と時期を指定することを示唆しています。

Zeichickは、いくつかの大規模な開発ショップが独自のコードレビューを行う可能性があると指摘しました。 「コードレビューを行うのに最適な人は、開発チームの人です」と彼は言いました。

悪意のあるコーダーの回避

コードレビューはほぼ永遠に行われています。 私が大規模な政府施設でプログラマーのチームを管理していたとき、私たちは毎週金曜日の午後にCOBOLの気が遠くなるような行を調べました。 退屈な作業でしたが、見落とし、間違い、誤った参照、その他のコーディングエラーが頻繁に見つかりました。 事実、私たちは皆間違いを犯し、賢明なレビューは誰にとってもコードを改善します。

残念ながら、プログラマは時間の無駄だと信じてコードレビューをresすることがあります。 他の人は、人々がコードを二度と推測したくないと言います。 しかし、実際には、コードのレビューを拒否することは危険です。 コードの作成に料金を支払う場合、契約にはレビューの要件を合理的に含めることができます。 それを拒否すると解雇の原因になります。

残念ながら、優秀なプログラマーを見つけるのは最近困難です。 需要が高く、場合によっては、契約プログラマーは、連絡先がそうであると言っていても、コードのレビューを提出する必要がないと指定できると感じています。

このような問題を回避する最善の方法は、まず、以前の作業の参照を要求してから呼び出すことです。 次に、初日からコードレビューを実施します。 そうすることで、彼らは習慣になり、レビューを拒否するプログラマーは、開発プロセスにとって重要になる前にすぐに却下することができます。

• ハッキングされたときの対処方法ハッキングされたときの対処方法
• データ侵害後の6つの禁止事項データ侵害後の6つの禁止事項
• ランサムウェア攻撃後にハッカーに60万ドルを支払うフロリダ市ランサムウェア攻撃後にハッカーに60万ドルを支払うフロリダ市

残念ながら、開発プロセスのリスクは大きい可能性があります。 ゴールドは、非倫理的なプログラマーがコードにバックドアを挿入したり、顧客データや知的財産を盗んだり、重要なデータを別の会社や外国の権力に渡したりできることを指摘しています。

これを防ぐ方法は、継続的に管理し、プログラミングスタッフの作業成果物を確認し、コード管理システムで受け入れられる前にコードを確認することです。