利用期間を通じてソフトウェアを保守する

保守のサービス責任者を決める

有用なソフトウェアは、最初のリリース後も変わり続けます。依存関係に修正が出ます。ランタイムのサポートが終わります。証明書が期限切れになります。業務ルールが変わります。設定時に付与したアクセスが、意図した期間を超えて残ることもあります。

サービス、責任者、デプロイ済みバージョン、依存関係、サポート期限の一覧を保ちます。予定された作業と、新たな検出結果による作業を含めます。両方の対応能力を確保してください。責任者のいない保守バックログでは、サービスを守れません。

保守と、即時のインシデント対応を分けます。漏れた認証情報や、進行中の侵害の証拠には、通常の開発サイクルを終える前に封じ込めが必要な場合があります。そのようなケースは、セキュリティ対応プロセスへ引き継ぎます。

実際の曝露を優先する

深刻度は、起こり得る影響を表します。優先順位は、悪用状況、到達可能性、データ、既存の管理策、遅延の損失にも左右されます。トラフィックの少ない社内サービスにも、重要な認証情報があるかもしれません。

CISAのKnown Exploited Vulnerabilitiesカタログは、悪用の証拠がある脆弱性を記録しています。優先順位を決める情報として使います。未掲載だからといって、その脆弱性が安全なわけではありません。CISAカタログを参照してください。

次の架空の検出結果を考えます。期限は例の組織のものであり、普遍的な期限ではありません。

すべての指摘を、自動的に大規模アップグレードにしないでください。サポートされた修正を選び、互換性を調べ、重要な動作をテストします。一時的な緩和策には、責任者と期限の条件を記録します。

修正を本番まで追う

検出、判断、変更、レビュー、デプロイ、検証という、追跡可能な流れを使います。本番が実際に使う成果物の識別子を記録します。変更後に、関連する成果物や環境を再スキャンしてください。

架空の脆弱なPDFパッケージについて、チームが10:00にアップグレードをmergeしたとします。11:00の本番は、まだ昨日のイメージで動いています。リポジトリの修正は完了しています。本番の脆弱性対応は未完了です。

デプロイ後は、パッケージのバージョンとPDF生成の両方を検証します。脆弱性スキャンでは、エクスポートが引き続き動くことは確認できません。機能テストでは、脆弱なコンポーネントが取り除かれたことは確認できません。

NISTのSSDFは、継続的な脆弱性の発見と対応を含みます。機能の追加依頼が少ないソフトウェアも含め、ライフサイクル全体で適用してください。NIST SSDFを参照してください。

自動化の限界を明示する

TaigaのMaintainingは、接続したリポジトリをスキャンし、検出結果から修正のinitiativeを作成できます。直近の成功したスキャン、影響するバージョン、結果としての変更を確認します。リポジトリのスキャンでは、本番で脆弱な箇所に到達できるかは確認できません。Maintainingを参照してください。

自動化は繰り返しの作業を減らせます。それでも、サービスにはデプロイの責任者と検証が必要です。リリースの判断、緊急アクセス、例外の期限を明示します。

保守には廃止も含まれます。使われていないルート、認証情報、連携、インフラを、管理されたプロセスで取り除きます。削除前に、保存要件と依存するサービスを確認します。稼働中のサービスを廃止し、残る保存や監査の責任を割り当てます。

次のレッスンでは、継続的な脆弱性スキャンと修正を詳しく扱います。