最初におさらい「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のチェックでアンチパターンとなるのが洗い出しやランク付けなどを手動で実施することや、リリース直前に行うこと。ただし開発段階の初期にチェックを済ませたとしても、開発期間中に脆弱性が発見されることもあるので、チェックは定期的に繰り返す必要もある。
