開発者とセキュリティチームのための、プロアクティブなAppSecと継続的な脆弱性管理

現代のソフトウェア開発を取り巻くサイバーセキュリティリスクはどのように拡大し、CISOを悩ませているのでしょうか？

開発者やセキュリティチームが直面する脅威は増え続けています。巧妙化するオープンソースやベンダー管理のサプライチェーン攻撃から、プロンプトインジェクションなどのAI生成コードに起因する脆弱性、GitHub Copilotによる不適切なコードセキュリティまで、脅威は多岐にわたります。現代のアプリケーションは、npm、PyPI、RubyGemsなどで見つかるオープンソースコンポーネントやコンテナ化されたデプロイに大きく依存することが多く、その複雑さが課題に拍車をかけています。 

こうしたリスクの規模と複雑さを考えると、脆弱性管理の自動化は不可欠です。手作業によるサイバーセキュリティプロセスでは、潜在的な脆弱性やソフトウェア開発の量とスピードに対応できません。自動化は、セキュリティ上の問題の特定と修正を迅速化するだけでなく、セキュリティチームが日常的に行うプロセスを、ソフトウェア開発ライフサイクルのあらゆる段階で一貫して実施できるようにします。

特定の領域における継続的な脆弱性管理の重要性

• オープンソースコンポーネントへの依存の高まり：オープンソースコンポーネントは、現代のソフトウェア開発に広く浸透しています。アプリケーション開発者の開発を加速し、コスト削減にも役立つ一方で、重大なセキュリティリスクももたらします。XZバックドアやSolarWindsの情報漏えいのような注目度の高いサプライチェーン攻撃は、オープンソースの依存関係や、ベンダーが管理するクローズドソースコンポーネントの脆弱性が悪用された場合、被害が広範囲に及ぶ可能性を浮き彫りにしました。

• 開発におけるAI生成コードの利用拡大：ソフトウェア開発での生成AI（GenAI）の普及は、機会と課題の両方をもたらします。GenAIはコーディング作業を大幅に加速できますが、新たな脆弱性を生み出すこともあります。AI生成コードには、経験豊富な開発者なら通常考慮するセキュリティ上の配慮が欠けている場合があり、セキュリティ上の隙につながる可能性があります。その一例が、GitHub CopilotがReactにXSSを持ち込んだ事例です。

• コンテナ化アプリケーションの急速な普及：コンテナ化アプリは、現代のソフトウェアをデプロイする標準的な方法になっています。コンテナには、環境間で一貫性を保てることや、スケールしやすいことなど、多くのメリットがあります。一方で、コンテナイメージに含まれる脆弱性の管理など、新たなセキュリティ課題も生まれます。そのため、開発者が最適なコンテナイメージの選び方やコンテナ活用の基本的なヒントを学ぶことも重要ですが、Dockerコンテナイメージの脆弱性を自動的に管理することも欠かせません。

もう少し詳しく見ていきましょう…。注目度の高いサプライチェーン攻撃の別の例に、攻撃者が人気のコードカバレッジツールの脆弱性を悪用して機密データにアクセスしたCodecovへの攻撃があります。開発者の日常業務には、オープンソースの依存関係に伴うリスクの管理も含まれます。オープンソースの依存関係は、コードベースに直接的な脆弱性と推移的な脆弱性の両方を持ち込む可能性があります。直接的な脆弱性は明示的に追加したライブラリに存在し、推移的な脆弱性はそれらのライブラリが依存するコンポーネントに存在します。こうしたリスクを手作業で管理するのは大変であり、自動化は堅牢なセキュリティ戦略に欠かせません。

GenAIについても、GitHub CopilotやChatGPTのようなAIコードアシスタントは、実際に脆弱性を生み出す可能性があります。GenAIは、意図せず安全でないコーディング手法を取り入れたり、状況に応じたセキュリティ要件を認識できなかったりすることがあります。たとえば、AIモデルがSQLインジェクションやクロスサイトスクリプティング（XSS）攻撃に対して脆弱なコードを生成する場合があります。そのため、アプリケーションのセキュリティを維持するには、AI生成コードの監視と保護が重要です。 

