セキュリティと保証

Merlon の稼働を承認する立場の人（セキュリティレビュー担当、ベンダーリスク評価担当、内部監査）のための資料。

Merlon は規制対象の金融機関に導入される。したがって問われるのは常に「このソフトウェアは良いものか」だけではなく、「評価したことを証跡として示せるか」である。以下のページは後者の問いのために書かれている。

ページ	答えるもの
データ送出	何が自組織のネットワークから出ていくのか、その契機は何か
サプライチェーン	依存関係・イメージ・リリースをどう統制し、どう証跡化しているか
受容リスク	本プロジェクトが行わないと自認していることと、その理由

場所	内容
SECURITY.md	脆弱性の報告方法と対応コミットメント
認可と職務分掌	ロールモデル、職務分掌、二重統制
規制上のスコープ	Merlon が対応を主張する範囲と、しない範囲
FSA ガイドライン対応表	金融庁 AML/CFT ガイドラインに対するカバレッジ
データ保持	保持ポリシーの適用
コンテナイメージ	何が公開されるか、どう検証するか
リリースチェックリスト	リリースが何を主張するか、まだ証跡化されていないものは何か

要約

Merlon を評価中で、詳細を読む前に答えが欲しい場合は以下のとおり。

設定していない外向き通信は行わない。 テレメトリ、分析、ライセンス確認、更新確認のいずれも存在しない。データ送出を参照。
すべてのデータは自組織のインフラ上の PostgreSQL に留まる。 直接的な PII 顧客属性は保存時に暗号化され、鍵はデータベース外に保持される。
コンテナは非 root ユーザーで動作し、書き込み可能なファイルシステムを必要としない。
公開イメージは不変・マルチアーキテクチャであり、ビルド来歴証明と CycloneDX SBOM を伴う。 latest タグは存在しない。
監査記録はデータベースの権限レベルで追記専用である。 それが強制されていない場合、本番ではアプリケーションが起動を拒否する。
アクティブなメンテナは1名。その事実を成果物上で開示している。 単独メンテナのリポジトリでは独立した承認が成立しないため、リリースはそれを主張しない旨を自ら述べる（release-manifest.json、イメージラベル、リリースノート冒頭）。マージには、誰も与えられない承認の代わりに、ステータスチェックで強制するセルフレビュー証跡を要する。リリースチェックリストとリポジトリガバナンスを参照。

最後の項目は、多くのベンダー評価質問票に記入欄が無く、しかも貴組織の評価において最も重要になりうる項目である。