セキュアコーディングとは？10原則とIPA・JPCERTのガイドライン、脆弱性別のコード対策

セキュアコーディングとは、攻撃に悪用される欠陥（脆弱性）をソースコードに作り込まないための書き方と、その書き方をチーム全体で守らせる仕組みのことです。この記事では、SEI CERTの10原則とその土台にある設計原則、IPA・JPCERT/CCが公開しているガイドラインの選び方、OWASP Top 10:2025の分類に対応させた脆弱性別のコード対策、CI/CDへの組み込み方までを実装する側の目線で整理します。

まとめ：セキュアコーディングの要点と最初に読む公的ガイドライン

• 核心は「外部入力を信頼せず検証する」「他システムへ渡すデータを無害化する」「判定できないときは拒否する」の3点です。攻撃名を覚える前にこの3つを守ります。
• 原則の定番はSEI CERTのTop 10 Secure Coding Practicesです。IPAの講座はこれを実装原則とし、その上に1975年のSaltzer & Schroederの設計原則8つを置いています。
• 日本語の公的資料は目的で選びます。Webアプリの実装ならIPA「安全なウェブサイトの作り方」改訂第7版、原則と開発プロセスならIPA「セキュア・プログラミング講座」、C・Javaの規約ならJPCERT/CCのSEI CERTコーディングスタンダード日本語版、C++を含む学習なら同サイトのC/C++セミナー資料が入口です。
• OWASP Top 10:2025を確認の入口とし、自社での悪用可能性と被害の大きさから対策の優先順位を決めます。1位はアクセス制御の不備で、テストされた全アプリケーションで何らかの形が見つかっています。
• SQLインジェクションはプレースホルダ、OSコマンドインジェクションはシェルを経由しない呼び出し、XSSは出力時のエスケープで塞ぎます。いずれも「文字列連結で命令を組み立てない」が共通の答えです。
• 人のレビューだけでは漏れます。SAST・依存ライブラリ検査（SCA）をプルリクエスト単位で回し、認可漏れのようにツールが拾えない部分を診断で補います。

セキュアコーディングの意味と通常のコーディングとの違い

「セキュア」は、情報が不正な閲覧・改ざん・停止から守られている状態を指します。具体的には機密性・完全性・可用性の3要素が保たれていることで、セキュアコーディングはこれをコードの段階で実現する取り組みです。「セキュアプログラミング」もほぼ同じ意味で使われ、IPAは「セキュア・プログラミング」という呼び方を使っています。

機能要件の実装では、まず想定した入力に対して期待した結果を返すことを確かめます。セキュアコーディングの目標は「不正な入力や想定外の状態が来たときに安全側に倒れること」です。入力チェックを省いても機能は動きますが、攻撃者は画面を通さずに任意のリクエストを送れます。外部入力・API・ファイルといった境界を信頼しない前提で書くことが、両者の違いです。境界で何をどこまで検証するかは入力バリデーションの許可リスト設計を整理した記事で扱っています。

セキュアコーディングの原則を支える設計原則8つと実装原則10項目

国内の解説記事が「10個の原則」として挙げるのは、米カーネギーメロン大学SEIのCERT部門がまとめたTop 10 Secure Coding Practicesです。ただ、IPAのセキュア・プログラミング講座（2016年10月版）はこの10項目を「実装原則」とし、その上位に「設計原則」を置く2層で説明しています。設計原則と実装原則を対応させると、実装時の対策がどの設計判断に基づくかを確認できます。

SEI CERTの実装原則10項目と事故に直結する3項目

Webアプリの事故に直結しやすいのは1（入力検証）・5（既定で拒否）・7（無害化）の3つで、後半の脆弱性別対策はほぼこの3項目の各論です。並び順は資料で異なり、IPAの講座は「実装原則2」に無害化（Sanitize data sent to other systems）を繰り上げて紹介しています。番号ではなく原文の名前で覚えるほうが資料間で迷いません。

Saltzer & Schroederの設計原則8つと実装原則の対応

IPAの講座が設計原則に採っているのは、Saltzer & Schroederが1975年の論文「The Protection of Information in Computer Systems」で示した8原則です。講座は実装原則との対応を明記しており、Keep it simpleは「Economy of mechanism（効率的なメカニズム）」、Default denyは「Fail-safe defaults（フェイルセーフなデフォルト）」、最小権限は「Least privilege」と同じ意図、多層防御は「Separation of privilege（権限の分離）」と同じ意図だと説明しています。

