2022年のDevOps：ソフトウェア・サプライチェーンを活用するための5つの重要なポイント
JFrogは、コミュニティとともに、バイナリ（ソフトウェアパッケージ、アーティファクト、またはイメージ）に焦点を当てて、現在のDevOpsを開拓しました。10年前は、バイナリ管理が重要だとは誰も考えていませんでした。今では、ほとんどの企業がこれなしでは生きていけない標準となっています。我々は当時からソフトウェアの普遍性が必要だと訴えてきましたが、今では他の人もそれに追随しています。かつて、クラウドはひとつのベンダーを使うものだと考えられていました。しかし、JFrogはハイブリッドクラウドとマルチクラウドに投資し、今では業界全体で実現しています。
2021年にはDevOps市場で大幅な成長の見込みとお伝えしました。それからわずか1年間で、一部の公開企業と投資家がDevOps市場の総獲得可能市場（TAM – Total Addressable Market)は500億ドルと見積もっていることを知りました。私たちの着目してきた市場が正しいものだと証明できる、確かに素晴らしい評価です。しかし、今デジタルでビジネスをさらに変革していく時となり、すべての企業の変革をサポートするためにDevOpsの次なる飛躍のチャンスがきていることがわかります。
6つの障害 DEVOPSの成功に向けて | EBOOK
EBOOK をダウンロード
2022年はバイナリがすべてです
自動化により、よりスマートで、より迅速で、より優れたソフトウェアが大規模に開発されるようになり、今やバイナリ管理はあらゆる企業の中核となりました。そして、ソフトウェアが世界を動かし、バイナリはすべての人のビジネスの源になっています。その意味を説明します。
バイナリは、組織に「持ち込まれ」、構築、テスト、自動化、セキュリティの確保、プロモートを経て、エッジで配布されます。バイナリは、ソフトウェア・サプライチェーンの血流であり、最終的に本番環境に提供されるソフトウェアの世界で唯一の資産です（この役割を果たすのはソースコードではありません）。ソフトウェア・サプライチェーンは、組織の開発チームによってインポート、構築、配布されるバイナリのことであり、ソースコード中心のアプローチでは単純に制御できません。
実際、「Git以降」のすべては、ソフトウェアリリースサイクルのバイナリ主導のステップとなります。自動化とはバイナリに関することです。エッジへの配布とはバイナリ展開のことです。たとえそれが静的なソースコードのスキャンからはじまったとしても、企業のセキュリティは、本番環境で実行されるバイナリに関係しています（SolarWindsとLog4jをご参照ください。詳細は後でご説明します）。以上です。
JFrogは長年バイナリビジネスに携わってきましたが、2022年には、多くの企業やプラットフォームのロードマップで、バイナリのライフサイクルがDevOpsやセキュリティスタックのミッションクリティカルな部分として扱われるようになると考えています。この部分が適切に処理されなければ、企業は来年のデジタル・トランスフォーメーションの約束を果たすことができないでしょう。
「デジタル・トランスフォーメーション」という言葉を昨年の言葉だと思っている人は、もう一度考え直してみてください。アナリストの中には、デジタル・トランスフォーメーションを計画している企業のうち、まだ4分の1しか着手できていないと推測しているところもあります。変革をもたらすDevOpsには長い道のりがあり、バイナリ管理によりその道は拓かれています。
DevSecOpsはまだ現実のものではありません
（しかし、そうなる可能性を秘めています）
「DevSecOps」の周りにはたくさんの話題がありますが、これはまだ単なるフレーズに過ぎません。開発者とセキュリティの関係者が、共通認識を持てるような具体的な標準がないことは確かです。その理由を正直に言いましょう。DevOpsは開発者と運用チームをより融合させる考え方をもたらしましたが、「DevSecOps」の世界ではそれがまだ実現されていないのです。セキュリティは、ソフトウェアのリリースプロセスにおいて、まだアドオンのような扱いであり、とても重要にもかかわらず開発者にとっては邪魔なステップなのです。
少し前まで、「Dev（開発）」はプログラマーの世界のことを指し、「Ops（運用）」はITの世界のことを指していたことを覚えていますか？この2つの世界は、同じ痛みと同じ見返りを共有することで1つとなり、現在ではDevOpsチームになりました。私たちは皆でこの新しいDevOpsの現実を作り上げたのです。
しかしながら、DevSecOpsに「Sec」を追加すると大きく変わります。現在、企業は開発者にセキュリティのスキルを身につけることを求めています。少なくともセキュリティスキャンとトリアージをプロセスに組み込むように求めています。このような動きを説明するために「シフトレフト」などと言います（もちろん、とても重要です）。それでも、開発者に尋ねると、セキュリティを気にせずに、コーディングをして付加価値をもっと提供できるようにすることを望んでいます。
しかし当然のことながら、セキュリティは、最初からサプライチェーンのライフサイクルに統合されるべきです。これは開発者や開発プロセスだけでなく、組織を守るために必要なことです。今回のLog4jをはじめ、注目を集めているソフトウェア・サプライチェーン攻撃は、この点を強調するものです。そして、次の「大事件」は確実にすぐそこに迫ってきています。
2022年には、開発者を中心としたサプライチェーン・セキュリティが注目を浴びるでしょう。
組織は、セキュリティ・テストとスキャンの民主化*（*今まで権限がなかった人にも権限を付与するようになる動き）、ソフトウェア部品表（SBOM）要件の導入、システムを円滑かつ安全に稼働させるためにソフトウェア・リリースの完全な管理チェーンを構築するためのセキュリティ・ソリューションの活用を推進しています。しかし、セキュリティ・ソリューションは、セキュリティ・エンジニアリング・チームが推進する4つ、5つ、6つ、7つ以上のセキュリティ・ソリューションが存在する今日よりも、はるかに包括的なものでなければなりません。次に、開発者は自分のコードやアプリケーションを調べるために、さまざまな特殊なソリューションを持っています（これも重要です）。このような崩壊したムリヤリなアプローチは変えなければなりません。
例をご紹介します。世界中の何百万もの開発者がクリスマス休暇を返上して、Log4jの脆弱性から回復させようと相当な努力を重ねました。開発者たちは皆、セキュリティツールやOSSスキャナを持っているのに、何が起きたのか？開発者たちは、なぜ再びセキュリティ侵害の代償を払うことになったのか？簡単な答えは、正しい資産に焦点を当てていなかったからです。開発者は、すべてを解決する1つのバイナリを見つけて置き換えたかったのですが、既存のシステムにはバイナリのセキュリティと管理方法が実装されていないため、置き換えができなかったのです。
幸いなことに、このジレンマは両チームにとって解決が可能であるということです。セキュリティを確保するための「方法」（各ステップに対応する無数のツール）ではなく、「何を」（バイナリ）を確保しようとしているのかに注目することです。DevOpsの世界では、開発者を保護し、オープンソースのキュレーションプロセスを保護し、ビルドプロセスを保護し、デプロイメントとランタイム環境を保護します。したがって、DevOpsパイプライン全体でバイナリを包括的に保護することは、組織を保護し、開発者をより効率的にして、DevSecOpsの約束を果たすための鍵となります。
つまり、2022年は、セキュリティチームと開発チームが一体となり、バイナリを共有資産として中心に据えるという、実際の文化の変化がはじまる年になると考えています。パブリックハブからプロキシするDockerイメージやOSSパッケージの場合もありますが、バイナリは、私たちが管理、保護、配布できる資産になります。
ソースコードを管理してもサプライチェーンは修正できません
ソースコードとCIは、すべての開発者の出発点です。かつてはSubversionやPerforceが主流でしたが、現在ではほとんどのVCSソリューションがGitベースです。しかし、今日の課題は、ソースの管理やIDEの選択ではありません。今の悩みは、バイナリを中心としたデリバリー・サイクル全体を自動化する際の規模、速度、そして信頼性なのです。
「GitOps」やその他のソース主導のアプローチは、場合によっては有効かもしれませんが、このようなサプライチェーンの問題を解決するために使用するのに適切な資産ではありません。なぜでしょう？メタデータは、バイナリやソフトウェアパッケージに含まれています。依存関係が、バイナリに適用され提供されます。自動化はバイナリの動きにより実現されます。サプライチェーンセキュリティは、バイナリを管理し、保護することです。
つまり、2022年、VCSやGitOpsのプラクティスと並んで、バイナリ管理は単なる「必要なもの」ではありません。サプライチェーン全体をコントロールするための必要条件となります。最近、業界を震撼させたセキュリティ警告は、すべてソフトウェアパッケージの脆弱性に関するもので、ソースコード管理や運用に関するものではありません。影響を発見することは、バイナリーについてです。パッチやアップデートにはバイナリが必要です。ここには無視しがたいテーマがあります。
2022年、ハイブリッドは第一級オブジェクトになります
私たちの仕事環境がハイブリッドモデルに変化を成し遂げたように、ほとんどの企業の導入モデルも変化しています。これはニュースではないかもしれませんが、JFrogは長い間、ハイブリッド・クラウドが、偶発的なものや一回限りの例外ではないと主張してきました。ハイブリッドは新しいクラウドの標準であり、多くの企業にとって有意義なものです。
しかし、2022年には、「クラウド・ファースト」の企業であっても、もはや単一のデプロイメント環境は存在しないと誰もが気付くでしょう。クラウドベンダー自身がこのハイブリッドコンセプトの採用を推進しているのがわかります。オンプレミスとクラウドをつなぐ架け橋として、AWSのようなプロバイダーが最近、オンプレミスのKubernetesデプロイメントで利用できるサービスを開始したことを見てみましょう。ハイブリッドは、意図的で効率的なニューノーマルであり、企業がこれらのモデルをサポートするサービスを採用しなければ、変革は困難なものとなるでしょう。
もちろん、クラウド中心のアプローチへの道筋として、より多くのハイブリッド設定を目にすることになるでしょう。たとえ企業がクラウドへの完全移行を意図していたとしても、2022年には開発や生産のためのハイブリッド設定が増えているはずです。
2022年は「エッジの年」です
アナリストによると、今後数年間で、数十億台の新しいデバイスが導入される一方で、データセンター、サーバー、クラスターにて管理しなければならないエッジの数は数百万台増加すると予想されています。2022年には、業界全体でクラウド、マルチクラウド、ハイブリッドエッジトポロジーの利用が推進され、企業のバイナリを配布と配布の管理をするための堅牢なソリューションが必要になるでしょう。
例えば、世界で最も人気のある自動車会社が、「もうタイヤやエンジン、座席や馬力は重要ではない」と公に言っています。ドライバーであるお客様に真の価値を提供するのは、OTA（Over The Air）ソフトウェアアップデートなのです。運転中のお客様の体験が改善され、より安全に、より賢く、より多くの情報を得て、ドライバーとして楽しむことができるようになります。この焦点の変化で、ソフトウェアがさらに最前線に立つようになります。CI / CDワークフロー、ソフトウェアの配布、そして、デバイス上にデプロイされるバイナリ（もしくはバイナリのみ）が、新たな競争上の差別化要因となるのです。
2022年はバイナリが 「爆発的に増加 」します
2022年には、バイナリーはさらに爆発的に増加するでしょう。それは、バイナリーの数だけでなく、バイナリーの重要性やそのライフサイクルを管理する技術が注目されるようになるからです。これはトレンドではありません。これからも変わらない真実です。
しかし、単に何かを管理するだけでは十分ではありません。資産を使って差別化を図るためには、その資産に十分な自信を持たなければなりません。このDevOpsの世界が広がっていく中で、JFrogチームと開発コミュニティが、DevOpsとソフトウェア・サプライチェーンを受動的に取り入れるのではなく、成功を導くために大胆に活用することを楽しみにしています。
May the Frog be with us all in 2022. (2022年もカエルたちと共にあれ)
See what JFrog & GitHub can do together
