2022 年、Alex Smolen は、セキュリティプログラムは不変条件から組み立てるべきだという短いエッセイを 書きました。その候補リストの先頭は「すべてのソフトウェアサービスがシングルサインオンを使う」でした。 4 年後のいま、そのチェックはこの一文を読み終える間にモデルが書いてくれます。難しいのは、もともと チェックではありませんでした。

Smolen の言う不変条件とは、議論の余地なく言い表せて、解釈の余地なく検証できるセキュリティ上の性質 です。覚えておくべきは、その定義の一文です。「どこでも真とは限らない。だが、真でない場所はすべて わかっている」。

最後の一節がすべてです。不変条件とは「失敗ゼロ」ではありません。説明のつかない失敗ゼロです。 そこへ至る手順として、彼は 4 つのステップを示しました。対象となるリソースをすべて特定し、各リソースが 守っているかを測定し、例外を記録し、後退を防ぐ。

この言葉は Smolen の造語ではありません。AWS は 2019 年には公に使っていました。推論ツール Tiros の 論文は*「多くの AWS サービスにおけるセキュリティ不変条件の遵守」*の確認を自動化していると書き、AWS の ガイダンスはサービスコントロールポリシーのガードレールをセキュリティ不変条件と呼びます。この系譜では、 不変条件はガードレールか証明です。Smolen が加えたのは、この記事の主題——例外と、説明のつかない失敗 ゼロに至るプログラム——です。

私は以前、AI 駆動のデリバリーパイプラインの内側で 不変条件を論じました。この記事は、それを環境全体でセキュリティ運用の実践として回す話です。2026 年に 4 つのステップがどう見えるか、私ならどのエンジンを選ぶか、そして残りを育てるためにどんな小さな種を 植えるか。実際にそれを回すことになるセキュリティ責任者に向けて書いています。

Smolen の 4 ステップを 2026 年にやり直す

Smolen の 4 ステップ——特定、測定、例外の記録、後退の防止——それぞれについて、2026 年の技術が簡単にしたことと難しくしたこと。
Smolen の 4 ステップを 2026 年にやり直す。ステップの出典は Security Invariants or GTFO。

特定する。 インベントリはいまやクエリできるテーブルです。ただし環境には、誰も登録しないものが 育ちます。カードで買われた AI ツール、OAuth 許可、誰かの認証情報で動くエージェント。ですから網羅率は 主張ではなく、測る数値です。「把握している Y 件のうち X 件を評価」のように。

測定する。 簡単になったのはここです。Smolen はのちに、セキュリティポリシーは*「単なる文書ではなく、 データだ」と論じました。ポリシーの 1 行がデータなら、モデルはそれをインベントリへのクエリに変換 できます。ただし BEAVER によれば、実際の企業データウェアハウスでは GPT-5.2 を使った最先端のエージェント型フレームワークでも「正答率はわずか 10.8%」*でした。モデルは チェックを書く。だがチェックそのものではない。 すべての不変条件に 2 つのフィクスチャを付けます。必ず 赤になる既知の悪い例と、緑のままの既知の良い例です。失敗するところを見たことのないチェックは、動くと わかっていないチェックです。私はそれを Watari で、 高くつく形で学びました。

例外を記録する。 Smolen は、守れていないリソースを 2 つのバケツに分けます。*「この問題は解決 すべき」か、不変条件が「このリソースには当てはまらない」*か。最初のバケツはすでにバックログを 許しています。収まらないのは、私が関わったどの環境にもあったケースです。不変条件は当てはまり、 直すべきで、そして——まだ——直せない。 ベンダーが SSO を提供していない。そのアプリは 3 月に 廃止予定。SSO 付きのプランは基本料金の数倍——sso.tax は何年もその上乗せを記録 してきました。このケースには理由と日付が要るのに、いまの既定のツールはどちらも与えてくれません。

6 つのツールを 2 つの問い——例外は失効するか、理由は必須か——で比べた表。Security Hub CSPM、AWS Config、Kyverno、Powerpipe、Sigma Filters はいずれも文書化していない。Sysdig Secure は両方を満たす。
各ツール自身のドキュメントが例外について述べていること（2026 年 10 月時点）。出典は末尾の一覧に。

