knqyf263's blog

自分のためのメモとして残しておくためのブログ。

Trivyのアップデート（2019/10 - 2020/04)

噂によると日本でもGWが終わったらしいです。自分は去年のGWにTrivyを開発したので気づけばもう一年経ちました。いい機会なので直近のアップデートをまとめようと思います。

あと会社の評価の時期の前に自分の成果まとめておくかーと思ったのですが（多分もう評価終わってしまったけど）、仕事の80%近くをOSSであるTrivyに費やしているので、Trivyに関して近頃のアップデートや周辺のニュースをまとめけば大体OKということに気づいたというのも理由の一つです。ということで書いておきますが、気まぐれなので次以降も書くかは不明です。近況が追えてなかったという人もちらほらいたので、基本は自分で見返すために書いてますが誰かの役に立てば幸いです。

なぜそういう仕事をすることになったのかについては過去にやたらと長いやつを書いてあるので興味あれば。

knqyf263.hatenablog.com

そしてこの記事もかなりかいつまんで書いたつもりだったのですが、やたらと長くなりました。アップデートだけ知りたい人は見出しだけ流し読みすれば良さそうです。

概要

そもそもどういうツールなの？という人はそもそもこの記事を開かずにスキップするとは思うのですが、一応貼っておきます。コンテナの脆弱性をスキャンするツールです。

qiita.com

どうでも良いですが自分のQiitaの記事を探そうと"trivy qiita"とかでググったら全然ヒットしなくて記事の書き方の下手さを改めて実感しました。

新機能

この半年でちまちまと新機能が増えました。バグの修正も多かったですが... 同僚や外部の方々等、色々な人に助けてもらっているもののメインはやはり自分一人なので若干もどかしい部分はあります。まだまだ足したい機能があるのでもう少しリソースを割きたい気持ちはありつつ、弊社はまだベンチャーでGAFAのように金が無限にある状態ではないので、会社としては今ぐらいが丁度よいバランスなんじゃないかと思っています。小さい会社でOSSチームがあるだけ凄いなと思っています。

あとはやはりOSSをビジネスに繋げていこうというのが会社方針としてあります。どう繋げていくかについては内部でも非常に議論されていて面白いなと思っているのですが、それについて話すと長くなるので気分が高まった時に書きます。ということでビジネス要件で足した機能もあったりします。自分もヘルプでSaaS開発に入ったりするので、たまにそっちにリソースを割いたりもしています。

全部書くときりがないので、大きい機能だけ紹介します。Aqua Securityに譲渡したのが去年の9月ぐらいなので、それ以降のやつを書いていきます。

v0.1.7

Amazon Linuxのサポート

Amazon Linux 1/2をサポートしました。要望の声が多かったので優先度高めでやりました。Clair という競合ツールがあるのですが、そちらでは Amazon Linux 2018.03 以前のイメージはスキャンできません。スキャンできていそうに動きますが検知はされません。そんなに古いイメージ使わないからいいでしょ、という声もあるとは思いますが意外と闇のイメージがあったりします。

$ trivy amazonlinux:2

Google Distrolessのサポート

単純にDistrolessと言うとscratchやbusyboxとかと勘違いされやすい事が分かったのでGoogle Distrolessと呼んでいます。こちらは基本的にDebianがベースになっているのですが、パッケージがほとんど入っていません。distroless/baseだと確か6つぐらいです。そのため脆弱性も見つかりにくく近年利用が増えています。こちらは 天地さん の尽力もありサポートすることができました。

$ trivy gcr.io/distroless/base-debian10

Kanikoのサポート

Kanikoというビルドツールでビルドされたイメージは内部構造が若干違う関係で以前はスキャンが失敗していました。こちらもユーザからの声が増えてきたので対応しました。

templateファイルへの出力に対応

以前は結果をテーブルやJSONでしか出力できなかったのですが、template出力に対応しました。Golangのtext/templateのフォーマットで渡してあげれば結果がそのテンプレートを基に出力されます。自分としてはJSON出力しておけばあとはユーザ側でやってほしいという気持ちだったのですが、template対応したことでユーザがtemplateを書いてPRくれたりするようになったので（後述）対応して良かったです。

