手当たり次第に書くんだ

飽きっぽいのは本能

セキュアコーディングとは何か – OWASP / ASVS を使って基準を育てる

作者: si62512548投稿日: カテゴリー: セキュリティタグ: , , , , , , , セキュアコーディングとは何か – OWASP / ASVS を使って基準を育てる へのコメントはまだありません

セキュアコーディングという言葉は、開発現場でもよく使われます。しかし実際には、「セキュアコーディングをしてください」と言われても、具体的に何をすればよいのかが明確になっていないことがあります。

SQL インジェクションに気をつける。XSS に気をつける。認証・認可を正しく実装する。ログに機密情報を出さない。どれも正しいのですが、それだけでは実務上の基準としては弱いです。

問題は、「気をつける」という言葉だけでは、どこまで対処すればよいのか、誰が何を確認すればよいのか、リリースしてよい状態とは何かを判断できないことです。セキュアコーディングは、注意喚起ではなく、組織として判断できる基準を育てる作業だと考えた方が自然です。

セキュアコーディングは精神論になりやすい

セキュアコーディングとは、単に安全そうなコードを書くことではありません。脆弱性を作り込みにくいように、設計、実装、レビュー、テスト、リリース判断を整えることです。

ところが、組織の中に具体的な基準がないと、セキュアコーディングは簡単に精神論になります。

  • セキュアコーディング規約が存在しない
  • 何をレビューすべきか決まっていない
  • 開発者ごとにセキュリティ観点が異なる
  • OWASP という言葉だけが出てくる
  • 脆弱性診断で指摘されてから初めて対応する
  • リリース可否の判断基準がない

この状態で「セキュアに実装してください」と言っても、実際には何も定義していないに等しいです。インフラで言えば、「安全なネットワークにしてください」とだけ言って、ファイアウォールポリシー、経路設計、認証方式、ログ取得、監視項目を何も決めていないようなものです。

最初から自社標準を作る必要はない

では、どうすればよいのか。私の考えでは、最初から自社独自のセキュアコーディング標準を作る必要はありません。むしろ、組織にその能力がまだない場合は、既存の標準やガイドラインを参考にするべきです。

これは能力不足をごまかすためではありません。判断基準を属人化させないためです。ネットワークで RFC を見るのと同じであり、クラウドで Well-Architected Framework を見るのと同じです。セキュアコーディングでも、まずは広く使われている基準を足場にすればよいのです。

その代表例が OWASP です。

OWASP とは何か

OWASP は、一般に「オワスプ」と読まれることが多いです。正式には Open Worldwide Application Security Project の略であり、Web をはじめとするソフトウェアセキュリティに関する標準、ガイドライン、ツール、教育資料、コミュニティ活動を含む大きな枠組みです。

セキュアコーディングの文脈で OWASP を参照する場合、特によく使われるものは次のようなものです。

名称位置づけ
OWASP Top 10Web アプリケーションにおける重大リスクの分類
OWASP ASVSアプリケーションセキュリティ検証基準
OWASP Secure Coding Practices開発者向けのセキュアコーディングチェックリスト
OWASP Cheat Sheet Series個別テーマごとの設計・実装ガイド
OWASP ZAPWeb アプリケーション向けの診断支援ツール

つまり、OWASP は単一の製品名ではありません。「OWASP を使う」という表現だけでは少し曖昧です。実務では、どの OWASP 成果物を、何の目的で使うのかを明確にする必要があります。

OWASP Top 10 はリスクの入口として使う

OWASP と聞いて、多くの人が最初に思い浮かべるのは OWASP Top 10 だと思います。OWASP Top 10 は、Web アプリケーションにおける重大なセキュリティリスクを整理した文書であり、公式にも開発者や Web アプリケーションセキュリティに向けた標準的な啓発文書として位置づけられています。

