PyPI で公開されているパッケージの半数近くが何らかのセキュリティ上の問題を含むとの調査結果 28
ストーリー by headless
問題 部門より
問題 部門より
Python パッケージの公式リポジトリ PyPI で公開されているパッケージの半数近くに何らかのセキュリティ上の問題が含まれるとの調査結果が発表された(The Register の記事、 論文)。
対象は PyPI に保存されている全パッケージ 19 万 7 千件以上のスナップショットで、静的コード解析ツール Bandit を用いて調査している。セキュリティ上の問題は exec 関数の使用やパスワードのハードコードといったものから、セキュアでない例外処理やハッシュ関数の使用、SQL インジェクションや XSS が可能といったものまで幅広い。調査の結果、約 75 万件の問題が見つかり、46 % のパッケージが少なくとも 1 つの問題を含んでいたとのこと。
ただし、見つかった問題の半数以上を占める約 44 万件は深刻度の低いものであり、約 23 万件が深刻度中、約 8 万件が深刻度高に分類される。深刻度低の問題を含むパッケージは全体の 35.8 %、深刻度中は 25.3 %、深刻度高は 11.4 % にとどまる。また、今回の調査では誤検出・検出漏れや実際の使用では実行されないコードが検出されている可能性のほか、調査時に展開されなかったファイルが含む問題や Python 以外の言語で書かれたコードに含まれる問題は検出できないといった制約もあるとのことだ。
対象は PyPI に保存されている全パッケージ 19 万 7 千件以上のスナップショットで、静的コード解析ツール Bandit を用いて調査している。セキュリティ上の問題は exec 関数の使用やパスワードのハードコードといったものから、セキュアでない例外処理やハッシュ関数の使用、SQL インジェクションや XSS が可能といったものまで幅広い。調査の結果、約 75 万件の問題が見つかり、46 % のパッケージが少なくとも 1 つの問題を含んでいたとのこと。
ただし、見つかった問題の半数以上を占める約 44 万件は深刻度の低いものであり、約 23 万件が深刻度中、約 8 万件が深刻度高に分類される。深刻度低の問題を含むパッケージは全体の 35.8 %、深刻度中は 25.3 %、深刻度高は 11.4 % にとどまる。また、今回の調査では誤検出・検出漏れや実際の使用では実行されないコードが検出されている可能性のほか、調査時に展開されなかったファイルが含む問題や Python 以外の言語で書かれたコードに含まれる問題は検出できないといった制約もあるとのことだ。
どれだけアクティブに開発されているの？ (スコア:0)
実際に使われているパッケージなんてほんの一握りでしょ。
Re: (スコア:0)
アクティブに開発されてるかどうかと
実際に使われてるかどうかは別の話。
Re: (スコア:0)
それはそうだが、それを区別するならより母集団や重みづけを変えるべきでは？
実際に使われていてもメンテナンスされてなければ修正される見込みはほぼないのだから。
Re: (スコア:0)
これはあくまで機械的に調べたものだから重みづけなんて眼中にないのは当たり前。
重みづけすれば修正されるわけでもないんだから、実際に重みづけで優先度の高いものから直そうとしている人でないと重みづけデータに意味があるとは思わないな。
「どういう重みづけにするか」は目的によって違うもので、それによって客観性のあるデータではなくなるのだから。
ぴこーん！！ (スコア:0)
その Bandit を PyPI に組み込んで、パッケージを登録したらチェックして表示してくれるようにすればいいじゃないの？
# CPAN 版もないのかしら
Re: (スコア:0)
だったらPythonの標準ライブラリにすれば無問題。
Apache-2.0だし。pytのようにGPLだとアレだけど。
ちなみにPysaは使った事ないからよう知らん。
Re: (スコア:0)
大丈夫。俺も Python 使ったことないし。
Re: (スコア:0)
なら安心安全なPython最強という事で。
# 買わなければ外れない宝くじ論法
記事としては (スコア:0)
問題を大きく見せたいのだろうけど、
大半が個人が試しに登録してみた程度のまともに使われていないものであることは想像に難くない。
パッケージ管理システム全体の信頼性という意味では各パッケージのダウンロード数を掛けたものを分母にすべきだろう。
経験則以上の根拠は全くないが深刻度中以上は1%以下とかそういう数字になると思う。
元記事の
The situation is similar with package registries like Maven (for Java), NuGet (for .NET), RubyGems (for Ruby), CPAN (for Perl), and CRAN (for R).
についても同様。
Re:記事としては (スコア:1)
何を勘違いしているのかわかりませんが、この論文の目的は「パッケージ管理システム全体の信頼性」を求めることではありません。
Re: (スコア:0)
ダウンロード数≠使用数なので。長く改変の必要がないなら必然的にランクが上がる。。
それにまともに使われてないという想定がひっくり返る、参考として使われている可能性だってある。
Re: (スコア:0)
あたりまえのこと言うなよ。
今の単なる全パッケージが同じ重みであるという状態よりはよほど実態に近づくって話だろ。
Re:調べたなら (スコア:1)
ただのプログラムを作る⇒プログラミングシステム製品を作るコストの差は3×3＝9倍
#最悪だったのは何故か2*2=4倍と記憶していた事(；´Д｀)
#大昔、読んだ教科書的な本の内容を思い出した検索してみたけど「人月の神話」が元ネタだったみたいです。もちろん読んだことは。。。無い。
#どこにコメントするか迷ったけど、ここで。
Re:調べたなら (スコア:1)
見つけた人に責任を負わせるのは、ダメ職場の王道だわな
ドヤ顔でこんな指摘できる奴に伝わる気がしないけど
Re: (スコア:0)
「我々があんたのコードを機械的に調べた結果こういう問題を見つけましたので報告します、修正・追加後のコードはわかりませんが」
ここまでは報告出せるでしょ。
Re: (スコア:0)
いや迷惑にも程があるでしょ。悪意のある人が利用するかもしれないし
Re: (スコア:0)
じゃ直すしかないね!
Re: (スコア:0)
悪意のある人が既にこっそり利用しているかもしれないから、報告してもらえるほうがまだマシ。
Re:調べたなら (スコア:1)
お前が直したっていいんだぞ
Re: (スコア:0)
あたかも妖精がやったようにひっそり直して何事もなかったかのようにするほうがいいと？
レポして警鐘を鳴らすやつも必要だろ。
Re: (スコア:0)
そしたらひっそり直してたパッケージの調査報告あげるやつが出てくるだけでは
Re: (スコア:0)
その観点なら、レポジトリ全体のパーセンテージでなく、
自分が使っているパッケージに脆弱性があるか否かでは？
誰からも見向きもされないマイナーパッケージ(おそらく、
メジャーなパッケージよりも数が多くセキュリティのチェックも十分でない)を含めて、
脆弱性件数が云々と指摘されても、
「使用するパッケージのコード含めて、テストとチェックは必要」という
月並みな意見しか得られない。
Re:調べたなら (スコア:1)
現状はその月並みな事もできてないんだから、こういうレポが必要だね。
Re:調べたなら (スコア:1)
この手の話題では何度も同じこと言わなきゃいけないわけだが、
調べなくてもある程度予想できることに調べる価値がないと考えるのは大間違い
実際に確認して裏付けを取れば説得力がまったく違うし、具体的な数字が出てくるからこそわかることもある。
Re: (スコア:0)
解析ツールで問題点見つけ出すのと、意図している動作に支障がないようにその問題を修正するのとでは、必要な労力に差がありすぎるだろ…
Re: (スコア:0)
比較的すぐできる対応だと、運営と連携してコード解析の結果をタグ付けするぐらい、かなぁ。
それでも既にダウンロードした人には無力だから悩ましい。
Re: (スコア:0)
直しちゃいけないバグとかあるだろ。。