WhiteSource導入事例 - 株式会社ラキール様※WhiteSourceは、「Mend SCA」に名称変更となりました。
OSSの脆弱性とライセンスを
一括で自動チェックする仕組みを、
WhiteSourceを使って構築していきます
株式会社ラキール
株式会社ラキール プロダクト開発本部 飯田氏（写真左）、金子氏（写真右）にWhiteSourceを導入した経緯とその効果について詳しく聞きました。
（ラキールについて）
株式会社ラキール（https://lakeel.com/) は、デジタルネイティブカンパニーとして、投資効率の高い製品・サービスにより顧客のビジネスに貢献することをミッションとし、企業のDX化を推進するシステムを開発、提供しています。プロダクト開発本部ではLaKeel DXというデジタル・ビジネス・プラットフォーム上で各種SaaSを展開しています。
SaaS 展開しているサービスには在宅ワークを促進するLaKeel Workflow、データ分析基盤のLaKeel DataInsight、Microsoft 365などと連携する認証サービスのLaKeel Passport などがあります。
また、LaKeel DXプラットフォーム自体をお客さまのクラウド環境へ導入し、ラキールが提供するコンポーネントとお客さまが独自に開発するコンポーネントを組み合わせることでローコード開発を支援するプラットフォームとして利用いただいています。
自社クラウド製品を安心してお客さまに使ってもらうためのDevSecOpsの実現
ラキールではオープンソースソフトウエア（以下OSS）を積極的に利用しています。WhiteSource はそれらのOSS に対して「ライセンス形態が自社ポリシーに照らして妥当か」「脆弱性がないか」などをチェックするために活用しています（※ 以下「OSSチェック」と総称）。
貴社ではWhiteSourceをどう活用していますか。
2020年2月に購入し、4月から本格的に利用し始めました。
私たちプロダクト開発本部 LaKeel Platform Groupでは、ソースコード管理にGitLab を利用しており、CI/CD の仕組みとWhiteSource を連携させてOSSチェックを行っています。WhiteSource が提供しているUnified Agent というコマンドラインツールを利用し、パイプラインの一部として自動実行しています。
現在はチームメンバーの一部で活用を開始しています。次の段階として開発チームごとにWhiteSourceを使って開発サイクルにOSS チェックを組み込むことで、開発サイクルの早い段階でセルフチェックできるDevSecOps体制を構築中です。
ExcelによるOSSチェックの限界
昨今、開発におけるOSSの活用は当たり前になってきました。今までは、開発チームごとにOSS のライセンスを管理していましたが、大量のOSSを利用するとなると、Excel 管理だけでは管理漏れが起きてしまいライセンス違反に気づけないリスクに危機を感じました。このため全てのOSS のライセンスや脆弱性を一括で管理できるツールを探すことにしました。
OSSチェックツールの導入目的
ラキールがOSSチェックのシステム化を推進している目的について教えてください。
OSSチェックのシステム化の目的は次の5点です。
- 目的1．「プロダクトの品質向上と早期リリースの両立」
- LaKeel DX ではサービス単位、コンポーネント単位で開発し、クラウドを通じてサービスを提供しています。開発の効率化とリリースの早期化を実現するためにOSS を積極的に利用しているため、OSS の脆弱性の排除とライセンスポリシーに関する妥当性の確保が重要になります。しかし、これらを実現するためのOSSチェックを、Excelなどを利用した手作業で行うのではチェック自体に時間がかかってしまいます。そこで、チェックツールを利用してOSSのライセンスや脆弱性チェックにおける時間の短縮と管理の効率化を実現し、早期リリースとセキュリティの確保を両立します。
- 目的2．「チェック品質の向上」
- OSSは頻繁にコードが更新されます。それに伴い脆弱性に関する情報もどんどん更新されていきます。高品質のチェックを行うには、常に最新の脆弱性情報を入手する必要がありますが、それを手動で行うと抜け・漏れのリスクが生じてしまいます。このため「最新情報の入手」をチェックツールの活用により保証します。
- 目的3.「チェック精度を高位平準化する」
- OSS チェックを属人的に行っていると、「人による判断のバラツキ」が生じてしまいます。システムを使ってチェックすることにより、高レベルの脆弱性チェックや会社のポリシーに照らしたライセンス妥当性のチェックを、全社で平準化して実施することが可能になります。
- 目的4.「早い段階で、頻繁にチェックする」
- 脆弱性やライセンスのチェックは、リリース直前でのチェックという形で一括して大きく行うのではなく、開発サイクルの中で日々チェックを行い、その都度対処することで手戻りを減らし、開発者への負担を軽減します。
- 目的5.「製品開発への集中」
開発者がOSS の脆弱性やライセンスの管理に時間を割かれることなく、開発者は「開発スピードを速め、高品質なサービスを提供」できるよう、ツールを導入し開発者の負担を軽くします。
以上の目的のもと、自社のOSS チェックをシステム化することを決定し、具体的な製品選定を開始しました。
製品選定はどう進めていったのでしょうか。
はじめに、ラキールの知財関係の顧問弁護士に「良いOSSライセンスチェックツールはないか」と相談し、10製品ほどリストアップしてもらいました。同時に自分たちでもインターネットでの検索や「ライセンス管理」などをテーマにしたセミナー参加を通じ、情報収集しながらピックアップしました。
次に、それらを「CI/CD サイクルに組み込めるか」「コンテナに対応しているか」などの初期条件でふるいにかけ、その結果、WhiteSourceと製品D、製品Fの3製品が残りました。
さらにコスト面で比較検討した結果、最終的にはWhiteSource と製品F を実際の環境で検証し製品選定を行いました。
製品を選んだ3つのポイント
WhiteSourceを選定されたポイントを教えてください。
検証した製品の比較ポイントは大きく3つあります。
- ポイント1.「 社内のCI/CDに簡単に組み込めること」
- 現在、社内で推進している開発のCI/CDパイプラインに無理なく組み込めること、ソース管理ツールなど他システムの連携が容易であることを求めました。
- ポイント2.「開発エンジニアの負担が少ない」
OSSチェックは将来的に、全ての開発者が日常的に行うことになります。その場合、プロセス数、手間数は少ないほどよい。たとえわずかな一手間でも、その分、ビルドやデプロイの所要時間が延びてしまいます。
製品Fは、「ソースコードをGitLabとは別のサーバーに置き、そこでハッシュ計算を行い、脆弱性をチェックする」という仕様でした。この場合、別サーバーにソースを送る必要があり、余計な1 ジョブが増えてしまいます。CI/CDサイクルを回すにあたって、毎回ソースを解析用の専用サーバーにコピーする処理は、ビルド～デプロイにおいて時間がかかり、非効率的であると判断しました。
一方WhiteSource では、OSS を登録するローカルサーバーにエージェントを導入すれば、そこで勝手にハッシュを作ってくれる。手間がかからず、ネットワーク通信にかかる時間も少ない仕様でした。CI/CD を円滑に回すために、CI/CD サイクルへの影響が小さいことがWhiteSource を選んだポイントでした。
- ポイント3.「ひと目でわかるインターフェース（ダッシュボード）」
今後、開発者自身でOSS のライセンスや脆弱性をセルフチェックするにあたり「見やすい」「わかりやすい」というのは非常に重要なポイントでした。WhiteSource と他製品との差は歴然で、WhiteSourceは誰でも直感的にわかりやすいダッシュボードで学習コストが低いことを評価しました。
以上の選定基準で候補製品を相互比較しました。ラキールが求める要件をWhiteSource が相対的に満たしていたため採用に至りました。
現在の評価とこれからの活用
実際に使ってみて「見やすい、すぐわかる」ことの価値をあらためて実感しています。WhiteSourceでは、OSS のライセンスに対してリスクスコアが出るので、それを「指標」として判断できます。早い段階で危険なOSS を把握できるので重宝しています。ダッシュボードもわかりやすく直感的な画面構成で使いやすいと感じています。
WhiteSourceをこれからどう活用していきたいと考えていますか。
ラキールでは、WhiteSource を開発サイクルに組み込むことで開発の早期段階においてセキュリティチェックを実現します。
それにより開発者自身がOSS のコンプライアンスやライセンスに対して意識をもち、WhiteSource から脆弱性やライセンス違反が見つかったときにアラートが上がれば、すぐに修正するといったDevSecOpsのサイクルを社内に確立していきたいです。その開発サイクルが確立することで開発スピードが上がりOSS を活用した高品質な製品の提供につながると考えています。
WhiteSource およびリックソフトにはそうしたラキールの取り組みを、OSSチェックに関する優れた技術、製品、サポートを通じて、後方支援いただくことを希望します。今後ともよろしくお願いします。
本事例の内容は2020年8月取材時のものです。
本事例掲載のダッシュボード、レポート画面はサンプルであり実際のデータとは異なります。
本事例に記載されている会社名、製品名は各社の商標または登録商標です。