Skip to content

fix: Node・Java・OSの信頼設定と関連依存を更新 - #570

Merged
lambig merged 2 commits into
mainfrom
fix/security-runtime-20261022
Oct 22, 2026
Merged

lambig merged 2 commits into
mainfrom
fix/security-runtime-20261022

Conversation

@lambig

@lambig lambig commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner

実行環境とTLS信頼設定を更新し、eMudhra CA問題への対策をOS・Node.js・JDK・Goへ適用します。ビルド時と実行時の対策を揃える変更で、稼働環境への適用完了は別の受け入れ条件です。

変更

  • Node.js 24.22.1 / npm 11.19.1へ固定。Vitest 4.1.12で既知の2件のmoderate指摘を解消。
  • Corretto 25のイメージを更新。OpenJDK由来の48指紋を既存Java拒否設定に追記し、CI・ビルド・コンテナへ適用。
  • Amazon LinuxのOS拒否設定と、MinIO / mcのGo 1.26.10・Debian CA修正版下限を追加。
  • デプロイ時のJava拒否設定を固定コントローラーから取得。古い候補ソースでも対策が欠落しない。保存済みイメージの再利用時は既存どおりビルドを省略。
  • フロントエンド復旧時に古い選択ソースの.nvmrcへ戻らず、delivery側のNodeを継続使用。コントローラーと選択ソースの既存の区別を保持。

検証と到達点

  • 初期更新版9beb4ba4ではGitHub全24チェック、バックエンド単体934件、ビルド、MinIO / mc起動、OSの対象ルート除外とJavaでの問題中間証明書16件拒否を確認。
  • 最新head 8941c2fda74fadf43680946a75beb2bf2412af17では、追加した経路・既存イメージ再利用のテスト27件とYAML解析がローカルで成功。最新headのGitHub全24チェック成功。ストレージ・プレーヤー検査はUbuntuミラー取得の遅延を伴う時間切れ後、同一コミットの再実行で成功。ストレージ24件、プレーヤー73件、端末準備フロー1件が合格。
  • 呼出側では同じ固定SHAと実際のNode・JDK拒否設定を確認する検査を追加。公開側は汎用の経路変更のみで、個別設定・アカウント値・運用データを含まない。

残る受け入れ条件・レビュー観点

  • 呼出側の両ワークフロー参照とcontroller_shaが同じ修正版を使うこと、古い検証ソースでランタイムが旧版へ戻らないことを確認する。
  • 両PRの確認・マージ後、対策を含む候補からのビルドと本番反映が必要。稼働イメージdigest、JDK拒否設定、Node/CA版、プロセス再起動、疎通の証跡が揃うまでセキュリティリリース完了と扱わない。
  • OSで対象ルート全体を拒否するため、そのルートにのみ連鎖する正当な接続も失敗し得る。接続先側の証明書更新が必要な場合がある。
  • 初期CIはCloudWatch Agent再起動時の例外とUbuntuミラー遅延を経て、同一コミットの再実行で成功。監視エージェントの例外原因自体は未解明。

根拠: Node.js、Oracle、OpenJDK、Ubuntu、Amazon Linux、Go。

@lambig
lambig marked this pull request as ready for review October 22, 2026 11:09

lambig commented Oct 22, 2026

Copy link
Copy Markdown
Owner Author

レビュー(テックリード/PM/PO)

判定:コード差分の方向性は妥当。ただし実運用への適用経路に統合上の未解決事項があります(P1)。

テックリード:P1 — ABAffairs経由のデプロイにJDK拒否設定が届かない

このPRの .github/workflows/deploy.yml には、Correttoをセットアップした後に backend/security/update-java-blocklist.sh を適用するステップが追加されています。一方、本番操作の入口 lambig/ABAffairs/.github/workflows/deploy.yml は、再利用ワークフローを lambig/ABService/.github/workflows/deploy.yml@1f93f6df31e118f00b882c037ad8c4e087ffb2ae に固定したままです。この旧版には当該ステップがありません。

commit_sha にこのPRを含む候補を渡せば、新しいDockerfileによって実行コンテナ側には対策が入ります。しかし、Gradleの依存取得・ビルドを行うGitHub Actionsランナー上のJDKには、このPRの追加ステップが適用されません。CIでの緑と、実際の再利用ワークフローを経た保護範囲を区別してください。

同様に、ABAffairsの deploy-frontend.yml も旧版 @1f93f6d を参照し、コントローラーの delivery/.nvmrc は 24.20.0 のままです。新しいソースの 24.22.1 とは独立した実行経路です。