$ trivy --format template --template "{{ range . }} {{ .Target }} {{ end }}" golang:1.12-alpine

v0.2.0

スキャンの高速化

色々工夫した結果、スキャンの実行時間が劇的に短縮されました。実行時間のほとんどが脆弱性情報の更新だったのですが、そこが高速化されました。詳細は長いので割愛しますが、GitHub Releases上に脆弱性DBファイルを置いてあるので実行時にダウンロードするだけになっています。以前は初回スキャンだと数分かかってしまっていたのですが、現在はデフォルトオプションだと10秒前後で、--light オプションを使うと数秒です。CIサービスによっては1秒を切ることもありました。

ちなみに高速化前でも他の多くのスキャナーよりは速かったです。ただ何となく自分で許せないところまで来たのでカッとなってやりました。他のスキャナーと比べて遅いわけじゃないならやらなくて良いと会社は言っていたのですが、熱意を伝えて工数を勝ち取りました。

そしてハマコーさんがブログにしてくださいました。正直特に評価もされないのにかなり頑張ったのでブログにしてもらえて嬉しかったです。

dev.classmethod.jp

こういう声も嬉しいです。サポートOSが増えた関係でDBサイズも大きくなっちゃったのですが、まだ許容範囲のはずです。

lightオプションの追加

上に書いたように−−lightオプションを追加しました。以前は脆弱性詳細や関連URL一覧も取得していたのですが、人によってはCIで回したいだけなので詳細は不要で深刻度ぐらい分かれば良いという人も多いことがわかりました。CVE-IDさえ分かればあとは検索すれば詳細は出てくるのでそちらを参照というスタイルですね。こちらであればDBサイズがさらに小さいのでより速くスキャン可能です。

$ trivy --light alpine:3.11

環境変数によるオプション指定に対応

trivy --exit-code 1 alpine:3.11 のようなものが TRIVY_EXIT_CODE=1 trivy alpine:3.11 のように指定できるようになりました。今の御時世だとコンテナオーケストレーションツール経由で渡す場合など、何でも環境変数で指定できる方が便利ということですね。

v0.2.1

GITHUB_TOKENの指定

GitHub ReleasesからDBファイルをダウンロードするため、大量のイメージがある人はGitHub APIのRate Limitingに引っかかる事が分かりました。GITHUB_TOKENでtokenを指定するとRate Limitingの上限が上がり回避可能です。

$ GITHUB_TOKEN=xxx trivy alpine:3.11

v0.3.0

Client/Serverに対応

以前はスタンドアローンでしか動かせなかったのですが、10ホストあると10回脆弱性DBをダウンロードする必要があります。CIサービスとだとキャッシュも使えますし、そもそも上述したように数秒なのであまり問題ないのですが、オンプレミスでCI環境を構築していたり各マシンでcronでやっていたりすると一度ダウンロードしたDBを使いまわしたいというニーズがありました。そこでserver modeを用意し、serverで脆弱性DBさえ更新すればclient側は不要で済むようにclient/serverを実装しました。

サーバ側を以下のように起動して、

$ trivy server --listen localhost:8080
2019-12-12T15:17:06.551+0200    INFO    Need to update DB
2019-12-12T15:17:56.706+0200    INFO    Reopening DB...
2019-12-12T15:17:56.707+0200    INFO    Listening localhost:8080...

クライアントでスキャンするだけです。

$ trivy client --remote http://localhost:8080 alpine:3.11

サーバは定期的に勝手にDBを更新するので放っておけば良いです。

Oracle Linuxのサポート

これは @masahiro331 がメインでやってくれました。

$ trivy oraclelinux:8.2

v0.4.0

Photon OSの対応

