はじめに
この記事は「Snykを使って開発者セキュリティにまつわる記事を投稿しよう！ by Snyk Advent Calendar 2022」の13日目です。今回は、SnykのReports機能について概要を説明したいと思います。Reportsを活用してセキュリティチームもアプリ開発セキュリティに貢献していきましょう！
開発者フレンドリーなセキュリティ対策ツール：Snyk
Snykは、開発者フレンドリーなセキュリティ対策ツールです。以下のようなプロダクトで構成されています。
- Snyk Code・・・開発中のコードの脆弱性を指摘する（SAST、Static Application Security Testing）
- Snyk OSS・・・オープンソースのコンポーネントのセキュリティ管理を自動化
- Snyk Container・・・コンテナイメージの脆弱性管理
- Snyk IaC・・・TerraformなどのInfrastructure as Codeの設定ファイルの問題点を指摘
これらのWebアプリケーション開発・運用局面で気を付けておきたいセキュリティ問題にオールインワンで対応できるのもSnykの魅力の１つです。またVisualStudioCodeやGitHubなど開発者に馴染みのあるツールとの連携もスムーズで、とても開発者フレンドリーなプロダクトになっています。
Reportsについてはじめに知っておきたいこと
Snykの料金プランにはFree、Team、Business、Enterpriseの4種類があります。Snyk Code、OSS、Containier、IaCなどの機能を試してみるにはFree版から機能制限なしで利用できます。しかし、この記事で紹介するReportsの機能は、Business、Enterpriseでのみ提供されています。
Snykの導入に際しては、Free版から使い始めて、有用性を感じてから有償版への移行を検討して頂くと良いと思います。Business、EnterpriseにはReports以外にもAPI連携や社内のオンプレミスのレポジトリの走査（Enterprise）などの機能があります。なお、当社（株式会社ラック）でもSnykを取扱していますのでお気軽にお問い合わせください。
2022年11月8日に開催されたSnykLaunchでは、Snyk製品スイートへの最新の追加機能が発表されました。SnykLaunchでは新しいReports機能についても説明がありましたが、原稿執筆時点では新機能はBeta版として提供されています。この記事では、SnykLaunchで発表された新しいReportsについて紹介します。Beta版の新しいReportsを試すには、Snykの管理者権限でログインし、「Settings」→「Snyk Preview」から「Beta Reporting」を有効にします。
Reportsの概要
Reportsの公式ドキュメントでは、Reportsについて以下のような紹介があります。
Snyk reports help security and development teams work together. As your coding projects progress, Snyk's reporting dashboard lets security professionals monitor activity and maintain security insight, without looking over development’s shoulder.
（抄訳）Snyk Reportsを使えば、開発チームとセキュリティチームが協力して作業できます。開発プロジェクトの進捗に併せて、セキュリティ専門家が開発チームの活動を注視し、セキュリティ上の課題を把握し続けることが可能です。Snyk Reportsを使えば、セキュリティチームは開発者の肩越しに様子を覗き込む必要はありません！
Reportsでは、Snykが検出した自組織のプロジェクトのセキュリティに関する課題を一気通貫で確認することができます。著名なパッケージや良く使われているフレームワークやライブラリに脆弱性が発見されると、攻撃者により無差別に攻撃されるリスクがあります。2021年12月にApache Log4jの脆弱性（Log4Shell）が発表されましたが、Javaで開発されたアプリケーションで広く使われていたことから、影響は広範囲に及びました。このような脆弱性が発見された場合には、迅速に組織内で使われているライブラリを調査する必要があります。Reportsを使うことで、セキュリティチームは個々の開発チームに問い合わせするまでもなく、組織全体で対応が必要なプロジェクトを洗い出すことができます。
また、従来のReportsでは、Snyk OSSで検知されるオープンソースのコンポーネントの脆弱性のみが表示されていました。これだけでもセキュリティチームにとっては十分に有用ですが、新しいReportsでは、Snyk Code、Snyk OSS､Snyk Container、Snyk IaCのSnyk製品スイート全体で検出された脆弱性が表示されるようにアップデートされています。セキュリティチームは自組織で進行している開発プロジェクト全体のセキュリティ対策状況を鳥瞰し、優先してサポートが必要なチームを選別することができるようになります。
Preview版のReportsをプレビューする！
それでは、Preview版のReportsを見てみましょう。Reportのトップページには、Snykが管理する自組織のアプリケーションで検出された脆弱性のサマリが表示されます。
フィルター（filter）機能で絞込み
フィルター（filter）を追加することでReportsに表示する脆弱性を絞り込むことができます。様々なフィルターが用意されていますが、手始めに「Snyk Product」と「Issue Severity」「Prioject Name」あたりを追加しておくと良いでしょう。「Snyk Product」フィルターを用いると、「Snyk Code」「Snyk OSS」「Snyk Container」「Snyk IaC」を選択することができるようになります。「Issue Severity」フィルターでは、検出された脆弱性を重大度（Severity)で絞り込むことができます。目的に応じてReportsをカスタマイズしていきましょう。
Issues Detail
Reportには「Issues Detail」「Issues Summary」「Vulnerabilities Detail」の3つのビューがあり、左上の「CHOOSE REPORT」プルダウンでビューを切り替えることができます。デフォルトでは「Issues Detail」ビューが表示されています。
「Issues Detail」ビューには、Snykが検出したセキュリティ上の課題（Issue）が一覧表示されます。
右上のプルダウンではIssueの集計を「Severity」「Product Name」「Issue Type」で切り替えることができます。
「Product Name」を選択すると「Snyk Code」「Snyk OSS」「Snyk Container」「Snyk IaC」単位の集計が表示されます。
「Issue Type」を選択すると「VULNERABILITY」「CONFIGURATION」「LICENSE」単位の集計が表示されます。
オープンソースのソフトウエアには様々なライセンス形態がありますが、Snykはシステムで使われているオープンソースソフトウェアのライセンスを確認し、コンプライアンス上の問題を確認することができます。たとえばGPL（General Public License）ライセンスを利用して作成されたソフトウエアは、頒布時にソースコードを公開する義務がある、とされています。パッケージソフトウエアのような形でシステムを販売する場合には、こうしたライセンスに違反していないかを確認する必要があるのです。
Issues Summary
「Issues Summary」ビューでは、脆弱性対応の状況が時間軸で表示されます。期間内に発見された脆弱性数（TOTAL OPEN）と、解決（修正）された脆弱性数(TOTAL RESOLVED)、そして修正が完了するまでの平均時間(MEAN TIME TO RESOLVE)がグラフとともに表示されます。
フィルター（filter）を使って対象範囲を絞りこんでいくことで、プロジェクト毎のセキュリティ対策の状況を可視化することができます。セキュリティチームとしてはこうしたファクトを用いて開発プロジェクトに対するサポートを検討していくことができます。
Vulnerabilities Detail
「Vulnerabilities Detail」ビューでは、脆弱性の種類で絞り込んだレポートを表示することができます。次の図では「CWE-78（コマンドインジェクション）」の脆弱性を持つプロジェクトを特定して表示しています。
それぞれのレポートはCSV形式でダウンロードすることができますので、さらに必要な集計を行うことで組織にとって有用なレポートを作成することができるでしょう。
おわりに
この記事では、SnykのReports機能について概要を説明しました。記事で紹介した新しいReports機能は執筆時点のPreview版ですので、今後変更される可能性があります。Reports機能を活用することで、マネジメント層に対してセキュリティ対策の自社の状況をレポートし、今後必要な施策を提言していく際の根拠として利用することができるでしょう。決して、現時点での開発チームの対応状況が良くないことを責める材料に使うのではなく、エンジニアに対する教育プログラムの検討の必要性や、その他のセキュリティソリューションの導入提案の必要性を訴求する形で利用して頂ければと思います。