ここで注意が必要なのは、OWASP Top 10 は版によって分類名や並びが変わることです。2026 年 7 月時点で、OWASP 公式サイトでは現行リリース版として OWASP Top Ten 2025 が案内されています。社内基準や記事で参照する場合は、単に「OWASP Top 10」と書くのではなく、どの版を基準にしているのかを明示した方がよいです。

OWASP Top 10:2025セキュアコーディング上の見方
A01: Broken Access Control認可の不備。他人のデータを見られる、一般ユーザーが管理者操作できる、といった問題
A02: Security Misconfiguration設定不備。デバッグ設定、本番設定、CORS、HTTP ヘッダ、クラウド公開設定などの問題
A03: Software Supply Chain Failures依存関係や外部コンポーネントの問題。ライブラリ、パッケージ、CI/CD、コンテナイメージなど
A04: Cryptographic Failures暗号化や機密情報保護の失敗。弱い暗号、平文保存、不適切な鍵管理など
A05: InjectionSQL、OS コマンド、LDAP、NoSQL などへのインジェクション
A06: Insecure Designそもそもの設計不備。セキュリティ制御が設計されていない問題
A07: Authentication Failures認証の失敗。パスワード管理、セッション、MFA、認証バイパスなど
A08: Software or Data Integrity Failuresソフトウェアやデータの完全性の失敗。改ざんされた更新、署名検証不足、CI/CD 経由の混入など
A09: Security Logging and Alerting Failuresログと検知の不備。必要な操作ログがない、異常を検知できない、追跡できない問題
A10: Mishandling of Exceptional Conditions例外条件の不適切な処理。異常時に安全側へ倒れない、内部情報を返す、といった問題

ただし、OWASP Top 10 をそのままチェックリストとして使うだけでは足りません。Top 10 は、リスクを考える入口としては有用ですが、具体的な実装基準やレビュー観点に落とすには、もう一段分解する必要があります。

Top 10 をレビュー基準に変換する

たとえば Broken Access Control と書くだけでは、レビュー担当者は何を見ればよいのか分かりません。実務で使うには、リスク分類を自分たちのシステムに合わせた確認観点へ変換する必要があります。

リスク分類実務上の確認観点
Broken Access ControlAPI ごとに権限チェックがあるか。ユーザー ID を差し替えて他人のデータへアクセスできないか。管理者用処理が一般ユーザーから呼べないか。
InjectionSQL や OS コマンドを文字列連結していないか。プレースホルダや安全な API を使っているか。入力値の型や範囲が制限されているか。
Cryptographic Failuresパスワードやトークンを平文で保存していないか。鍵やシークレットをコードに埋め込んでいないか。TLS や暗号方式が古くないか。
Security Logging and Alerting Failures認証失敗、権限エラー、管理操作、重要データの変更が追跡できるか。ログに機密情報を出していないか。
Software Supply Chain Failures依存ライブラリの脆弱性を確認しているか。コンテナイメージや CI/CD の経路が信頼できるか。Secret が混入していないか。

このように変換して初めて、セキュアコーディングは「気をつける」から「確認できる」に変わります。

ASVS は実装とレビューの基準に近い

OWASP Top 10 がリスク分類の入口だとすれば、OWASP ASVS はもう少し実装と検証に近い基準です。ASVS は、アプリケーションセキュリティの検証要件を体系化したもので、開発者、設計者、診断者、発注者が共通の基準として使いやすい形になっています。

2026 年 7 月時点で、OWASP 公式サイトでは ASVS 5.0.0 が最新安定版として案内されています。ASVS は要件に識別子が付いているため、「認証まわりは ASVS のこの要件を基準にする」「API はこの章をレビュー対象にする」のように、レビューや診断の粒度へ落とし込みやすいのが特徴です。

ただし、ASVS もそのまま全部を適用すればよいわけではありません。対象システムの種類、扱うデータ、公開範囲、認証方式、業務リスクによって必要な水準は変わります。重要なのは、外部基準を丸写しすることではなく、自分たちのシステムに必要な判断基準へ変換することです。

