Skip to the content.

まず結論

  • セキュアコーディングとは、ソフトウェアを作る段階で、脆弱性を作り込まないように安全な設計・実装を行う考え方です。
  • SG試験では、「作った後に見つける対策」ではなく「作る段階で防ぐ対策」として判断します。

直感的な説明

セキュアコーディングは、建物を作るときに、最初から安全な構造にしておくイメージです。

完成後に壊れやすい場所を直すことも大切ですが、最初から危ない作りにしない方が安全です。

ソフトウェアでも同じです。

作った後に脆弱性診断やテストで問題を見つけるだけでなく、開発中に次のような点を意識します。

  • 入力値をそのまま信用しない
  • 権限確認を忘れない
  • エラー情報を出しすぎない
  • パスワードや秘密情報をコードに直接書かない
  • 不要な機能や危険な処理を残さない

つまり、セキュアコーディングは「あとで直す」のではなく「最初から危ない書き方を避ける」ための考え方です。

定義・仕組み

セキュアコーディングは、ソフトウェア開発において、脆弱性を生みにくい設計・実装を行うための考え方や実践です。

代表的な観点には、次のようなものがあります。

  • 入力値を検証する
  • 出力時に適切にエスケープする
  • 認証・認可を正しく実装する
  • エラー処理を適切に行う
  • 重要情報を安全に扱う
  • 不要な権限を与えない
  • 安全なライブラリや関数を使う

特に重要なのは、外部から入ってくる値を信用しないことです。

利用者の入力、URLパラメータ、ファイル、APIから受け取る値などは、攻撃者が意図的に細工してくる可能性があります。

そのため、入力値チェックや出力時の処理を適切に行わないと、SQLインジェクションやクロスサイトスクリプティングなどの脆弱性につながります。

IPAでは、セキュアな実装を行うための考え方として、セキュア・プログラミング講座を公開しています。安全な実装の基本を確認する資料として参考になります。

セキュアコーディングは、特定のツールそのものではありません。

開発者が安全な実装を行うための考え方であり、必要に応じてソースコードレビュー、SAST、DAST、ファジングなどと組み合わせて品質を高めます。

どんな場面で使う?

セキュアコーディングは、ソフトウェア開発のあらゆる場面で意識します。

たとえば、次のような場面です。

  • Webアプリケーションの入力フォームを作るとき
  • ログインや権限管理を実装するとき
  • 個人情報や秘密情報を扱うとき
  • ファイルアップロード機能を作るとき
  • 外部APIと連携するとき
  • エラー画面やログ出力を設計するとき

特に、外部から入力を受け取る処理では注意が必要です。

たとえば、入力フォームに悪意のある文字列を入れられたとき、アプリケーションがその値をそのままデータベースに渡したり、画面に表示したりすると、攻撃につながる可能性があります。

セキュアコーディングでは、このような危険を前提にして、入力値検証、エスケープ、権限確認などを実装します。

一方で、セキュアコーディングは、作った後の検査そのものではありません。

コードをツールで解析するならSASTです。

実行中のアプリを外部から検査するならDASTです。

攻撃者視点で侵入可能性を検証するならペネトレーションテストです。

SG試験では、開発時に脆弱性を作り込まない考え方として整理します。

よくある誤解・混同

セキュアコーディングは、SAST、DAST、ソースコードレビュー、脆弱性診断と混同しやすいです。

混同しやすい用語 判断ポイント
セキュアコーディング 開発時に脆弱性を作り込まないように安全に実装する考え方
ソースコードレビュー 人がコードを読み、設計・品質・安全性を確認する活動
SAST ソースコードを実行せず、ツールで危険な実装を検出する手法
DAST 実行中のアプリを外部から検査し、応答や挙動を見る手法
脆弱性診断 システムやアプリの既知の脆弱性や設定不備を洗い出す活動

SG試験では、次のような表現に注意します。

  • 「開発時に脆弱性を作り込まない」
    → セキュアコーディングを疑います。

  • 「安全な実装方法を守る」
    → セキュアコーディングです。

  • 「人がソースコードを確認する」
    → ソースコードレビューです。

  • 「ツールでソースコードを解析する」
    → SASTです。

  • 「実行中のアプリに外部からアクセスする」
    → DASTです。

よくあるひっかけは、セキュアコーディングを検査ツールの名前だと思うことです。

セキュアコーディングは、ツールそのものではありません。

開発者が安全な実装を行うための考え方です。

また、セキュアコーディングをしていれば検査が不要になるわけでもありません。

人のミスや設計漏れは起こり得るため、ソースコードレビュー、SAST、DAST、脆弱性診断などと組み合わせて確認します。

まとめ(試験直前用)

  • セキュアコーディングは、開発時に脆弱性を作り込まない考え方です。
  • 入力値検証、出力時のエスケープ、認証・認可、秘密情報管理などが重要です。
  • SASTは、ソースコードを実行せずにツールで検査する手法です。
  • DASTは、実行中のアプリを外部から検査する手法です。
  • SG試験では、作る段階で防ぐのか、作った後に検査するのかで判断します。

確認問題

セキュアコーディングの説明として、最も適切なものはどれか。

ア. 開発時に入力値検証や権限確認などを適切に実装し、脆弱性を作り込まないようにする考え方である。
イ. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する手法である。
ウ. ソースコードを実行せずにツールで解析し、危険な実装パターンを検出する手法である。
エ. 攻撃者の視点で侵入シナリオを作成し、重要情報に到達できるかを検証する活動である。

回答と解説を表示 正解は **ア** です。 セキュアコーディングは、開発時に脆弱性を作り込まないように、安全な設計・実装を行う考え方です。 イはDAST、ウはSAST、エはペネトレーションテストに近い説明です。

🔗 関連記事


🏠 情報セキュリティマネジメントトップに戻る