OWASP Top 10 2025:OWASP Top 10 2021からの変更点と企業が取るべきセキュリティ強化ポイント

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

OWASP Top 10 2025:OWASP Top 10 2021からの変更点と企業が取るべきセキュリティ強化ポイントアイキャッチ画像

OWASP Top 10はWebアプリケーションの主要なセキュリティリスクをまとめた世界的な基準です。2025年版では、ソフトウェアサプライチェーンに起因する問題や例外処理の不備など、新たなリスク項目が追加され、順位も変動しています。本記事ではこれらの新しい動向も踏まえ、各項目を平易に解説し、企業が取るべきセキュリティ対策の方向性を提示します。

はじめに

2025年11月、国際的なセキュリティ啓発コミュニティであるOWASP(オワスプ:Open Web Application Security Project)から、「OWASP Top 10 2025」が公開されました。前回の「OWASP Top 10 2021」より4年ぶりの公開となります。本記事ではOWASP Top 10 2025から追加された新たなリスク項目や順位変動を踏まえ、企業が取るべきセキュリティ対策の方向性を提示します。

OWASP Top 10とは

Webアプリケーションの代表的なセキュリティリスクをまとめた国際的なガイドラインで、意識向上を目的とする啓発資料です。全てのセキュリティ要件を網羅する標準というより、優先的な対策項目を示すリストと考えます。

OWASP Top 10 2025の特徴

今回の「OWASP Top 10 2025」では、ソフトウェア開発の全工程にわたる新しいリスクが反映されました。特に、依存ライブラリやCI/CD環境を含む「ソフトウェアサプライチェーンの不備」や、「例外処理(エラー処理)の不備」という2つの新カテゴリが追加されています。これにより、従来のコード脆弱性に加え、開発・運用プロセス全体に起因するリスクが明確に強調されました。

また、2021年版まで独立項目だった「サーバーサイドリクエストフォージェリ(SSRF)」はA01(アクセス制御)に統合され、権限回避系の攻撃に含まれるようになっています。

OWASP Top 10の概要、「OWASP Top 10 2021」のリスク項目一覧について、以下の記事で解説しています。あわせてぜひご覧ください。
OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

OWASP Top 10 2021からの主な変更点

A01: アクセス制御の不備 (Broken Access Control)

引き続き1位です。従来のアクセス制御不備に加え、サーバーサイドリクエストフォージェリ(SSRF)攻撃がこのカテゴリに含まれるようになりました。

A02: セキュリティ設定のミス (Security Misconfiguration)

2021年5位から2025年2位に上昇しました。サーバやアプリの初期設定ミスや不要なサービス公開など、設定不備のリスクが増加しています。

A03: ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)

2021年版のA06「脆弱で古くなったコンポーネント」から大幅に拡張され、2025年版に新設されたカテゴリです。依存パッケージやビルド環境への攻撃を含み、開発~配布の全過程におけるマルウェア侵入のリスクを扱います。

A04: 暗号化の失敗 (Cryptographic Failures)

前回2位から今回は4位に下降しました。古い暗号方式や不適切な暗号設定によって、機密データ漏洩のリスクが引き続き高い項目です。

A05: インジェクション (Injection)

前回3位から5位に下降しました。依然として多く検出されるリスクですが、他カテゴリの変動により相対的に順位が変わりました。

A06: セキュアでない設計 (Insecure Design)

2021年に新設された項目で、前回4位から6位になりました。設計段階でセキュリティを考慮しないことによるリスクを指し、脅威モデル不足などが該当します。最近は設計レビューや脅威モデルの導入が増えつつあります。

OWASP Top 10 2021およびセキュアなWebアプリケーション開発にむけてどのように取り組むべきかについて、以下の記事で解説しています。あわせてぜひご覧ください。
Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

A07: 認証の失敗 (Authentication Failures)

名称が「識別と認証の不備」から若干変更され、順位は7位で維持されました。ログイン機能やパスワード管理の不備などが含まれ、標準的な認証フレームワークの利用増加でやや改善傾向にあります。

