SnykCon振り返り：コンプライアンスの強化とフィードバックループの高速化を実現する自動化

自動化は効率を高めるため、DevSecOpsの重要な要素です。ソフトウェア開発ライフサイクルの作業を自動化すれば、複数のツールをワークフローに組み込めます。また、開発者やメンテナー、セキュリティチャンピオンは、面倒な手作業に時間を費やすのではなく、難しい問題を解決するための創造的な方法を考えることに専念できます。

SnykCon 2021では、自動化に焦点を当てた講演が2つ行われました。CitrixのSam Hodgkinson氏とBen Davies氏は、自動化を活用してオープンソースライセンスの承認プロセスを効率化した方法を詳しく紹介しました。BainのDavid Wiggs氏は、自動化によってパイプラインをサービスとして提供する方法を掘り下げ、チームがCI/CDパイプラインにセキュリティを組み込んだ方法を説明しました。どちらの講演も、自動化を活用して開発ワークフローを強化する方法を取り上げています。

オープンソースライセンス承認の自動化

オープンソースソフトウェアについて知っている人は多くても、オープンソースライセンスについて知っている人はそれほど多くありません。オープンソースのコードは開発者によって書かれ、誰でも自由に利用できます。オープンソースのライセンスは、オープンソースパッケージをどのように、いつ利用できるかを定めています。自動化によって、コード内のオープンソースライセンスを検出・分析できます。これにより、オープンソースパッケージに適用されるライセンス上の制限を確認し、社内の法務ポリシーと照らし合わせて、コードを安心して利用できるか判断できます。

直面していた課題

Citrixのエンジニアは、組織全体で使われている多様なパッケージマネージャーやプログラミング言語に対応しながら、プロジェクト内のすべてのオープンソースライセンスを把握する方法を求めていました。また、ライセンスコンプライアンスに基づいてCI/CDビルドを制御し、法務チームと協力して、誰にとっても明確なポリシーを策定したいと考えていました。

Sam氏とBen氏は、解決策を求めてSnykのプラットフォームを検討し始めました。エンジニアにも法務チームにも負担をかけない、シームレスで人を中心としたワークフローの構築を重視していました。また、Snykのツールを使って、ユーザーとのやり取りをシンプルにできる点にも魅力を感じました。

次に、法務の枠組みに基づくポリシーのプロセス全体を自動化されたAPIに組み込み、将来のニーズにも対応できる拡張性を持たせる方法を検討しました。

Sam氏とBen氏は、Snykの出力を使ってポリシーAPIで判断を行い、ポリシーの承認・却下について開発者が判断できるよう、わかりやすいフィードバックを提供できました。

構築したソリューション

ソースコードから始まり、Snyk CLIを経由するCI/CDパイプラインを構築しました。Snykがソースコードを分析し、ライセンス情報を返します。その情報はライセンスゲートに渡され、ライセンスの使用状況に基づいてコードの一部を「失敗」とするかどうかが判断されます。ライセンスゲートを通過したコードはポリシーAPIに送られ、「承認」または「却下」の応答を受け取ります。（ポリシーはCitrixの法務チームが策定します。）このプロセスは、ケースの90%で完全に自動化されています。それ以外のケースでは、法務チームのメンバーによる手動レビュー用のチケットが作成される場合があります。ただし、レビュー結果はそのまま反映されずに終わるわけではありません。承認内容はポリシーAPIにフィードバックされ、開発者は作業を続けられます。

「このプロセスを完全に自動化したことで、2週間かかっていた作業の大部分で、ポリシーに関する判断の90%を数秒で完了できるようになりました。素晴らしいことです。」

Citrixは、複雑な法的枠組みに基づくカスタムポリシーエンジンを開発しました。Snykは、CI/CDパイプラインを通じてセキュリティを実現しながらプロセスを完全に自動化できるよう、技術的な障壁の克服を支援しました。また、解決までの時間も短縮されました。プロセスが自動化されたことで、ほとんどのポリシー判断が数秒で完了します。現在、Sam氏とBen氏はビルド設定の一部としてSnykのツールを有効にするだけで、あとはテクノロジーが処理します。