10原則に直接の対応が無い設計原則のうち、実装で効くのは「Complete mediation（完全な仲介）」です。考え得る全アクセスをチェックし、チェック自体を回避できない位置に置くという原則で、講座は「クライアント側でのチェックでは不十分でサーバ側で全てのアクセスをチェックしなければならない」と書いています。認可漏れの多くはこの原則の違反です。もう一つの「Open design（オープンな設計）」は、仕組みを隠すことを防御の前提にしないという原則で、独自の暗号や難読化に頼る実装を避ける根拠になります。設計段階でどこに脅威があるかを洗い出す手順は、講座の第3章と同じSTRIDEを使う脅威モデリングの手順を解説した記事にまとめています。

IPA・JPCERTのセキュアコーディングガイドラインの目的別の選び方

「IPAのガイドライン」と言っても、IPAとJPCERT/CCには性格の違う資料が複数あります。更新の時期もばらばらなので、目的に合わない資料を最新版のつもりで読まないことが大切です。

IPAの2資料：セキュア・プログラミング講座と安全なウェブサイトの作り方

IPAセキュア・プログラミング講座は、2002年の「Webプログラマコース」「製品プログラマコース」、2007年の「Webアプリケーション編」「C/C++編」を、原則中心に再編した2016年10月版（2017年6月一部修正）が最後の版です。ページはアーカイブに置かれ、「本ページの情報は、2016年10月時点のものです」と明記されています。中身は第1章 脆弱性、第2章 原則（設計原則・実装原則）、第3章 脅威モデリング、第4章 開発プロセス、第5章 計画すべきセキュリティ機能（認証・認可・暗号化・入力の検証・出力のエスケープ・例外処理など）です。個別の脆弱性対策は「安全なウェブサイトの作り方」やJPCERT/CCを参照する方針と書かれているため、原則と開発プロセスを学ぶ教材として使います。

Webアプリを実装するなら、安全なウェブサイトの作り方のほうが実務に直結します。改訂第7版（最終更新は2021年3月31日の第4刷）の第1章で、SQLインジェクション・OSコマンド・インジェクション・クロスサイト・スクリプティングなど11種類の脆弱性について、原因をなくす根本的解決と影響を減らす保険的対策を分けて示しています。第2章はウェブサーバの運用やパスワードの扱いなど7項目です。サーバ運用側の対策はIPAの20ヶ条でWebサーバーのセキュリティ対策を整理した記事、設計段階の作り込みは設計段階から作り込むWebサイトのセキュリティ構築の記事で扱っています。

JPCERT/CCのSEI CERT C・Javaコーディングスタンダード日本語版

C・C++・Javaを書くなら、JPCERT/CCのセキュアコーディングのページが入口です。中心はSEI CERT C コーディングスタンダードと「Java コーディングスタンダード SEI CERT/Oracle 版」の日本語版で、C版はプリプロセッサ（PRE）・宣言と初期化（DCL）・整数（INT）・メモリ管理（MEM）など、Java版は入力値検査とデータの無害化（IDS）・例外時の動作（ERR）などの章に規則が並びます。ほかにJava・C/C++のセミナー資料、CSRF対策資料、OWASP ASVSの日本語版への案内があります。規則はIDで参照できるので、社内のコーディング規約を一から書かず「この規則IDに従う」と指定するのが現実的な使い方です。

海外の標準：OWASP・CWE・NIST SSDFの役割分担

使う順番は、OWASP Top 10で「何が起きやすいか」を掴み、CWEで「原因の型」を特定し、IPA・CERTの資料で「どう書くか」を決める流れです。MITREのCWE Top 25の2025年版は、2024年6月1日から2025年6月1日に公開された39,080件のCVEレコードを分析し、1位がCWE-79（XSS）、2位がCWE-89（SQLインジェクション）、3位がCWE-352（CSRF）でした。OWASPは2025年版の本文で、セキュリティ要件の基準にはTop 10ではなくASVSを使うよう勧め、「Top 10を完全にカバーした」というツールの主張は「単に真実ではない」と書いています。Top 10は啓発用の順位表で、チェックリストではありません。組織の開発プロセスとして何を満たすべきかは、NISTのSP 800-218（SSDF）が定めています。現行の最終版は2022年2月公開のVersion 1.1で、改訂版のRev. 1は2025年12月17日に初期公開草案が出た段階です。OWASPのプロジェクト全体の見取り図はOWASPの主要プロジェクトを整理した記事にあります。