A08: ソフトウェアとデータの整合性の不備(Software or Data Integrity Failures)

前回同様8位です。ソフトウェア更新時やデータ伝送時の改ざん検知の欠如を扱い、サプライチェーンより下層でのデータ改ざんリスクが対象です。

A09: ログ監視・アラートの不備 (Logging & Alerting Failures)

同じく9位を維持しました。ログ監視や侵入検知の仕組みが不十分で、攻撃検知が遅れるリスクを指します。名称も「セキュリティログとモニタリングの不備」から変更されています。

A10: 例外処理の不備 (Mishandling of Exceptional Conditions)

2025年に新設された新しいカテゴリです。エラー発生時の不適切な処理(例:内部情報露出やセーフティネットの欠如)により、システム全体の安全性が損なわれるリスクを扱います。

OWASP Top 10 2025のリスク項目詳細解説

A01: アクセス制御の不備 (Broken Access Control)

攻撃者が本来許可されていない操作やデータにアクセスできる脆弱性です。例として、URLやパラメータを操作して他ユーザーの情報を取得したり、管理者権限を取得したりする攻撃が挙げられます。

A02: セキュリティ設定のミス (Security Misconfiguration)

システムやアプリの初期設定・構成に誤りがある状態です。脆弱なデフォルト設定や、不要なサービスの有効化、パッチ未適用のサーバ起動などにより、本来防げる攻撃を許してしまいます。

A03: ソフトウェアサプライチェーンの不備 (Software Supply Chain Failures)

外部ライブラリやパッケージ管理システムが攻撃され、正規ソフトウェアにマルウェアが混入するリスクです。開発者の環境やCI/CDパイプラインを介して侵入するため、従来型のコード診断だけでは検知しづらい問題となっています。

A04: 暗号化の失敗 (Cryptographic Failures)

古い暗号方式や誤った暗号設定によって、暗号化すべきデータの機密性が損なわれるリスクです。例えば、弱い鍵長の使用や最新プロトコルの不採用により、攻撃者に通信内容を解読される危険があります。

A05: インジェクション (Injection)

ユーザ入力を十分に検証せずにSQL文やOSコマンド等に含めて実行することで、不正なコードが実行される脆弱性です。SQLインジェクションクロスサイトスクリプティング(XSS)などが代表例で、攻撃者がデータベース改ざんやセッションハイジャックを実行します。

A06: セキュアでない設計 (Insecure Design)

設計段階でセキュリティが考慮されておらず、必要な防御策(脅威モデルやセキュアアーキテクチャ)が欠落しているリスクです。実装以前の段階で脆弱性を取り除かないと、後工程では完全対応できない欠陥を内包します。

A07: 認証の失敗 (Authentication Failures)

ログインやセッション管理に欠陥があり、不正ログインを許してしまう脆弱性です。例えば、パスワードポリシー不備やセッションIDの固定化、二要素認証不備などにより、攻撃者が他人の権限を奪取する可能性があります。

A08: ソフトウェアとデータの整合性の不備(Software or Data Integrity Failures)

ソフトウェア更新やデータ取得時に改ざんを検知できない状態で、不正なコードやデータが実行されてしまうリスクです。例えば、更新ファイルやコンテナイメージが攻撃者によって差し替えられても気づかない場合が該当します。

A09: ログ監視・アラートの不備 (Logging & Alerting Failures)

インシデント発生時に監査ログが残らない、またはアラートが機能しない状態で、攻撃を見逃してしまうリスクです。攻撃検知や対策対応が遅れるため、被害が拡大する可能性があります。

A10: 例外処理の不備 (Mishandling of Exceptional Conditions)

エラー・例外発生時に適切な対処がされず、システムが想定外の動作をしたり機密情報を漏洩したりする脆弱性です。具体例として、エラーメッセージで内部情報を出力するものや、例外処理のループ抜けでシステム停止しないなどがあります。

