ウェブアプリケーションセキュリティ 第2版

第26章 脆弱性の発見 脆弱性の発見

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

セキュアにアーキテクトされたコードが設計され、記述され、レビューされた後、脆弱性がその隙間をすり抜けることがないように、パイプラインが整備されるべきである。一般的に、最良のアーキテクチャを持つアプリケーションは、最も脆弱性が少なく、最もリスクの低い脆弱性を経験する。その後、十分にセキュアなコードレビュープロセスが実施されているアプリケーションは、そのようなプロセス がないアプリケーションよりも脆弱性が少なくなる（しかし、デフォルトでセキュアなアーキテクチャのアプリケーションよりも多くなる）。

安全にアーキテクトされ、十分にレビューされたアプリケーションであっても、時折脆弱性の餌食になる。脆弱性はレビューをすり抜けることもあれば、アプリケーションが異なる環境で実行されたり、意図した環境がアップグレードされたりしたときに、予期せぬ振る舞いの結果として現れることもある。その結果、プリプロダクション・コードではなく、プロダクション・コードを対象とした脆弱性発見プロセスが必要になる。

セキュリティ・オートメーション

脆弱性を発見するための初期化段階として、アーキテクチャとレビューの段階を経て、自動化の段階に入る。脆弱性発見を自動化することは不可欠だが、それはすべての脆弱性を発見できるからではない。その代わり、自動化は（通常）安価で、効果的で、長続きする。

自動化された発見テクニックは、アーキテクトやコードレビュー担当者の目をすり抜けるような、コード中の日常的なセ キュリティ上の欠陥を発見するのに適している。自動化された発見テクニックは、アプリケーションの関数に特有な論理的な脆弱性を発見することや、有効であるために「連鎖」を必要とする脆弱性（複数の弱い脆弱性が一緒に使われると強い脆弱性を生み出す）を発見することは得意ではない。

セキュリティの自動化にはいくつかの形態がある：

• 静的解析

• 動的解析

• 脆弱性回帰テスト

これらの自動化にはそれぞれ別の目的があり、アプリケーション開発ライフサイクルにおける位置づけがある。

静的解析

あなたが書くべき自動化の最初のタイプは、おそらく最も一般的な、静的解析である。静的解析は、ソースコードを見て、構文エラーやよくあるミスがないかコードを評価するスクリプトである。静的解析は、開発中にローカルで行うこともできるし（リンター）、ソースコードリポジトリに対してオンデマンドで行うことも、メインブランチにコミット/プッシュするたびに行うこともできる。

以下のような堅牢で強力な静的解析ツールが数多く存在する：

• Checkmarx (ほとんどの主要言語-有料)

• PMD (Javaフリー)

• バンディット（Pythonフリー）

• ブレーキマン（Rubyフリー）

これらのツールはそれぞれ、テキストを含むドキュメントの構文を分析し、コード・ファイルを表現するように構成できる。これらのツールはいずれも、実際にコードを実行しない。それは、動的解析、あるいは、 ランタイム解析と呼ばれる次のカテゴリーに移行するからである。静的 分析ツールは、OWASPのトップ10の脆弱性を探すように設定されるべきである。

このようなツールの多くは、主要な言語用に無料と有料の両方で存在する。静的解析ツールはゼロから書くこともできるが、社内で作ったツールは、大規模なコードベースではうまく機能しないことが多い。 ...