SnykCon のまとめ: 自動化によるコンプライアンスの向上とフィードバックループの迅速化

DevSecOps の鍵は自動化です。それにより効率が高まるからです。ソフトウェア開発ライフサイクルで作業を自動化することで、複数のツールをワークフローに統合できます。また、開発者、メンテナンス担当者、セキュリティ担当者は、面倒な手作業に時間を費やす代わりに、難しい問題に対して創造的な解決策を考えることに集中できるようになります。

SnykCon 2021 での 2 つのプレゼンテーションは、自動化に焦点が当てられました。Citrix のサム・ホジキンソン氏 (Sam Hodgkinson) とベン・デイビス氏 (Ben Davies) は、自動化によりオープンソースライセンスの承認プロセスを簡素化した方法について詳しく説明してくれました。Bain のデイビッド・ウィッグス氏 (David Wiggs) は、自動化でパイプライン・アズ・ア・サービスを実現する方法について詳しく説明し、チームとともにセキュリティを CI/CD パイプラインに統合した方法について説明してくれました。どちらのセッションでも、開発ワークフローを強化する自動化の活用事例が紹介されました。

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

オープンソースソフトウェアについては多くの人が知っていますが、オープンソースライセンスについて知っている人はそれほど多くありません。オープンソースコードは開発者によって書かれたもので、一般に自由に利用することができます。オープンソースパッケージを使用する場合、オープンソースライセンスをどのように見分けることができるのでしょうか。自動化を導入すれば、コードに含まれるオープンソースライセンスを検出して、分析できます。これにより、オープンソースパッケージに適用されるライセンス制限が警告されるため、社内の法的ポリシーと比較して、コードに問題がないことを確認できます。

直面した課題

Citrix のエンジニアは、組織全体で使用される多数のパッケージマネージャーと言語をサポートしながら、プロジェクト内のすべてのオープンソースライセンスを検出する方法を探していました。また、ライセンスコンプライアンスに基づいて CI/CD ビルドをゲートで制御し、法務部門と連携してより明確に定義されたポリシーを全員に提供したいと考えていました。

そこで、サムとベンは、Snyk プラットフォームの導入を検討しました。それは、エンジニアたち (あるいは法務チーム) が苦労しない、シームレスで人間中心のワークフローを強く望んでいたからです。そのため、Snyk のツールを活用して構築したシンプルなユーザーインタラクションが気に入りました。

次に、将来のニーズに合わせて拡張可能なソリューションとするため、法的枠組みのポリシープロセス全体について、自動化して API に取り込むことを検討しました。

サムとベンは、Snyk のアウトプットを使って、ポリシー API でポリシーを決定し、ユーザーフレンドリーなフィードバックを提供して、開発者がポリシーに関する決定を承認するか拒否できるようにしました。

構築したソリューション

まず、CI/CD パイプラインを構築し、Snyk CLI を直接通過するソースコードから作業を始めました。Snyk はソースコードを分析し、ライセンス情報を返します。その情報はライセンスゲートを通過し、ライセンスの使用状況に応じてコードの一部を「不合格」にするかどうかを判断します。ライセンスゲートを通過したコードは、ポリシー API に送られ、イエスかノーで応答されます(ポリシーは Citrix 法務チームから提供されます)。 このプロセスは、90% のケースで完全に自動化されています。残りのケースでは、法務チームのメンバーが手動でレビューするためのチケットが生成されます。そのレビューが失われることはなく、ポリシー API にフィードバックとして返されて承認されると、開発者は作業を続行できるようになります。

「このプロセスを完全に自動化することで、2 週間かけて行っていたポリシー決定のほとんど (90%) を数秒に短縮することができました。これはすごいことです。」

Citrix は、複雑な法的枠組みに基づいてカスタムポリシーエンジンを開発しています。Snyk は、チームが技術的な障壁を克服してプロセスを完全に自動化し、CI/CD パイプラインでセキュリティを確保できるように支援しました。それにより、問題の解決に要する時間も短縮されました。自動化されたプロセスでは、ほとんどのポリシー決定が数秒で行われます。サムとベンは、ビルドの設定の一部として Snyk ツールを有効にすることで、テクノロジーにより自動的に処理されるようにしています。

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

