Pages

Wednesday, July 13, 2022

IntelliJでSnyk Open Sourceをやってみた~オープンソースライブラリの脆弱性をチェックしてみる~ | セキュリティ対策のラック - LAC

「安全なソフトウェア開発を、迅速に」を掲げているSnyk(スニーク)サービス。
アジャイル開発センターのメンバーが、実際にSnyk Open Sourceを使ってみました。

Snyk Open Sourceを使ってみよう

お気付きかもしれませんが、前回ソースコードの脆弱性検知ツールとしてSnyk Codeを使ってみたとき、オープンソースライブラリの脆弱性は検知できていませんでした。

最近のシステムはオープンソースライブラリを利用して、実装コードを減らしていくことが流行っています。
実装した範囲に脆弱性がなかったのに、利用しているオープンソースライブラリに脆弱性が存在していて、それが原因となって脆弱性検査で指摘を受けたら悲しくなってしまいます。自分のせいじゃないのに......。

関連記事

となれば、次はオープンソースライブラリの脆弱性をチェックしてみましょう。
Snyk Codeと同じく、アジャイル開発センターで利用している統合開発環境で、Snyk Open Sourceを使ってみます。

チェックしたいソースコードはJavaで実装されているので、IntelliJでSnyk Open Sourceをどう使って、結果をどうやって見ていくのか、という点を調べてみます。利用しているソフトウェアプロジェクト管理ツールはMavenとなっています。

色々と調べる前に

契約内容の確認をしましょう

前回と同じく、Snyk Open Sourceが使える契約になっているか確認します。
契約はBusinessでしたね。
Snyk Open Sourceが実行できる契約になっているので、オープンソースライブラリの脆弱性チェックができる状態になっています。
よしよし、これも問題なし、と。
Snyk Codeと同じように、こちらもFreeの契約でもTeamの契約でもSnyk Open Sourceは実行できる契約のようでした(Snyk Open SourceもSnyk Codeと同じように、Freeだと実行上限回数があるみたいですが)。

Snyk Open Sourceで何ができるのか、再確認

Snyk Codeの時と同じく、こちらもSnyk Open Sourceで何ができるのか、再確認しておきましょう。
「Snykのポイントを解説」でSnyk Open Sourceについてもまとめていたので、その内容をおさらいします。

プロジェクト(≒システム)が依存しているオープンソースライブラリの脆弱性を検知する機能です。
依存しているオープンソースライブラリのエリアに存在する脆弱性を検知します。

機能

  1. 依存しているオープンソースライブラリで、公開された脆弱性を含むバージョンを使用していないかをチェック
  2. 脆弱性を含むバージョンを使用している場合は検知する
  3. 検知されたライブラリに対して(公開されていれば)修正案を提供
    GitHub連携をしている場合は、修正した内容でのプルリクエストをボタン2つで作成可能

関連記事

インストールしたプラグインを確認

前回インストールしたSnykのプラグインで、Snyk Open Sourceが利用できるか確認してみましょう。
Snyk Open Sourceにチェックがつけられるのであれば大丈夫かな、という期待を込めて、設定画面を開いてみます。

Snykの設定画面

Product Selectionの先頭に「Snyk Open Source」がありますね。

ではチェックをつけて、実行するだけです。

さあ、Snyk Open Sourceを実行!

Snyk Open Sourceの実行

Snyk Codeの時と同じ手順で、さっそく実行します。
ワンちゃんのアイコンをクリックして、Snykのコンソールを表示させて、再生ボタンをクリックします。

IntelliJの画面下部にあるボタン
Snykのコンソール画面

検査結果が出てくるまで待ちましょう。

実行結果

今回は結構あっさり結果が出てきましたね。

利用しているオープンソースライブラリのバージョンをわざと少し古めのバージョンにしたのですが、19件も検知しました。
2021年5月にリリースされたライブラリなのに、重大度がHighのものもあります(記事執筆時点は2022年6月です)。

開発期間が長いプロジェクトだと、開発当初に選択したバージョンのままリリース前までチェックしていなかったら、重篤な脆弱性が潜んでしまう、なんてこともあり得そうです。

Snyk Open Sourceの検査結果

対応はどうすればよいのでしょうか?
Snyk Codeの時の結果のように、何かしらの対応案なりが表示されることを期待しながら、重大度Highの結果となった脆弱性org.thymeleaf:thymeleaf-spring5@3.0.12.RELEASE:Remote Code Executionをクリックしてみましょう。

検知した脆弱性と、検知した箇所、修正の方法の表示

期待通り、出てくれました。
内容はというと、Snyk Codeの時と似たような結果が出てきています。
検知した脆弱性と、検知した箇所修正の方法ですね。
クリックしても、自動で該当箇所まで飛んでくれるということはないみたいです。

検知した脆弱性については、脆弱性の詳細が説明されているリンクも合わせて出てきてくれています。
今回の脆弱性についてのリンクは4つありますが、情報公開をしてくれている団体が違うサイトとなっています。ほぼ同じ内容ではありますが、確認した上で脆弱性の全貌を把握することが必要ですかね。

検知した箇所というのは、どのオープンソースライブラリが原因なのかということです。
具体的には、Vulnerable moduleに記載されているライブラリになります。
今回参照した脆弱性でいえば、どうやらthymeleaf-spring5が原因だったようです。

Introduced throughに記載されている内容で、Vulnerable moduleに記載されているライブラリを利用しているオープンソースライブラリとそのバージョンがわかります。pom.xmlに直接記述しているライブラリとそのバージョンのことですね。

Fixed inで、修正されたバージョンを提示してくれています。
脆弱性を検知したライブラリはorg.thymeleaf:thymeleaf-spring5で、修正バージョンが3.0.13.RELEASEとなっています。

検知結果内容を確認すると、この脆弱性への対応は提示されたthymeleaf-spring5のバージョンを利用しているspring-boot-starter-thymeleafのバージョンを指定するということがわかります。

脆弱性によってはFixed inがないものもあります。
対応バージョンが未公開、というものです。

脆弱性によってはFixed inが表示されないものもある

この場合は、対応バージョンがリリースされるまで待つか、同等機能の他ライブラリを利用するか、という対応が必要です。

最後に

開発中に頻繁に行う必要はない脆弱性検査ではありますが、利用しているオープンソースライブラリに含まれている脆弱性を検知することは非常に重要です。開発するソースコードでは対応できない(かもしれない)脆弱性が潜んでしまっているわけですから。

脆弱性に対応するためにオープンソースライブラリをバージョンアップすると、使い方も変わってくることもあります。
直接的・間接的に開発中のソースコードを修正する必要がありますよね。なるべく早い段階で対応してソースコードの修正を行うことができれば、Snyk Codeで検知する脆弱性と同じように、期間を取って行う脆弱性検査で検知される脆弱性の数を減らせます。

Snyk Open Sourceでのチェック、開発中から定期的に実施し、検知された場合は対応することで、これもまた品質の向上が見込まれます。Snyk Codeと合わせて使えば、セキュリティ的にも一定程度以上の品質が保たれたシステムとなることが期待できます。

Adblock test (Why?)


からの記事と詳細 ( IntelliJでSnyk Open Sourceをやってみた~オープンソースライブラリの脆弱性をチェックしてみる~ | セキュリティ対策のラック - LAC )
https://ift.tt/TYsXuSJ

No comments:

Post a Comment