修正条件:ABAffairs側の両再利用ワークフロー参照と controller_sha を、今回の対策を含む検証済みの固定コミットに更新し、その経路でJDK拒否設定とNode版を確認すること。単純なlatest追従ではなく、既存のコントローラー/配布物分離を保持して検証してください。対応場所はABAffairs #117側でも構いません。

PM

現在のPR説明は、CI完了と「マージ/デプロイ/プロセス再起動/疎通確認が残る」ことを分離しており適切です。一方、実行時の制御点である再利用ワークフローが旧版のままなので、このPRのCI成功をセキュリティリリース完了の根拠にしないことを求めます。運用導線の更新と適用先の実行イメージ・プロセスの確認を、完了判定へ含めてください。

PO

ビルド時のTLS検証と実行コンテナ内の検証が揃った状態を受入条件にしてください。新規Dockerfile自体のOS/JDK対策、Go 1.26.10・Debian CA更新の下限チェック、Node 24.22.1への更新は、今回のコード差分では合理的です。既存イメージの再利用を禁止する必要はありませんが、対策が入った新しいイメージで稼働しているという証跡が必要です。

lambig commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner Author

レビュー指摘に対応し、8941c2fda74fadf43680946a75beb2bf2412af17へ更新しました。

  • デプロイのJava拒否設定を固定コントローラーから取得し、古い候補ソースでもGradle実行前に適用します。保存済みイメージの再利用条件は保持しています。
  • フロントエンド復旧で古い選択ソースの.nvmrcへ戻らず、コントローラー側のNode版を継続します。通常リリースと手動復旧の既存のソース選択条件を保持しています。
  • 呼出側の両ワークフロー参照とcontroller_shaも同じ固定SHAへ更新しました。その固定版をcheckoutする検査で、実際のNode 24.22.1、Corretto 25.0.4、Java拒否指紋48件を確認し、後退を検出するテストも成功しました。
  • 公開側の追加経路・既存イメージ再利用テスト27件がローカルで成功しました。最新headのGitHub全24チェックが成功しました。ブラウザ2件はUbuntuミラー取得の遅延を伴う時間切れ後、同一コミットの再実行で成功。ストレージ24件、プレーヤー73件、端末準備フロー1件が合格し、CodeQL・バックエンド・実スタックE2E・両CPU向けコンテナ検査も成功しています。

PM/POの受け入れ条件は継続します。PRの確認・マージ後、対策入りイメージのdigest、実プロセスのJava拒否設定・Node/CA版、再起動・疎通の証跡を揃えて最終判断します。コードとCIの修正だけで本番の対策完了とは扱いません。修正と証拠の再レビューをお願いします。

lambig commented Oct 22, 2026

Copy link
Copy Markdown
Owner Author

再レビュー結果(8941c2f/テックリード・PM・PO)

前回指摘したP1は解消しました。コード/CI段階の再レビューは承認相当です。

テックリード

  • .github/workflows/deploy.yml が .release-controller を条件なしにcheckoutし、固定コントローラー内の update-java-blocklist.sh を Set up Gradle より前に実行することを差分で確認しました。既存ECRイメージの再利用時はJavaセットアップ/ビルドを省く従来の条件も維持されています。
  • .github/workflows/deploy-frontend.yml のNode指定は両方とも delivery/.nvmrc に統一され、古い選択ソースの .nvmrc に戻らなくなりました。候補ソースの選択・配布境界は維持しています。
  • ABAffairs 環境別設定分離とシークレット管理を整備する #117 の backend/frontend 両 uses と controller_sha が同じ 8941c2fda74fadf43680946a75beb2bf2412af17 を参照することも照合しました。
  • infra/release/workflow.test.mjs に後退防止テストが追加されています。最新コミットの CI実行 は確認できた17ジョブすべて成功(CI gate、Backend full check、E2E、両アーキテクチャのコンテナビルド・起動を含む)。

PM/PO

前回の「CI成功≠実環境の対策完了」という区分がPR本文・対応コメントでも維持されており、適切です。今回の指摘を理由にコードのマージを止める必要はありません。 本番でのセキュリティ対策完了は別判定とし、対策込みの候補・固定コントローラーからの実配布、稼働イメージdigest/実行中のJDK拒否設定・CA版/再起動・疎通の証跡を照合してください。

判定:前回P1クローズ。PRのコードレビュー完了。本番受け入れは未実施のため別途残存。

@lambig
lambig merged commit c0391f5 into main Oct 22, 2026
38 of 41 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant