開発者主導のセキュリティ対策の強い味方、脆弱性スキャンを随所に組み込む「Snyk」の価値

2022年11月21〜22日に開催されたクラウド関連の最新動向に迫るテックカンファレンス「CloudNative Days Tokyo 2022」に、Snykの日本法人でシニアソリューションエンジニアを務める伊藤 仁智氏が登壇。開発者主体で取り組むセキュリティ対策の重要性を説くと共に、そこで役立つ脆弱性管理サービス「Snyk」の詳細を解説した。

Snykでシニアソリューションエンジニアを務める伊藤 仁智氏

Snykは、SaaS型でソフトウェアの開発ライフサイクルに組み込んで使える開発者向けの脆弱性管理サービスだ。統合開発環境(IDE)、バージョン管理ツールのGit、各種CI/CDツールなど、組み込める対象が広いのが特徴。開発中のソースコードや利用しているオープンソースライブラリ、コンテナイメージ、IaC(Infrastructure as Code)に含まれる脆弱性を検出するのが主要な機能である。

Snykの設立は2015年で、すでにクラウドネイティブへと時代が移りゆくタイミングだったと伊藤氏は振り返る。「従来のレガシーな環境と比べて、アプリケーション開発者のカバー範囲はますます広くなっています。開発者主体のセキュリティ対策と、開発者にとって使いやすいツールが必要であり、まさしく、そのニーズに応えるのがSnykです」。

DevOpsにSecを挟み込むことは
依然として難しい

開発チームと運用チームとの分業が一般的だったころ、開発者はソースコードを書いて成果物を作るだけでよかった。その成果物をデプロイして実ビジネスに展開するのが運用チームという明確な線引きがあったわけだ。ところがクラウド全盛となり、そこで動かすアプリケーションをどんどん進化させることが競争力を左右するようになると、悠長なやりかたが通用しない。そこで、必然的にDevOpsのようなアプローチが注目されることとなった。

実際のところ、昨今のシステム開発においてはソフトウェアで制御する範囲が拡大し、開発者がシステムのソースコードを書くだけでは済まなくなっている。SaaSとの連携、コンテナイメージの作成、サーバーの構成・設定をコード化するIaCのスクリプト作成、といった作業もカバーする必要が出てきているのは周知の通りだ(図1)。

図1：クラウド時代は、ソフトウェアで制御する範囲が拡大している。開発者がカバーしなければならない範囲は広がっている(出典：Snyk)

当然ながら、こうしたタッチポイントの全てにおいてセキュリティを考慮しなければならない。ところが「開発者はアプリケーションのソースコードを書くことは得意でも、クラウドのインフラについてはさほど詳しくない場合が多いため、脆弱性が潜在してしまうことが懸念されています」と伊藤氏は来場者や視聴者に訴えた。

CI/CDに代表されるような開発と運用を支援するツールが充実してきたことによって、DevOpsの実現のハードルは低くなっている。しかし、「セキュリティの要素を組み込んだDevSecOpsについては、まだ実現できている企業は少数派です」と伊藤氏。開発とセキュリティの分業体制が解消されない理由として伊藤氏は、セキュリティツールが未成熟である点を挙げる。

Audit(監査)ではなく
修正のために脆弱性をスキャンせよ

ソフトウェア開発におけるセキュリティ対策の現状を見ると、ほとんどにおいて開発者と監査担当者(セキュリティ担当者)が個別に動いているのではないだろうか。開発後、セキュリティ担当者が静的解析ツールを使ってソースコードを監査するようなスタイルだ。

このように従来のスキャンツールの主な目的は“Audit”であり、開発が終わった成果物をリリースする直前に、監査目的でスキャンしていた。もちろんのこと、監査で問題があった場合は手戻りが発生していたわけである。

ここでの課題を打破するためによく採られる戦術がシフトレフトだ。静的解析などによるソースコードの監査を、当初のソースコードでの開発段階に組み込むアプローチを指すが、「監査の場所を前工程に移すだけでは、開発者に負担を強いるだけとなり意味がない」と伊藤氏は指摘する。

IDEで使える監査ツールなど、アプリケーション開発時に簡易的にセキュリティをチェックできるツールが出てきているのは朗報に映るものの、実際には脆弱性をすべて検出することは難しく中途半端との声もある。「前工程で脆弱性を潰したつもりでも、後工程で問題が見つかり結局は手戻りが発生してしまうケースが少なくありません」(伊藤氏)。

アプリケーション開発者が主体となって
脆弱性を修正

セキュリティ担当者の絶対数が少ないという切実な事情もあり、つまるところ「開発者が主体となって取り組まない限りセキュリティを担保することは難しく、DevSecOpsの実現もかないません」とは伊藤氏の弁だ。

こうした背景から求められているのが、開発者主体の脆弱性管理ツールだ(図2)。監査時に1回だけスキャンするのではなく、ソフトウェア開発工程のあらゆる場面で継続的にスキャンすることが望ましい。スキャンの目的は監査ではなく、脆弱性を修正することだと再認識しなければならないのだ。

図2：スキャンの目的は監査ではなく、脆弱性を修正すること。開発者が主体となって、ソフトウェア開発工程のあらゆる場面で継続的にスキャンすることが大切(出典：Snyk)

開発工程の各箇所に
脆弱性対策を組み込めるSnyk

時代の要請に応えるものとして、講演の後半ではSnykを紹介することに時間を割いた。同社は、脆弱性を調べる対象に応じて4つのサービスを提供している(図3)。自分で開発したコード向けの「Snyk Code」、オープンソース向けの「Snyk Open Source」、コンテナ向けの「Snyk Container」、IaCコード向けの「Snyk IaC」だ。以下に概要をまとめる。

図3：脆弱性管理サービス「Snyk」の概要。脆弱性を調べる対象に応じて4つのサービスを提供している。新サービス「Snyk Cloud」の提供も予定する(出典：Snyk)

Snyk Codeは、開発者自身で書いたソースコードの脆弱性を検出する。頻繁なデプロイが発生することを想定し、短いスキャン時間で、なおかつ簡単に使えることを重視した。スキャンの対象は、プログラミング言語で記述したソースコードだ。

Snyk Open Sourceは、開発で利用しているオープンソースのライブラリに含まれる脆弱性を検出する。脆弱性が存在しているパッケージを利用しているかどうかを調べ、必要に応じてパッチを当てる。スキャンの対象は、パッケージマネージャーのマニフェストファイルだ。

Snyk Containerは、コンテナイメージ及びコンテナにインストールされたオープンソースのライブラリに含まれる脆弱性を検出する。また、コンテナのベースイメージから混入してくる脆弱性への対処として、安全なベースイメージを使うためのアドバイスを提供する。スキャンの対象は、コンテナのイメージだ。

Snyk Iacは、サーバーの設定ミスや、ベストプラクティスから外れた運用などを、アプリケーションをプロビジョニングする前にチェックする。スキャンの対象は、TerraformやCloudFormationなどのIaCツールのスクリプトだ。さらに、コンテナ運用基盤であるKubernetesの設定ファイルを検査し、安全でない設定を検出する。

Snyk Cloud投入で
稼働後も継続的にスキャン可能に

4つの製品は、開発工程のどこにでも組み込める(図4)。コーディング段階でスキャンするためのシステム要素として、IDEのプラグインやコマンドラインツールを提供している。これにより、Gitなどのリポジトリに登録する前に脆弱性を潰せる。シフトレフトの最も左側での対策になる。

図4：Snykは、コーディング段階、ソースコード管理、CI/CD、運用環境など、開発工程の各箇所に組み込んで利用できる(出典：Snyk)

ソースコード管理のフェーズでもGitと連携。Gitのリポジトリにコードが登録されたタイミングで解析したり、1日に1回など定期的にリポジトリをスキャンしたりして脆弱性を検出する。CI/CDと連携し、ビルドなどが動作する度にSnykを起動して検出する使い方もできる。

クラウドが主流の今は、本番環境の監視も必要性を増している。脆弱性は、ある時点で見つかっていなくても、後日見つかることが珍しくないためだ。すなわち、継続的スキャンが不可欠ということであり、このニーズを満たすために用意する新サービスが「Snyk Cloud」である。「従来のSnykは、プロビショニング前の静的なリソースをスキャンしていました。これに対して、現在稼働しているリソースをスキャンするのがSnyk Cloudの位置付けです」(伊藤氏)。

このようにクラウドネイティブ時代のDevSecOpsを推し進めるために、全方位で着々と機能を充実させているのがSnykなのである。