フィードバックループを閉じる

ソフトウェア開発パイプラインにセキュリティを導入すること自体は、新しい考え方ではありません。しかし、パイプラインの仕組みに目が向き、そのパイプラインが実際にどう使われているかは見落とされがちです。BainのDavid Wiggs氏は、こう問いかけました。提供しているソフトウェア開発パイプラインを開発者は使っているか、そして必要なものを得られているか、と。セキュリティツールやテストツールは、開発者が利用する製品だと考えてみてください。パイプラインが製品なら、ユーザーである開発者はそれを使いこなせているでしょうか。

自動化を支える3つの柱

「サービスとしてのパイプライン」モデルは、稼働中のリポジトリから始まります。次に、パイプラインがどこから各ステップを取得するかを定義する「カスタムアクション」リポジトリを用意します。さらに、APIラッパーやリポジトリツールなど、ツールごとの自動化を含むツール用リポジトリを設けます。

最初の3つの柱によって、変更や追跡が必要な場所を最小限に抑えられます。ユーザーからプロセス改善の提案があった場合、複数の場所で同じ変更を繰り返すのではなく、1か所で対応できます。

ワークフローの実行

この構成により、次の手順を実行できます。

1. パイプラインのワークフローが起動します（パイプラインが「実行」されるイメージです）。カスタムアクションのリポジトリがチェックアウトされます。

2. action.ymlファイルによって、セキュリティツール専用のリポジトリがチェックアウトされます。

3. ツール専用のスクリプトが実行されます。これにより、機能リクエストや更新を一元的に行い、カスタムアクションを利用するすべてのユーザーに変更を反映できます。

同じパイプラインアーキテクチャを、セキュリティツールのリポジトリから順に、下の層から見ていきましょう。このリポジトリには、複数の機能を定義するスクリプトを格納できます。たとえば、Snyk APIを使うPowerShellスクリプトを呼び出して、対象のリポジトリがSnykプラットフォームに登録されているか確認できます。登録されていなければ、そのリポジトリをインポートします。この段階ではいくつかのスクリプトが実行され、残りのアーキテクチャによって、稼働中のリポジトリでこれらのスクリプトを継承できるようになっています。

次に、1つ上の層を見てみましょう。カスタムアクションのリポジトリは、セキュリティツールのリポジトリをチェックアウトし、セキュリティ専用のスクリプトを実行します。コンポジットアクションを使うと、複数のコマンドを1つのステップとしてまとめて実行できます。これにより、ユーザーエクスペリエンスをシンプルにする抽象化レイヤーが生まれる一方、複数のスクリプトを呼び出したり、依存関係を追加したりできます。

これはaction.ymlファイル内で行われます。このファイルを使えば、複数の稼働中リポジトリに変更を加えずにバージョンを設定できます。

最上位の層では、稼働中のリポジトリからGitHubのカスタムアクションを利用できるようにします。稼働中のリポジトリでワークフローが初期化されると、カスタムアクションのリポジトリがチェックアウトされ、その内容が実行環境に取り込まれます。さらにネストしたチェックアウトを行うことで、ツールリポジトリにあるaction.ymlファイルやスクリプトを、稼働中のリポジトリの実行環境内で利用できます。

ユーザーの視点から見ると、複数のカスタムスクリプトを導入しながらも、「ネイティブ」な方法で利用できます。GitHub Actionsを使ってSnykのツールによるセキュリティをパイプラインに組み込めます。GitHub Actionsでセキュリティツールをパイプラインに統合すれば、開発者はセキュリティ情報を得るために、使い慣れた作業環境（GitHub）を離れる必要がありません。複数の場所に変更を加えるよう開発者に求めることなく、「裏側」でフィードバックループを高速化できます。

ワークフローを改善する自動化を探る

自動化は、組織全体の効率向上につながります。ここで紹介した講演は、自動化を活用する2つの例ですが、ほかにも多くの方法があります。Snykのプラットフォームには、ワークフローに自動化を取り入れ、開発プロセス全体にセキュリティ基準をシームレスに組み込むためのツールが数多く備わっています。