セキュア・コーディングとは

セキュア・コーディング（セキュア・プログラミングとも呼ばれる）は、脅威アクターからのサイバー攻撃を防御できるソースコードを書く手法です。コードにセキュリティーを組み込むことで、脆弱性を抑制し、サイバー脅威に対抗できる堅牢で回復力のあるソフトウェアを作ることができます。

セキュア・プログラミングは、セキュア・ソフトウェア開発ライフサイクル（SSDLC）の重要な部分です。従来のSDLCではセキュリティがテスト段階でのみ考慮されるのに対し、SSDLCはソフトウェア開発プロセスのあらゆる段階にサイバーセキュリティーを組み込んでいます。コード・セキュリティーは、単なる後付け、オプションのアドオン、または別個の側面ではなく、安全なソフトウェアを構築するための不可欠な要素です。

セキュア・コーディングも、広い意味でアプリケーション・セキュリティーのカテゴリーに含まれます。セキュア・プログラミングはサイバーセキュリティーをコードに統合することに重点を置いていますが、アプリケーション・セキュリティーはハードウェア保護からソフトウェアベースの防御まで幅広いセキュリティー対策をカバーし、SDLC全体に及びます。

IBMの2026年X-Force Threat Intelligence Indexによると、脆弱性のエクスプロイテーションは攻撃の主な原因となっています。セキュア・コーディングなどのより積極的で予防的なアプローチに移行することで、脅威が拡大する前に阻止できます。

セキュア・プログラミングには以下のメリットがあります。

• コスト効率：セキュリティー上の欠陥の修正は、リリース後よりもデプロイメント前の方がコストがかかりません。

• データ・セキュリティー：機密データの保護はソースコード・レベルで適用され、データ保護規制の遵守をサポートします。

• 早期検知と防止：脆弱性を開発中に発見して排除するため、本番環境への伝播を防ぎます。

• 時間と労力の節約：セキュア・コードは、稼働中のシステムのインシデント対応と修復に伴う多大な時間と労力を回避するのに役立ちます。

コードのセキュリティー脆弱性の原因となるのは、通常、ソフトウェアの設計とアーキテクチャーの欠陥、設定ミス、プログラミング・エラーです。悪意のあるアクターは、これらの脆弱性を攻撃のエントリー・ポイントとして悪用することがよくあります。

Open Worldwide Application Security Project（OWASP）のウェブ・アプリケーション・セキュリティ・リスクのリストに基づいて、セキュア・プログラミングが対処を目指す典型的な脆弱性をいくつか紹介します。

• 認証失敗

• アクセス制御の障害

• 暗号化の失敗

• インジェクション攻撃

• セキュアでない設計

• ロギングおよびアラートの失敗

• セキュリティの設定ミス

• ソフトウェアまたはデータ整合性の障害

サイバー犯罪者は認証メカニズムの弱点を利用してユーザーの認証情報を盗み、悪意のある活動を実行します。認証の失敗には、脆弱なパスワード・ポリシー、強力な認証方法の欠如、不適切なセッション管理、試行錯誤によって正しいパスワードを見つけるブルート・フォース攻撃や、漏洩したユーザー名とパスワードの組み合わせを使用してユーザーのアカウントにアクセスするための認証情報スタッフィングなどのパスワード・クラッキング手法に対する不十分な保護が含まれます。

アクセス制御は、データまたはリソースにアクセスできるユーザーと、実行が許可されているアクションを確立します。制御が壊れたり、誤って適用されたりすると、不正アクセスや権限の悪用につながる可能性があります。脅威には、アクセス制御チェックをバイパスするためにAPIリクエストやURLパラメータを変更することや、アクセス許可を検証することなく一意の識別子を使用してデータやリソースを直接参照することを可能にする、安全でない直接オブジェクト参照が含まれる可能性があります。

暗号化手法に欠陥があると、機密データが漏洩し、データ侵害が引き起こされる可能性があります。暗号化の失敗には、暗号化アルゴリズムが古いまたは脆弱であること、キー管理プロトコルが不十分であること、ハードコードされたキーを使用していること、適切に暗号化されないデータを送信または保管することなどが含まれます。

