率直に言って、私たちはあなたのコードベースを通過しないように努めます、私たちはそれを行うためのツールを書こうとします。
まず、理論。セキュリティはソフトウェアシステムの要件であるため、他の要件（機能性、使いやすさ、アクセシビリティ、パフォーマンスなど）と同様に、要件の収集から展開および保守までのソフトウェアエンジニアリングワークフローのすべての段階で考慮する必要があります。実際、これは可能であり、ソフトウェアプロジェクトチームがそれを行うのに役立つガイダンスが存在します。私は主にiOS開発者と協力していますが、「安全な開発ライフサイクル」についての私のお気に入りの説明はMicrosoft Pressからのものです。
このモデルでは、ユーザーから要件を引き出そうとするときにアプリケーションのセキュリティが始まります。私たちは彼らのセキュリティとプライバシーの懸念を発見する必要があります。これは私たちがユーザーではなく専門家であり、彼らがセキュリティ要件を理解している場合、それらを表現するのは難しいと感じるかもしれないため、簡単ではありません。また、ソフトウェアが展開時にさらされるリスクと、許容可能なリスクのレベルを発見する必要があります。
これらの要件を満たすことを念頭に置いてアプリケーションを設計します。これらの要件を満たし、コードレベルのセキュリティミスに関連する追加のリスクを回避することを目的として、コードを記述します。ソフトウェアをテストして、セキュリティのモデルが実際に構築したものと一致していることを確認してから、設計時に環境について行った仮定に一致する方法でソフトウェアを展開します。最後に、ユーザーがセキュリティ要件に一致する方法でソフトウェアを操作できるようにサポートとメンテナンスを提供し、提示されたリスクの新しい変化にユーザー（および私たち）が対応できるようにします。
理論についてはこれで終わりです。では実際に（非技術系のファッションにもかかわらず）非常によく説明されている理由のためGeekonomics、主な方法のソフトウェア会社が動機づけられて、彼らのために、上記のもののほとんどは発生しませんです。代わりに、これを取得します。開発者は：
- 警備員またはギャルを雇って、彼らが契約に入札しているときに、警備員が「手に入れられる」ことを示すために立ち会います。
- ソフトウェアを書く。
- セキュリティ担当者またはギャルを雇って、リリース前にソフトウェアを検証し、ステップ2で発生した多くの問題を修正します。
- 展開後にその他すべてにパッチを適用します。
したがって、ほとんどのアプリセキュリティの人々が実際に行っているのは、あなたが言うように、バグを見つけることです。これは本当に素晴らしいコードレビューですが、このレビューが探している種類のバグの専門家である人々によって実行される非常に焦点を絞ったコードレビューなので、それを行うために外部の助けを得ることにはまだ価値があります。もちろん、これはテティングの一般的なルールです。常に、他の人にテストに参加させて、モノの作成に関わっていない人をテストしてください。
上記をtrueとして受け入れた場合、購入を決定する人々は「有能なセキュリティ担当者」を「多くのバグを発見すること」と同一視する可能性が高いということになります。コンピューターに仕事を任せる人は、そうでない人よりも多くのバグを見つけます。そのため、当然、静的分析ツールに大きく依存しており、特定のクライアントの特定の問題のコーディングよりもツールの拡張に多くの時間を費やすことを目指しています。次に、アプリのセキュリティ担当者は、コードを読み取るよりも、コードを読み取るためのツールを書く可能性が高いと結論付けます。
**警告：残っているのは個人的な意見と推測です**
現実は壊れています。ソフトウェアセキュリティの理論はすべてソフトウェアシステムに依存するリスクを特定して対応することに関するものであり、実践はできるだけ多くのバグを見つけることに関するものであることに気付くでしょう。もちろん、それでもリスクは軽減されますが、副作用としてのみです。ゲームのポイントはゲームに「勝つ」ほど重要ではなくなったため、勝ちやすくなるようにルールが変更されています。
それについてソフトウェア開発者として何ができますか？元のルールに従ってゲームをプレイします。セキュリティの重要性を理解し、彼らからベジーズを訓練するチームの誰かを見つけます（できれば、実際には請負業者ではなく、チームのメンバーであることが望ましいです。そうすれば、彼らは迅速な勝利よりも長期的な結果を提供するように動機付けられます）。その人に、私の回答の冒頭で説明したエンドツーエンドのセキュリティを提供するようチームに指示する責任を与えます。
また、その人にをフォローする権限を与えます。設計がセキュリティ要件を表していない場合は、それを修正する必要があります。実装がセキュリティ要件を満たさない場合は、リリースしないでください。セキュリティ担当者は判断を下すことができますが、その判断に基づいて行動することが許可されている必要があります。これはセキュリティ担当者が「OMFGセキュリティが最も重要なこと」と言っているように聞こえるかもしれませんが、それは私が言っていることではありません。製品が機能性、使いやすさ、またはパフォーマンスの要件を満たしていない場合も、リリースしないでください。
なぜそうしたいのですか？それはもっと安くあるべきです：私たちは皆、コード補完表を見てきました（そしておそらく安い+10担当者のために引用されています）。セキュリティの欠陥も欠陥です。私は実際のゲームのルールです。それらのほとんどは、メンテナンスで修正される要件の問題です。安いですか？
さて、私はそれを雇うためのセキュリティ銃として何ができますか？まあ、私も修正されたルールでプレーすることを拒否できることがわかりました。リスクを軽減することがすべてであり、すべての段階でこれを実行できることを開発者に伝えてから、開発者がそうするのを支援することができます。