新たなコンテナ脆弱性への対応の難しさは、セキュリティチームにとっても例外ではありません。新しいコンテナ脆弱性が次々と発見され、対応に追われることもあります。潜在的な悪用を防ぐには、脆弱性を一つひとつタイムリーに特定し、修正する必要があります。この複雑な課題に対処し、コンテナセキュリティを効果的に管理するには、セキュリティの専門知識を備えた自動化ソリューションが求められます。

コンテナの脆弱性は、アプリケーション全体のセキュリティに大きな影響を及ぼします。脆弱なコンテナイメージが一つあるだけで、アプリケーションスタック全体が危険にさらされる可能性があります。Snyk Containerのようなツールは、コンテナイメージの脆弱性の特定と修正を自動化します。Snyk Containerは、脆弱性の数を最小限に抑える新しいベースイメージタグを提案し、コードリポジトリを更新するプルリクエストを自動作成できます。

こうしたAppSecのサイバーセキュリティ脅威を、どのように軽減できるでしょうか？

SnykによるプロアクティブなAppSecと継続的な脆弱性管理

AI生成コードに伴うリスクを軽減するには、Snyk Codeのようなツールの利用をご検討ください。Snyk DeepCode AIを搭載したこの高速なSASTツールは、プラグインを使って開発者のIDEに直接統合できます。セキュリティに特化したデータで学習し、脆弱で安全でないコードを認識するため、開発の早い段階で問題を特定し、対処できます。

Snyk DeepCode AIの利用開始は簡単です。Visual Studio Code、IntelliJ IDEA、VS Code、PyCharmなど、一般的なIDEに対応しています。 

Visual Studio CodeにSnyk DeepCode AIをインストールして統合する手順

1. Snyk拡張機能をインストールする：

• Visual Studio Codeを開きます。

• ウィンドウのサイドバーにあるアクティビティバーから、拡張機能アイコンをクリックして拡張機能ビューを開きます。

• 「Snyk」を検索し、Snyk拡張機能の「インストール」をクリックします。

2. Snykに認証する：

• インストール後、Snykアカウントで認証するよう求められます。

• 画面の指示に従って、こちらからログインまたは登録してください。

3. Snyk DeepCode AIを有効にする：

• 認証後、アクティビティバーからSnykビューを開きます。

• Snyk DeepCode AIを有効にして、コードの脆弱性スキャンを開始します。
  

インストールすると、サイドバーのSnykロゴに、オープンソースの依存関係、自作コード（GenAIが生成したコードを含む）、IaCで見つかった脆弱性やセキュリティ上の問題が表示されます。

開発者がIDEで安全でないコードパターンを特定できるSASTツールのメリット

1. リアルタイムのフィードバック：コードを書くと、Snyk DeepCode AIがリアルタイムで解析し、潜在的なセキュリティ上の問題をすぐに知らせます。これにより、脆弱性がコードベースに定着する前に対処できます。

2. AIによる分析：このAIモデルは、セキュリティに特化した膨大なデータセットで学習しているため、GenAIや不適切なプログラミング手法によって生じたものも含め、安全でないコーディングパターンを認識できます。

3. シームレスな統合：Snyk DeepCode AIはIDEに直接統合されるため、開発者のワークフローになじみ、業務への影響を抑えながら生産性を高めます。

GenAIが持ち込んだ脆弱性を軽減する例を見てみましょう。このプロジェクトでは、GitHub Copilotを使って、OpenAI APIに問い合わせるExpressのPOSTエンドポイントルートのコードを自動補完し、res.send()でブラウザーに応答を送信しました。

しかし、このペイロードの応答がブラウザー上に直接レンダリングされるとしたらどうでしょうか。このリクエストの送信にデフォルトのtext/html Content-Typeヘッダーが使われると、クロスサイトスクリプティングの脆弱性が実行中のアプリケーションに影響を及ぼします。どう対処すればよいでしょうか？

31行目の上にある注釈のとおり、Snykはこのセキュリティ上の問題の修正を提案しています。提案をクリックすると、数秒でSnyk DeepCode AI拡張機能がres.send()をres.jsonに置き換える修正案を提示しました。

res.json(response.choices[0].message.content);

この変更により、Expressアプリケーションは応答のcontent-typeをapplication/jsonに設定します。これは汎用的なテキストであり、<script>alert()</script>のようなテキストも使用できます。