インジェクション攻撃は、最も一般的なセキュリティー脆弱性の1つです。コード、コマンド、クエリ、スクリプトなどの悪意のあるインプットがプログラムやWebページに挿入され、マルウェアを起動したり、データを変更したり、個人情報を盗んだりするなどの悪質な行為が行われます。クロスサイト・スクリプティング、クロスサイト・リクエスト・フォージェリー、サーバー側リクエスト・フォージェリーは、よくあるインジェクション攻撃です。

クロスサイト・スクリプティング（XSS）とは、信頼できないコードやスクリプトが信頼できるWebサイトにデプロイされ、それが何も知らないユーザーによって実行されることです。これは通常、アプリケーションがユーザーから提供されたデータのエスケープ、フィルタリング、サニタイズ、または検証に失敗した場合に発生します。

クロスサイト・リクエスト・フォージェリー（CSRFまたはXSRF）とは、認証済みのユーザーを装って、Webサイトに不正なリクエストを送信する攻撃です。これは、サイトが認証済みユーザーのWebブラウザーに対するサイトの信頼性を悪用し、リンクやスクリプトを用いてブラウザーを騙して悪意のあるリクエストを標的サイトに送信させます。

サーバー側リクエスト・フォージェリー（SSRF）は、サーバーに送信されるURLを改ざんする攻撃です。サーバーが最初にURLを検証せずに改ざんされたリクエストを受け取ると、そのリクエストを使用してデータベースなどの内部サービスに接続したり、ファイル、サーバー構成、その他のメタデータを読み取ったりすることが可能になります。

セキュアでない設計とは、ビジネス・ロジックやアプリケーション・アーキテクチャーの欠陥によって引き起こされる脆弱性を指します。これは、SDLCの計画フェーズの早い段階で、要件を定義し、システムの青写真を計画する際に発生します。リスク評価の欠如、安全な設計パターンや参照アーキテクチャーの限定的な使用、計画されたアーキテクチャーの潜在的なセキュリティー脆弱性を体系的に分析するための脅威モデリングの最小化といった要因はすべて、セキュアでない設計につながる可能性があります。

不十分または効果のないアラートやログにより、攻撃や侵害が検知されない事態が発生し、それによって脅威アクターが深刻な被害を引き起こす恐れがあります。ロギングやアラートの障害例としては、重要なイベントが記録されないか記録されているが一貫性がないこと、改ざんや不正アクセスが発生しやすい安全でないログ・ストレージ、リアルタイムまたはほぼリアルタイムのアクティブな攻撃に対するアラートの不足、不明瞭または詳細やコンテキストが欠如しているログメッセージ、マスキングやスクラブされていない機密データを含むログ、などがあります。

この脆弱性は、クラウド・サービス、データベース、フレームワーク、ライブラリ、オペレーティング・システム、Webサーバーを含むアプリケーション・スタックのセキュリティ設定が適切に行われていない場合に発生します。セキュリティの設定ミスには、セキュリティ更新プログラムの無効化、広すぎる権限範囲、デフォルトの認証情報の変更、不要な主要機能の有効化などがあります。

これらの障害は、外部ソースからの無効なデータや信頼できないデータを受け入れたり処理したりすることに対する安全対策が欠如していることに起因します。例えば、整合性を検証せずにソフトウェアの更新を自動的に適用すること、サードパーティーのライブラリーやプラグインなどの信頼できないソースを依存関係に使用すること、コードやその他のソフトウェア開発成果物を検証せずに取得するCI/CDパイプラインを使用することなどが挙げられます。

一部の生成AIテクノロジーは安全なプログラミングに役立ちます。例えば、Claude CodeやIBM Bobのようなエージェント型AIコーディング・プラットフォームは、リアルタイムで脆弱性を発見し、安全でないコードの修正プログラムを提案できます。AIコード生成ツールは、セキュリティー向上のためのコードのリファクタリングにも役立ちます。