OWASP Top 10:2025の分類別に見る脆弱性のコード対策

OWASP Top 10:2025は通算8回目の改訂で、サプライチェーンの不備（A03）と例外処理の不備（A10）が新設され、SSRFはアクセス制御の不備に統合されました。ここでは実装で直せる項目を、危険なコードと対策後のコードの対比で示します。コードはPythonの実装断片（サプライチェーンの例のみシェルのpipコマンド）で、初期化や認証処理は省略しています。変更点の全体はOWASP Top 10 2025年版の10項目と変更点の記事で確認できます。

アクセス制御の不備とパラメータ改ざんを防ぐサーバ側の所有者確認

1位（A01）のアクセス制御の不備には40のCWEが対応し、OWASPの解説によればテストされたアプリケーションの100%で何らかの形が見つかり、平均発生率は3.74%です。典型はURLやリクエストのIDを書き換えて他人のデータを見る「パラメータ改ざん」で、OWASPもaccountInfo?acct=notmyacctという例を挙げています。

# 危険：URLのIDだけで注文を返す（IDを書き換えれば他人の注文が見える）
@app.get("/orders/<int:order_id>")
def show_order(order_id):
    return jsonify(ORDERS.get(order_id))

# 対策例：上の危険例と置き換えて登録する（同じ関数名・URLの同時登録は不可）
# 前提：認証処理がサーバ側で g.user_id にログイン中の利用者IDを設定済み
@app.get("/orders/<int:order_id>")
def show_order(order_id):
    order = ORDERS.get(order_id)
    if order is None or order["owner_id"] != g.user_id:
        abort(404)   # 他人の注文は「存在しない」と同じ応答にする
    return jsonify(order)

画面からボタンを消すだけでは防げません。設計原則の「完全な仲介」のとおり、リソースを返す全ての経路で所有者や権限をサーバ側で判定します。権限昇格まで含めた対策はIDORと権限昇格をサーバ側で止める実装の記事で扱っています。

SQLインジェクションを防ぐプレースホルダでの値のバインド

インジェクション（A05）は2021年版の3位から5位に下がりましたが、OWASPの解説では37のCWEを抱え、関連CVEの件数は全カテゴリで最多です。順位が下がったのは脅威が減ったからではありません。

# 危険：入力を文字列連結でSQLに埋め込む
name = "x' OR '1'='1"
query = "SELECT * FROM users WHERE name = '" + name + "'"
cur.execute(query).fetchall()   # WHERE句が常に真になり全件が返る

# 安全：プレースホルダにバインドし、入力を値として扱う
cur.execute("SELECT * FROM users WHERE name = ?", (name,)).fetchall()   # 0件

プレースホルダの記法はドライバで異なり、標準ライブラリのsqlite3は?、psycopgやPyMySQLは%sです。ORMを使っていても、生SQLを組み立てる箇所だけは同じ注意が要ります。攻撃の手口と被害例はSQLインジェクションの仕組みと対策をコード付きで解説した記事にまとめています。

OSコマンドインジェクションを防ぐシェルを経由しない呼び出し

入力をOSコマンドの文字列に連結してシェルに渡すと、;や|の後ろに別のコマンドを続けられます。IPAの「安全なウェブサイトの作り方」も11種類の1つに挙げており、根本的解決はシェルを起動する関数を使わないことです。

# 危険：シェル経由で入力を連結する
host = "127.0.0.1; echo INJECTED"
subprocess.run("ping -c 1 " + host, shell=True)   # echo INJECTED まで実行される

# 安全：許可する形式に限定し、引数をリストで渡してシェルを経由しない
if not re.fullmatch(r"[A-Za-z0-9.-]{1,253}", host):
    raise ValueError("invalid host")
subprocess.run(["ping", "-c", "1", "--", host], timeout=5)