OWASP Top 10 2025で注目すべきポイント

  • サプライチェーンリスクの急浮上
  • 例外処理カテゴリの新設が示す業界動向
  • コード脆弱性から“開発プロセスの安全性”への時代変化

OWASP Top 10 2025は、従来の入力検証など個別コード脆弱性に加え、サプライチェーンや設計、例外処理といったシステム全体に関わる根本原因を重視しています。企業はこれを踏まえ、開発プロセスや設計段階からの脆弱性予防策を強化する必要があります。

企業が取るべき対応(例)

  • 開発プロセス全体のセキュリティレビュー
  • サプライチェーン管理の強化
  • 設計段階のセキュリティ確保(脅威モデリング等)
  • ログ・アラート体制の見直し

情報システム部門やセキュリティ担当者は、今回のリスク項目をセキュリティ教育・セキュリティ診断・セキュリティ監査項目に組み込み、継続的な対策に活用しましょう。特にサプライチェーンや例外処理の項目は従来対応が十分でないことも多く、注力すべきポイントです。

まとめ

OWASPはTop 10に加え、SAMMやASVSなどのフレームワーク活用も推奨しています。OWASP Top 10は優先対策項目の一助と位置付け、組織全体のセキュリティ成熟度を高める施策を並行して検討することが望まれます。

脆弱性診断の活用

では、意図せず作りこまれてしまう脆弱性に、どう対処すればいいでしょうか。それには脆弱性診断を実施することが、最も有効な手段の一つと言えます。

脆弱性診断によって、システムにどのような脆弱性があり、どの程度のリスクがあるのか可視化され、その優先度に応じてセキュリティ対策を検討・実施することができます。

脆弱性診断を効果的に活用するには、システムの機能や取り扱う情報の重要度に応じて、実施時期や頻度を考慮することも大切です。セキュリティ事情は常に変化しています。日々新たな脆弱性が発見され、サイバー攻撃も巧妙化する一方です。また、何年も前に報告されたのに放置されがちな脆弱性が、改めて悪用されることもあります。健康診断と同様、脆弱性診断も定期的に実施することが重要なのです。

また、「SQAT® Security Report」では、セキュリティ事情に関するトピックをお伝えしております。情報収集の一助としてご活用ください。

【参考情報】