AIコーディング・アシスタントはソフトウェア開発を自動化し、高速化できますが、安全なコードを生成するための指示が依然として必要です。プログラマーは、機能だけでなくセキュリティー要件も指定する明確なプロンプトを提供する必要があります。たとえば、「ログイン関数を作成する」などの一般的なプロンプトにセキュア・コーディングの指示を含めて、「期待されるフォーマットと長さについてユーザー入力をチェックするログイン関数を作成する」という文言にまで拡張できます。オープンソース・セキュリティー財団のガイドには、AIアシスタントがコード・セキュリティーを考慮するのに役立つサンプル手順が記載されています。

ソフトウェア・エンジニアリング・チームは、生成AIをより安全なコードを生み出すように方向付けるコンテキストを提供することもできます。検索拡張生成（RAG）は、AI搭載の開発者ツールを内部の安全なコーディング標準に接続します。明確なガイドラインがないチームにとって、Secure Code WarriorのAIセキュリティー・ルールは、より安全なAI生成コードを作成するための出発点となります。

AIアシスタントと同様、AIコーディング・エージェントもガイダンスの恩恵を受けます。Project CodeGuardは、安全なコーディング手法をエージェント型ワークフローに直接組み込むルールセットとスキル・フレームワークを提供します。AIコーディング・エージェントは、計画段階では目標の一部として、実行段階ではコードを記述する際に、これらのルールとスキルを使用できます。

人工知能自体が生成するコードには脆弱性が生じる可能性があるため、正確性と安全性の最終的な判断は依然として人間のプログラマーに委ねられています。生成AI対策は、以下のセキュアなコーディングのベスト・プラクティスと組み合わせて、複数の保護層を構築する必要があります。

セキュア・コーディングのベスト・プラクティスには、ソフトウェアのセキュリティーを強化するためのさまざまな防御的なプログラミング戦略が含まれます。企業は、セキュア・コーディングと配信速度のバランスを取ることに懸念を抱いているかもしれません。しかし、これらの手法の多くは、設計段階にセキュリティーを組み込む、安全なコーディング・ガイドラインを確立する、コーディング時にセキュリティー上の欠陥を特定して修正できるように開発者をトレーニングする、脆弱性を検出するためのコード分析とテストを自動化するなど、迅速な提供を犠牲にすることなくセキュリティーをコードに組み込んでいます。

安全なコーディングのベスト・プラクティスをすべて紹介することはできませんが、このリストを出発点として、これらのプラクティスを組み合わせることで、組織のセキュリティー体制を強化できます。

• セキュア・コーディング標準に従う

• セキュリティーを設計に組み込む

• インプットを検証およびサニタイズし、アウトプットをエンコードする

• 強力な暗号化プロトコルを実装する

• 認証および認可する

• 堅固なロギングと安全なエラー処理メカニズムを確立する

• 徹底したセキュリティー・テストを実施する

• コード・レビューの一環としてセキュリティーを追加する

これらの標準は、セキュア・コーディング手法を既存の開発ワークフローに効果的に統合するための基本的な指針となるものです。これらは、ソフトウェア・プロジェクト全体で安全なプログラミングのための共通のベースラインを提供します。

OWASPデベロッパー・ガイドは、プログラマーが安全なソースコードを作成する際に役立つ参考資料です。このガイドは、テクノロジーに依存しないセキュアなコーディングの実践方法を概説しており、アーカイブされたOWASPセキュア・コーディング実践クイック・リファレンス・ガイドから移行したチェックリストで、コード・セキュリティの重要なポイントを説明しています。

OWASPは、セキュア・コーディングの原則を実装し、さまざまなコードの脆弱性に対処するための一連のチートシートも提供しています。

カーネギーメロン大学のソフトウェア工学研究所によって作成されたSEI CERTコーディング標準は、Android、C、C++、Java、Perlプログラミング言語における安全なプログラミングのためのガイダンスを提供しています。この標準には、ルール、推奨事項、準拠しているコードと非準拠のコードの例が含まれています。ルールと推奨事項には、ソフトウェア・エンジニアリング・チームが作業の優先順位を付けるのに役立つよう、重大度、発生可能性、修復コストに応じて分類された対応するリスク・アセスメントが含まれています。

米国国立標準技術研究所（NIST）は、情報セキュリティのためのサイバーセキュリティー・フレームワークや、サイバーセキュリティー・リスク管理に加え、安全なソフトウェア開発フレームワークも発表しています。このフレームワークは、成果重視型の高度なセキュア・ソフトウェア開発手法で構成されており、OWASPやSEI CERTのより技術的な標準規格を補完する理想的なものとなっています。