セキュリティをソフトウェア開発パイプラインに組み込むことは、新しいアイデアではありません。ただ、人々はパイプラインの仕組みには注目するものの、パイプラインそのものがどのように使われるかについては見過ごしがちなだけです。Bain のデビッド・ウィッグス氏は次のように尋ねます。ソフトウェア開発パイプラインで開発者は必要なものを得られているでしょうか。セキュリティツールとテストツールは、開発者が使用する製品です。製品のパイプラインの場合は、ユーザー (開発者) がその使用に満足しているでしょうか。

自動化の 3 つの柱

「パイプライン・アズ・ア・サービス」モデルは、作業用のリポジトリを作るところから始まります。次に、パイプラインでステップを調達する場所を定義する「カスタムアクション」レポジトリの導入が考えられます。さらに、APIラッパー、リポジトリツール、あるいはツール固有の自動化など、ツール用のリポジトリを導入する場合もあります。

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

ワークフローを呼び出す

このレイアウトにより、次のステップを設定できます。

1. パイプラインワークフローをトリガーします (これによりパイプラインが「実行」されると考えることができます)。カスタムアクションリポジトリがチェックアウトされます。

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

3. ツール固有のスクリプトが実行されます。この方法では、機能のリクエストや更新が一元的に行われ、カスタムアクションを使用するすべてのユーザーが変更を継承します。

この同じパイプラインのアーキテクチャについて、セキュリティツールのリポジトリを下から順に見ていきましょう。このリポジトリには、複数の機能を定義したスクリプトを格納することができます。たとえば、Snyk API を使用する PowerShell スクリプトを呼び出して、指定されたリポジトリが Snyk プラットフォーム上にあるかどうかを確認し、ない場合はそのリポジトリをインポートできます。この時点で、いくつかのスクリプトが実行されており、残りのアーキテクチャでは、指定された作業リポジトリに対してこれらのスクリプトが継承されるようになっています。

では、1 つ上のレイヤーを見てみましょう。カスタムアクションリポジトリは、セキュリティツールリポジトリをチェックアウトし、セキュリティに特化したスクリプトを実行します。複合アクションを使用すると、複数のコマンドを 1 つのステップとして編成できます。これにより抽象化レイヤーを作成して、ユーザーエクスペリエンスを簡素化できますが、同時に複数のスクリプトを呼び出して依存関係を導入できます。

これは action.yml ファイル内で行われるため、必ずしも複数の作業用リポジトリに変更を導入する必要もなくバージョンを確立できます。

一番上のレイヤーでは、作業用リポジトリから GitHub カスタムアクションを表示できるようにします。作業用リポジトリのワークフローを初期化すると、カスタムアクションリポジトリがチェックアウトされ、その内容がランタイムに取り込まれます。ネストのチェックアウトを再度行うと、ツールリポジトリの action.yml ファイルとスクリプトを利用できるようになります。すべてのファイルとスクリプトは作業用リポジトリにあります。

ユーザーの観点からすると、「ネイティブ」な方法で複数のカスタムスクリプトを導入したことになります。Snyk ツールを使用して、GitHub アクションを使用することで、パイプラインにセキュリティが組み込まれます。GitHub アクションでセキュリティツールをパイプラインに統合できれば、開発者は使い慣れた作業スペース (GitHub) を離れずに、開発プロセスに関するセキュリティ情報を入手できます。開発者の見えないところですばやいフィードバックループを構築でき、複数の変更を依頼する必要はありません。

より良いワークフローのための自動化を追求する

自動化により、組織全体が効率化されます。今回のプレゼンテーションでは、自動化を活用した 2 つの事例をご紹介しますが、ほかにも多数の事例があります。Snyk のプラットフォームには、ワークフローに自動化を組み込む多数のツールが搭載されており、開発プロセス全体でシームレスにセキュリティ標準を組み込んでいます。