オープンソースVPNが調達で拒否される理由

オープンソースを挙げる拒否は、めったにライセンスの問題ではない。レビュアーは通常、展開されたリリースを誰かが保守していること、導入されたビルドが識別できること、評価が接続対象を網羅していること、あるいは接続を撤回できることといった要件を守っている。その後の議論は、誰も尋ねていない問いに答えることが多い。

ライセンスを弁護する前に、どの要件が当てはまるかを尋ねる。その答えが、必要な文書を決める。

ラベルは要件ではない

読めるソースコードは、公開された実装を検査できるという意味だ。誰かが検査したこと、ゲートウェイ上のビルドが公開されたものと一致すること、保守担当者があなたの展開に修正を負っていることを意味するわけではない。それぞれは別の所有者を持つ別の主張であり、その一つを必要とするレビュアーは他では満たされない。主張を口に出して名付けるだけで、会話はたいてい変わる。

逆の誤りも同じくらい多い。商用ライセンスは、サポートが依存している機能を覆っていること、評価が展開するコンポーネントを調べたこと、ベンダーが保守時間内に修正を届けることを証明しない。ライセンスは配布条件を述べるが、調達の判断は信頼の問題だ。どちらにせよ、ライセンスは答えの中で最も情報の少ない部分である。

クライアントとサービスも分けておく。デスクトップクライアントの監査は、パートナーのゲートウェイ設定、その ID プロバイダー、運用担当者がアカウント削除をどう扱うかについて何も語らない。集める証拠は、パートナーに信頼を求めている境界と一致していなければならない。

懸念を成果物に変える

承認者に要件を一文で述べてもらい、それを満たす文書を名指しする。あいまいな安心感が、この会話をイデオロギー論争に変えるのだ。

NIST Secure Software Development Framework がここで役立つのは、調達の会話を実務とサプライヤーとのコミュニケーションという共通の語彙の周りに枠づけるという一つ狭い理由からだ。これはラベルについて論じる代わりに定義された証拠を求めることを支え、特定の VPN が合格する認証ではない。

中央の列が何をしているかに注目してほしい。各行は存在するかしないかのどちらかの文書を求め、それによって意見が、誰かが作るか拒否できる成果物に変わる。

クライアントとサービスを分ける

クライアントアプリケーションのサポート契約は、あなたのトラフィックが到達するサーバーについての約束ではない。証拠を示す前に、経路のどの部分をパートナーが運用し、どの部分をあなたがその代理として運用するのかを印づける。両者を混ぜると、網羅的に見えて何も答えない文書の束ができる。

展開があなたのものであれば、パートナーは ID とアクセス規則だけを信頼すればよいかもしれず、ソフトウェア供給網全体を信頼するよりはるかに小さな要求だ。展開が相手のものであれば、あなたの好むクライアントは無関係かもしれず、ゲートウェイ設定が主題になる。どちらの場合かを二回目の会合の前に見極めれば、レビューの一巡を節約できる。

次に、レビューが実際に失敗する運用上の問い、つまり誰がアカウントを削除するのか、どれだけ速く、その後どんな証拠が残るのかを確認する。削除手順のない美しく文書化された評価は、依然として未解決の所見である。

議論ではなく決定で締める

やり取りは、受け入れられたバージョン、それに付随する統制、名前を挙げた運用担当者、まだ提出されていない証拠、そしてその期限という書面の結果で締めくくる。未解決のものは、一般的な承認の声明に吸収するのではなく、条件として記録すべきである。

方針が特定の承認済み製品を名指ししているなら、誰も承認していない並行の取り決めを作るのではなく、例外の経路を使う。説得力のある技術的論拠は許可を与えないし、非公式の展開は発見を待つ所見である。

要件が本当に満たせないなら、承認された代替に移り、その理由を述べる。この作業の目的は、組織が何に依拠できるかを確定することであり、明快な「いいえ」は、後で誰も弁護できない承認よりも良い結果である。