1. はじめに
想定読者
- Webアプリケーションの開発・運用に携わっている方
- CI/CDやコンテナ、GitOpsを利用している、または導入を検討している方
- 脆弱性対応などの緊急変更を、平時の開発・運用とどう接続するか考えたい方
先日、pixivの脆弱性対応について書かれた記事を読みました。
最初は「こんなに迅速に対応できるのか、すごいなあ」と思いながら読んでいましたが、読み進めるうちに、個々の作業の速さ以上に、普段から整備されている開発・運用の仕組みが印象に残りました。
CI/CD、コンテナ、GitOps、自動テストなど、
それぞれは今となっては珍しい技術ではありませんが、組み合わさることで緊急時にも変更を進められる状態が作られているのだと感じました。
そこで思い出したのが、これまで関わってきた案件ごとの違いです。
同じ時期に関わっていた案件でも、ある案件ではSBOMやCI/CD、脆弱性対応のフローまで整備されている一方で、別の案件ではビルドから本番反映まで、ほとんどが手作業でした。
当然、変更を届けるまでの手順や確認しなければならないことも大きく異なります。
ただ、仕組みが整備されている案件なら何も心配がないのかというとそういうわけでもありませんでした。
実際に、緊急リリース用のフローを用意したものの、一度も動作確認できないままだった経験もあります。
こうした経験から、緊急時に迅速かつ安全に変更できる状態とは、具体的にどのような状態なのだろうと考えるようになりました。
この記事では、特定の脆弱性対応の内部事情や個別ツールの導入手順には深く踏み込まず、Webアプリケーションの開発・運用に携わるエンジニアの視点から、緊急時の変更を支える平時の開発・運用基盤に、どのような性質が必要なのかを考察してみます。
具体的には、重大な脆弱性が見つかった場面を想定し、以下の流れに沿って整理します。
- 影響範囲を把握する：どのサービス・環境を修正するのか
- 変更を準備・反映する：普段と同じ手順で変更を届けられるか
- 検証・判断する：何を根拠に本番へリリースできるか
- 結果を確認・復旧する：修正が完了したことをどう確かめるか
- 仕組みを維持する：緊急時に本当に利用できる状態なのか
本記事で扱う「速さ」について
デプロイコマンドの実行時間だけを指すものではありません。
影響を把握し、変更を準備・検証し、判断し、本番へ反映して結果を確認するまでを含みます。
2. 緊急時の変更を難しくするもの
仮に利用中のライブラリに重大な脆弱性が見つかり、修正版が既に公開されているとします。
対応としては、影響するサービスを特定→依存関係を更新して検証→本番へ反映することになります。
ただ、この一連の作業をどう進めるかは開発・運用の仕組みによって大きく異なります。
例えば以下のような違いがあります。
| 工程 | 仕組みが整備された環境 | 手作業が中心の環境 |
|---|---|---|
| 影響調査 | SBOMや成果物情報を手がかりに調査 | サーバーや依存関係を個別に確認 |
| ビルド・テスト | 定義されたCIパイプラインで実行 | 担当者が手順に沿って実行 |
| 本番反映 | CDなどの定義済み経路で反映 | WARの配置などを手動で実施 |
| 履歴の確認 | パイプラインや成果物の記録を参照 | 作業記録やサーバーログなどを参照 |
もちろん、手作業だからといって必ずしも問題があるわけではありません。
手順や確認方法が整っていれば、安全に変更を届けることもできます。
また、自動化されていてもその仕組みが正常に動くことを確認できていなければ、別の課題が残ってしまいます。
両者を比べて感じるのは、違いが単純なデプロイ時間だけではないということでした。
緊急時には、少なくとも以下の問いへの回答を考える必要があると思っています。
- 影響範囲：どのサービスや環境が影響を受けているのか
- 変更内容：何を修正する必要があるのか
- 検証：変更後も主要な機能が動作するのか
- 判断：誰が、何を根拠に本番反映を承認するのか
- 完了確認：修正が対象環境に正しく反映されたのか
- 復旧：変更によって障害が起きた場合、どう対応するのか
上記に答えるための情報や手順が整っていなければ、緊急時に一つずつ調査し、確認し、判断することになります。
私は、緊急対応を難しくしている要因の一つは作業そのものにかかる時間だけではなく、変更に伴う不確実性を、その場で解消しなければならないことにあるのではないかと考えています。
もちろん、脆弱性の影響や修正版の不具合など事前には分からないこともあります。
それでも変更手順や検証方法、稼働状況の確認方法、承認経路まで、緊急時に初めて考える必要はないはずです。
以降は、それぞれの工程でどのような不確実性があり、平時の仕組みで何を減らせるのかを考えていこうと思います。
3. どこを直すのか分かる状態か
重大な脆弱性が公開されたとき、最初に必要となるのは影響範囲の把握です。
修正版が公開されていても、どのサービスが対象なのか分からなければ、対応を進められません。
個人的に、手作業が中心の案件で特につらいと感じるのが、この影響調査です。。
私自身、サーバーに入ってライブラリのバージョンを一つずつ確認する作業を経験しています。
対象のサーバーが少なければ対応できるものの、確認対象が増えるほど調査の負担も大きくなるなと感じています。
特に、以下のような状況では確認が複雑になるなという印象があります。
- サーバーごとに配置されているライブラリのバージョンが異なる
- 一部の環境に古い成果物が残っている
- バッチ処理だけ更新経路が異なる
- リポジトリ上の依存関係と、本番で稼働しているものが一致しない
手作業だから必ず見落としが発生するわけではありませんが、確認した対象や結果を記録しなければ、どこまで調査できたのか分からなくなる可能性もあります。
3.1 SBOMがあれば、影響範囲を特定できるのか
上記のような調査を支える仕組みの一つが、SBOM（Software Bill of Materials）です。
SBOMを利用することで、成果物に含まれるソフトウェアコンポーネントや依存関係を把握しやすくなります。
ただし、SBOMだけですべてを解決できるわけではありません。
例えば、以下の情報は区別して考える必要があると思っています。
- SBOM：成果物にどのようなコンポーネントが含まれているか
- ビルド情報：どのソースコードから、どの成果物が作られたか
- デプロイ履歴：どの成果物を、どの環境へ反映したか
- 実行環境の情報：現在、どのバージョンや設定が稼働しているか
- 公開・利用状況：外部から到達できるか、該当機能を利用しているか
あるイメージに脆弱なライブラリが含まれていると分かっても、そのイメージが現在どの環境で動いているかは、別の情報と照合する必要があります。
逆に、デプロイ履歴だけあってもその成果物に何が含まれているか分からなければ同じことです。
そのため以下情報をつなげて追跡できる状態が重要だと思っています。
脆弱性の対象製品・バージョン
↓
依存関係・ビルド成果物
↓
成果物を利用しているサービス
↓
各環境に実際に展開されているバージョン
↓
外部公開状況・利用経路・緩和策
また、重大度の高い脆弱性が公開されたからといって、すべてのシステムで同じ緊急度になるとは限りません。
実際の利用状況、外部からの到達可能性、悪用状況、既存の防御策なども踏まえて判断する必要があります。
ただし、悪用可能性が確認できないことと、影響がないことは同じではありません。
SBOMを持っているかどうかではなく、脆弱なコンポーネントがどこで、どのような状態で稼働しているかを根拠を持って追跡できるか。
まずはこのような状態を作ることが重要なのかなと思っています。
4. いつもの手順で変更をリリースできるか
修正対象を特定できたら、次は変更を準備して本番へリリースする必要があります。
ここで考えた方が良いと思っているポイントとしては、変更経路の再現性です。
私が関わった手作業中心の案件では、ビルドしたWARをサーバーへ手動で配置する運用がありました。
この運用では、以下のような確認が必要でした。
- どのソースコードからWARをビルドしたか
- どのサーバーへ配置する必要があるか
- どのサーバーまで配置が完了したか
- 配置したWARが意図した成果物と一致するか
- 作業中にエラーが発生した場合、どこから再開するか
場合によっては、配置前後でハッシュ値を比較することもあります。
もちろん、手順書や成果物の管理、作業記録が整っていれば、手動でも再現性を確保できます。
ただ、確認を担当者が個別に行う部分が増えるほど、手順の抜け漏れや作業結果のばらつく傾向があり、成果物も一貫性がなくなってしまうと思います。
4.1 「自動化されている」より「同じ経路を通せる」こと
CI/CDが整備された環境では、ビルド・テスト・成果物の保存・デプロイといった工程を、定義されたパイプラインで実行できます。
ここで重要なのは、単にデプロイが速くなることだけではないと思っています。
例えば、以下のような運用があった場合：
通常の変更経路
ソース変更
→ CIでビルド・テスト
→ 成果物を保存
→ 承認
→ CDで反映
→ 反映結果を確認
緊急時の例外経路
担当者が本番サーバーへ接続
→ 手作業で修正
→ その場で動作確認
→ 後から変更内容を記録
普段はCI/CDを利用していても、緊急時だけ例外的な経路を使うのであれば、通常のパイプラインが持っていた次の仕組みを利用できなくなる可能性があります。
- ビルド・テストの実行結果
- 成果物とソースコードの対応関係
- 変更や承認の履歴
- デプロイの実行記録
- 反映対象や結果の追跡
もちろん、緊急時に例外経路を使うことが必ずしも誤りというわけではありません。
通常のパイプラインが利用できない場合や、攻撃の緊急度によって通常の手続きを待てない場合も考えられます。
ただし、その場合はどの検証や記録を省略したのか、その不足をいつ、どのように補うのかを明確にしておく必要があると思います。
4.2 検証した成果物と本番に反映する成果物は同じか
変更経路とあわせて考えたいのが、検証した成果物と本番へ反映する成果物の一貫性です。
コンテナ構成であれば、検証環境と本番環境で同じイメージのダイジェストを参照することで、同一のイメージを利用できます。
同じタグ名を指定するだけでは、そのタグが後から別のイメージを指す可能性があります。
また、ビルドし直した成果物が、検証済みの成果物と完全に同じになるとも限りません。
ここで区別した方が良いと思っているのは、以下の3点です。
- 成果物の同一性：検証したものと本番へ反映するものが同じか
- 環境の差異：環境変数や外部サービスなど、動作に影響する条件が異ならないか
- 反映結果：意図した成果物が、実際に本番で稼働しているか
同じイメージを利用しても環境設定などによって動作が変わる可能性はあります。
それでも、成果物の同一性を確認できれば、不確実性を一つ減らせるのかなと思っています。
IaCやGitOpsについても、同じように責任範囲を把握しておく必要があります。
例えば、以下のような管理の分担が良いのかなと。
| 変更対象 | 管理経路の例 |
|---|---|
| アプリケーションのイメージ | CI/CD、GitOps |
| ネットワークやインフラ構成 | TerraformなどのIaC |
| ホストOSのパッケージ | OS管理ツール、パッチ適用手順 |
| マネージドサービスの更新 | IaC、クラウド管理機能、個別の運用手順 |
※ 実際の管理範囲は採用している構成や運用方式によって異なります。
例えば、GitOpsを採用していても、Gitへ変更をマージしただけでは、実際のワークロードまで反映された証明にはなりません。
コントローラーの同期状態や、稼働中の成果物を確認する必要があります。
どの変更を、どの経路から反映するのか。
この責任範囲が曖昧だと緊急時に「この修正はどこから入れるんだっけ」と考えるところから始まってしまうと感じています。
5. 何を根拠に本番へリリースできるか
修正対象と変更方法が決まったら、次に必要になるのは検証とリリース判断です。
留意点としては、CIが成功したことと、今回の変更が安全であることは同義ではないという点です。
例えば、ライブラリを更新してユニットテストがすべて成功しても、以下のような問題は残る可能性があります。
- 本番設定でしか発生しない互換性の問題
- 外部サービスとの通信や認証方式の変更
- テストされていない画面・バッチ・例外系への影響
- 起動時や高負荷時にだけ発生する問題
ユニットテスト、結合テスト、E2Eテスト、依存関係のスキャンなどは、それぞれ確認できる範囲が異なります。
| 検証手段 | 主に確認できること | それだけでは確認しにくいこと |
|---|---|---|
| ユニットテスト | 関数・クラス単位の期待動作 | 実環境の設定やサービス間連携 |
| 結合テスト | コンポーネント間の主要な連携 | 本番トラフィック特有の条件 |
| E2Eテスト | 代表的な利用シナリオ | 網羅されていない機能・異常系 |
| 依存関係のスキャン | 既知の脆弱性に関する検出情報 | 実際の攻撃成立条件や修正の稼働確認 |
これらは互いの代わりになるものではなくそれぞれ異なる不確実性を減らすものです。
そのため、「テストがあるから速く出せる」というより何を確認できていて、何が未確認なのかを短時間で説明できることに価値があると思っています。
5.1 テストが存在することと、判断に使えることは別
もう一つ留意点としては、普段から不安定なテストについてです。
いつも失敗するテストが放置されている環境では、緊急時にテストが失敗しても、「以前から発生していた問題なのか、今回の変更によるものなのか」を切り分ける必要があります。
せっかく自動テストがあっても、結果を信頼できなければ、追加の調査が必要になってしまいます。だからこそ、常に以下のような状態を維持することが重要だと思っています。
- 失敗しているテストを放置しない
- 不安定なテストと、その発生条件を把握する
- テストの実行時間を把握する
- 主要な業務フローを継続的に検証する
- テストで確認できていない範囲を把握する
当たり前のことかもしれませんが、緊急時に何を優先して確認するべきか判断するための土台になるのかなと。
もちろん、日々の優先タスクに追われて、不安定なテストを改善する工数を確保できないこともあると思います。
それでも、少なくともどのテストが不安定で、今回の変更に対してどこまでの判断材料になるのかは把握しておきたいなと思っています。
5.2 技術的な準備が整っても判断で止まることがある
検証が終わってもそこで自動的に本番反映できるとは限りません。
緊急時には、以下のような判断が必要になります。
- 誰がリリースを承認するのか
- 通常の承認フローを変更できる条件は何か
- 担当者が不在の場合、誰が代行するのか
- 最低限実施しなければならない検証は何か
- 省略した確認や記録を、いつ補うのか
チャットで「対応していいですか」「OKです」とやり取りすること自体が悪いわけではありません。
ただ、誰がどの条件で承認できるのか、何を記録に残すのかが曖昧だと、緊急時にその場で確認することになってしまいます。
反対に、承認経路が明確でも承認者が影響範囲や検証結果を把握できなければ、十分な根拠を持って判断できません。
ここでも技術と運用の両方がつながっている必要があると思います。
必要な検証結果と判断基準が揃い、担当者が不在でも変更を進められること。
これも平時から整えておきたい性質の一つだと思います。
6. 本当に修正できたことをどう確認するか
変更を本番へ反映できたとしても、それで脆弱性対応が完了したとは限りません。
パイプラインが緑色で Success を示していても、アプリケーションが期待どおり動いているとは限らないからです。
（私が新卒の頃は、デプロイが成功していれば大丈夫だと思っていたこともありました…）
脆弱性対応では、少なくとも以下3つを区別して確認する必要があります。
- 反映の完了：意図した成果物や設定が、対象環境に展開されたか
- サービスの健全性：エラー率、レイテンシ、主要機能などに異常がないか
- 対策の有効性：脆弱なバージョンや設定が残っていないか、必要な対策が機能しているか
例えば、CDが成功していても、一部のインスタンスが古いイメージのまま稼働している可能性があります。
また、サービスが問題なく応答していても、脆弱なバージョンが残っていればセキュリティ対策としては不十分です。
可観測性の仕組みがあれば、メトリクス、ログ、トレースなどを利用して、変更前後の状態を比較できます。
ただし、監視データが存在しているだけでは正常に動作しているか判断できるとは限りません。確認したい情報も目的によって異なります。
| 確認したいこと | 確認方法の例 |
|---|---|
| 変更が反映されたか | デプロイ履歴、稼働中のイメージ・バージョン |
| サービスが正常か | メトリクス、ログ、トレース、主要機能の確認 |
| 脆弱性への対策が有効か | 実際のバージョン・設定、必要に応じた追加検証 |
デプロイできたこと、サービスが正常に動いていること、脆弱性への対策が完了したことは、それぞれ別の確認になります。
6.1 段階的に出すと脆弱な時間は延びる
変更による障害の影響を抑える方法としてカナリアリリースがあります。
一部のインスタンスやトラフィックに先行して変更を適用し、問題がないか確認してから展開範囲を広げる方式です。
カナリアリリースの特徴は以下の通りです。
- メリット：変更に問題があった場合、影響が全体に広がる前に検知できる可能性がある
- デメリット：段階的に確認するため、全体への展開完了まで時間がかかる場合がある
- 脆弱性対応での注意点：展開中、未更新のインスタンスが脆弱なまま残る可能性がある
攻撃の切迫度が高い場合には、通常より展開を速めたり先にアクセス制限を設けたりする判断も必要になります。
つまり、変更による障害リスクを抑えることと、脆弱な状態を早く解消することは必ずしも両立しないと言えると思っています。
「段階的に出せば安全」ではなく、両方のリスクを考慮する必要があるのかなと思っています。
6.2 ロールバックが脆弱性の再導入になることもある
通常のリリースで問題が起きた場合、直前のバージョンへロールバックする方法が有効なことがあります。
しかし、今回の変更が脆弱性の修正だった場合、元のバージョンへ戻すことは脆弱性を本番環境へ再び導入することになってしまいます。
その場合、以下のような対応を検討する必要があると思っています。
- ロールフォワード：修正版を維持したまま不具合を追加修正する
- 機能停止：問題のある機能を一時的に停止する
- アクセス制限：ネットワーク制御などで攻撃経路を制限する
- 縮退運転：必要に応じてサービスの一部を制限して継続する
どの方法を選べるかは、システム構成や障害の性質によって異なります。
重要なのは、「問題が起きたら元に戻す」という方針が、セキュリティ修正にもそのまま当てはまるとは限らないことだと思います。
障害が起きてから代替手段を考えるよりも、平時から取れる選択肢を整理しておいた方が判断しやすくなります。
変更を安全に進めるには、成功した場合の確認方法だけでなく、失敗した場合に何ができるかを把握しておくことも必要なのだと感じました。
7. 緊急用の仕組みは本当に使える状態なのか
ここまで、影響範囲の把握、変更の再現性、検証、承認、反映後の確認や復旧について整理してきました。
こうした仕組みが整っていれば、緊急時に一から考えたり確認したりする負担を減らすことができます。ただ、私自身の経験からもう一つ気をつけたいことがあります。
それは仕組みを用意したことと、その仕組みを実際に使えることは別だという点です。
7.1 一度も動かせなかった緊急リリースフロー
以前、ある案件で緊急リリース用のフローを用意したことがあります。
通常のリリースとは別に、緊急時に素早く本番へ反映するための経路です。
しかし、そのフローを実際に通して検証する工数を確保できませんでした。
（緊急時に初めて一連のフローを動かすことになる状態でした）
幸いにもそのフローを本番の緊急対応で使用する機会はありませんでした。
ただ、もし実際に利用する必要があったらと考えると今になって少し怖く感じます。
例えば、以下のような点です。
- 実行に必要な権限は有効なままなのか
- 参照している環境や設定に変更はないのか
- 手順書は現在の構成に合っているのか
- 一連の処理が、想定した順序で正常に実行されるのか
- 途中で失敗した場合、どこから再開できるのか
個々の設定を確認することはできても、一連のフローが意図どおりに動くことを確認できていない状態でした。
緊急時に初めて動かして問題が発生したら、原因を調査しながら同時に脆弱性への対応も進めなければなりません。
もちろん、緊急用のフローを整備すること自体には意味があります。
ただ、存在しているというだけで実際に使えると判断することはできないのだと思いました。
日常のリリースでも同じ経路を利用するか、緊急用の経路を定期的に検証するなど、現在の環境で利用できることを確かめる機会が必要だったのだと思います。
7.2 「仕組みがある」と「実行できる」の間にあるもの
この経験を踏まえると、冒頭で触れた案件ごとの差についても、少し見方が変わってくることに気付きました。
手作業中心の案件には、担当者による確認や作業に依存する部分があります。
一方で、CI/CDや緊急対応フローが整備されている案件にも、その仕組みが実際に動くか検証できていなければ、別の不確実性が残ります。
つまり、ツールがあるかどうかだけで、緊急対応の能力を判断することはできません。
- 必要な情報を取得できるか
- 変更を再現性のある方法で届けられるか
- 検証結果をリリース判断に使えるか
- 変更後の状態を確認できるか
- 失敗した場合の対応手段があるか
- それらの手順を、実際に動かせる状態か
平時の開発・運用基盤に求められるのは、こうした能力を備えることだけでなく、継続的に使える状態を維持することなのかなと思っています。
8. 自分たちの現場では何ができる状態になっているだろうか
これまでの内容を技術の導入チェックリストではなく、実際に実行できる能力として整理してみようと思います。
| 確認したい能力 | 自分たちの現場への問い |
|---|---|
| 影響を把握する | 稼働中の成果物と依存関係を、サービス単位でたどれるか |
| 同じ変更経路を使う | 緊急修正も、通常のビルド・検証・反映経路を使えるか |
| 検証結果を判断に使う | テストが保証する範囲と、未確認の範囲を説明できるか |
| 判断を止めない | 夜間や担当者不在時の責任者・承認経路が明確か |
| 反映を確認する | 意図した修正版が、対象環境のすべてで稼働していると確認できるか |
| 失敗から復旧する | 脆弱性を再導入せずに取れる復旧手段があるか |
| 仕組みを実行できる | 緊急時に利用する手順や権限を、事前に確認できているか |
どれも特定のツールを導入していれば、自動的に満たされるものではありません。
また、すべてを一度に整備するのは現実的ではないと思います。
では、今の現場でどこから取り組むべきなのか。
その確認方法として、架空の脆弱性を想定した机上訓練が考えられます。
8.1 架空の脆弱性で、対応の流れをたどってみる
例えば、利用中のライブラリに重大な脆弱性が見つかったという前提で、実際のリポジトリやデプロイ情報を使って対応の流れを確認してみます。
重大な脆弱性が公開される
↓
影響するサービス・環境を特定する
↓
修正対象と変更方法を決める
↓
修正版のビルド・テスト方法を確認する
↓
本番反映の承認経路を確認する
↓
反映後の確認方法を整理する
↓
障害発生時の対応方法を確認する
本番環境に変更を加えなくても実際の情報を使って手順をたどるだけで、課題が見つかるかもしれません。
例えば、以下のような課題などが挙げられます。
- 影響するサービスを特定できない
- リポジトリの情報と、稼働中の成果物を照合できない
- テスト結果だけでは、リリース判断に必要な根拠が足りない
- 担当者不在時の承認経路が決まっていない
- デプロイ後に脆弱なバージョンが残っていないか確認できない
- 障害時の復旧手段が明確になっていない
以前、緊急用フローを検証する工数を確保できなかった経験からすると、実際に本番へ反映する訓練が難しくても、まずは机上で流れを確認するところから始めるのは現実的なのかなと思います。
ただし、机上訓練だけでは、実際のパイプラインや権限が正常に動作することまでは確認できません。
机上での確認と、検証環境などでの実行テストは、それぞれ目的が異なるものとして考える必要があります。
8.2 どこで手が止まり、何が分かれば進められたのか
訓練で課題を整理するのであれば、各工程にかかった時間だけでなく、どこで手が止まり、何が分かれば次へ進めたのかを記録しておくことが良いと思っています。
例えば、影響範囲の調査に時間がかかったとしても、次の2つでは必要な改善が異なります。
- 情報を集める作業が重い：確認対象が多い、手作業が多い
- 情報の所在が分からない：構成情報や依存関係の管理が不明確
また、承認者が不在で対応が止まるのであれば、CI/CDを改善するよりも、緊急変更の運用ルールを整える方が先かもしれない。
検証に時間がかかっている場合でも、必要な確認を実施しているのであれば、単純に短縮すればよいという話ではありません。
重要なのは、作業を速くすること自体ではなく、緊急時に解消しなければならない不確実性を、平時の仕組みでどこまで減らせるかだと思います。
ツールを先に決めるのではなく、緊急時に実行できないことから改善を考える。
その方が、現場の実態に合った取り組みにつながるのではないかなと思いました。
9. まとめ
pixivの脆弱性対応の記事をきっかけに、緊急時に迅速かつ安全に変更を届けるためには、平時にどのような仕組みが必要なのかを考えてみました。
今回整理したのは、次のような能力です。
- 影響範囲の把握：どこを修正すべきか特定できる
- 変更の再現性：普段と同じ経路で変更を届けられる
- 検証可能性：何を確認できていて、何が未確認なのか説明できる
- 判断可能性：必要な情報と承認経路が揃っている
- 可観測性：反映後の状態を確認できる
- 復旧可能性：問題が起きた場合の選択肢を持っている
- 実行可能性：これらの仕組みを緊急時に実際に利用できる
こうした能力が日常の開発・運用の中で整備され、実際に利用できる状態になっていれば、緊急時に一から調べたり、手順を考えたり、判断基準を決めたりする場面を減らすことができると思っています。
ただ、今回改めて感じたのは、仕組みが整備されていることと、その仕組みが緊急時に機能することは、必ずしも同じではないという点です。
手作業中心の案件には、手作業ならではの課題があります。
一方で、仕組みが整っているように見える案件にも、一度も検証していない緊急リリースフローのような課題が残っているかもしれません。
だからといって、すべての現場に同じ技術や運用を導入するべきだとは思いません。
まずは、自分たちの現場で何ができていて、何ができないのかを把握することが大切なのだと思います。
明日、自分の関わるシステムに重大な脆弱性が見つかったとして、普段と同じ開発・運用プロセスで、必要な根拠を持って修正を届けられるだろうか。
緊急時になって初めてその答えを探すことにならないよう、まずは机上で一度、対応の流れをたどってみるところから始めたいと思います。
この記事が少しでも参考になりましたら、いいね／ストックをしてもらえるととっても励みになります！