IPA の資料も日本語の足場として使える

日本語で確認しやすい資料としては、IPA の「安全なウェブサイトの作り方」も有用です。Web サイトの脆弱性や対策、チェックリストが整理されており、日本の開発現場でセキュリティ観点を共有する入口として使いやすい資料です。

もちろん、IPA の資料だけで現代のクラウド、API、コンテナ、CI/CD、サプライチェーンリスクをすべてカバーできるわけではありません。それでも、SQL インジェクション、XSS、CSRF、認証、セッション管理といった基本を日本語で揃えるには有効です。

自社基準に落とすときに見るもの

セキュアコーディング基準を作るときは、外部標準をそのまま貼るのではなく、自分たちのシステムの性質に合わせて変換する必要があります。

  • API を公開しているのか
  • 個人情報や機密情報を扱うのか
  • 管理画面があるのか
  • ファイルアップロードがあるのか
  • バッチ処理やジョブ実行があるのか
  • クラウドや SaaS と連携しているのか
  • コンテナや CI/CD を使っているのか
  • 外部委託や複数チームで開発しているのか

たとえば、ファイルアップロードがないシステムであれば、アップロード処理の詳細な基準は優先度が下がります。一方、管理画面があり、個人情報を扱い、外部 API と連携するシステムであれば、認証、認可、ログ、Secret 管理、依存関係管理の基準はかなり重要になります。

すべてを一律に適用するのではなく、適用する理由と、適用しない理由を明確にすることが大切です。

基準は一度作って終わりではない

セキュアコーディング基準は、一度作って終わりではありません。むしろ、運用しながら育てるものです。

脆弱性診断で指摘された内容、コードレビューで繰り返し出る指摘、障害やインシデントで見えた弱点、フレームワークの更新、クラウドサービスの仕様変更、依存ライブラリの脆弱性などを基準へ反映していく必要があります。

ここを更新しないと、セキュアコーディング規約はすぐに形骸化します。作った瞬間は立派でも、実際の開発や運用で使われなければ意味がありません。

セキュアコーディングを開発プロセスに接続する

セキュアコーディングを本当に機能させるには、基準を文書として置くだけでは足りません。開発プロセスの中に接続する必要があります。

工程接続する観点
設計レビュー認証、認可、データ分類、ログ、例外処理、外部連携、脅威の前提を確認する
コードレビュー入力検証、権限チェック、Secret 混入、例外処理、ログ出力、危険な API 利用を確認する
自動テスト権限境界、異常系、入力値、API の失敗パターンを確認する
SAST / SCA / Secret scanning静的解析、依存関係、シークレット混入を機械的に検出する
脆弱性診断外部から見えるリスクを確認し、結果を基準へ戻す
リリース判断未対応リスクを把握し、受け入れるのか止めるのかを判断する

重要なのは、ツールを入れることではありません。ツールが出した結果を、どの基準で判断し、誰が対応し、どこまで対応すればリリースできるのかを決めることです。

まとめ

セキュアコーディングは、「気をつける」ことではありません。気をつけるだけでは、レビューも、テストも、リリース判断も安定しません。

必要なのは、OWASP Top 10、OWASP ASVS、OWASP Secure Coding Practices、IPA の資料などを足場にしながら、自分たちのシステムに合わせた判断基準を育てることです。

外部標準はゴールではありません。入口です。そこから、自社のアプリケーション、データ、運用、開発プロセスに合わせて、何を確認し、何を許容せず、何をリリース条件にするのかを決めていく必要があります。

セキュアコーディングとは、個人の注意力に依存する作法ではありません。組織として安全性を判断できる基準を作り、それを開発の中で育て続けることだと思います。

参考リンク

参考書籍

関連する記事

関連する記事
セキュアコーディングとは何か – OWASP / ASVS を使って基準を育てる

関連記事

Default Thumbnailサーバー要塞化はなぜ古く見えるのか – OS 防御から実行環境の統制へ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る