こんにちは。アプリケーション部の兼安です。
少し前に脆弱性検知のブログを書かせていただきました。
その時に作った検証用リポジトリでGitHubのDependabotをONにしていたところ、2024年1月になってパッケージの脆弱性を検知してくれました。
偶然の産物ですがせっかくなので、脆弱性の検知から解消までの流れを書かせていただきます。
本記事のターゲット
- Pythonを使用した開発をされている方
- Pipfileによるパッケージ管理の経験がある方
- GitHubでのソース管理の経験がある方
- 脆弱性の検知と解消のノウハウを探されている方
GitHubのDependabotが通知してくれた内容
こちらの件名のメールが届きました。
xxの部分は日付です。
[GitHub] Your Dependabot alerts for today Jan xx
このメールが2024年が1月12日から、毎日9時ごろに届いていました。
本文には脆弱性の内容が記載されていました。
jinja2に脆弱性があるとのことです。
書かれているCVEで検索してみると、確かに脆弱性の情報がHITします。
対処法はjinja2を3.1.3にアップデートすることのようです。
リンク先の脆弱性ページには、情報を公開した日付も書かれています。
NVD Published Date:
01/10/2024
メールが最初に届いたのが2024年が1月12日の9時です。
時差を考えると、情報が公開されてすぐに検知してくれたようですね。
なぜDependabotはメールを送ってくれたのか？
Trivyを使用して脆弱性検知とSBOM出力をやってみる - サーバーワークスエンジニアブログ
このブログを書く時にDependency graphをONにするついでに、DependabotもONにしていたからですね。
それぞれの使用方法はGitHubのドキュメントに記載されています。
GitHubのリポジトリの設定画面で、DependabotがONになっているのを確認できます。
Dependency graphも依存関係が表示されているので、ONになっているとわかります。
そして、Dependency graphの画面上でも脆弱性の存在が確認できました。
素晴らしい。
jinja2が2行表示されているのは、私がDependency graphだけでなく、GitHub Actions＋TrivyでSBOM出力して、それもDependency graphに表示させているからです。
Trivyもきちんと今回のjinja2の脆弱性を検知してくれています。
これまた素晴らしい。
脆弱性を解消してみる
では、ここから脆弱性を解消してみます。
ターゲットのリポジトリはPythonのFlaskを使用した非常に簡単なWebアプリケーションです。
PipfileとPipfile.lockの確認
パッケージは、PipfileとPipfile.lockで管理しています。
まずは、Pipfileを確認してみます。
[[source]] url = "https://pypi.org/simple" verify_ssl = true name = "pypi" [packages] flask = "*" [dev-packages] [requires] python_version = "3.11"
脆弱性が検知されたjinja2の記述はありませんでした。
ということは、jinja2を直接インストールしておらず、他のパッケージの依存関係としてインストールされていると予想されます。
次に、Pipfile.lockを確認してみます。
以下の記述を見つけました。
よくよく見れば元のメールにもDefined in Pipfile.lockと書かれていますね💦
{
（省略）
"default": {
（省略）
"jinja2": {
"hashes": [
"sha256:31351a702a408a9e7595a8fc6150fc3f43bb6bf7e319770cbc0db9df9437e852",
"sha256:6088930bfe239f0e6710546ab9c19c9ef35e29792895fed6e6e31a023a182a61"
],
"markers": "python_version >= '3.7'",
"version": "==3.1.2"
},
（省略）
defaultの下にjinja2が記載されています。
バージョンが3.1.2なので、問題はここですね。
ただ、これだけだと何のパッケージの依存関係としてインストールされているのかわかりません。
コマンドで依存関係を確認してみる
依存関係を確認するために、pipenv graphコマンドを実行してみます。
$ pipenv graph
次の結果が確認できました。
Flaskに依存していることがわかります。
（省略）
flask==3.0.0
├── blinker [required: >=1.6.2, installed: 1.7.0]
├── click [required: >=8.1.3, installed: 8.1.7]
├── itsdangerous [required: >=2.1.2, installed: 2.1.2]
├── Jinja2 [required: >=3.1.2, installed: 3.1.2]
│ └── MarkupSafe [required: >=2.0, installed: 2.1.3]
└── Werkzeug [required: >=3.0.0, installed: 3.0.1]
└── MarkupSafe [required: >=2.1.1, installed: 2.1.3]
（省略）
脆弱性の大元のパッケージをアップデート
jinja2は、Flaskの依存関係としてインストールされていることがわかりましたので、Flaskをアップデートしてみます。
$ pipenv update flask
ちなみに、pipenv update jinja2としても、jinja2はPipfileに記載されてはいないので通りませんでした。
アップデートの結果、Pipefile.lockのjinja2のバージョンが3.1.3に変わりました。
割愛しましたが、Flaskのバージョンも少しあがっているのが確認できました。
{
（省略）
"default": {
（省略）
"jinja2": {
"hashes": [
"sha256:7d6d50dd97d52cbc355597bd845fabfbac3f551e1f99619e39a35ce8c370b5fa",
"sha256:ac8bd6544d4bb2c9792bf3a159e80bba8fda7f07e81bc3aed565432d5925ba90"
],
"markers": "python_version >= '3.7'",
"version": "==3.1.3"
},
（省略）
大元のパッケージではなく、脆弱性あるパッケージ単体をアップデート
Flaskのバージョンがあがってしまうのを避けたい場合は、Pipfileにjinja2を書いて、pipenv update jinja2で単体でアップデートかけるのもなくはないかなと思います。
この状態をずっと続けるかどうかは議論すべきとは思いますが。
[packages] flask = "*" jinja2 = "*"
Dependency graphで解消されたかを確認
この状態でGitHubのリポジトリにpushしてみると、 脆弱性が解消したことをDependency graphで確認できました。
画像は、jinja2が下の方に移動していたので、検索でjinja2だけ絞り込んで表示しています。
先ほどjinja2が上に表示されていたのあは、脆弱性があるバージョンだったからですね。
通知が来なくなったことを確認
この状態で翌朝様子をみたところ、脆弱性の通知メールが届かなくなったのを確認しました。
まとめ
- GitHubの
DependabotをONにすると、インストールしているパッケージに脆弱性がある場合にメールで通知してくれる - GitHubの
Dependency graphをONにすると、インストールしているパッケージの依存関係と脆弱性を可視化できる - パッケージの脆弱性の解消は、
Pipfile.lockやpipenv graphで依存関係を確認して、アップデートすることで解消できる
検知機能を活用して、安全なアプリケーションを開発していきましょう。
サーバーワークスでは、開発プロセスの最適化を支援するサービスを提供しています。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS1課所属
AWS12冠。
広島在住です。
最近認定スクラムマスターになりました。今日も明日も修行中です。