AWS Security Hub CSPM では、抑制とは*「検出結果を確認し、対応は不要と判断した」ことを意味します。 メモは任意で、何も失効しません。Sysdig Secure では「例外がいつまで有効かを定義」でき、「有効期限が 過ぎると、リスクは再評価」*されます。時計は作れるし、買える。ただ既定ではないだけです。

後退を防ぐ。 変更のたびに評価することは、いまや安価です。圧力は逆向きに移りました。エージェント は、誰がレビューするよりも速くインフラを変えます。

検知エンジニアリングから借りる

検知エンジニアは、この問題の形を何年も前に解いています。Sigma では、可搬性のあるルールを YAML で 1 つ書き、それを多数の SIEM 向けに変換できます。その処理パイプライン は*「フィールド名を対応づけ、ルールを正しいインデックスやログストリームに向け、環境固有の調整を施す ——元のルールには一切触れずに」。ルールはライフサイクルの status——experimental、test、stable——、 フレームワークの tags、既知の誤検知を持ちます。そして Sigma Filters は除外をルールの外側*に置きます。

Sigma のルール、logsource、パイプライン、バックエンド、状態、フィルタを、不変条件の仕様、リソース種別、環境マッピング、SQL と強制用バックエンド、ライフサイクル、期限付きの例外に対応づけた比較図。
検知エンジニアリングのアーキテクチャを状態のために借りる。Sigma 側の要素は SigmaHQ のドキュメントより。

私は OCSF イベントに対する Sigma の相関エンジン、Secrust を作ったので、このアーキテクチャを内側から知っています。ほとんどは移せます。移せないのは 1 つ。Sigma が 照合するのはイベントで、不変条件が判定するのは状態です。「これは起きたか？」と「これはいま、 すべてのリソースについて真か？」は違う問いです。ですから借りるのはアーキテクチャで、ルール言語では ありません。最も近い先行例は cnspec で、クラウド、Kubernetes、 SaaS、Infrastructure as Code にまたがって 1 つのクエリ言語 MQL を使います。状態に対する Sigma 型の 可搬な形式は見つけられませんでした。

特に効くのは 2 つです。ライフサイクルはブロックする権利を得ていく過程に重なります。experimental は監視、test はアラート、stable は強制。そして Sigma は除外をルールの外側にデータとして置きます—— ただし上の比較表のどの既定とも同じく、時計も理由もないまま。

エンジン：同期したインベントリに対する SQL

私が選ぶエンジンは地味です。不変条件はすべてのリソースを量化する、つまり集合に対するクエリで、 それは SQL の本領です。本記事の例——すべての SaaS アプリケーションが SSO の背後にある——には、ID プロバイダのアプリカタログ、OAuth 許可、支出データの結合が要ります。そして追跡には履歴が要ります。 CloudQuery は*「クラウドインフラのメタデータをデータ ウェアハウスに同期」*するためのもので、結果が残ります。

各不変条件は 3 つの列——リソース、ステータス、理由——を返します。 Powerpipe がコントロールに使っているのと同じ契約 です。結果は OCSF Compliance Finding として、 検知と同じ SIEM パイプラインへ出ていきます。コンプライアンスの表計算ではなく、セキュリティ運用の 実践です。

3 つの種ファイル——不変条件の仕様、環境マッピング、例外表——が同期したインベントリに対する SQL に入り、リソース、ステータス、理由を OCSF Compliance Finding として SIEM と 3 つのビューへ出力する。同じ仕様は、予防と即応のために強制用バックエンドへコンパイルされる。
種：3 つのファイルと 1 つの契約。SQL が記録を持ち、強制エンジンは同じ仕様のコンパイル先です。

ブロックや修正ができるエンジンは、同じ仕様の二次的な出力先です。最も強いのは予防的なガードレール です。AWS のサービスコントロールポリシーとリソースコントロール ポリシーは、組織全体で 不変条件を破りにくくします。ただし破れないわけではありません。AWS 自身の データペリメーターのガイダンス は、SCP がサービスリンクロールや AWS サービスプリンシパルには*「適用されない」*と注記しています。 ですから守られた不変条件でもチェックは残します。次に Infrastructure as Code には OPA、アドミッションには Kyverno、変更時の評価や修復には Cloud Custodian と AWS Config。 計画の段階で止められるものは止めてください。そこがいちばん安い場所です。ただし Infrastructure as Code が確かめるのは計画で、不変条件が確かめるのは現地です。コンソールでの変更、 ブレイクグラス、実行時のエージェント、SaaS ベンダーの SSO 設定は計画を通りません。ですから両方に コンパイルします。コードで強制しているはずのものが実行時に赤になれば、コードをすり抜ける経路がある ということです。