システムの青写真にセキュアな設計を組み込むことは、ソフトウェア開発プロセスのより早い段階でセキュリティーを組み込む「シフト・レフト」のアプローチと一致しています。この手法は、最初のコード行が書かれる前から、ソフトウェアのセキュリティを確保する方法を検討します。

包括的なリスク・アセスメントと脅威モデリングにより、ソフトウェア・アーキテクチャーの潜在的なセキュリティー脆弱性を表面化させることができます。セキュアな設計段階では、セキュリティー・チームを参加させ、セキュリティー要件とソースコード・レベルでの対処方法に関する実践的なコラボレーションとガイダンスも提供する必要があります。

セキュリティーを設計に組み込む方法についての詳細は、OWASPが提供するセキュアな製品設計と脅威モデリングに関するチートシート、およびセキュア・バイ・デザイン・フレームワークを参照してください。

インジェクション攻撃によって示されているように、基本的なセキュア・コーディング原則はインプットを決して信用しないことです。サーバー側の検証とサニタイズにより、インプットが処理される前にセキュリティー・リスクがないことを確認できます。

ソフトウェア・エンジニアリング・チームは、すべての検証およびサニタイズ・ロジックを安全な中央ファイルまたは場所に配置することで、一貫性を維持し、迅速かつ簡単にアクセスして更新できるようにします。また、プログラミング言語やフレームワークに組み込まれた検証モジュールやサニタイズ・モジュールを使用することもできますが、これらは新たに発見された脆弱性に対応するために定期的に更新する必要があります。

インプット検証では、データ型、形式、長さ、範囲、サイズ、その他の制約が正しいことを確認します。これには、インプットを承認されたパターンと照合したり、許可されている文字または値のセットと比較したりすることが含まれる場合があります。

インプットをサニタイズするには、洗浄と安全な形式への変換が必要です。プログラミング言語またはフレームワークに合わせて調整する必要があります。

例えば、HTMLでは、&、<、>、”、’などの特殊文字をエスケープすると、XSS攻撃を防ぐのに役立ちます。DOMPurifyのようなライブラリは、HTMLのサニタイズに役立ちます。

データベースの場合、パラメーター付きクエリとプリペアド・ステートメントを組み合わせることで、インプットが意図せず実行される可能性のあるSQLコードではなくデータとして扱われるため、SQLインジェクション攻撃を防ぐことができます。パラメーター付きクエリは、インプットまたはパラメーターのプレースホルダーを使用してすべてのSQLコードを定義し、その後、各パラメーターをクエリに渡します。プリペアド・ステートメントは、事前にコンパイルされたSQLステートメントであり、挿入されたSQLコマンドによってクエリの意図や実行方法が変更されることはありません。

アウトプットのエンコードにより、データがテキストとして安全に表示されるため、コードとして解釈されなくなります。多くのフレームワークには、デフォルトのアウトプット・エンコーディング保護機能、または自動エンコーディングおよびエスケープ機能が付属しています。OWASP Java Encoderは、URL、インラインCSS、インラインJavaScriptに変数を配置したり、HTML属性値、CSSプロパティ、または2つのHTMLタグ間に変数を挿入したりするなど、異なるコンテキストに対応したコンテキスト・アウトプット・エンコーディングをサポートしています。

暗号化技術は、正しく適用されていれば、情報の機密性、完全性、可用性を確保します。

プログラマーは、転送中および保存中のデータを暗号化する際に、最新かつ強力なアルゴリズムを使用する必要があります。AESは、認証済みモードと256ビットのキーで高レベルのセキュリティーを提供する、対称暗号化のゴールド・スタンダードだと考えられています。非対称暗号化の場合、セキュアなカーブを使用したECC、またはランダム・パディングを有効にしたRSAで、少なくとも2048ビットのキーを使用することで、堅牢なセキュリティーが提供されます。

