バッジは表示するのは安く、解釈するのは高い。公開された監査レポートは、範囲の限られたエンジニアリング作業である。名前の明らかな評価者が、名前の明らかなコンポーネントを、名前の明らかなバージョンで、明示された手法と時間予算のもとに調べた。この四つの事実が、結論が何を支えられるかを決め、通常はマーケティング用の要約ではなく最初の数ページに書かれている。それを読むのに十分かかり、クライアントアプリの所見をサービス全体に広げるというよくある誤りを防ぐ。

範囲の節が実際に区切るもの

範囲の記述は柵であり、その外側は合格ではなく未回答のままである。レポートは、調査したコンポーネント、コミット範囲またはビルド識別子、使用した環境、許可された相互作用モデルを列挙する。デスクトップクライアント、モバイルアプリ、サーバーコード、アカウントのバックエンド、本番インフラは五つの異なる対象であり、作業はそのいずれの部分集合も対象にできる。

除外は含めることと同じくらい重要である。意図的に書かれ、不注意に読まれるからだ。範囲外と記されたアカウントシステムは、暗黙に安全とはみなされず、作業から外されたモバイルアプリは単に未調査である。自分のメモでは、試験していないコンポーネントをすべて不明として印を付け、評判で空白を埋めたくなる誘惑に抵抗してほしい。

二種類の試験は別の問いに答える

ソースレビューと実行時試験は、異なる故障を探す。コードを読むレビュアーは、鍵導出をたどり、長さ検査の欠落に気づき、パーサ全体について実行せずに推論できる。稼働中のサービスに対するテスターは、配備されたビルドが実際に何をするかを発見する。アプリが拒否する証明書、いまだ有効なフォールバックプロトコル、誰もレビューしていない設定を通じてバージョンバナーを漏らすエンドポイントなどである。

どちらも他方を代替せず、レポートは通常どちらを実施したかを明記する。要約がその区別なしに「監査済み」と言うなら、曖昧さは要約にあり、レポートにはない。

アクセス制限も同じ働きをする。ブラックボックスの作業はサーバー設定を見られず、配備されたエンドポイントに一度も触れないアーキテクチャレビューは、本番が図と異なることに気づけない。どちらも正当だが、両者の結果を混同することは正当ではない。

所見が修正済みバージョンになるまで

レポートの価値ある半分は修復表である。各所見、評価者の手法による重大度、運用者の対応、再試験の結果。重大度の数値は自然からではなく選択された方法論から来るので、重大度は一つのレポートの中で比較し、尺度の異なる二つのレポートの間で比較しないこと。

次に、修正をリリースされたソフトウェアにつなげる。修正された所見が利用者にとって意味を持つのは、修正を含むバージョンが実際に導入されているときだけであり、だからこそレポートのビルド識別子とリリースの変更履歴を一緒に読む必要がある。修正を覆う再試験はループを閉じる。試験されていない修正は主張にすぎない。安定版リリースが一度も統合していないブランチだけで出荷された修正も同じである。

バッジが伝えられないこと

所見がないことは欠陥がないことの証明ではない。固定予算の短い作業は何かを見落とすし、きれいなレポートの正直な読み方は、評価者が使えた時間の中で探していた問題の種類を見つけられなかった、というものである。

バッジはまたその範囲外の性質について語ることはできない。ログ記録の慣行、管轄、保持に関する主張はポリシー文書にあり、クライアントアプリの監査にはない。評価者の評判がその境界を越えて移ることはない。

弁護できる証拠を記録する

引用は三つの部分で書く。コンポーネント、バージョン、検証済みの修正である。Mozilla が委託した VPN 監査のような公開された作業は、その範囲が記述する命題だけを支え、それ以上は支えない。引用が正確であれば、それはなお大きな価値を持つ。決して調査していない事柄に同じレポートを引用するのは、引用しないより価値が低い。誰も得ていない信頼を招くからだ。

主張された性質が入手できるどのレポートの外側にあるなら、文書の中で未解決のままにしておく。未解決の一行は追加の問いを招くが、バッジは招かない。唯一の例外は、別の、同じくらい具体的な文書が決着させる性質であり、そのとき変わるのは主張ではなく引用である。

さらに二つの習慣が読解を長持ちさせる。実際に動かしているリリースに対してレポートの日付を記録すること、そして試験したものと配備したものの差分を保つことだ。どちらも信頼の判断を、同僚が確認できるものに変える。

関連記事