ソフトウェア開発は、世界中でますます多くの人々が携わるようになっています。ソフトウェアを構築している企業と個人がいますが、その中にはプロプライエタリなもの、フリーまたはオープンソースのもの、そしてその 2 つを組み合わせたものもあります。ユーザーやそのソフトウェアのセキュリティに対する脅威は、何かが完成と宣言されて実稼働環境に出荷されたからといってすぐに現実化するものではないため、忍び寄る可能性のあるセキュリティ リスクの管理に役立つセキュリティ実践について話し合うのに適切な時期であるように思われます。開発プロセス中のソフトウェア。 SSDLC (Secure Software Development Life Cycle) フレームワークはいくつかあります。 OWASP, CISA, NIST (SSDF)。この記事では、それらすべてから少し借用して、ソフトウェア開発に伴うリスクの管理を支援することを目的としたいくつかの実践方法に焦点を当てます。自分にはそんなことは起こらないと考えて、誤った安心感を持って生きてはいけません。 チェック・ポイントの 2023 年中間サイバー セキュリティ レポートにより、世界的なサイバー攻撃が 8% 急増していることが明らかになりました 2022 年にかけてその傾向は逆転しそうにありません。
ソフトウェア開発ライフサイクルとは何ですか
ソフトウェア開発者は、ソフトウェアを高速、正確、安全に構築することを目指しています。もちろん、常に 3 つすべてを取得できるわけではありません。時間が経つにつれて、開発プロセスは、あらゆるソフトウェア開発に適合するいくつかの個別のフェーズに分割されました。これらのフェーズは次のように分類できます。
- 要件分析 – 何を構築するのか、そしてその理由は
- 計画 – 一般的にどのように構築するか
- ソフトウェア設計 – 建築設計などの具体的な観点でどのように構築するか
- ソフトウェア開発 – ソフトウェアの作成とコンパイル
- テスト – 計画どおりに機能することを確認します
- 展開 – エンドユーザーが使用できるように出荷または公開します
このサイクルには他にもいくつかのバージョンがありますが、全体的には非常に似ています。このサイクルは 1 回限りのものではないことを覚えておくことが重要です。通常、クライアントに出荷したり、クラウドに公開したりしてもサイクルは終了しません。ほとんどの場合、再設計 (振り出しに戻る) が必要になる可能性のある、対処する必要がある問題、修正する必要があるバグ、追加したい機能などが存在します。いくつかのステージを並行して作業したり、ステップの途中で停止して後退したりすることもあります。どのステップも本質的にセキュリティ中心ではないため、セキュリティは常に開発プロセスに追いつく必要があり、今日の多忙な開発速度ではそれだけでは十分ではありません。
SDLC を保護することの重要性
安全なソフトウェア開発は、セキュリティをプロセスへのアドオンとして扱うのではなく、プロセスのすべての段階でセキュリティに関する考慮事項を含めることを目的としています。このように、プロジェクトの要件を考え、アーキテクチャを計画し、必要なビルディング ブロックとインフラストラクチャを検討し、コードの開発に取り組むなど、プロセスのどのフェーズに取り組んでいる場合でも、セキュリティは常に考慮すべきです。このアプローチは、 左シフトセキュリティ アプローチで回避できます。
ここでのシフトレフトとは、セキュリティ上の懸念を開発プロセス全体に分散させ、開発者をセキュリティの設計、実装、テストに関与させることを指します。
これまでセキュリティ問題について深く考えたことのなかった開発者にとって、突然セキュリティ問題に対処しなければならないのは恐ろしいことかもしれません。要件が複数の明確に定義されたベスト プラクティスに分割されている場合、処理が大幅に容易になります。新しい IDE を購入するようなものと考えることができます。
要件がより明確に定義され、使用できる自動化ツールと包括的なツールが増えるほど、タスクは簡単になります。
SDLC セキュリティのベスト プラクティス
ここでは、開発プロセスを保護するために役立ついくつかのベスト プラクティスを順不同で示します。
トレーニング – 多くの開発者は、セキュリティ上の考慮事項を適用し、作成中のコードをテストするというタスクに不平等を感じるでしょう。ほとんどの開発者は、汚染された入力データをバックエンドに入れると、よく知られている「ドロップ テーブル」と同様に、リモート コードがアクティブ化される可能性があることを認識しています。ただし、バッファ オーバーフロー テストや、三次 (またはそれ以上) の依存関係の脆弱性スキャンに精通している人はほとんどいないでしょう。開発者はトレーニングを利用することで、こうした知識のギャップを埋めることができます。開発者は、セキュリティ上の課題や潜在的な脆弱性について理解を深めると、日々のコーディングやテストにセキュリティ上の懸念を組み込む準備が整います。また、コードを作成し、その機能に精通している開発者にとって、セキュリティ上のギャップを考慮し、それに応じてテストを計画することは非常に理にかなっています。
スキャニング – さまざまな種類のスキャンを使用して、コード全体の安全性を高めることができます。静的分析、動的分析、対話型分析はその一部です。静的分析では、ソース コード内の明らかなコーディングの欠陥や潜在的なセキュリティ脆弱性を探します。これは、潜在的な脆弱性、安全でないコードの実践、コーディング標準の違反を探すために使用できます。コード構文のみを検査するため、実行時イベントは考慮されません。動的分析では、アプリケーションの実行中にセキュリティ上の欠陥、コーディングの欠陥、その他の問題がないかどうかを調べます。これを使用して、メモリ リーク、標準以下の操作、およびおそらく不安定な入力またはプロセスを特定できます。このタイプのテストは特定の入力を使用して特定の時間に実行されるため、テストの品質はテストを考案した個人に完全に依存することに注意してください。目的は、ユーザーが発見する前に問題を発見することです。対話型分析によりアプリケーションを検査し、潜在的なセキュリティ上の欠陥やその他の重大な問題を見つけます。潜在的な脆弱性、ユーザビリティの問題、ユーザー インターフェイスの問題を探すことができます。より包括的なスキャン ツールを使用するほど、保護は強化されますが、当然のことながら、開発速度はトレードオフになります。各アプリケーションは固有であるため、適切なスキャン量と望ましい開発速度の間のバランスを見つけるのはあなた次第です。さらに、アプリケーションの完全な SBOM を作成し、そのデータ ソースにもさまざまなスキャンとレポートを適用することをお勧めします。アプリの SBOM レガシーを持つことは、さまざまなセキュリティ上の理由から非常に貴重になる可能性がある非常に詳細なコンポーネントとパッケージの情報を保持する良い方法です。
コードレビュー – ソース コードをアクティブな開発ブランチと組み合わせる前に、セキュリティ上の欠陥、コーディングの間違い、その他のソフトウェアの欠陥を見つけるためにソース コードを検査することは、コード レビューとして知られています。通常、コードの作成者よりも優れた専門知識を持つ開発者がこのレビューを実施します。このようなレビューは、コードが適切に記述されており、アプリケーションが安全であることを保証するのに役立ちます。さらに、コード ベース全体にわたる単一の標準およびコーディング規則 (関数名や変数名など) の維持もサポートされます。
少なくとも 2 組の目でレビューした後でコードをメイン ブランチに統合できるようにすることがベスト プラクティスとみなされます。もちろん、コードを作成した開発者が最初の目です。チームリーダーなどの高度なスキルを持ったエンジニアにとっても、他の人にコードを評価してもらうことは有益な場合があります。これにより、少なくとも、複数の人がコードの各セクションに精通していることが保証されます。大きなストレスにさらされているときや、危機に瀕しているときには、人々はこの要素を控えることを検討する可能性があることに留意してください。可能であれば、このルールをバイパスできないように、CI/CD のハードコーディングされた要素として追加することを検討してください。
テスト – コードをテストしてセキュリティ上の欠陥を問題になる前に発見することがいかに重要であるかは、説明する必要はありません。コード プロジェクトの大部分は複雑で相互に関連しているため、単一の小さなギャップが最終的にコード ベース全体のセキュリティにどのような影響を与えるかを予測することは不可能です。
自動テストを作成するときは、最近作成されたコードの機能だけでなく、コード ベースの他の部分との重要なバックエンドおよびフロントエンドの相互作用も考慮に入れてください。
SQL インジェクション、クロスサイト スクリプティング、安全でないデータ ストレージ、不適切なメモリ割り当て (バッファ オーバーフローを引き起こす可能性がある) などの脆弱性は、通常テストで対処されるセキュリティ問題の例です。テストでは、メモリ リーク、パフォーマンスの低下または信頼性の低下、およびユーザビリティに対処する必要があります。単体テストと統合テストの両方を経ずに新しいバージョンやアップデートを公開できないように、テストは自動で行われ、CI/CD パイプラインに統合される必要があります。
独立した侵入テスト – 誰もすべてを考えることはできません。開発者として、私たちは自分が書いたコードに関して盲点が見つかることがあります。コードレビューと同様に、独立したペネトレーションテストにより、アプリとユーザーを保護するために私たちが行ったことや取った予防策を批判的に検査するための新たなアプローチと別の目が可能になります。このようなテストは少なくとも年に 1 回行うことが推奨されており、アプリの脆弱性だけでなくインフラストラクチャの評価も組み込む必要があります。
オープンソースを安全に使用する – 現在開発されているほぼすべてのソフトウェアには、多かれ少なかれオープンソース ソフトウェアが含まれています。オープンソース コンポーネントは、直接または一時的な依存関係を通じて、アプリケーションに脆弱性がインポートされる主な原因の一部です。さらに、あなたを危険にさらす可能性があるのは、使用しているライブラリだけではなく、古いライブラリを更新したり、最新の公開された CVE を最新の状態に保てなかったりすることも、影響を与える可能性があります。組織で使用するために承認されたオープンソース パッケージのリストを作成し、それを常に確認して更新することをお勧めします。たとえテスト目的であっても、開発者が希望するパッケージを追加できないようにすることで、対処しなければならない脆弱性の数を減らすことができます。
脆弱性が悪用されないようにする – 脆弱性のないコードベースはほとんどありません。適切なスキャンを行った場合、数百から数千ものデータが検出されます。それらをすべて排除することは不可能です。脆弱性が悪用されるわけではないことを覚えておくことも重要です。フィルタリング プロセスを使用して、発見した脆弱性が悪用可能な脅威ではないことを確認し、このリストを常に更新してください。こうすることで、最新の CVE について懸念する第三者やユーザーを、それがアプリケーションにまったく影響しないことを安心させることができます。
セキュリティは考え方から始まります
おそらく、開発者、フレームワーク、コーディング言語の数と同じくらいソフトウェアを開発するさまざまな方法があります。つまり、使用している言語、分野、IDE に関係なく、開発プロセスを保護するためのベスト プラクティスを見つけるのは簡単ではありません。 「次のかけがえのないセキュリティ ツール」として注目を集めているプロプライエタリなツールや無料のツールを含め、数多くのツールを超えて、使用できる最も重要なセキュリティ ツールはあなたの考え方です。
デザインの選択、アーキテクチャ、ストレージについて考えてください。ユーザーベースの急激な増加という選択肢を検討したことがありますか?コードベースとインフラストラクチャのさまざまな部分に対するアクセス権限を適切にセグメント化していますか?データや秘密に対する標的型攻撃と、ソフトウェア サプライ チェーンの「間接的」攻撃の両方を考慮しましたか?
これらすべての質問やその他の質問は、アプリケーションの計画に着手する前に検討する必要があり、コードベースとアプリの成長と進化に応じて定期的に再検査する必要があります。
ソフトウェアの最も脆弱な部分はそれを実行する (または作成する) 人間である、というのは公理と考えられています。あなたのアプリケーション、ソフトウェア、またはコード ライブラリが、新たなサイバー攻撃の波の増加する統計の一部にならないようにしてください。適切な計画、ツール、自動化があれば、サイバー リスクの管理、開発ライフ サイクルの保護、十分に文書化された包括的で効率的なコードの作成の間で適切なバランスを見つけることができます。