パスワードを保護するには、ハッシュ・アルゴリズムを適用し、ハッシュ・プロセスの一部としてソルト（ランダムに生成された個別の文字列）をパスワードに追加する必要があります。ハッシュ・アルゴリズムとは、データを一意で短く固定長の値に変換する一方向の数学関数であり、その値は復号化したり元に戻したりすることができません。現代のハッシュ・アルゴリズムには、Argon2idやscryptなどがあります。

開発者は独自の暗号化ライブラリーを作成するのではなく、Bouncy Castle、Libsodium、OpenSSL、Tinkなどの暗号化ライブラリーの、信頼性が高く、サポートおよび保守されている実装を採用する必要があります。

キーはソースコードにハードコーディングしたり、バージョン管理システムにチェックインしたり、環境変数に保管したり、ログに公開したりしてはなりません。キー管理のソリューションとテクノロジーは、生成、配布、ストレージから使用、ローテーション、取り消し、破棄に至るまで、キー管理のライフサイクルを自動化するのに役立ちます。

トランスポート層の保護に関しては、ソフトウェア・エンジニアリング・チームはHypertext Transfer Protocol Secure（HTTPS）やHTTP Strict Transport Security（HSTS）などのプロトコルと、最新バージョンのTLSを使用する必要があります。機密データのキャッシュは無効にし、機密データの不必要なストレージは避ける必要があります。

認証と承認は、エンティティーのIDを検証し、そのエンティティーが適切なレベルのアクセス権限を持っていることを確認するための、極めて重要なセキュア・コーディング手法です。

多要素認証（MFA）は、パスワード関連の攻撃に対する最良の防御手段の一つです。その他のメカニズムには、ハッカーがパスワードを何度も推測することを防ぐためのログイン・スロットリングや、ログインに何回も失敗した後に一定期間ログイン試行を停止するアカウント・ロックアウトなどがあります。

パスワードレス認証の場合、開発者はOpenID Connect（OIDC）やSecurity Assertion Markup Language（SAML）などのプロトコルを検討できます。FIDOおよびFIDO2のオープン・スタンダードは、パスキーによるパスワードレス認証を可能にし、アプリケーション、オンライン・サービス、Webサイトの認証に利用できます。

認証されたセッションが確立されたら、安全なセッションIDまたはトークンを使用して維持する必要があります。セッションIDは、強力な暗号学的安全性を備えた擬似乱数ジェネレーターを使用して生成する必要があります。他のユーザー・インプットと同様に、セッションIDまたはトークンは、処理前に検証し、無効な値を除外する必要があります。

各セッションに有効期限を設定することで、悪意のあるアクターがアクティブなセッションを乗っ取って攻撃を開始できる期間が制限されます。ソフトウェア・エンジニアリング・チームは、Web開発フレームワークが提供する組み込みのセッション管理機能を利用できます。

プログラマーは、OIDC認証プロトコルと連携して機能するOAuthなどの認証プロトコルを利用できます。アクセス制御に関しては、ロールベースのアクセス制御（RBAC）が一般的なモデルであり、ユーザーは事前に定義されたロールに基づいてアクセスを許可されます。より堅牢で、よりきめ細かな権限をサポートできる他のオプションには、属性ベースのアクセス制御（ABAC）や関係ベースのアクセス制御（ReBAC）があります。ABACは、アクション、オブジェクト、ユーザーの属性（ユーザーの名前、リソースのタイプ、時刻など）を分析して、アクセスが許可されるかどうかを判断します。ReBACは、リソース間の関係に基づいてアクセス権を付与します。

プロトコルやアクセス制御モデルが整備されている場合でも、すべてのリクエストに対して権限を検証し、エンティティがアクセスしようとする各オブジェクトに対してアクセス制御チェックを実行する必要があります。また、デフォルトでアクセスを拒否し、最小権限を適用することも、承認に関するセキュアなコーディング原則です。

ログやエラー・メッセージは、悪意のあるアクターが攻撃を仕掛ける際に役立つ豊富な情報源となります。つまり、ログもエラーも慎重に扱う必要があります。

アプリケーション・エラーや構成変更、管理者権限または特権操作に関連するシステム・イベント、認証、承認、インプット検証、セッション管理の分野における障害イベントはすべて、侵害の試みを示す可能性があるため、すべてログに記録する必要があります。分析とデバッグを支援するために、ユーザーの詳細（ID、ロール、権限）やエラーまたはイベントのコンテキスト（ターゲット、アクション、結果）など、十分な情報を含める必要があります。

