‫わかりました｡
‫次は､ コードレポスキャンです｡
‫これはDockerに特化したものでもないのですが､ 世の中にはツールがあり､
‫Sneakもその一つです｡
‫Sneakは､
‫レポの中のコードの依存関係をスキャンします｡
‫オープンソースの開発であれば､ このようなことを無料でたくさんやってくれます｡
‫GitHubのレポ､ Bitbucketのレポをスキャンして､
‫依存関係を調べます｡
‫毎週､ 私のオープンソースレポートと､ 彼らが発見した脆弱性についてのレポートを受け取っています｡
‫現在では､ GitHubもこの多くを無償で行っています｡
‫スニークの方が長くやっているので､
‫両方持っているようなものです｡
‫GitHubからメールを送ってもらい､
‫Sneakも持っています｡ スニークにお金を払ってスキャンしてもらえばいいんです｡
‫また､ コードレポジトリだけでなく､ 画像や他のものも扱えるようになり､
‫より多くの機能を備えています｡
‫しかし､ そのためには､ プロセスの早い段階でレポをスキャンすることです｡
‫画像を構築して､ CIでスキャンしているところをテストしているのを待つ必要はありません｡
‫なるべく早くスキャンする｡
‫これは､ ShiftLeft Securityと呼ばれるものの中核となる考え方の一つです｡
‫カンバン盤を想像してください｡ 左側にすべての作業､ 右側にアウトプットがあるように､
‫ShiftLeftセキュリティの動きは､
‫ShiftLeftセキュリティと検索すれば､ 開発ワークフローの早い段階でセキュリティの責任をシフトすることを意味します｡
‫その1つの方法として､ サーバー上で何かを実行する段階になる前に､ gitリポジトリの中でコードの依存関係を自動スキャナーでスキャンすることができます｡
‫私ならそうします｡
‫特にDockerのことではありませんが､ 私ならそうします｡
‫次は画像スキャンそのものですが､ それとよく似ています｡
‫しかし､ ここではより多くの機能を手に入れることができます｡
‫私たちは､ あなたのコードの依存関係をスキャンするだけではありません｡
‫コンテナそのものをスキャンすることができます｡
‫画像は､ 右です｡ npmパッケージやPythonパッケージ以外の依存関係をすべてスキャンすることができます｡
‫YUMパッケージやAPK､
‫apt､ この手のOS用パッケージマネージャーをスキャンするようになったんですね｡
‫イメージスキャナは､ コードの依存関係だけでなく､ それらもスキャンすることができるので､
‫そういう意味です｡
‫だから､ ここにはたくさんのツールがあるんです｡
‫非常に人気のあるセットは以前からありましたが､ 新しいものがいくつか出てきたので､
‫それについてお話したいと思います｡
‫最初にご紹介するのは「トリビー」ですが､ 私は今月､ 実は10月に知ったばかりです｡
‫Trivyは､ MicroScannerを製造しているAqua Security社によって製造されています｡
‫MicroScannerは､ 他の多くのツールと一緒に､
‫Anchorもまた､ 人気のあるツールの1つでした｡
‫これらはすべて､ CVE脆弱性のために画像をスキャンするオープンソースツールです｡
‫CVEとは､ 私たちがニュースで耳にする､ オープンソースのドナーの脆弱性を集めたデータベースのことです｡
‫そのデータベースを管理しているミットレ社からです｡
‫これって､ コミュニティのことですよね｡
‫誰かがソフトウェアの脆弱性を発見した場合､ それを入力し､
‫CVE番号を取得します｡
‫よくある脆弱性とエクスプロイト､ そんな感じです｡
‫CVEが何の略語かよく覚えていないんです｡
‫きっとどなたかがチャットで教えてくれるはずです｡
‫でも､ CVEは数字が出るんですよね｡
‫その既知のバグに割り当てられた番号をコミュニティで見かけます｡
‫CVEスキャナは､
‫その脆弱性に対して画像をスキャンします｡
‫これを実装するとなると､ ビルド時にDockerイメージの中でスキャナを実行する必要があるのか､
‫とか､ いろいろと細かいことが出てきます｡
‫それとも､ すでに構築されている画像をスキャンするのでしょうか？
‫そのスキャナーは､ ベースディストリビューションに対応していますか？
‫Red Hatには対応していますか？
‫アルパインに対応していますか？
‫その他の配布用画像のようなものを選択した場合､
‫それらに対応するのでしょうか？
‫npmやpipなど､ アプリ用のパッケージ・マネージャーもサポートしていますか？
‫それらにも対応しているのでしょうか？
‫MicroScannerはそのすべてをやっていたわけではありません｡
‫しかし､
‫エコシステムに含まれる他の多くのツールと同様､ すべてを実現できるわけではありません｡
‫今､ アクアセキュリティのトリビーというのがあるんですが､
‫これの一番上まで行ってみてください｡
‫Trivyは､ 最も完全なオープンソースのフリースキャナであると主張しています｡
‫この下に､ 彼らが何をサポートしているかが書かれています｡
‫これらのベースとなる画像をすべてサポートしていることがおわかりいただけると思います｡
‫そして､ 実際に下に降りていくと､ 他のすべてのツールや､ 少なくともこれらのツールの人気のあるオープンソース版との比較が表示されています｡
‫これ以上のツールは絶対にない｡
‫ここでは､ たくさんの選択を迫られることになります｡
‫一つの選択肢として､ どこでスキャンするか？
‫Docker Enterprise DTRのように､ イメージリポジトリが自らスキャンするようにしたいのですが？
‫レジストリに画像を保存しておき､ そのレジストリがレジストリ内の画像に対して一斉にスキャンを実行するというものです｡
‫クワイもそうです｡ Quayはクラウドホスティングの画像保管庫で､
‫スキャンもできるんですよね｡
‫これらのスキャナーはそれぞれ､ 必ずしもすべての画像タイプやアプリの依存性をスキャンするわけではありません｡
‫だから､ ここで見せるのはかなりクールなんだ...｡ 基本的にXはやらないという意味です｡
‫そこにある「0」や「O」､ 「丸」は､ 彼らがやっていることを意味します｡
‫それから､
‫ここのダブルOOはベスト､ トライアングルは問題あり､
‫懸念ありという意味だと思います｡
‫つまり､ 今年買収したトリビーのことを主張しているようなものですね｡
‫Trivyがすべてやってくれる｡
‫OSのパッケージやアプリケーションの依存関係もあります｡
‫使いやすさを謳っています｡
‫その方が正確だと言うのです｡ アルパインのベース画像は､
‫ほとんどのスキャナで使えないということが､
‫私が言い続けている大きな問題です｡
‫ただ､ 脆弱性データベースが正しく接続されていないため､
‫これらのスキャナーを実行すると､ アルパインの脆弱性が検出されるのです｡
‫Trivyは､ 自分たちが実装している新しい方法でそれを解決したと主張していますが､
‫他の人たちもそれを実装するかどうかを見てみましょう｡
‫最も完成度の高いものと謳っている｡
‫Docker Captainの友人たちは､ みんなDockerを使っていて､ 素晴らしい使い方をしていると言っています｡
‫どのスキャナーを使うかということ以外に､ どこでスキャンするかということも決定事項のひとつです｡
‫イメージビルド中にスキャンするのが好きなんです｡
‫イメージ構築後に後からスキャンするよりも､
‫CIの自動イメージ構築時にスキャンする方が良いですね｡
‫それは､ 私だけのことです｡
‫念のため､ 異なるタイミングでスキャンを行うシステムもあるかもしれませんね｡
‫環境によっては､
‫本番稼働しているサーバーでスキャンするシステムもあるかもしれません｡
‫それはあまりないですね｡
‫しかし､ 超セキュアな環境でライブスキャンを行いたい場合は､
‫これらのツールを使用すれば確実に実行できます｡
‫私がよく行うデモは､ MicroScannerについてです｡
‫基本的にMicroScannerでやることは､
‫この他のツールと同様に､ MicroScannerでは､ Dockerfileに追加することです｡
‫Tiveyのアプリは､ 画像を構築した後にスキャンするんですよね｡
‫超偏執狂的な人は､ Dockerイメージの中にMicroScannerを使うのもいいかもしれませんね｡
‫それから､ レジストリに送る前の画像に対して､ Tiveyのようなものを事後的に実行することもありますよ｡
‫後でいつでもダウンロードできますが､
‫私は自分の画像が脆弱性フリーであることを確認してからアップロードしたいのです｡
‫そこで､ そのようなこともあるかもしれません｡ 今すぐ
‫ただ､ 注意事項をお伝えしたいと思います｡
‫あなたは､ おそらく､ 何も... となると､ 脆弱性が皆無の画像はないだろうし､
‫あっても数枚だろう｡
‫それは､
‫オープンソースの特性によるものです｡ 一般的に､ 世の中のどんな画像もスキャンすれば､
‫脆弱性があるのが普通です｡
‫何が許容範囲なのか､ セキュリティチームと協力するのがあなたの仕事であって､
‫絶対に脆弱性があってはいけないというわけではありません｡
‫なぜなら､ ある種の脆弱性は自分には当てはまらないかもしれないからです｡
‫イメージの中にあるからといって､ 自動的に問題になるわけではありませんよね｡
‫仕事してもらわないとね｡
‫私が提案したいのは､
‫これらを今すぐ実装することです｡ ただし､
‫失敗したときの対処はオフにして､ 「失敗しても続ける」､ つまり､
‫脆弱性があることを警告するだけにすることです｡
‫脆弱性があるからといって､
‫ビルドを止めるつもりはないんです｡
‫これは重要なことで､ これらのツールをすべて自動的に導入し始めると､
‫プロセスを失敗させることになるからです｡
‫そのままではCIに失敗したり､ ビルドに失敗したりします｡
‫脆弱性を見つけても失敗しないように､
‫監査専用モードにしておくのです｡
‫そうすれば､ 少なくともハードコアを始める前に､ どんな脆弱性があるのかを知ることができますよね？
‫ハードコアになる前に