リストで渡せば入力全体が1つの引数として扱われ、;は区切り文字になりません。--は、以降の引数をオプションとして解釈させないための区切りです。可能なら外部コマンド自体を呼ばず、言語の標準ライブラリで同じ処理をするほうが安全です。

XSSを防ぐ出力時のエスケープとCSPの併用

クロスサイト・スクリプティング（XSS）は、入力に含まれたスクリプトがHTMLとして出力され、閲覧者のブラウザで実行される脆弱性です。SQLインジェクションが「DBへ渡す入力」の問題なら、XSSは「HTMLとして出す出力」の問題です。

# 危険：Jinja2の自動エスケープを |safe で外している
render_template_string("<p>{{ comment | safe }}</p>", comment=comment)
# → <p><script>alert(1)</script></p> がそのまま出る

# 安全：自動エスケープに任せる
render_template_string("<p>{{ comment }}</p>", comment=comment)
# → &lt;script&gt; に変換されて表示されるだけ

エスケープは出力する文脈（HTML本文・属性値・JavaScript内・URL）に合わせ、出力の瞬間に行います。この例のFlaskのrender_template_stringでは自動エスケープが有効ですが、Jinja2を単体で使う場合は既定で無効なので、使用環境の設定を確かめます。加えてContent-Security-Policyヘッダでスクリプトの読み込み元を絞れば、エスケープ漏れがあっても被害を抑えられます（実装原則8の多層防御）。CSRFとの違いと対策はXSSとCSRFの違いを実装レベルで比較した記事が詳しいです。

暗号化の失敗を防ぐ鍵の分離管理とパスワードハッシュ

暗号化の失敗（A04）は32のCWEを抱え、平均発生率は3.80%です。通信はTLSで保護し、保存データは用途に応じて暗号化とハッシュ化を使い分けます。パスワードは可逆な暗号化ではなく、ソルト付きの遅いハッシュで保存します。OWASPのPassword Storage Cheat Sheetは第一候補をArgon2id、使えなければscryptとし、bcryptは既存システム向け（作業係数10以上・パスワード72バイトまで）としています。もう一つの落とし穴が鍵の管理です。鍵やAPIトークンをソースコードや設定ファイルに直書きすると、リポジトリにアクセスできる人全員が鍵を持つのと同じになります。鍵はシークレット管理サービスでアクセス権限と更新を管理し、リポジトリにはコミットしません。環境変数で渡す場合も、ログやプロセス情報への露出を防ぎます。

サプライチェーンの不備を抑える依存バージョンの固定とハッシュ検証

新設のA03「ソフトウェアサプライチェーンの不備」は、依存ライブラリ・ビルドシステム・配布基盤で起きる侵害をまとめたカテゴリです。OWASPの解説では対応するCWEは6つ、関連CVEは11件しかありませんが、テストされた範囲での平均発生率は5.72%で全カテゴリ中最も高く、コミュニティ調査では回答者のちょうど50%が1位に選んでいます。

# 危険：バージョンも中身も固定せずに入れる
pip install requests

# 対策：推移的依存も含めて全てのバージョンとハッシュを固定した要件ファイルから入れる
# ハッシュ一致は配布物が改ざんされていないことの確認で、脆弱性が無いことは保証しない
pip install --require-hashes -r requirements.lock

依存をロックファイルで固定し、ハッシュ検証を有効にし、CIでビルドに使う認証情報の権限を絞ります。既知脆弱性との照合を自動化するならOSV-Scannerの使い方とTrivyとの違いの記事、規制対応まで含めた全体像はソフトウェアサプライチェーンセキュリティの記事を参照してください。

例外処理の不備を防ぐ判定不能時の拒否（fail closed）

もう一つの新設カテゴリがA10「例外的な状況の不適切な処理」で、24のCWEが対応します。誤ったエラー処理や論理エラーに加え、異常時に許可側へ倒れる「failing open」が対象で、代表CWEにはCWE-636 Not Failing Securely（’Failing Open’）が挙がっています。

# 危険：例外を握りつぶして許可する（fail open）
try:
    allowed = check_permission(user, resource)
except Exception:
    allowed = True

# 安全：判定できないときは拒否する（fail closed）
try:
    allowed = check_permission(user, resource)
