https://yn-labs.com/tags/release/Recent content in Release on 万屋猫LabsHugojaMon, 15 Jun 2026 12:00:00 +0900https://yn-labs.com/posts/secure-rust-cicd-release/Mon, 15 Jun 2026 12:00:00 +0900https://yn-labs.com/posts/secure-rust-cicd-release/<h2 id="テストが緑で満足できなかった理由">「テストが緑」で満足できなかった理由</h2> <p>エージェントに本物の API キーを渡さずに動かす CLI ツールを開発している。守りたい性質はシンプルで、子プロセスに本物の鍵を渡さないこと。ここが崩れれば、このツールを使う意味はない。</p> <p>ただ、テストが通っているだけでは確認として物足りなかった。テストが言えるのは「この入力では問題ない」までで、「どんな入力でも問題ない」ではない。鍵を扱う以上、その差は無視できない。</p> <p>そこで Lean で証明を書き、CI でビルドするようにした。手間はかかるが、扱うものを考えれば妥当な投資だと思う。この記事では、そのときに組んだ CI/CD を抜粋して紹介する。プロジェクト固有の内部名は伏せ、設計と仕組みのところだけを残した。</p> <h3 id="数字で見た中身">数字で見た中身</h3> <table> <thead> <tr> <th>指標</th> <th>値</th> </tr> </thead> <tbody> <tr> <td>Lean の定理／補題（<code>formal/lean</code>）</td> <td>28</td> </tr> <tr> <td>Lean 証明中の <code>sorry</code> / <code>axiom</code></td> <td>0</td> </tr> <tr> <td>安全不変条件ゲート（CI ステップ）</td> <td>11</td> </tr> <tr> <td>リリース配布ターゲット（matrix）</td> <td>5</td> </tr> <tr> <td>サプライチェーン検査</td> <td>cargo-deny + Trivy</td> </tr> </tbody> </table> <p>地味だが効いているのが、<code>sorry</code>（証明の穴埋めサボり）と <code>axiom</code>（無証明の仮定）が両方とも 0 という点だ。核の不変条件を仮定でごまかさず最後まで証明している、ということで、これが CI を緑にする条件に入っている。</p> <h2 id="ci-は三層に分けている">CI は三層に分けている</h2> <pre tabindex="0"><code>┌─────────────────────────────────────────────┐ │ 1. 形式検証（核） │ │ 「子プロセスは本物の鍵を受け取らない」を │ │ Lean で証明 — 定理28 / sorry・axiom 0 │ ├─────────────────────────────────────────────┤ │ 2. 安全不変条件ゲート × 11 │ │ deny-before-inject / DNS guard / │ │ audit boundary / secret-type … を │ │ 1条件＝1ゲートで機械チェック │ ├─────────────────────────────────────────────┤ │ 3. 汎用品質 + サプライチェーン │ │ fmt / clippy -D warnings / test / │ │ cargo-deny（advisories, bans, sources） │ └─────────────────────────────────────────────┘ </code></pre><h3 id="1-核は-lean-で証明してci-でビルドする">1. 核は Lean で証明して、CI でビルドする</h3> <p>「子プロセスは本物の鍵を受け取らない」という核の性質は、<code>formal/lean</code> に証明として置いている。定理と補題で28本、うち <code>sorry</code> も <code>axiom</code> も無し。CI は毎回この証明をビルドして、サボりや無証明の仮定なしで通ることを確かめる。</p>