OWASP Top 10 2025リリースノート/Aikidoブログ(https://www.aikido.dev/blog/owasp-top-10-2025-changes-for-developers#:~:text=OWASP%20emphasizes%20that%20the%20Top,Application%20Security%20Verification%20Standard


BBSecの脆弱性診断サービス

弊社では、お客様のニーズに合わせて、様々な脆弱性診断サービスを提供しております。システムの特徴やご事情に応じてどのような診断を行うのが適切かお悩みの場合も、ぜひお気軽にご相談ください。

「毎日/週など短いスパンで定期診断して即時に結果を知りたい」

デイリー自動脆弱性診断「Cracker Probing-Eyes®」は、脆弱性の検出結果を、お客様側での簡単な操作で、日々確認できます。導入のための設備投資が不要で、コストを抑えつつ手軽に診断できます。 世界的なセキュリティ基準をベースにした弊社独自基準を設け、シグネチャの見直しも弊社エンジニアが定期的に行うことで、信頼性の高い診断を実現しております。

「システム特性に応じた高精度な診断をしたい」

対象システムの機能が複雑である、特にミッションクリティカルであるなどの理由により、広範囲かつより網羅性の高い診断をご希望の場合は、弊社エンジニアが手動で実施する「SQAT®脆弱性診断サービス」をおすすめします。 Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、トータルコストを低減しつつ、さらなるクオリティ向上を実現する手法です。セキュアなWebアプリケーション開発プロセスの実現のためには、この考え方が重要です。しかし、多くの企業・組織にとって、DevSecOpsの実現には様々な課題があるのが実情です。 本記事では、開発の現場担当者が感じている課題を整理したうえで、セキュアなWebアプリケーション開発にむけて、どのように取り組むべきかについてご紹介します。

OWASP Top10に新たな項目

2021年9月、「OWASP Top 10 2021」が発表されました。Webアプリケーションセキュリティに関する最も重大な10項目のリスクを取り上げたものです。前回発表された2017年版(OWASP Top 10 2017)から4年ぶりの更新となります。

※OWASP(Open Web Application Security Project)…Webアプリケーションセキュリティに関する国際的コミュニティ

2017年版Top 10の各項目は、2021年版ではそれぞれ順位を上げ下げしつつ、一部統合されて7項目となり、完全に消えたものはありませんでした。そして、新たなカテゴリが3項目追加される形で計10項目となりました。

OWASP Top 10 – 2021

A01:2021 –アクセス制御の不備
A02:2021 –暗号化の不備
A03:2021 –インジェクション
A04:2021 –NEW セキュアでない設計
A05:2021 –セキュリティ設定のミス
A06:2021 –脆弱かつ古いコンポーネントの使用
A07:2021 –識別と認証の不備
A08:2021 –NEW ソフトウェアとデータの整合性の不備
A09:2021 –セキュリティログとモニタリングの不備
A10:2021 –NEW サーバサイドリクエストフォージェリ(SSRF)

NEW」は2021年度版で追加された項目
https://owasp.org/Top10/ より弊社和訳

新設された3項目のうち2つが、システム開発のプロセスにかかわる内容に焦点を当てています。

● セキュアでない設計(Insecure Design)
  ポイント:設計における管理策の欠如、ロジックの検証が不十分である等
  推奨対策:シフトレフトによる開発ライフサイクルの実践 等
● ソフトウェアとデータの整合性の不備(Software and Data Integrity Failures)
  ポイント:安全でないデシリアライゼーション、
  信頼できないコンポーネントの利用、CI/CDパイプラインにおける検証不備 等
  推奨対策:データの整合性チェック、コンポーネントのセキュリティチェック、
  CI/CDのセキュリティ対策

※シフトレフト…開発工程のより早い段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方

ここで推奨対策例として出てきた「シフトレフト」と「CI/CDのセキュリティ対策」はアプリケーション開発プロセス手法である「DevSecOps」実現に欠かせません。

アプリケーション開発における「DevSecOps」

DevSecOpsは、「DevOps」―開発(Development)チームと運用(Operations)チームが相互協力しながら品質を向上させ続けるサイクル―の一環に、セキュリティ(Security)を組み込むことで、結果的にトータルコストも削減でき、サービスの価値をさらに向上させる手法です。

DevSecOpsとシフトレフト(Shift Left)について、詳しくは過去記事「前倒しで対処 ー セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とはー」をご覧ください。

“セキュリティ”が組み込まれていないと…

DevSecOpsにおけるシフトレフト

DevSecOps実現のためには、「シフトレフト」の考え方が大切になります。セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

DevSecOpsにおけるCI/CDのセキュリティ対策

“Sec”が入らないDevOpsにおいては、設計・実装を小さな単位で素早く繰り返し実行していく手法(アジャイル開発手法等)が一般的ですが、このスピード感をサポートするのが「CI/CD」です。

CI/CDの説明図

CI(Continuous Integration)は継続的インテグレーション、CD(Continuous Delivery)は継続的デリバリの略です。アプリケーション開発におけるコード、ビルド、テスト、デプロイといった各作業を自動化して継続的にサイクルを回せるようにする仕組みを指します。オンプレミスでもクラウド上でも展開可能で、CI/CDを提供する様々なツールやサービスが提供されています。

ただし、CI/CDはセキュリティ上のリスクにもなりえます。CI/CD環境に脆弱性が潜んでいて不正アクセスされるようなことがあれば、そこを発端に組織全体が危険にさらされる恐れもあるのです。このため、DevSecOps実現のためには、CI/CDのセキュリティ対策が不可欠です。

セキュアでない設計によるリスク

では、シフトレフトが意識されていない、セキュアでない設計にはどのようなものがあるでしょうか。ユーザの認証に用いられる情報がIDと生年月日である場合、生年月日は他者が容易に知りうる情報なので、本人確認の仕様としてはふさわしくないことがわかります。例えば、補助金の申請システムにおいて、申請者の本人確認や申請内容の検証が甘いために容易に複数の虚偽申請を許してしまうようでは、実用に耐えるとはいえないでしょう。

こうしたセキュリティについて考慮されていない設計は、弊社の脆弱性診断でも相当数検出されています。アカウントロックアウトが設定されていない、Webサーバからのレスポンスにクレジットカード番号のような重要情報が含まれている、個人情報が暗号化されないまま送信されている、といった例は多々見受けられます。放置しておくと、個人情報や機密情報の漏洩を引き起こしかねません。

プライバシーマーク推進センターによって報告された、2020年度「個人情報の取扱いにおける事故報告集計結果」によると、誤送付や紛失・盗難によらない情報漏洩のうち、プログラムやシステムにおける設計・作業ミスを原因とするものは102件あったとのことです。大した件数ではないようにも見えますが、インシデント1件あたりの漏洩件数が増加傾向にあるとの報告もあり、影響の大きさに注意が必要です。また、これらはあくまで報告があったものだけの数ですので、セキュアでない設計によるアプリケーションが人知れず稼働したままになっている危険性は大いにあるでしょう。

一般財団法人日本情報経済社会推進協会(JIPDEC)プライバシーマーク推進センター
2020年度「個人情報の取扱いにおける事故報告集計結果」(2021年10月15日更新)より

CI/CDパイプラインにおける検証不備によるリスク

コードカバレッジツールへのサイバー攻撃の概要図

CI/CDパイプラインに起因するリスクの方はどうでしょう。2021年にあるインシデントが発生しました。ソースコードのテスト網羅率を計測するコードカバレッジツールがサイバー攻撃を受けた結果、このツールを使用していた国内企業のCI環境に不正アクセスされ、重要情報を含む1万件以上の情報漏洩につながったというものです(右図参照)。

自動化、高効率化ツールによる利便性を享受するためには、そこに係るすべてのツールや工程におけるセキュリティチェックを行う必要があるのです。

DevSecOps実現を阻む壁

さて、安全なWebアプリケーション開発の重要性は認識できているとしても、実現できなければ意味がありません。とはいえ、DevSecOps実現には、多くの企業・組織において様々な障壁があるものと思われます。今回は主な障壁を「組織」と「技術」のカテゴリに分類し、それらの問題点および解決の糸口を考えていきます(下図参照)。

DevSecOps実現のためにできること

DevSecOpsに特化したガイドラインが存在しないというのも、対応を難しくしている要因の1つかもしれません。とはいえ、Webアプリケーション開発におけるセキュリティ対策の課題を考慮すると、鍵となるのはやはりシフトレフトです。シフトレフトを意識しながら、システム開発プロセスに組み込まれたセキュリティ対策を実践する例として、以下のようなイメージが考えられます。

Webアプリケーション開発におけるセキュリティ対策実施の背景には、Webアプリケーションの規模や利用特性ばかりでなく、開発組織の業務習慣や文化等、様々な事情があることでしょう。例えば、セキュアコーディングのルール整備やスキルの平準化が不十分という課題があれば、まずは現場レベルでそこから取り組んでいくといったように、信頼されるWebアプリケーション構築のために、少しずつでもDevSecOpsの実装に近づけていくことが肝要です。

【参考】システム開発プロセスのセキュリティに関するガイドライン・資料等

●NIST
 Security Assurance Requirements for Linux Application Container Deployments
 https://csrc.nist.gov/publications/detail/nistir/8176/final

●OWASP
 OWASP Application Security Verification Standard
 https://github.com/OWASP/ASVS

●内閣サイバーセキュリティセンター(NISC)
  情報システムに係る政府調達におけるセキュリティ要件策定マニュアル
  https://www.nisc.go.jp/active/general/pdf/SBD_manual.pdf

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像

プログラミング言語の脆弱性対策を考える

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

プログラミング言語のセキュリティは、組織のシステム全体のセキュリティに大きな影響を与えます。「アプリケーションの脆弱性の半数はC/C++に起因する」という報告もあり、プログラミング言語における脆弱性の特徴を理解し、適切な対策を講じることは、いまや組織のセキュリティに不可欠な取り組みといえます。本記事では、プログラミング言語の最新動向、脆弱性が生まれる背景を解説します。

プログラミング言語のトレンド

言語 使用している
開発者の比率
JavaScript69.7%
HTML/CSS 62.4%
SQL 56.9%
Python 41.6%
Java 38.4%
Bash/Shell/PowerShell 34.8%
C# 32.3%
TypeScript 28.3%
PHP 25.8%
C++20.5%
C 18.2%
Go 9.4%
Kotlin8.0%
言語 使用している
開発者の比率
Ruby7.5%
VBA6.2%
Swift6.1%
R5.5%
Assembly4.9%
Rust4.8%
Objective-C4.4%
Scala3.9%
Dart3.7%
Perl3.3%
Haskell1.8%
Julia0.9%

Stack Overflow Developer Survey 2020 より弊社作成
https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

JavaScript、HTML/CSS、SQLなどが上位に並んでいますが、皆さんの予想どおりでしょうか?ちなみに冒頭で述べた、「脆弱性の半数」を生み出すとされるC/C++に関しては、昨今IoTデバイスなどの組込機器やデスクトップアプリケーション等に利用目的が収れんしてきているといわれ、その使用率は減少傾向にあります。また、リストには記載がありませんが、日本に限ってみると、COBOLなどのレガシーシステム向けの言語がいまだ根強いシェアを保っているのはご存じの方も多いことでしょう。

なお、弊社での診断傾向としては、JavaScriptのほか、Pythonが目立っています。今後については、「オーバーヘッドが少なく、静的型付け言語である」という特徴をもつTypeScriptなどが、軽量さの望まれるサーバレス環境での需要につながるものとみられます。また、Android端末向けにKotlinの需要も高まると予測しています。以下、ご参考に、プログラミング言語と主な利用分野のマッピングを示します。

図:主要プログラミング言語と現在利用されている代表的分野

プログラミング言語の脆弱性 ― 言語ごとに異なる特徴を知る

プログラミング言語の脆弱性を考える場合、特定の言語に固有のものと、言語間で共通のものを押さえておく必要があります。

例えば、C/C++では、その脆弱性の7割がメモリハンドリングのミスに起因するといわれており、メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにすることが、重要なセキュリティ対策となります。そのほか、言語固有の脆弱性として代表的なものは、Javaでの「安全でない入力に対するデシリアライゼーション」の問題、JavaScriptでの「パストラバーサル」や「暗号」の問題、PHPでの「クロスサイトスクリプティング(XSS)」や「SQLインジェクション」などになります。

なお、2000年代後半以降にリリース開始された比較的新しいプログラミング言語(Kotlin、Golang、Rustなど)については、上記とは若干が異なる観点からの注意が必要です。まず、こうした言語では、セキュアコーディングのための様々な関数やライブラリなどが用意され、セキュリティに関する手厚い対策が組み込まれているのですが、その一方で、セキュリティの機能が増えれば増えるほど関連ドキュメントが膨大になり、把握が追いつかないという課題が生じています。例えば、Kotlinの場合、Kotlin自体のドキュメンテーションではセキュリティ関連の記述はNULLの安全性に触れる程度なのですが、セキュアコーディングに取り組もうとすると、膨大なAndroid Developer Guideを参照する必要があります。また、相互運用性への配慮も必要です。例えばKotlinやGolangはJavaと一緒に利用するケースが多いため、こうした言語で開発を行う場合には、Java側の環境を考慮したうえでのセキュアコーディングが不可欠になり、それが開発の難易度を押し上げているという状況があります。

プログラミング言語の脆弱性 ― 全言語に共通の特徴を知る

続いては、すべての言語に共通する脆弱性です。これは大きく以下の3つに分類できます。

情報漏洩
・表示する必要のない機微な情報(ユーザ名やIDなど)の露呈
・不要なシステム情報の公開
入力検証の不備
・不正なパラメータの許容、XSS、SQLインジェクション
・HTTPヘッダ分割
認可・認証関連の脆弱性
・オブジェクトやファイルなどへのアクセス認可の不備
・認証情報の保護機構や暗号化の不備

脆弱性が発生する背景

以上述べてきたような脆弱性は、なぜ発生するのでしょう。その背景には、開発現場における以下のような課題があると考えられます。

・プロジェクトベースで人員が変わることが多く、知識や経験の共有が行われることがまれ
・脆弱性やセキュアコーディングに対する意識、知識レベルがプログラマによって異なる
・ギリギリのスケジュールでプロジェクトが進むことが多く、知識や経験の共有まで手が回らない
・セキュリティへの対応が明示的な業務として遂行されるのではなく、プログラマやプロジェクトメンバー1人1人の善意に依存する面が強い

具体例で説明しましょう。先ほど、PHPではXSSやSQLインジェクション等の脆弱性がよく見られると述べました。しかし、PHPでも、バージョン4以降であれば「htmlspecialcharacters」という関数を利用することでXSSの回避に必要な特殊文字のエスケープ処理ができます。SQLインジェクションについても、プレースホルダの利用による回避が可能です。このように、すでに対策が存在する場合であっても、プログラマ間で知識や経験の共有が行われていない場合、ソースコード診断やステージング環境でのWebアプリケーション脆弱性診断が実施されない限り、脆弱性は放置されることになります。また、「機微な情報の露呈」という問題については、個人情報保護などの法制度に対する知識が共有されておらず、そもそも課題として認識されていないという可能性があります。なお、知識共有のハードルは、セキュリティ機能が充実しているゆえに把握すべき情報量が膨大で、他の言語との互換性等まで含めた配慮が求められる最近のプログラミング言語では、さらに高いといえるでしょう。

こうした課題を解決するには、プログラマ個人の知識・技術レベルを高めることはもちろんですが、それ以上に重要なのは、組織を挙げての体系的な取り組みであるといえます。

先手を打った対処がカギ

そこでぜひ取り入れたいのが、プログラミング言語に関わる脆弱性が生じていないかを、開発の初期段階から継続的に点検する取り組みです。これは「DevSecOps」とも呼ばれる考え方で、「開発(Dev)」・「運用(Ops)」に「セキュリティ(Sec)」の観点を組み込むことで、システムのセキュリティ強化を図るものです。開発プロジェクトは常に時間との闘いですが、だからといって脆弱性への対応を先送りしてはなりません。対処が事後になればなるほど、影響範囲が広がり、コストも肥大する恐れがあります。

以前の記事でも解説しましたが、何よりも、初期段階からの取り組みが重要です。例えば、人員の流動が激しいプロジェクトベースの現場では、開発の早期からソースコード診断を含むテスト活動を実施し、脆弱性をコード単位で効率的に解消していくことによって、各段階で積み上げられた知識や経験を、後続の工程で活用することが可能になります。また、近年主流になっているアジャイル型の開発手法でもこれは有効で、短い開発サイクルが繰り返される中で早期に・こまめにテストや修正を行うようにすることで、セキュリティを強化できるのみならず、プロジェクト全体の工数も抑制できます。なお、短いサイクルでテストを回すには、SaaSタイプのソースコード診断サービスの利用を検討してもよいでしょう。

先手を打って脆弱性に対処できれば、脆弱性の要因となっていた様々な課題に取り組む余裕も生まれます。結果として、セキュリティと開発効率をともに高められる好循環を実現できるのではないでしょうか。

Security NEWS TOPに戻る
バックナンバー TOPに戻る


資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像
セキュリティトピックス動画申し込みページリンクへのバナー画像