except Exception:
    logger.exception("authz check failed")
    allowed = False

例外の中身を画面に返さないことも同じカテゴリの論点で、CWE-209（機密情報を含むエラーメッセージ）が該当します。スタックトレースやSQL文は攻撃者への情報提供になるため、利用者には一般化したメッセージを返し、詳細はサーバ側のログにだけ残します。

言語別に事故が起きやすい実装箇所

原則は共通でも、穴が開きやすい箇所は言語ごとに違います。

JavaScriptでは、サーバ側の対策に加えてブラウザ側のDOM操作が問題になります。入力を表示するときはinnerHTMLではなくtextContentを使い、HTMLとして組み立てる必要がある場合だけサニタイズ用のライブラリを通します。依存パッケージの数が多いので、npm auditやロックファイルの固定もこの言語では必須です。C・C++ではメモリ安全性が最大の論点で、境界チェックのある関数を使い、コンパイラ警告を全て解消すること（実装原則2）が出発点になります。米CISAなどは2023年12月にThe Case for Memory Safe Roadmapsを公開し、ソフトウェア製造者にメモリ安全な言語の優先と移行ロードマップの公表を求めています。新規のコンポーネントをC・C++で書くかどうかは、この流れも踏まえて決める論点です。

SAST・SCA・DASTをCI/CDに組み込む手順

人のレビューには意味がありますが、それだけでは見落としが残ります。検出手段ごとに守備範囲が違うため、組み合わせて使います。

検出手段ごとの守備範囲

• SAST（静的解析）：ソースコードを実行せずに危険なパターンを見つけます。プルリクエストごとに回せるので最初に入れます。仕組みとツールの選び方は静的解析とツールの選び方の記事にあります。
• SCA（依存ライブラリ検査）：使っているライブラリの既知脆弱性を照合します。A03への直接の手当てです。
• DAST（動的診断）：稼働中のアプリにリクエストを送って脆弱性を探ります。無償の代表例はZAP（旧称OWASP ZAP）です。
• IAST：実行中のアプリを計測し、実際の制御フローやデータフローに基づいて脆弱性を検出します。違いはIASTとSAST・DASTの違いの記事で比べています。

認可漏れや業務ロジックの抜けは、汎用ツールの自動検査だけでは十分に検出できないため、権限別のテストと手動レビューで補います。OWASPがTop 10の完全カバーをうたうツールを否定しているのも、この限界があるからです。

既存プロジェクトへ後から入れる5工程

1. 棚卸し：外部から届く入力の口（画面・API・ファイル取り込み・Webhook）を一覧にし、権限判定をしている場所を書き出します。
2. 優先度付け：OWASP Top 10:2025の順位と自社での影響度を掛け合わせて対象を絞ります。
3. 規約の明文化：言語ごとに「やらないこと」を10行程度で定めます。CERTの規則IDを引用すれば短く済みます。
4. 自動検出の接続：SASTとSCAをプルリクエスト単位で回します。既存の検出はトリアージして修正期限と担当者を定めます。新規検出を失敗条件にしつつ、既存でも悪用可能性や影響が大きいものはリリースを止めます。
5. 残存リスクの確認：ツールで拾えない認可漏れや設計起因の問題を、診断で確かめます。

工程3を飛ばして工程4から始めると、検出結果の採否を誰も判断できず、警告が積み上がったまま放置されます。規約は短くてよいので先に置きます。

AIが生成したコードのレビューで追加して見る3点

コード生成アシスタントを使う開発では、レビューの重心が「書く」から「確かめる」へ移ります。動作確認が通っていても、次の3点は人が見ます。

• 存在しない依存の混入：インポート先が実在するか、名前が似ているだけの別パッケージでないかを確かめます（A03の観点）。
• 認可判定の位置：機能を満たす実装が優先され、権限チェックが画面側だけに置かれることがあります（A01の観点）。
• 例外処理の倒れ方：exceptで握りつぶして既定値を返す実装が混ざりやすいので、拒否側に倒れるかを見ます（A10の観点）。

生成AIを組み込んだアプリでは脅威の種類が変わり、Web向けのTop 10では捉えきれません。代表的なプロンプトインジェクションはプロンプトインジェクションの攻撃例と対策の記事で扱っています。LLMを使っていないWebアプリは、従来のTop 10を入口にし、ASVSを基準に自社の機能に合わせた要件を定めます。