同じ分け方から、2 つの速度が生まれます。ウェアハウスは決まった間隔で同期し、追跡と証明を担います。 変更をきっかけに動くバックエンドは、公開されてしまったバケットを捕まえます。2 つのフィクスチャは すべての出力先に対して走らせます。

種

種は小さな 3 つのファイルと 1 つの契約です。ほかはすべて、そこから育ちます。本記事の例について、 いちばん大事な 2 つを示します。私自身の説明用のスケッチであり、公開された形式ではありません。

# invariants/saas-sso.yaml — one invariant, borrowing Sigma's fields
id: inv-saas-sso-001
title: Every application provisioned through our IdP, or granted OAuth access, enforces SSO
status: experimental              # experimental → test → stable = monitor → alert → enforce
policy: POL-IAM-04                # every invariant traces to one policy statement
threat: >                         # in plain language: what goes wrong if this is false
  A phished or reused password opens an app holding our data, because the app never went
  through our IdP — so it may skip MFA and survive offboarding.
resource: saas_application        # abstract type; the environment mapping says which table
holds: sso_enforced
exception_classes: [vendor_has_no_sso, sso_tier_not_purchased, retiring]
fixtures:
  must_fail: an app with OAuth access to our workspace and no SSO
  must_pass: an app provisioned through our IdP with SSO enforced
owner: identity-team

# exceptions/legacy-crm.yaml — data, reviewed like code, never edited into the rule
invariant: inv-saas-sso-001
resource: legacy-crm
state: cannot_fix_yet             # or out_of_scope: Smolen's "doesn't apply"
class: retiring
compensating: inv-crm-ip-allowlist-002   # itself an invariant, so it can turn red too
accepted_by: head-of-sales        # the risk owner, not security
expires: 2027-03-31               # checked in the query: the row turns red again by itself

3 つ目のファイルは環境マッピングです。この環境では、どのテーブルが saas_application なのか。 契約は、リソース、ステータス、理由。ここから、プログラムの各部分に 1 つずつ明確な答えを示します。

ポリシー。 すべての不変条件は 1 つのポリシー記述に紐づき、それが答える脅威を平易な言葉で名指し します。AWS の re:Inforce 2022 の セッション が示した順序——脅威モデル、不変条件、チェック——です。平易な言葉は二度効きます。人は不変条件が 脅威に答えているかを判断でき、同じ文章でコーディングエージェントに指示も出せます。AWS の AI コーディングエージェント向けの ガイダンス は、*「セキュリティ不変条件を、ステアリング文書の自然言語の制約として記述する」*ことを勧め、決定的な ゲートでチェックします。1 つの仕様に 3 つの姿——チェック、ガードレール、エージェントへの指示。

モデルがポリシー記述から仕様と SQL の下書きを作ります。承認する人は SQL を読まず、2 つのフィクスチャを 確かめます。「OAuth アクセスがあって SSO のないこのアプリは赤になるか？ SSO のあるこちらは緑のままか？」。 ポリシーの持ち主なら誰でもできるレビューです。Smolen は不変条件を*「セキュリティ以外のチームにも セキュリティチームにも役立つ」レンズにしたいと書いていました。専門性は、ルールを書くことから曖昧な ルールを拒むことへ移ります。私の最初の下書きでは「会社のデータを持つすべての SaaS アプリケーション」 でした。それは誰が決めるのか？ 彼の助言は「答えが決定可能になるまで言い換えよ」*。それで仕様の形に なりました。これなら誰でも確かめられます。

キャンペーン。 キャンペーンは1 つの不変条件を 1 つの範囲で、test から stable へ進めます。最初の 赤の数はアラートの列ではなく、あるチームが受け持つバックログです。キャンペーン中は誰も呼び出されま せん。すべての赤は、3 つの結末のどれかで終わらなければなりません。

赤になったリソースが迎える 3 つの結末——修正済み、対象外、まだ直せない。最後のものは担当者、補償的な不変条件、有効期限を持ち、期限後は再び赤に戻る。
すべての赤は 3 つの状態のどれかで終わらなければなりません。時計を持つのは 3 つ目だけです。