ログは読み取り専用メディアに書き込まれ、アクセスが制限され、改ざん検知機能が組み込まれた安全な場所に保管する必要があります。ログを他のシステムに送信する必要がある場合は、安全な送信プロトコルを使用する必要があります。

機密データはログに記録してはならず、ログから削除または消去する必要があります。データベース接続文字列、ファイル・パス、内部ネットワークの名前や場所、セッションIDまたはトークンなど、クリティカルとみなされるその他の情報は、暗号化、ハッシュ化、またはマスクする必要があります。

ロギング・ライブラリは定期的に更新され、セキュリティの脆弱性が確実に修正されるようにしなければなりません。これは、広くデプロイされているオープンソースのLog4jロギング・ライブラリに影響を与え、ハッカーが影響を受けたシステム上でほぼすべてのコードを実行できるようにするLog4Shellの脆弱性によって実証されています。

エラー処理はロギングと密接に関係しており、エラーに関する情報は通常ログに記録されます。また、未処理のエラーは、脅威アクターの侵入経路となる可能性があります。

開発者は、予期しないエラーに対して一般的な応答またはエラー・コードを返し、サーバー側でエラーの詳細を記録するグローバル・エラー・ハンドラーの作成を検討できます。これにより、ハッカーへの情報漏洩を回避しながら、エラーに安全に対処し、プログラマーがさらに調査するために必要な結果を提供できます。

ソースコードに組み込まれているすべてのセキュリティー対策を検証する必要があります。QAチームと開発チームは、コード・セキュリティをテストするための基礎として、OWASPのWeb Security Testing GuideおよびApplication Security Verification Standardを参照できます。自動化ツールもこのプロセスを支援できます。

静的アプリケーション・セキュリティー・テスト（SAST）では、事前に定義されたルールを適用して、脆弱性の可能性を示すコード内のパターンを特定します。SASTは「ホワイト・ボックス」テストと呼ばれることもありますが、SASTツールは、アプリケーションを実行する必要なしにコードをスキャンするため、静的コード・アナライザーとしても知られています。

SASTツールは、一般的なコードの脆弱性にフラグを立てることに優れており、見つけた脆弱性の正確な行番号とファイルを特定できます。また、ほとんどのIDEやCI/CD環境ともシームレスに統合できます。ただし、疑陽性が発生しやすくなります。

動的アプリケーション・セキュリティー・テスト（DAST）は、外部からのアプローチを採用しており、現実世界の脅威アクターの行動を模倣するために、シミュレートされた攻撃を使用してランタイム環境のアプリケーションを評価します。そのため、DASTはブラックボックス・テストと呼ばれることが多く、テスターはシステムの内部構造やソースコードについて知る必要も、それらにアクセスする必要もありません。DASTは通常、SASTよりも偽陽性が少なくなります。

SASTとDASTを組み合わせることで、潜在的な脆弱性の全体像を明らかにできます。さらに包括的なセキュリティー・テストのために、SASTとDASTは、コードのコンテキストとランタイムの動作の両方を評価し、脆弱性をリアルタイムで報告する対話型アプリケーション・セキュリティー・テスト（IAST）や、ソフトウェアを分析してそのコンポーネントが安全かつ最新であることを確認するソフトウェア構成分析（SCA）など、他の手法と組み合わせることができます。

コード・レビューのほとんどは品質に重点を置いており、スタイル・ガイドラインへの準拠、論理的な問題、最適なフローとテスト、エッジ・ケースのカバレッジについてコードを検証します。しかし、セキュリティーもコード・レビュー・プロセスの一部でなければなりません。

セキュアなコード・レビューは、静的コード・アナライザーの次の防御線として機能します。人間のコード・レビュー担当者は、自動化ツールが見逃しがちなコード・セキュリティーの脆弱性について、専門知識、判断力、洞察力を提供します。

より構造化されたアプローチを求めるコード・レビュー担当者はOWASPのセキュア・コード・レビュー・チート・シートを参照できます。