最初におさらい「DevOps」と「アーティファクト」
今日のテーマはDevSecOpsの実践。その前にキーワードとなる「DevOps」と「アーティファクト」をおさらいしておこう。横田氏は「DevOps」を「顧客に価値を素早く届けるため、開発と運用が協力する文化的な姿勢や取り組み」と定義する。Dev（Developer：開発）とOps（Operations：運用）が同じ方向を目指して協力していくことが重要なポイントだ。
かつては全く別々の組織として歩むのがよいとされていた開発と運用だが、今では「それじゃやっていけない」と横田氏。両者の間で分断があると「バトルばかりがはかどってしまい、ビジネスやサービスの成長が停滞」してしまうため、競争に勝てなくなってしまう。
もう1つは「アーティファクト」。ビルドやパッケージングを経て生成されたファイルを指す。多くはバイナリファイルにあたり、「～～パッケージ」と呼ばれるものやDockerやKubernetesで用いる「コンテナイメージ」などをひっくるめてアーティファクトと呼ぶ。
DevOpsにセキュリティを組み込んだDevSecOpsとは具体的に何をするのか？
では本題となるDevSecOpsへと進もう。DevSecOpsはDevOpsを発展させて、セキュリティ（Sec）も協業の輪に組み込む。とはいえセキュリティはとても幅広く、いくつもの層（データ、アプリケーション、エンドポイント、ネットワークなど）がある。DevSecOpsで扱うセキュリティは主にソフトウェアに関連するものとなる。
DevOpsもDevSecOpsも多様な立場が協力し、究極のゴールとして「エンドユーザーに素早く価値を提供し続けること」を目指す。サービス提供側は新機能を素早くリリースし、ユーザーから反応（レビューコメントや利用頻度、滞在時間など）を得てまた新しいフィーチャーへと繋げる。このフィードバックサイクルを回し続けることが欠かせない。
「エンドユーザーに素早く価値を提供し続けること」をゴールに掲げているものの、もちろんDevやOpsにも恩恵がある。横田氏は「サービスの改善はもちろん、リソース不足や繰り返し作業といった身近な悩みにも効果があります」と、DevOpsは個人レベルでも恩恵をうけることができる点を強調した。
DevOpsの実践で欠かせないのがCI/CD（CIは継続的インテグレーション、CDは継続的デリバリー・継続的デプロイ）。CIではソースコードをチェックアウトしたら、ビルドして、テストして、CDではリリースして、デプロイする……と進む。ここに自動化ツールを活用してCD/CDパイプラインを作る。
DevSecOpsはソフトウェア開発ライフサイクルにセキュリティの考慮を入れることであり、具体的にはCI/CDパイプラインにセキュリティを組み込むことと言える。なるべく自動化することが大事であり、できるだけ早いタイミングで問題を検出できるような構成にするのがいい。後からまとめてセキュリティの問題が発覚すると手戻りが大きくなるためだ。左から右に時間が流れるよう表現することが多いパイプラインの図において「早い段階」とは「より左」に寄せていくことになるので、「シフトレフト」という表現もある。
先ほどDevSecOpsに該当するセキュリティとはソフトウェアに関するものと限定したものの、この中でも取れる手段は多種多様だ。具体的には脅威モデリング、静的アプリケーションセキュリティテスト（SAST）、動的アプリケーションセキュリティテスト（DAST）、ソフトウェアコンポジション解析（SCA）、ファジング、ペネトレーションテストなどである。
またテスト対象は自前で書いたコードや設定の他に、自分たち以外が開発したOSSやライブラリなどもある。開発者はつい自分が書いたコードだけに目を向けがちかもしれないが、後者も忘れてはならない。特にOSSだ。
今では9割以上の組織がソフトウェア開発でOSSを利用している。そしそのOSSは多くの場合、別のOSSに依存している。あるデモでは、簡単なアプリケーションを作った時のコードの行数が示されていた。開発者が書いたのはたった4行であるにも関わらず、依存解決をした後のコード全体は52万行を超えるという。実際の数字はさておき、自分が書いたコードがほんのわずかでもアプリケーションを完成させるには大量のコードが関与しており、それだけリスクも潜んでいるということだ。
OSSに潜むリスクを放置し、事故が起きたケースもある。例えば2017年にはJavaのWebアプリケーションフレームワークとなるApache Struts2の脆弱性が攻撃され、情報流出につながったケースがあった。また2014年に発見されたOpenSSLの脆弱性（Heartbleed）はクレジットカード情報の漏えいなどの問題をもたらした。脆弱性を放置したことで深刻な問題に発展したケースは数知れず、OSSを利用するなら脆弱性に関する情報は常に警戒しておくべきだろう。
そのためソフトウェア開発では（自分たちが書いた）ソフトウェアの動的なチェックと、使用するOSSの静的なチェックの両方を実施する必要がある。なおOSSのチェックでアンチパターンとなるのが洗い出しやランク付けなどを手動で実施することや、リリース直前に行うこと。ただし開発段階の初期にチェックを済ませたとしても、開発期間中に脆弱性が発見されることもあるので、チェックは定期的に繰り返す必要もある。
DevSecOpsを一歩進めることができるバイナリ・リポジトリマネージャー（BRM）
ここで横田氏は「自分たちで書いて生成したソースコードだけを管理・チェックするのでは足りません。アーティファクトも管理しましょう」とバイナリ・リポジトリマネージャー（以下、BRM）の活用を提案する。BRMとはアーティファクトの保管専用ツールであり、アーティファクトの脆弱性やライセンスのチェックができるSCAツールと組み合わせて使うことができるものだ。
しかしここで疑問が沸くのではないだろうか。「ソースコードがあればアーティファクトを作れるのだから、わざわざ別に管理する必要はないのでは」と。横田氏はこの疑問に対して「同じソースコードをビルドしても、アーティファクトの中身が同じになるとは限らないため」と説明する。依存解決の際に含まれるOSSのバージョンが変わるかもしれないし、ビルド時のフラグや設定の差異で結果が異なることもありえる。
さらに、アーティファクトはビルドにより一度作られると、テストやデプロイのさまざまな段階で何度も使い回す。使う度にアーティファクトを刷新していては、「検品済みのものを出荷する」ことができない。せっかくテストやSCAを行っても、それと違うアーティファクトをリリースするのでは効果が弱まる恐れがある。また、ビルドにはそれなりの時間がかかる。それなら本番まで同じものを使うほうが時間を節約できて、流動的な要素を減らすことができて確実だ。
アーティファクトをBRMに保存して管理するとしよう。保存するものは2種類ある。これまで説明したように自分たちのソースコードからビルドして作成したアーティファクトに加えて、Docker Hub、Maven Central、npmなど外部から取得したアーティファクトもある。
前者についてはこれまで説明したとおり。後者は外から取ってくるわけだが、必要になるたびに取得するのではなく、保存しておけば2回目以降のダウンロード時間を短縮可能だ。何らかの障害で取得できない時に備えておくこともできる。どちらもSCAツールで定期的にセキュリティスキャンを実施し、問題があれば修正するまで使用できないように設定できる。
このようにBRMはセキュリティの組み込みの他にもビルド時間の短縮や品質の担保に効果的なツールと言えるわけだが、今回のテーマ「DevSecOps」を考えるときにはやはりSCAとの連携が肝となる。CI/CDパイプラインの中でビルド時とリリース時にスキャンを行うことで、開発ライフサイクルにセキュリティが組み込まれることになる。DevSecOpsを1つ実現したと言えるだろう。
横田氏は「SCAツールを導入したら、OSSスキャンは当然実施することとして定着させること」と釘を刺した。「今回は忙しいからスキップ」などとルールが形骸化してしまったら意味がない。またスキャンで問題が発覚したときのフローもあらかじめ決めておくといい。こうしてセキュリティチェックも自動化することにより、人間がより重要な判断に時間を費やせるようになる。
最後に横田氏は「みなさんの組織ではどうでしょうか」と問いかけた。DevOpsやDevSecOpsの理解が浸透している環境だろうか。「なぜやらなくてはいけないの？」という疑問が最初の大きなハードルとなる。
特に、上司を説得したり組織全体を巻き込んだりするところで苦労する人も多い。ただ、セキュリティはこうした壁を越えるのにも効果的である。「開発が効率化される」「運用がしやすくなる」といったメリットに比べて「セキュリティ対策ができる」というのは誰にとっても分かりやすく、所謂マネージャーや経営層を巻き込むきっかけにしやすいからだ。これを越えることができたら、以降は楽になる。アーティファクトの管理、CD/CDパイプラインの整備、CD/CDパイプラインにセキュリティを組み込む、というようにステップアップしていけばいい。
「自分の組織でできていること、できていないことを分析し、取り組めるところから始めましょう。まずは身近な仲間と話すことから始めてみては。自分が楽になり、幸せになることを考えて行動すればチームや、ひいては会社のためになります」（横田氏）
JFrog Platformで早速DevSecOpsを始めてみませんか
JFrog Artifactoryによるバイナリ管理を中心とした継続的インテグレーション（CI）と継続的デプロイメント（CD）の実現が可能です。まずは無料版からお気軽にお試しください。：JFrog Platformご利用開始ページ