これも@masahiro331 がメインでやってくれました。実はこれがHarborのデフォルトスキャナーとなるために重要な機能の一つでした。HarborはVMwareがメンテナンスしているOSSですが、Photon OSもVMwareが提供しているOSになります。Harborのイメージは全てPhoton OSで構築されているため、Photon OSのスキャンは重要でした。Harborは以前から脆弱性スキャナーとしてClairを採用していましたが、Issueを出しても一向にPhoton OSの対応をしてくれないということでメンテナーの方々も色々な思いを吐露していました。公の場で言うのはアレなのでここまでにしておきますが、既にデフォルトとなっているものをわざわざ置き換えるというのは非常に労力も大きいですし相当アレがアレしてました。

ちなみに他のOSと比べてPhoton OSはセキュリティアドバイザリがとても親切です。新たなOSに対応するのは簡単ではないのですが、実はその大部分がセキュリティアドバイザリの難しさから来ていたりします。その点Photon OSは開発者フレンドリーで最高です。まずJSONなどという生ぬるいフォーマットで完全な情報が提供されているのがPhoton OSぐらいです。Harborのメンテナーはとても喜んで感謝してくれていましたが、感謝を述べたいのは正直こっちでした。

そしてRed Hatのセキュリティアドバイザリの難しさは群を抜いています。対応しているOSは現時点で12個ぐらいあるのですが全体の工数の7割ぐらいをRed Hatに持っていかれています。

SUSE Enterprise Linux / openSUSEの対応

これも@masahiro331 と協力し進めました。セキュリティアドバイザリが異常な難しさで、Clair含め既存の脆弱性スキャナーは正しく動作しません。@masahiro331はSUSEの脆弱性スキャンに世界一詳しいと言ってました。

使い方はいつも通り。

$ trivy opensuse/leap:15.0

v0.4.3

templateをファイルとして指定

text/template が使えるということを上述しましたが、@を最初につければファイルとして渡せるようになりました。

$ trivy --format template --template "@/path/to/template" golang:1.12-alpine

そしてこちらの機能を使ってGitLabのContainer ScanningのフォーマットのJSONを出力できるようになりました。こちらは @mrueg さんによるContributiionです。本当にありがたいです。

github.com

GitLab CIの連携

上でも触れましたが、@tnir さんがさらにGItLab CIとの連携を改良してくださって、簡単に使えるようになりダッシュボードでいい感じに表示できるようになりました。ありがとうございます。

https://github.com/aquasecurity/trivy/blob/master/contrib/Trivy.gitlab-ci.yml

実はGitLab CIをちゃんと使ったことなかったのですが便利すぎて感動しました。

v0.5.0

キャッシュの改良

以前はスキャンしたイメージのレイヤーをまるごとtarファイルとして保存していました。理由としてはCIで回すなら揮発するしローカルでそんなに大量にスキャンしないじゃろ、ぐらいのノリでした。あとはDockerのレイヤーを自前で組み立てるためにはopqファイルとか諸々処理しないとダメで、まるごと残っている方が都合が良いというのもありました。GW中に開発終えたかったのであまり余裕がなかったというただの言い訳も挟んでおきます。

当然ユーザが増えて大規模にスキャンする人が出てきてキャッシュサイズが問題になりました。Harborなどのレジストリに統合する場合は特に問題です。ということでレイヤーから必要な情報のみ抽出してJSONに変換して保存するようになりました。これにより劇的にキャッシュサイズが減ったので問題になるユーザはほとんど現れないと思われます。

また、Client/Serverで起動したときにキャッシュをサーバ側で共有するように変更し、不足しているレイヤーだけRegistryから取得するようにしました。そのため、ホストAでalpine:3.11をスキャンし、ホストBでalpine:3.11にレイヤー一つ足したイメージをスキャンした場合はalpine:3.11の部分は既にレイヤーのキャッシュがサーバに存在するためホストBではダウンロードせず、不足しているレイヤーだけ取得します。ローカルのDocker Engineにあるような場合はそもそもダウンロードが発生しませんが、その場合でも解析がスキップされるのでキャッシュの効果があります。