キャンペーンが終わるのは説明のつかない赤がゼロになったときで、それはまさに Smolen の言う「確立」 の定義です。そうしたら*「GO を通過して 200 ドルを受け取り、次の優先課題へ進む」*。その後、赤は何かが 変わったときにしか現れないので、インシデントとして SecOps に回します。赤の担当者がわかっていて、 直すのが安い不変条件から選んでください。同時に進めるキャンペーンは 1 つです。

4 四半期にわたって確立した不変条件が階段状に増えていく図。各段の前に、説明のつかない赤がゼロになるまで減っていくキャンペーンのバックログがあり、運用チームへの呼び出しは低いまま推移する。
進捗は確立した不変条件の階段です。後退を防いでいるから、各段は崩れません。

追跡。 すべての評価を*（不変条件、リソース、ステータス、理由、時刻）*として保存します。見るのは、 ゼロへ向かう説明のつかない赤、網羅率、例外の経過期間と更新回数、修正までの時間です。

可視化。 ビューは 3 つ。グリッド：不変条件と環境の表で、例外が走っていればカウントダウン付きの 琥珀色。ポリシー網羅マップ：検知チームの ATT&CK マップを借りて、どのポリシー記述の背後に不変条件が あり、どれがまだ文章のままかを示します。例外の経年：今後 30 日で失効するもの。後の 2 つが経営層を 動かします。しかも確立した不変条件は監査証跡です。Smolen のチームはインベントリを使って FedRAMP 向けの *「月次の継続的モニタリング報告書を自動生成」*していました。

例外。 例外はルールの外側に、データとして置きます。補償的な不変条件、名前のあるリスクの持ち主、 有効期限を持つのはまだ直せないだけです。有効期限はクエリの中で評価するので、誰かが削除を覚えて おく必要はありません。署名するのはセキュリティではなくリスクの持ち主です。SSO の上乗せ料金は、事業側が 払うか、期限付きで受け入れる 1 行になります。PCI は*「正当で文書化された技術上または業務上の制約」*が ある場合の補償を認めています。この記録が、その文書化です。

モデルがすること、しないこと。 仕様を下書きし、すべてのバックエンドへ翻訳します。sigma-cli が ルールを変換するように、フィクスチャを安全網にして。担当者の候補と例外の理由を、人間の確認用に 下書きします。評価だけは決してしません。

チェックを誰がチェックするのか

自分で育てた仕組みには、それ自体の不変条件が要ります。すべての不変条件が直近 1 日以内に評価されている こと。すべてのフィクスチャがいまも赤にしていること。担当者と有効期限のない例外がないこと。効いているか の指標には、私は何度でも リコールに戻ります。 インシデントのたびに、既存の不変条件が捕まえるべきだったかを問う。取りこぼしは、まだ不変条件のない 脅威を教え、鳴らなかった当たりは壊れているものを教えます。

それでも出てくるはずの 3 つの問い

まっすぐ答えるに値するほど難しい反論が 3 つあります。

「それは結局 CSPM では？」

違いますし、そうなるべきでもありません。ポスチャツールが答えるのは何が間違っているか。 不変条件プログラムが答えるのは**「完了」とは何を意味し、残りを誰が決めたか**です。Cloud Custodian や お使いの CSPM がエンジンでいい。プログラムは、それを通して回すものです。ですから役に立つ試験は 機能比較ではありません。すでに持っているものに投げる 5 つの問いです。

  1. 例外は失効するか？
  2. 例外に理由が必須か？
  3. **「適用されるが、まだ直せない」**という状態があるか？
  4. 不変条件ごとに説明のつかない失敗ゼロを報告できるか？
  5. 各ルールは自社のポリシー記述のどれかに紐づくか？

5 つすべてを満たすなら、買ってください。何も作る必要はありません。比較表によれば、ほとんどの既定は 最初の 2 つで落ちます。

「例外を認めたら、不変条件の意味がなくなるのでは？」

目的が失敗ゼロなら、そうなります。でも目的はそうだったことがありません。Smolen はこう書いています。 「不変条件が成り立たないリソースについては、そのどれについても例外を特定できなければならない」。 二値なのは知識であって、準拠ではありません。意味を失わせるのは、誰も説明できない失敗か、担当者の いないまま永遠に生き続ける例外——比較表が示す既定の姿です。例外がなければ、不変条件は自明に真になる まで縮みます。ガードレールは、例外が修正より速く増えるなら、その不変条件は嘘をついているということ。 更新せずに、分割するか書き直してください。

