信頼と、オープンソースを選ぶということ

この記事は
https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
を翻訳したものです。
ずっと昔、遠い遠いところで(よくある表現でしょ)、私はトラストとセキュリティという標準化文書の下書きに関わっていました。(標準化に関わっていたことがなければ恐怖に感じるでしょうけれど、関わったことがあれば普通のことですよ)
この文書は ETSI GS NFV-SEC 003: Network Functions Virtualisation (NFV);NFV Security; Security and Trust Guidanceと呼ばれ、セクション5.1.6.3は「推移的トラスト」についてでした。
複雑で長い文書で、とても自信を持ってできた仕事です。
(私は調査員の一人で、また文書のほとんど特にトラストのセクションを記述しました。)この文書は題名からもわかる通りトラスト周りの重要な問題に対応しているものです。

この中でこう定義されています。

「推移的トラストは、CがBを信用しているので、AはBというものを信頼する」

その文書のどこにもオープンソースソフトのことは書いてありません。
公平を期すために、どのソフトやベンダーにも偏らないように記述してあります。標準化に関わる多くの企業はベンダー仕様のソフトに注目しがちです。さらにいうと私は当時Red Hatに勤めていませんでした。

Red Hatに転職し、基本的に標準化の世界から遠ざかることになるのですが、オープンソースについては考えるようになりました。
また、トラストに関してももっと深く考えるようになりました。ビジネス、組織や企業でオープンソースをどうやって使うようになるのか、と。

オープンソースが「それ自体は」他のベンダーソフトと比べて特に安全ではないにしても、どうしてオープンソースがさらに安全性を高めることができるだろうか、と別の記事にも書いています。

どうしてこのことが信頼、特に推移的トラストに関わるのでしょう。
オープンソースとトラストがどうリンクするかについて私はずっと考えていました。大部分が拡散したトラストについてです。
拡散したトラストとブロックチェーンは同じように扱われることが多いです。喜ばしいことです。信頼とはブロックチェーンに確実に関係しているという事実を無視しがちな罠に陥いることが多いからです。暗に言われているだけでちゃんと定義していないからです。

ただし、ここで私が興味を持っているのは、オープンソースソフトを使用するかどうかを選択する方法としての分散した推移的な信頼(トラスト)です。
これは、オープンソースのセキュリティなどの非機能的な詳細についてだけに言えることではなく、ソフト自体の場合についてもです。

「オープンソースソフトを信頼しています」とは、どういうことでしょう?
それは、コードを書きテストをした十分な数の人間が私と同じような要件を提示している。ソフトを使用することのリスクを受け入れることができるだけ十分な経験がその人間にはある。そう私たちが決断しているということと同じなのです。

以下にさらに興味深いことを挙げます。

・ユースケースと要件に合ったデザインがされていると、アーキテクトと設計者を信頼している、ということ
・その設計に合ったようにコードが書かれていると開発者を信頼している、ということ
・お互いのコードのレビューがされていると開発者を信頼している、ということ
・ソフトが正しく文書化されていると、文書化チームを信頼している、ということ
・ユースケースに合ったテストが書かれ、行われ、チェックがされているとテスターを信頼している、ということ
・ユースケースに合った方法でデプロイしているとコードをデプロイした人を信頼している、ということ
・バグレポートをしているとコードをデプロイした人を信頼している、ということ
・バグレーポートを受け取った人がちゃんと修正していると信頼している、ということ

もちろんもっと色々なケースはあるでしょうが、話を進めるには十分でしょう。
ベンダー仕様のソフトを選択すれば信頼関係はもっと明確で絆が強いものでしょう。もし期待した品質のものでなければ別のベンダーに移行するか期待した仕様になるよう元のベンダーに作業するよう言うからです。

オープンソースソフトの場合はもっと漠然としています。
デザイナーやソフトウェアエンジニア、テスターなどの関与した人を見つけることは少なくともできるでしょう。でもその人たちに与える影響力はずっと小さいでしょうね。
おかしなパラドクスがあるのですが、ベンダーソフトには主張できてソフトウェアの方向性に対する影響力は比較的大きいです。(お金がかかってくるので)
ところが、オープンソフトに比べると欲しいものを得る事ができると確信したり、実際何が開発で起こっているかはっきりと見えません。

これはオープンソースだと、「私自身」が上にあげたどの項目にも参加する事ができるからです。
私、もしくは私の所属する組織は、アーキテクトにも設計者にも、文書作成やテスター、もちろんデプロイしたりバグ報告したり、どの役割にもなれるからです。
もしオープンソースへの影響は他の人と同等であれば、分散された信頼は推移する事が少なくなります。

作成、メンテナンス、要件やソフトウェア品質に対してみんな平等で、分散された信頼関係ネットワークの一部になります。
ベンダー仕様のソフトを買った場合に経験するような排除感は減るのです。

では、何故ベンダーからオープンソースソフトウェアを買ったりライセンスを得たりするのでしょう。
それは、そうすることで、上記に挙げた分散された信頼のネットワークの利点を得つつ、サポート、パッチ、トレーニングなど他のリスクを訴えることができるからです。