これは結構大変だったので、この改善により後述する各種レジストリーとの統合の話が進んで良かったです。

v0.5.3

レイヤーIDの表示

脆弱性が発見されたけどレイヤーが多くてどこでそのパッケージのバージョンが入ったか分からない、という問題もありました。いやパッケージ名でDockerfileをgrepすれば良いんじゃないの...みたいな気持ちもありましたが依存で入ったりするケースもあり、やはり対応してもらえたほうが嬉しいということだったので対応しました。

脆弱性が発見された場合に以下のようにLayerが表示されます。ざっくり言うとDiffIDはレイヤーを解凍したあとのIDで、Digestというのは圧縮時のIDです。Docker Registryにある場合はDigestの方をLayerIDとして見ることが多く、ローカルにあるイメージはDiffIDの方がLayerIDというような扱いになっています。もちろん細かい条件でどちらが使われるか違うのですが、大枠そんなイメージです。

    "Vulnerabilities": [
      {
        "VulnerabilityID": "CVE-2011-3374",
        "PkgName": "apt",
        "InstalledVersion": "1.8.2",
        "Layer": {
          "DiffID": "sha256:78c1b9419976227e05be9d243b7fa583bea44a5258e52018b2af4cdfe23d148d"
          "Digest": "sha256: 9740df1ac227d21600b22524f869c9bec2d8c13446d1c8579a6195b6d855ae2b"
        },
        "SeveritySource": "debian",
        "Description": "It was found that apt-key in apt, all versions, do not correctly validate gpg keys with the master keyring, leading to a potential man-in-the-middle attack.",
        "Severity": "LOW",
        "References": [
          "https://snyk.io/vuln/SNYK-LINUX-APT-116518"
        ]
      },
  ...

v0.6.0

内部のライブラリを変えてソースコードの変更が莫大だったんですが、今見るとユーザに価値を提供するようなやつなかったのでスキップ。

v0.7.0

OCI Image Formatのサポート

OCI Image Formatをサポートしました。個人的にはskopeoとかでDockerイメージフォーマットに変更してもらえれば良いのでは...と思っていたのですが何やかんやで要望も多く対応しました。

Buildah:

$ buildah push docker.io/library/alpine:3.11 oci:/path/to/alpine
$ trivy --input /path/to/alpine

Skopeo:

$ skopeo copy docker-daemon:alpine:3.11 oci:/path/to/alpine
$ trivy --input /path/to/alpine

tarで固められている場合には対応していません。ディレクトリである必要があります。

ニュース

新機能のv0.2.0あたりで既に疲れて後半かなり適当になってきているので、ここからは完全に雑です。Trvyを取り巻くニュース的なやつをまとめておきます。見返したら結構多かったので大きいやつだけ。

Harborのデフォルトスキャナーに採用

まずはこれがとても大きいです。HarborというのはOSSのコンテナレジストリーです。ただ2.0からはOCIレジストリーとして進化を遂げてコンテナイメージだけに限らなくなっています。

Harborのブログを見ると、Trivyをデフォルトスキャナーとして採用したという件が非常に大きく書いてあります。感無量のあまりまだ実は読んでないです。

goharbor.io

元々はClairというスキャナーがデフォルトでした。自分にはClairを使うのが難しすぎて、これ使える人プロだけなのでは？みたいな気持ちが膨れ上がり爆発した結果Trivyを作り始めたという背景もあるため、デフォルトを置き換えられたのはとても嬉しいです。ただ実際にはClairもまだデフォルトスキャナーの位置づけではあります。Trivyの方が優先してインストールされるという感じで、一応両方デフォルトという名目になっています。これ実はHarborのメンテナー達と我々現場のメンバーではもう撤廃しようぜｗｗというノリで盛り上がってたんですが、うちのチームのボスとあちらのマネージャーが大人なミーティングをした結果、廃止は角が立つので一応残そうということになったという背景があります。ですがそのぐらい評価していただいている状態です。

これはうちのチームメンバーであるDanielがHarborにコミットし続けた結果、コミッターになったというのも大きいです。Harborの脆弱性スキャン周りは完全に裁量を持っています。ただ上述したようにPhoton OSの対応だったりバグがあったときの迅速な対応だったり、そもそも機能的に優れていたりという諸々が積み重なった結果、こういう成果を得たという感じです。スキャナーとしてどのぐらい違うのか、というのは自分が精度や機能面で比較してブログ書いたのですが大人の事情でまだリリースされていません。お蔵入りになる可能性も高そうです。

大きなニュースと思ってもらえたのか、InfoQでも記事にしてもらっています。普通はツール名しか載らないものですが、InfoQでは自分の個人名を載せてくれています。これはとてもありがたいのでInfoQのファンになりました。

www.infoq.com

Docker Enterpriseでの採用

Docker EnterpriseはMirantisが2019年11月に買収したのですが、そのMiranatisからDocker EnterpriseにTrivyを統合したいというお声がけをもらいました。

www.itmedia.co.jp

これは弊社の営業が強いとかでも何でもなく、自分個人宛にメールを頂いています。Docker Enterpriseでは既に自分達のスキャナーを持っているのですが、それがいまいちなので置き換えを検討していたらしくClairなども含め色々検討した結果、Trivyが良かったということで連絡をもらいました。

以下の記事に貰っているコメントが載っていますが、全て最高に嬉しいです。

www.prnewswire.com

containerjournal.com

Docker Enterpriseへの統合は発表したもののいくつか不足している機能があるためMirantis社のSlackに入って一緒に開発しています。Windowsイメージの対応もやってくれるということでお願いしています。

CNCF Cloud Native Interactive Landscapeへの掲載

以下のLandscapeに載せてもらったので、一応クラウドネイティブなツールと言っていけそうです。

landscape.cncf.io

これはCNCFプロジェクト（Kubernetesみたいなやつ）ではないものでもクラウドネイティブ関連ツールであれば掲載されます。ただうちのチームのボスはCNCFのTOCでチェアーをやっています。このTOCは投票でCNCFのプロジェクトとして採択するかどうかを決める立場であり、恐らく弊社OSSもCNCFプロジェクトして寄贈することは可能です。

なのになぜプロジェクト寄贈しないの？というのは前に質問して裏話が聞けて結構面白かったので、いつかオフラインの場で話せせたらなと思っています。

ThoughtWorks Technology Radarへの掲載

Trialという区分で載せてもらいました。

www.thoughtworks.com

どうやら凄いことみたいなのですが、見つけた当時は全く知らなかったので和田さんに教えていただきました。

無知すぎてめちゃめちゃ恥ずかしいことを言っていました。

AWSブログ掲載

AWSのブログに載せてもらいました。ECRの裏側ではClair使われてるのでTrivyダメなのかというとそういうわけではなく、単純にECR連携のプロジェクトが開始したときはまだTrivyなかったとかそういう背景もあったりします。

aws.amazon.com

これはうちのボスがAWS Container Hero的なやつなので、その力も大きそうです。イギリスでTrvyについて発表したらAWSの人がブログ書いてほしいと声かけてきて寄贈したという流れみたいです。発表するだけで次々と面白い話が転がってきていてすげーな...と他人事みたいに眺めてました。

Grafanaでも利用

あんまりどこで使われているかとか把握してないのですが、自分がミスって最新版が一部の環境で動かなくなったときにGrafanaで動かないんだけど、と言われて知りました。個人で始めたので最初の頃はまだどこか気楽に考えていたのですが、有名OSSのJobを失敗させてしまって怒られるとなるともう気軽にミスできるようなプロダクトではなくなってきたのかなと思うようになりました。

github.com

Clairが自分のライブラリを使用

これはかなり驚いたんですが、Clairが自分のバージョン比較のライブラリを使い始めました。Clairを倒すために作り始めたものなのに気づいたらClairに使われるという。

github.com

自分はバージョン比較王を名乗るぐらいバージョン比較を厳密にやることにこだわっていて、有名なOSSの実装を見に行ってバージョン比較のバグを直してあげたりしています。Clairも過去にPR送って直したりしてます。その結果、自分たちで開発するよりライブラリを使おうとなったのかなと思います。そして選ばれたのが自分のライブラリというのは何とも奇妙な話です。

TrivyをベースにしたSaaSをリリース

Aquaには元々脆弱性スキャナーがあったのですが、Trivyをベースにした全く新しいSaaSを0から開発しました。このSaaSでは動的解析やランタイムセキュリティなど脆弱性スキャン以外の豊富な機能を提供しています。この辺りの詳細もいずれ書けたら良いと思っています。 containerjournal.com

ブログ

かなり多くの方にブログにしてもらったので全ては挙げきれないのですが、印象に残ったものをリストアップしておきます。漏れてたらすみません。

IBMのブログ

公式ブログっぽい？

developer.ibm.com

Use Trivy and Azure DevOps to scan container images for Vulnerabilities

Microsoft Azure MVPの方がAzure DevOpsとの連携を書いてくださったみたいです。

pixelrobots.co.uk

Understanding Kubernetes: part 21 – Useful tools - part 4 - security

dev.to

Google Dev Expertの方が書いてくださったみたいです。

January Virtual Meetup Recap: Improve Image Builds Using the Features in BuildKit

Docker Captainの方がDocker Blogに寄稿したようです。BuildKitとかがメインの話でTrvyはほんの少し出てくるだけです。

www.docker.com

gitrivy

スキャン結果をIssueに登録してくれるGitHub Actionsです qiita.com

kube-trivy-exporter

Prometheus Exporterを実装してkube-trivy-exporterとして公開して下さったという内容がLIFULLのブログで触れられていました。周辺ツールを作ってもらえるのは本当に大歓迎です。

www.lifull.blog

helm-trivy

フランス語的なやつですが、helm-trivyを作ったという話っぽい。 www.objectif-libre.com

Docker Image Security: Static Analysis Tool Comparison – Anchore Engine vs Clair vs Trivy

コンテナスキャナーを比較した記事。最終的にTrivyがオススメと言ってくれていたので安心しました（記事を開く前は緊張する）。ただ比較が若干正確ではないので（例えばTrivyはCVE-IDベースだけどClairはRHSA-ID使ってたりするとかするのでどちらかに変換して比較する必要がある）、自分の方で比較したやつを公開したいのですが色々あって実現に至っておらずです。

www.a10o.net

20 ways to become a better Node.js developer in 2020

なぜかNode.jsの記事に突然脆弱性スキャンの話が出てきたのが面白かったのでここに入れました。

medium.com

KitPloit

www.kitploit.com

2019年にOSS界隈で話題になったニュース10選～日立社内SNSより～

日立のような大企業で認知されるのはやはり嬉しいです。

qiita.com

その他

medium.com

devopschat.co

scrapbox.io

発表とか

自分はまだ一回もまともにカンファレンスで話してないのですが、カンファレンスやmeetup等で誰かが話してくれていたようで自分で頑張らなくても広がるのは便利だなと思います。

GitHubの人の発表かな？

これは確かKubernetes Forum Seoul

インド

などなど

雑多な話

それ以外にも雑多なやつを少し書いておきます。

ステッカー

ステッカーをAquaが作ってくれました。KubeCon North Americaで配ったらしくみんな持ってるのに自分だけ持ってないという状態だったんですが、帰国してきたあとにちゃんと自分ももらいました。

ボスの手腕はやはり大きいですね。シンプルに凄いなーと思っています。でも上に書いたようなニュースは営業とかして得たわけではないしプロダクトが結局良くないとダメかなと思っているので、そこはある程度頑張った結果かなと思っていたりもします。

今後について

まだまだ機能追加する予定です。本音を言うと自分はsimpleに保ちたいので別プロジェクトとして立ち上げたいのですが、話し合いに負けたのでTrivyに足していくことになりました。ここらへんの大変さはまた別途書けたら良いなと思っています。

具体的には今はGitHubのリポジトリスキャン対応をしています。もちろんGitHubが既にプログラミング言語のライブラリに対して脆弱性スキャンを提供しているのですが、意外と検知できない脆弱性も多かったりします。そもそもGitHub使ってないという人も多いのでこの対応をします。

プログラミング言語に関してもJavaとC#の対応をしたいと考えています。パッケージマネージャのlockfileをベースでやってるためMavenとNugetになります。Mavenの仕様が色々と難しく難航という感じですがいずれそう遠くない将来対応できると考えています。

先ほど上でも述べたようにWindowsイメージのスキャンも実装されると思います。実はAqua社としてはプライオリティが低いのですがMirantisの方がやる気十分なのでいい感じに実装してくださると思います。こちらも既に話は進んでいるので一緒にやっていくことになると思います。

あとはDockerfileに組み込んで使いたいという声もあるため、そちらの対応も現在進めています。元々Aquaが提供していたフリーのスキャナーでMicroScannerというものがあり、そちらはDockerfileへの組み込み機能がありそちらが好評だったようです。Trivyの加入によってMicroScannerは廃止予定なので機能を引き継ぐ予定です。

github.com

また、現在は脆弱性の結果に対して簡単なフィルターしか行えないのですがOPAと統合することで複雑なルールを適用可能にします。さらにKubernetesへOPAと共に組み込み、脆弱なイメージはデプロイできないような設定を可能にします。このあたりはKubeCon Europe 2020で発表予定だったのですが延期になったのでまだ発表していません。

そして現在のようなパッケージベースの脆弱性だけでなく脆弱な設定のスキャンも行う予定です。例えばNginxの設定がこうなっていると危険、などといったようなものです。conftestに近いです。ですがもう少しセキュリティに特化し、具体的な攻撃や脆弱性の検知を行っていきたいです。

脆弱性を検知するだけではなく、その後の対応にも踏み込みたいと思います。以前は可視化されていなかった脆弱性が可視化されたのは良いが、結局その後の対応が楽になっていないと思っており、そこを何とかしたいと考えています。具体的には動的解析との連携を予定しています。AquaではtraceeというeBPFベースのコンテナ動的解析ツールをOSSとして提供しており、これを使って内部ではコンテナのサンドボックス環境を構築しています。コンテナを実際に動かしイベントを観察し、起動後に実際に影響の大きい脆弱性を検知したいと考えています。例えばbashで致命的な脆弱性が発見されたけど実際コンテナ起動後には一切使われない場合は極端な話対応しなくてもあまり問題ないわけです。似たアプローチしてDockerSlimのようにそもそも不要なものをイメージから削除するアプローチもあるのですが、意外とアプリケーションが動かなくなったりして大変です。一部のファイルだけ除外設定を渡してあげたりとなかなかチューニングが求められます。そもそも消したくないという話もあるかもしれませんし、あくまで削除はせずに検知できたら良いなと考えています。

github.com

他にもまだ温めている新しいアイディアがあるのですが、それらはそこそこ新規性があると思っているので実際に開発してから発表したいと思います。これは今年のGWで作るぞ〜〜と気合い入れていたのですがイスラエルはGWなくて作れませんでした。有給めっちゃ余ってるので取得できれば作るかもしれません。それが無理だと来年ぐらいになる可能性もあります...

そして何よりまだまだ知名度が低いので宣伝を頑張らないといけないなと思っています。自分は宣伝が苦手なので特に何もしていないのですが、やはり使われるためにはまず知ってもらわないといけないなと思っています。比較した上で他のツールを、というならもっと開発頑張ろうとなりますが、知らなかったので選びませんでした、となるのはもったいないなと感じています。比較してもらえれば良さが分かってもらえたかもしれないのにそのチャンスを失っています。

まとめ

途中で疲れてしまって書ききれなかったけど色々あった半年でした。