BLOGブログ
【Tech Blog】Vulsを用いた脆弱性検出・管理フローの構築②
文責：山本 和幸
- 脆弱性検出
前回のテーマ「【Tech Blog】Vulsを用いた脆弱性検出・管理フローの構築①」：https://segaxd.co.jp/blog/0ddbef566b58c27dcc63ed81a46b08082a25d07b.html
弊社では、クラウド・オンプレ問わず様々な環境でサービスを開発・運用しています。
プロダクトリリース前に第三者機関による脆弱性診断を実施していますが、万が一、リリース直前に重大な脆弱性が発見された場合、その対応によるスケジュールの逼迫というリスクが挙げられます。また、プロジェクトによって AWS では Security Inspector を用いたり、AWS Security Center の CVE 情報を Feed 経由で取得し特定タイミングで反映するなど、運用の統一ができていないという課題もありました。
これらの課題解決の為、脆弱性情報を検出するOSSである" Vuls "の構築を行いました。 導入・運用の方法、そして注意点などを2回に分けてお伝えさせていただこうと思います。
前回まではVulsの導入までを記しました。Vulsを利用することで稼働サーバー（コンテナ）の脆弱性を検知することが可能になりましたが、アプリケーションについてはできれば開発中に問題を検知したいところです。
そこで今回はアプリケーション内における利用ライブラリの脆弱性をOWASP dependency check（https://owasp.org/www-project-dependency-check/）を使って検知したいと思います。
また、当社ではコード管理にGitLabを利用しているので、gitlab-runnerと連携してCI上で動かすようにしたいと思います。
■インストール
dependency-check
$ curl -L -O https://github.com/jeremylong/DependencyCheck/releases/download/v6.1.5/dependency-check-6.1.5-release.zip
$ unzip dependency-check-6.1.5-release.zip
$ sudo mv dependency-check /opt/dependency-check
$ /opt/dependency-check/bin/dependency-check.sh --help
～ オプションが色々表示される ～
# 簡単な使い方、この例ではexampleプロジェクトのスキャン結果を実行ディレクトリ上にHTMLで保存する
$ /opt/dependency-check/bin/dependency-check.sh --project example --scan ./PROJECT_DIRgitlab-runner：基本的にはマニュアル通りに実行すれば問題ありません。
前回と同様にAmazon Linux2上に環境を構築します。また、Dockerに関しては今回既にインストールしている状態とします。
$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bash
$ sudo yum -y install gitlab-runner
$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
$ sudo gitlab-runner start
■設定
次はrunnerの登録を行います。GitLabのプロジェクトの設定メニューからCI → Runnerを選択します。下記画像からトークンとURLをメモしておきます。（今回はspecficのrunnerとしていますが、ここはそれぞれの開発プロジェクトの運用によって異なるかと思います。）
runnerをインストールしたサーバーにて下記を実行します。
$ sudo gitlab-runner register
Runtime platform arch=amd64 os=linux pid=6345 revision=7f7a4bb0 version=13.11.0
Running in system-mode.
Enter the GitLab instance URL (for example, https://gitlab.com/):
[先程メモしたgitlabサーバーのURLを入力]
Enter the registration token:
[先程メモしたrunnerのTokenを入力]
Enter a description for the runner:
[owasp-runner]: runnerの説明文。今回はとりあえずowasp-runnerとつけておきます。
Enter tags for the runner (comma-separated):
[owasp]: このrunnerにtagを付与しておきます。今回はわかりやすくowaspとしておきます。
Registering runner... succeeded runner=hogehoge
Enter an executor: ssh, shell, docker, docker-ssh, parallels, virtualbox, docker+machine, docker-ssh+machine, kubernetes, custom:
[shell]: dockerを使うほうがきれいですが、当社では様々な環境、構成で動いていることから一旦shell-executerを利用しています。
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!先程の設定画面を更新してみると、Runnerが登録されているのが確認できます。
■実例
では実際にCIファイルを作っていきたいと思います。プロジェクトのrootディレクトリに`.gitlab-ci.yml`を作成し、下記のように記載しておきます。
当社ではsymfonyを利用したアプリケーションが多く存在するため、今回の例においても空のsymfonyプロジェクトを作成しています。よって今回はbuildステージで必要なライブラリをダウンロードしておき、owasp-checkステージで実際にスキャンします。
stages:
- build
- owasp-check
build_job:
stage: build
script:
- /usr/local/bin/composer update --no-progress --no-scripts
tags:
- owasp
owasp_job:
stage: owasp-check
script:
- /opt/dependency-check/bin/dependency-check.sh --project example --scan ./
artifacts:
paths:
- dependency-check-report.html
tags:
- owasp作成したCIファイルをcommitします
$ git add .gitlab-ci.yml
$ git commit -m '[ETC] ADD CI Template.'
$ git push origin master完了後、GitLabのパイプラインページに遷移すると先程設定したjobが実行されています。
また、jobを選択すると、下画像のようにパイプラインベースでjobが順次実行されていることが確認できるかと思います。
また、先程のパイプライン一覧の右にダウンロードボタンが表示されていると思います。
ここからOWASP Dependency Checkのレポートファイルがダウンロードできるようになっています。
■終わりに
今回はOWASP Dependency Checkを利用してライブラリの脆弱性を検証することが出来ました。
他にもFOSSologyを用いたOSSのチェックを行っていますので、それはまた別の機会に紹介させていただきます。
セガ エックスディーでは一緒に働く仲間を募集しています！
少しでも興味をお持ちの方は、お気軽にお問合せください。
最後まで読んでいただきありがとうございます。
この記事の内容について詳しく聞きたい方は、以下よりお気軽にお問い合わせください。
※記載されている会社名、製品名は、各社の登録商標または商標です。
- 文責：山本 和幸 株式会社セガ エックスディー システム開発部 DevOpsエンジニア
- 「セガ エックスディーで、様々な技術を活用し開発推進・効率化に関して取り組んでいます。」