「悪用がいちばんの侵入口になったいま、これに意味はあるのか？」

むしろ意味は増しています。2026 年版 Verizon DBIR によれば、*「脆弱性の悪用は、いまや侵害の最も一般的な初期アクセス経路」*で 31%、認証情報の悪用は 13% に下がりました。ただし次の所見も読んでください。既知の悪用脆弱性のうち完全に修復されたのは 26% だけで、中央値は 43 日でした。

見つけられないのではなく、塞げないのです。「インターネットに面した資産は、 N 日より古い既知の悪用脆弱性を抱えない」は不変条件です——修復の約束を検証可能にしたものです。 Smolen のリストにも「スキャナーの結果はすべてトリアージされ、解決される」がありました。露出も状態 です。何がインターネットから到達可能か、そしてそもそもそれがインベントリにあるか。

正直な限界：露出したサービスのゼロデイに対して、不変条件が与えるのは封じ込めとインベントリで あって、予防ではありません。既知の真実を真であり続けさせる、コントロールの 1 系統です。

これが何を犠牲にするか

  • 生成したチェックは、見た目以上に間違っている。 不変条件ごとに 2 つのフィクスチャは任意では ありません。
  • 期限が来れば、予定どおりに赤になる。 それが狙いですが、すべての更新に担当者が要り、期限日は 騒がしくなります。
  • 種は保守の請求書になる。 同期ジョブは壊れ、API は変わります。持ち続けられないなら、5 つの問いを 満たすツールを買ってください。
  • 補償的な不変条件は、本当に補償しているかを誰も確かめなければ、ただの芝居になる。
  • 網羅は決して完全にならない。 シャドー SaaS は、定義上インベントリにありません。

私がこれをやらない場面： 資産インベントリがないところ。まずそこを直してください。キャンペーンを 1 つ回す人もいないところ。そして証跡の形式が規制で義務づけられているところ。NIST の OSCAL POA&M のような、決められた 形式を使ってください。

私が最初に選ぶ 5 つ

  1. 自社の ID プロバイダ経由でプロビジョニングされた、または自社のワークスペースへの OAuth アクセスを 許可されたすべてのアプリケーションは SSO を強制する。
  2. インターネットに面した資産は、N 日より古い既知の悪用脆弱性を抱えない。
  3. インターネットに面したすべてのサービスは、名前のある担当者とともにインベントリにある。
  4. 自動化やエージェントが使う ID は、長期間有効な静的認証情報を持たない。
  5. すべての非人間 ID には名前のある担当者がいて、そのシステムの廃止とともに削除される。

1 つ目は Smolen のリストの先頭を研ぎ澄ませたもの。2 つ目は DBIR の教訓です。残りの 2 つは OWASP Non-Human Identities Top 10 そのものから来ています。同リストは Improper Offboarding を 1 位、Long-Lived Secrets を 7 位に 挙げています。

残り——仕様の完全な形式、環境マッピング、カタログ、キャンペーンの手順書——は、コーディング エージェントに渡して自分の仕組みを育てられるレシピにまとめているところです。GitHub の Spec Kit が言うように、 「仕様がコードに仕えるのではない。コードが仕様に仕えるのだ」。

で、この考え方は生き残ったのか？

生き残った以上です。チェックを書くのが簡単になったので、仕事はその周り——インベントリ、例外、 それに署名する人——へ移りました。種を植えるのは、そこです。

Smolen の一文はいまも有効です。私なら 1 語だけ足します。真でない場所はすべてわかっている——そして、 いつまでかも。

出典

この考え方の 2 つの系譜——AWS と Smolen——、各ツールの挙動、すべての引用は出典を示してリンクして あります。例外の比較表は 2026 年 10 月時点の各ドキュメントに基づき、いずれ古くなります。私自身のものは、 SQL を記録の拠り所にする選択、種と 2 つの YAML スケッチ（説明用で、公開された形式ではありません）、 3 つ目の例外の状態、「キャンペーンは説明のつかない赤がゼロで終わる」、2 つのフィクスチャの原則、 ベンダーへの 5 つの問い、最初の 5 つの不変条件です。状態に対する Sigma 型の可搬な形式は見つけられて いません。存在するなら教えてください。開示：私は AWS に勤めています。引用した AWS の資料はすべて公開 されたもので、Amazon 社内の実務については何も書いていません。