脆弱性をより迅速に検出するためのSASTルールメンテナンスの最新化

Snyk Codeは、ユーザー向けのルールセットを生成・メンテナンスすることで、多くの静的コード解析ツールとは一線を画しています。これにより、一般的な脅威や新たに発見された脅威への対策を支援します。最近のHubの記事では、攻撃者がJavaScriptオブジェクトのプロトタイプを変更、つまり「汚染」し、さまざまな悪意ある操作を実行できる新たなJavaScriptの脆弱性、プロトタイプ汚染について解説しました。

この記事では、プロトタイプ汚染を例に、Snyk Codeのルールメンテナンス機能が開発者やセキュリティ担当者によるアプリケーションの保護にどう役立つかをご紹介します。この記事ではプロトタイプ汚染を詳しく掘り下げませんが、詳しく知りたい方はSnyk Learnのレッスンを受講するか、先ほどご紹介したHubの記事をご覧ください。

ルールセットをメンテナンスする従来の方法

静的アプリケーションセキュリティテスト（SAST）ツール、ひいては静的コード解析ツールの品質は、そのルールセットの品質によって大きく左右されます。簡単に言えば、ツールはソースコードをデータ構造に変換し、これらのルールを使って悪意あるパターンを検索します。最新のスキャナーの多くでは、ルールは論理プログラミングと呼ばれる、やや一般的でない形式で記述されます。

ルールセットの作成とメンテナンスは簡単ではありません。論理プログラミングに加え、スキャン対象の言語やライブラリに関する深い知識が必要です。ルールを作成した後も、デバッグという課題があります。本番環境で使う前に実際のコードでテストする必要があり、何時間もかかることもあります。そのため、調査1によると、開発者が設定を変更することはほとんどありません。カスタムルールが有効なケースもありますが、大半の場合、ツールはそのまま使えるべきです。

注：カスタムルールが有効なケースはごく限られています（該当する方はぜひお知らせください）。大半の場合、ツールはユーザーが手を加えなくても「そのまま使える」べきです。

Snyk Codeでルールメンテナンスを最新化

Snyk Codeは異なるアプローチを採用しています。ルールセットは製品の一部であり、ツールを使える状態にするためにお客様がルールをメンテナンスする必要はないと考えています。「カスタムルール」はSASTツールに欠かせない機能だとされる業界において、Snykはユーザーにシンプルなソリューションを提供します。セキュリティの専門家が責任を持ってルールセットを構築・メンテナンスし、強力で高速なエンジンを使って膨大な数のオープンソースプロジェクトをテストおよびトレーニング用データセットとして活用します。Snykの「human-in-the-loop」体制では、人が継続的に結果を監視・確認し、品質管理を担うため、お客様が行う必要はありません。

ルールメンテナンスに取り組むSnykのエンジニアの一人が、セキュリティ研究者のAlessio Della Liberaです。約1年前にSnykに入社しました。Snyk Code独自のアプローチについて尋ねると、彼は「[…] ある種のループのようなものです。何かを変更し、データセットの結果と照らし合わせて変更を確認するのに数分しかかかりません。これほど速く反復できるのは非常に役立ちます」と説明しました。

さらに詳しく

オープンソースプロジェクトのトレーニングセットは、スキャン結果やユーザーからのフィードバックに基づき、継続的に監視・更新されています。この監視の過程で、Liberaは既存ルールの一つが要件どおりに動作していないことに気付きました。

ルールを変更してテストしたところ、二つの結果が目を引きました。appwrite.ioというオープンソースプロジェクトには、litespeed.jsライブラリのコピーが含まれていました。公式サイトによると、「Appwriteはセルフホスト型ソリューションで、開発者がバックエンドの主要なニーズを管理するための、使いやすく統合も簡単なREST API群を提供します」。Snyk Codeは、マーケットプレイス経由で入手したライブラリとプロジェクト自体の両方で、同じ問題を検出しました。

appwrite.ioの稼働中のインスタンスで（たとえばmywebsite.com上で実行している場合）、攻撃者はmywebsite.com/auth/signup?__proto__[polluted]=yesを呼び出せます。ブラウザーの開発者ツールでJavaScriptの状態を確認すると、pollutedというメンバーが追加され、その値がyesになっていることがわかります。この問題の悪用方法を調査する中で、Liberaは悪意あるWebサイトがこの脆弱性を利用してクロスサイトスクリプティング（XSS）攻撃を引き起こせることを発見しました。

メンテナーへの報告

Appwriteのプロジェクトメンテナーに報告したところ、すぐにappwrite/server-ceパッケージとlitespeed.jsパッケージに対応する修正パッチがリリースされました。このアプリケーションは広く利用されているため、National Vulnerability DatabaseにもCVEが登録されました。

脆弱性が解決した後、AppwriteのメンテナーはLiberaにギフトカードを贈りましたが、Liberaはオープンソースコミュニティのために寄付してほしいと依頼しました。総じて、Appwriteのセキュリティ問題への対応は称賛に値します。問題を真摯に受け止め、コミュニティと協力して解決に取り組むことで、オープンソースの安全性向上に貢献しました。

まとめ

Snyk Codeを支えるルールセットを継続的に開発・メンテナンスすることで、Snykは検出範囲と精度を着実に向上させています。新たな問題パターンを常にスキャンしてルールに反映すると同時に、既存のルールもメンテナンスしています。私たちにとって、ルールセットは製品の一部であり、構築とメンテナンスは私たちの責任です。

Snyk Codeを今すぐ無料でお試しください。開発者中心のセキュリティプラットフォームが、これまで以上に効率よく高品質なコードを書くお手伝いをします。

1 Beller, M., Bholanath, R., McIntosh, S., & Zaidman, A. (2016). "Analyzing the state of static analysis: A large-scale evaluation in open source software". 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, 1, 470–481. https://doi.org/10.1109/SANER.2016.105