セキュアコーディングが形骸化するパターンと外部診断に出す判断条件

ガイドラインを配っても事故が減らない現場には、共通の失敗があります。

• 入力チェックをブラウザ側だけで済ませる：JavaScriptのチェックは使い勝手のためのもので、攻撃者は直接リクエストを送れます。設計原則の「完全な仲介」に反します。
• ツールの導入を目的にする：SASTを入れても、検出→トリアージ→修正まで回さなければコストが増えるだけです。
• 古い資料を最新として配る：2016年10月版の講座にも例外処理の説明はありますが、「サプライチェーン」という語は一度も出てきません。教材にするなら、依存ライブラリの管理など2025年版で新設された論点を現行の資料と実装例で補います。

どこまで自社で見て、どこから外に出すかは、検出手段の性質で切ります。SASTとSCAはプルリクエストごとに実行できるよう開発工程へ組み込み、結果の確認・修正の責任者を社内で定めます。前述のとおり認可漏れや業務ロジックの抜けは手動での検証が要り、社内に検証能力や独立したレビュー体制が不足する場合は第三者診断を組み込みます。外部診断を挟むかの分かれ目は、個人情報や決済情報を扱うか、障害時に外部への説明責任が生じるかの2点で、どちらかに当てはまるならリリース前に外部診断を挟む前提で計画を組みます。社内利用のみで個人情報を扱わない小規模な管理ツールに、リリースのたび外部診断を掛けるのは過剰です。

診断で見る項目はIPAの13項目とDAST・SAST・IASTの使い分けの記事、費用と外注の判断基準は脆弱性診断の種類・費用相場・進め方の記事にまとめています。開発と診断を一本の流れにしたい場合は、脆弱性診断・セキュリティ診断で範囲の設計から実施・再診断まで支援しています。

よくある質問

セキュアコーディングとセキュアプログラミングは違いますか？

ほぼ同じ意味です。どちらも脆弱性を作り込まない書き方を指し、IPAの講座は「セキュア・プログラミング」、JPCERT/CCは「セキュアコーディング」という呼び方を使っています。

セキュアコーディングの10原則は何ですか？

SEI CERTの「Top 10 Secure Coding Practices」で、入力の検証・コンパイラ警告の解消・セキュリティ方針の設計・単純さ・既定で拒否・最小権限・他システムへ渡すデータの無害化・多層防御・品質保証・コーディング規約の採用の10項目です。IPAの講座はこれを実装原則として扱っています。

IPAのセキュアコーディングのガイドラインはどれを読めばよいですか？

Webアプリを実装するなら「安全なウェブサイトの作り方」改訂第7版、原則と開発プロセスを学ぶなら「セキュア・プログラミング講座」（2016年10月版・アーカイブ）です。C・Javaの規約は、JPCERT/CCがSEI CERTコーディングスタンダードの日本語版として公開しており、C/C++を含むセミナー資料もあります。

JavaScriptのセキュアコーディングでは何に気を付けますか？

ブラウザ側では、入力をinnerHTMLに入れずにtextContentで表示し、DOMベースXSSを防ぎます。Node.jsのサーバ側では、SQLやOSコマンドを文字列連結で組み立てないことと、npm auditなどで依存パッケージの既知脆弱性を継続して確認することが基本です。

OWASP Top 10に対応すればセキュアコーディングは十分ですか？

十分ではありません。OWASP自身が2025年版で、Top 10を完全にカバーしたという主張は「単に真実ではない」とし、検証できる要件の基準にはASVSを使うよう勧めています。Top 10は優先順位を決めるための入口として使います。

関連記事

• SQLインジェクションとは？仕組み・攻撃例・対策をコード付きで解説
• XSSとCSRFの違いとは？仕組み・被害・対策を実装レベルで徹底比較
• 入力バリデーションとは？防げる攻撃の範囲と許可リスト設計を実装目線で解説
• OWASP Top 10の最新版は2025年版｜10項目と2021年版からの変更点・公式日本語訳
• Webアプリケーション脆弱性診断の項目｜IPA13項目とDAST・SAST・IASTの使い分け