--- title: "セキュアコーディングとは？脆弱性を作り込まない考え方【SG試験】" description: "セキュアコーディングは、開発時に脆弱性を作り込まないように設計・実装する考え方です。SG試験で迷いやすい脆弱性診断、SAST、ソースコードレビューとの違いを整理します。 試験対策として重要語の定義・具体例・よくある誤解をまとめ、短時間で復習できるように整理しています。" last_modified_at: "2026-05-19" canonical_url: "https://stemtazoo.github.io/sg/secure-coding/" section: "sg" --- ## まず結論 - **セキュアコーディング**とは、ソフトウェアを作る段階で、脆弱性を作り込まないように安全な設計・実装を行う考え方です。 - SG試験では、**「作った後に見つける対策」ではなく「作る段階で防ぐ対策」**として判断します。 ## 直感的な説明 セキュアコーディングは、建物を作るときに、最初から安全な構造にしておくイメージです。 完成後に壊れやすい場所を直すことも大切ですが、最初から危ない作りにしない方が安全です。 ソフトウェアでも同じです。 作った後に脆弱性診断やテストで問題を見つけるだけでなく、開発中に次のような点を意識します。 - 入力値をそのまま信用しない - 権限確認を忘れない - エラー情報を出しすぎない - パスワードや秘密情報をコードに直接書かない - 不要な機能や危険な処理を残さない つまり、セキュアコーディングは**「あとで直す」のではなく「最初から危ない書き方を避ける」**ための考え方です。 ## 定義・仕組み セキュアコーディングは、ソフトウェア開発において、脆弱性を生みにくい設計・実装を行うための考え方や実践です。 代表的な観点には、次のようなものがあります。 - 入力値を検証する - 出力時に適切にエスケープする - 認証・認可を正しく実装する - エラー処理を適切に行う - 重要情報を安全に扱う - 不要な権限を与えない - 安全なライブラリや関数を使う 特に重要なのは、**外部から入ってくる値を信用しない**ことです。 利用者の入力、URLパラメータ、ファイル、APIから受け取る値などは、攻撃者が意図的に細工してくる可能性があります。 そのため、入力値チェックや出力時の処理を適切に行わないと、SQLインジェクションやクロスサイトスクリプティングなどの脆弱性につながります。 IPAでは、セキュアな実装を行うための考え方として、[セキュア・プログラミング講座](https://www.ipa.go.jp/archive/security/vuln/programming/)を公開しています。安全な実装の基本を確認する資料として参考になります。 セキュアコーディングは、特定のツールそのものではありません。 開発者が安全な実装を行うための考え方であり、必要に応じてソースコードレビュー、SAST、DAST、ファジングなどと組み合わせて品質を高めます。 ## どんな場面で使う？ セキュアコーディングは、ソフトウェア開発のあらゆる場面で意識します。 たとえば、次のような場面です。 - Webアプリケーションの入力フォームを作るとき - ログインや権限管理を実装するとき - 個人情報や秘密情報を扱うとき - ファイルアップロード機能を作るとき - 外部APIと連携するとき - エラー画面やログ出力を設計するとき 特に、外部から入力を受け取る処理では注意が必要です。 たとえば、入力フォームに悪意のある文字列を入れられたとき、アプリケーションがその値をそのままデータベースに渡したり、画面に表示したりすると、攻撃につながる可能性があります。 セキュアコーディングでは、このような危険を前提にして、入力値検証、エスケープ、権限確認などを実装します。 一方で、セキュアコーディングは、作った後の検査そのものではありません。 コードをツールで解析するならSASTです。 実行中のアプリを外部から検査するならDASTです。 攻撃者視点で侵入可能性を検証するならペネトレーションテストです。 SG試験では、**開発時に脆弱性を作り込まない考え方**として整理します。 ## よくある誤解・混同 セキュアコーディングは、SAST、DAST、ソースコードレビュー、脆弱性診断と混同しやすいです。 | 混同しやすい用語 | 判断ポイント | |---|---| | セキュアコーディング | 開発時に脆弱性を作り込まないように安全に実装する考え方 | | ソースコードレビュー | 人がコードを読み、設計・品質・安全性を確認する活動 | | SAST | ソースコードを実行せず、ツールで危険な実装を検出する手法 | | DAST | 実行中のアプリを外部から検査し、応答や挙動を見る手法 | | 脆弱性診断 | システムやアプリの既知の脆弱性や設定不備を洗い出す活動 | SG試験では、次のような表現に注意します。 - **「開発時に脆弱性を作り込まない」** → セキュアコーディングを疑います。 - **「安全な実装方法を守る」** → セキュアコーディングです。 - **「人がソースコードを確認する」** → ソースコードレビューです。 - **「ツールでソースコードを解析する」** → SASTです。 - **「実行中のアプリに外部からアクセスする」** → DASTです。 よくあるひっかけは、**セキュアコーディングを検査ツールの名前だと思うこと**です。 セキュアコーディングは、ツールそのものではありません。 開発者が安全な実装を行うための考え方です。 また、セキュアコーディングをしていれば検査が不要になるわけでもありません。 人のミスや設計漏れは起こり得るため、ソースコードレビュー、SAST、DAST、脆弱性診断などと組み合わせて確認します。 ## まとめ（試験直前用） - 「**入力値の検証不足**」「**エスケープ漏れ**」が主因 → **セキュアコーディング不足**を疑う。 - 「**開発中にコードを解析**して欠陥を減らす」 → **SAST**（作り込み防止）。 - 「**公開中システムに疑似攻撃**して弱点確認」 → **DAST**（運用側の検査）。 - **検査で見つける**ではなく、まず**実装段階で作り込まない**が本筋。 - 迷ったら、**原因が実装品質か／検査工程か**で用語を切り分ける。 ### 確認問題 セキュアコーディングの説明として、最も適切なものはどれか。 ア. 開発時に入力値検証や権限確認などを適切に実装し、脆弱性を作り込まないようにする考え方である。 イ. 実行中のWebアプリケーションに外部からアクセスし、応答や挙動を確認して脆弱性を検査する手法である。 ウ. ソースコードを実行せずにツールで解析し、危険な実装パターンを検出する手法である。 エ. 攻撃者の視点で侵入シナリオを作成し、重要情報に到達できるかを検証する活動である。
回答と解説を表示 正解は **ア** です。 セキュアコーディングは、開発時に脆弱性を作り込まないように、安全な設計・実装を行う考え方です。 イはDAST、ウはSAST、エはペネトレーションテストに近い説明です。