ソースから直接コードを得ることもできるでしょう。しかしこれはソフトを使用する人たちがそのリスクを選んだということではありません。またこれはオープンソースコミュニティに参加している人たちも例外ではありません。

信頼とは、とても複雑なものです。そして他のものや人を信頼するのも複雑です。別のブログでも少し書きましたが。
ただ私は決定したことに関して、どうして決定したのかと考え理解することは非常に大切なことだと思います。それはリスク周りの情報に基づいた選択をするのに必要だからです。
元の記事 https://aliceevebob.com/2019/06/18/trust-choosing-open-source/
2019年6月18日 Mike Bursell

大勢がレビューしていても信用しないという仮説

大勢がレビューしているから、バグがないという考え方。これは神話です。

この記事は https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/ を翻訳したものです。
コードを書くことは大変な作業です。
ソースコードを書くのは、もっと大変です。もっと、もっと大変なのです。

セキュリティの機能を実装するコードを書いているとわかりますが、このようなコードは詳細まで精査されたアーキテクチャとデザインに基づいています。

さらに世界中でレビューされるというプロセスを経た、パーフェクトで破られることがないスタンダードが反映されているかもしれません。
(「パーフェクトで破られることがない」まあ、本当かどうかは置いておいて、そう仮定しましょう)

が、このようにデザインとアーキテクチャが素晴らしくても、実際のソフトウェアに組み込むのはとても特殊なことです。

数学的にソフトウェアが正しいと証明されても、実現しようとしている機能が正しく実装できるソフトウェアを書くということは、科学と芸術の間にあるようなものです。(デザインとアーキテクチャに寄るとは言っても結局自分が何をしたいかに寄るのですが。)

ソフトウェアをデバッグしたり、ソフトウェアに踏み入ることでその正確さを推測しようとする人にとっては、当然のことです。ただ、このブログ記事のポイントではありません。

誰も(コードを5行以上書いたことがある人、Perlでだったら6行)実際にソフトウェアがこのプロセスでパーフェクトになるとは思わないでしょう。
しかしソフトウェアは出来るだけパーフェクトでバグがないよう作るべきだ、というのはわかってもらえると思います。
だからこそ、コードレビューはソフトウェア開発の中心なのです。

ラッキーなことに(少なくとも私的には)、私たちが日々使うコードのほとんどはオープンソースです。これは誰もがコード見ることができ、何千もの人にレビューしてもらうことができる、ということです。

ここで問題が生じます。
オープンソースがたくさんの人にレビューされるということは、全てのバグが解決されるという考え方があります。

これは神話です。とても危険な都市伝説です。

先ほどの考えには二面性があります。
一つ目は、「ビルドすれば、出来上がる」という間違った考え方です。
世界中に全てのウェブサイトがリストされていた昔、そこにあなたのウェブサイトを登録すれば皆さんに見てもらえると思った時代があったでしょう。
(私も登録しました。見てもらえました。これは奇跡です)

同じように、オープンソースプロジェクトは(おそらく)少なかったので、たくさんの人がコードレビューしてくれました。
このような時代は終わりました。ずっと昔に。

二つ目に、セキュリティの機能を、良い例として暗号化の基礎などですが、正しくレビューできる人はすごく少ないのです。

ベンダー特有のコードに問題が少ないという訳ではありません。むしろ、正反対です。
ベンダー特有のコードのデザインやアーキテクチャがレビューに対してオープンになっていない、ということではなく、コードを見てくれる人が少なくてヒエラルキーなプレッシャーと組織的な考え方に寄る危険性がとても大きいということなのです。

「ベンダーのコードは安全だ」というのは神話というより、フェイクニュースでしょうね。
多くの企業がセキュリティソフトを隠したい理由がよくわかります。
「知的財産の保護」と彼らがよく言うのは、実際リリースするのに安全ではないからなのではないか、と心配してしまいます。
私にとってセキュリティソフトとは、一貫して「オープンなソース」なのです。

では、何ができるでしょう。
セキュリティを気にする企業や組織はリソースを割いて機能を実装したりコードのチェックやレビューができるはずです。そして、そうする責任があると私は考えます。
その部分に私の勤めるRed Hatがコミットしているのです。

同時にオープンソースコミュニティはクリティカルなプロジェクトをサポートし、コードに含まれるレビューの数を増やそうとする方法を探しているのです。(例えば Linux FoundationCore Infrastructure Initiativeです)

さらに学術組織に、オープンソースソフトの大切さをハイライトすることはもちろん、セキュリティソフトの書き方とレビューという暗黒アートを
生徒に訓練させるよう推奨する必要があります。

改善できることはあるでしょう。事実、改善もしています。
「多くのレビュー(略)神話」はコードを改善できないという訳ではなく、むしろできるということを認識しなければいけません。ただ、もっとエキスパートのレビューが必要だということです。
元の記事:
https://aliceevebob.com/2017/04/04/disbelieving-the-many-eyes-hypothesis/
2017年4月4日 Mike Bursell