開発者はIDEでSnykを活用することで、基盤となるSnyk DeepCode AIエンジンを使って脆弱性を早期に特定し、軽減できます。これにより、コードを最初から安全に保てます。オープンソースのサプライチェーンやGenAI生成コードに関するリスクが常に存在する今日、このようなプロアクティブなアプリケーションセキュリティのアプローチは不可欠です。

Snyk Open Sourceによる依存関係管理の自動化

Snyk Open Sourceは、オープンソースの依存関係に伴うリスクを開発者やセキュリティチームが管理できるよう支援する強力なツールです。オープンソースライブラリへの依存が高まるなか、堅牢で自動化された依存関係管理の重要性はかつてないほど高まっています。Snyk Open Sourceは、包括的な脆弱性スキャンと修正機能を提供し、プロジェクトの安全性とコンプライアンスを確保します。

先ほどのNode.jsアプリケーションではSQLiteの依存関係も使用していますが、Snykは次のようにセキュリティ上の問題を知らせてくれます。

この脆弱性情報から、どの推移的依存関係がセキュリティリスクを引き起こしているのか、また可能であればどう軽減できるのかを把握できます。この場合、推移的依存関係のinflightに中程度の脆弱性が検出されています。

Snykは、ロックファイルと依存関係が古くなっている可能性を検出したため、修正方法を見つけられませんでした。では、GitHubのコードリポジトリをSnykにインポートした場合の自動化を見てみましょう。インポートすると、Snykアプリケーションに次の情報が表示されます。

ここからは、パッケージマニフェストでセキュリティ脆弱性が検出されると、Snykが依存関係のアップグレードを提案するプルリクエストを自動で作成します。

依存関係の管理は、プロジェクトに直接追加したライブラリだけにとどまりません。直接依存関係によって取り込まれる推移的依存関係も、脆弱性の原因となる可能性があります。Snykは、直接依存関係と推移的依存関係の両方にある脆弱性を的確に特定し、修正します。

次の例を見てみましょう。

{
  "dependencies": {
    "express": "^4.17.1",
    "lodash": "^4.17.20"
  }
}

この例では、expressとlodashが直接依存関係です。しかし、expressには独自の依存関係があり、それらにもさらに依存関係があるかもしれません。Snykは依存関係ツリー全体をたどり、あらゆる階層の脆弱性を特定して対処します。

コンテナの脆弱性管理において、Snyk Containerはベースイメージのタグをセキュリティパッチで常に最新の状態に保つ負担を軽減します。

Snyk Containerは、開発者やセキュリティチームがコンテナの脆弱性を効果的に管理できるよう支援する包括的なソリューションです。コンテナ化されたアプリケーションのワークロードはエンタープライズで広く利用されており、こうした環境の保護も必要とされています。Snyk ContainerはCI/CDパイプラインにシームレスに統合され、コンテナイメージの脆弱性を継続的に監視し、プロアクティブな修正を実現します。

Snyk Containerの特長の一つは、コンテナイメージの脆弱性に対処するプルリクエストの作成を自動化できることです。この自動化により、コンテナイメージを安全に保つために必要な手作業が大幅に減り、開発者とセキュリティチームの双方に大きなメリットをもたらします。

Snyk ContainerがDockerfile内の脆弱なパッケージを更新するプルリクエストを自動作成する例を見てみましょう。

FROM node:14.1.0
RUN npm install express
COPY . /app
CMD ["node", "/app/index.js"]

Snyk Containerが脆弱性を検出すると、問題を緩和するために必要な変更を加えたPRを自動生成します。これには、脆弱なパッケージの更新やセキュリティパッチの適用が含まれる場合があります。このプロセスを自動化することで、Snyk Containerは脆弱性に速やかに対処し、攻撃にさらされる期間を短縮します。

推奨されるベースイメージを使用することで、コンテナイメージ内の脆弱性の数を大幅に減らし、アプリケーション全体のセキュリティを強化できます。

Snyk Containerはこのベースイメージに複数の脆弱性を検出し、イメージと関連する依存関係を更新するPRを自動生成しました。チームはこれらのPRをすばやく確認してマージし、プルリクエストをマージしてCI/CDパイプラインのテストが問題なく通ることを確認することで、わずか数秒で脆弱性の数を30%以上削減できました。

このプロアクティブなアプローチにより、アプリケーションのセキュリティ態勢が向上しただけでなく、開発者は脆弱性の管理に追われることなく、新機能の開発に貴重な時間を充てられるようになりました。