オープンソーススキャンの歴史みたいな記事の翻訳
WhiteSourceのとある記事が面白かった。ので、日本語にしてとっておきたいと思います。
それがこちら。
まだオープンソースを識別するためにオープンソースコードスキャナを使用していますか？もっと良い方法があります
それでは、以下が翻訳となります（DeepL先輩にお世話になってます）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
"オープンソースは無料" なぜコンマを反転させているのかと聞かれるかもしれません。ほとんどの組織が、オープンソースは自由に使用、変更、再配布することができますが、...それには許諾されたライセンスを遵守するという条件がつきものだということを理解していると思います。
現在では、オープンソース監査により、多くの組織がオープンソースライセンスの法的要件に精通するようになりました。オープンソース監査は通常、M&A、IPO、または新規投資ラウンドの場合に発生し、外部関係者がレビューのためにオープンソースのインベントリレポートを要求します。その他のケースでは、法律顧問、セキュリティ監査人、コンプライアンス担当者など、さまざまなチームから内部要件が提起されることもあります。
しかし、この種の情報を手動で収集することは、特に製品にオープンソースを多く使用している組織では、非常に時間がかかります。結局のところ、最近ではオープンソースがコードベース全体の 60 ～ 80% を占めており、オープンソースのインベントリを最初から監督し、管理する必要性と価値があることが明らかになっています。
3 年前までは、ほとんどの企業は、オープンソースのスキャンツールを使用して定期的に監査を実施することで、オープンソースの使用状況が準拠していることを確認したいと考えていました。しかし、近年では、ほとんどのオープンソース コード スキャナがアプローチを変更したり、顧客基盤を失ったりするなど、市場に目に見える変化が見られるようになりました。
すべての始まり
組織のオープンソース監査を支援するために、Black Duck Softwareという新興企業が、2002年に最初のオープンソーススキャンソリューションを発表しました。その後すぐに、Protecode、Palamida、Open Logicなど、オープンソースの発見という課題を克服するためにオープンソースコードスキャナを提供するベンダーが加わりました。一般的に、これらのオープンソーススキャナは、コードをスキャンして、オープンソースコンポーネントに含まれるコードに類似したコードの断片（「スニペット」とも呼ばれる）を識別することができます。ユーザーはコードの類似性を警告し、それぞれの警告を個別に確認する必要がありました。
当初、オープンソーススキャナは、組織がオープンソースのインベントリを監視・管理する方法に革命をもたらしたように見えました。しかし、オープンソース スキャナには重大な欠陥があり、コードベースのスキャンは当初考えられていたほど簡単で自動化されたものではないことに気づくまでにはそう時間はかかりませんでした。
スキャナベースのオープンソースライセンスとセキュリティ管理ソリューションの3つの落とし穴
オープンソース管理のプロセスを容易にする代わりに、オープンソーススキャナはより多くの課題をもたらしているかもしれません。以下では、このソリューションの3つの主な落とし穴を強調しています。
落とし穴1: 終わらない偽陽性の物語
オープンソーススキャナを使用する際に発生する主な課題の1つは、「偽陽性」アラートが大量に生成されることです。これらのアラートは、スニペットと一致しているように見えましたが、よく見ると、実際にはオープンソースコンポーネントの一部ではないことが判明しました。これらの誤検知はオープンソースのスキャンソリューションによってフラグが立てられ、開発チームによって除外されます。
あなたは、「ここにもここにもいくつかの誤検出があるかもしれない」と思うかもしれません。大多数が正しければ」と思うかもしれませんが、実際のところ、製品に使用されているオープンソースコンポーネントの総数が限られている場合、これらの誤検出は通常、管理可能な程度です。しかし、長年にわたり、オープンソースコンポーネントは指数関数的に増加しています。当社のデータベースだけでも、Java、Ruby、Pythonなどの言語の1億5500万以上のオープンソースコンポーネント（ソースとバイナリの両方）と、C/C++、Javascript、PHP、ObjectiveCなどの言語の110億のオープンソースファイルが存在します。これだけ多くのオープンソースコンポーネントが開発チームに提供されているのですから、スニペットが一致することは保証されています。偶然と言えば、何千ものスニペットが存在することになります（大げさではありません！）。
要するに、これらの偽陽性をふるいにかける作業は、非常に退屈で時間のかかる作業になります。
落とし穴2: アジャイルSDLCプロセス? オープンソースのスキャナではダメ
落とし穴1は、オープンソース コンポーネントのスキャンに時間がかかるという側面を明確に強調しています。これにより、ピットフォール2にスポットライトが当たります。オープンソースコンポーネントのスキャンは、継続的に行うことはできません。今日の時代にあって、ソフトウェア開発チームは、より頻繁に、より厳しい締め切りの下で新しいバージョンをリリースすることで、SDLCの俊敏性を高めようと、これまで以上に努力しています。しかし、この加速されたペースは、オープンソースのスキャナによって不本意に停止されてしまいます。自動化されたオープンソースのスキャンプロセスは、完了までに最大数週間かかることがありますが、これには落とし穴1（アラートのレビューが非常に（非常に）長い）が続きます。組織がウォーターフォール開発モデルを使用している場合でも、リリーススケジュールに大幅な遅延が生じる可能性があります。
コードのスキャンが完了するのを辛抱強く待っていたとしましょう。オープンソースのコンポーネントが、組織のポリシーに沿っていないライセンスで使用されていることがわかったらどうしますか? あるいは、深刻なセキュリティ上の脆弱性を持つコンポーネントを発見したらどうでしょうか？このような結果が遅れると、問題のあるコンポーネントの削除に集中しなければならないため、敏捷性が損なわれる可能性があります。結論から言うと、このような作業方法では、敏捷性とスピードが危険にさらされます。
落とし穴その3: セキュリティ脆弱性は時間が肝心
最後になりましたが、最後に挙げたのは、落とし穴その3「セキュリティの脆弱性」です。セキュリティの脆弱性が知られるようになったら、できるだけ早く修正することが重要であることは、潜在的な攻撃者がその脆弱性を悪用する絶好の機会であるということを、私たちは誰もが何らかの形で学ぶようになりました。これは、プロプライエタリなコードにもオープンソースコードにも当てはまります。残念ながら、スキャナベースのパラダイムでは、オープンソースの脆弱性を知るのは、次にスキャンを実行したときだけで、これはすでに説明したように、数ヶ月後になる可能性があります。さらに悪いことに、ソリューションがオンプレミスで展開されている場合は、データベースが更新されるまで、その脆弱性に気づくことができません。結論から言うと、ソリューションが継続的でない場合（オープンソースのスキャナを使用している場合、これはあなたにも当てはまります！）、あなたの顧客はずっとずっと長い間、脆弱性のままになってしまいます。
オープンソーススキャナではないなら...何が必要か？
オープンソース スキャナが導入された当初は、優れた主要なソリューションであったかもしれませんが、アプリケーションへのオープンソース コンポーネントの採用がますます増加していることや、今日の組織の敏捷性とペースに合わせて、オープンソース スキャナを採用することはできません。
オープンソースのコンポーネントを適切に管理することは、それほど面倒なことではありません。効果的で時間を節約し、最も重要なことは、オープンソースの使用状況を管理するための継続的なアプローチを提供する新しいソリューションが登場して久しいのです。最初のアジャイルなオープンソース管理ソリューションは、2011年に WhiteSource によって導入されました。実際にコードを一行ずつスキャンすることなく、リポジトリやビルド内のすべてのオープンソース コンポーネントのデジタル署名を計算できるプラグインが利用できます。これらのシグネチャは WhiteSource の包括的なデータベースと相互参照され、すべての依存関係を含むすべてのオープンソース コンポーネントを識別し、ライセンス、セキュリティ脆弱性、新しいバージョン、品質問題に関連する洞察力のある実用的な情報を提供します。
WhiteSource がこの新しいアプローチを開拓して間もなく、他の多くの企業が後に続き、このテクノロジーの背後にある膨大なメリットに気付きました。時間のかかる何千もの誤検出、長いスキャン期間、セキュリティの脆弱性に対するリスクの高い暴露ウィンドウの時代は終わりました。このソリューションの利点を以下の画像にまとめました。
アジャイルなオープンソース管理に向けて前進する時が来た
オープンソーススキャナは、敬意を持って安らかに眠る必要があることを認め、オープンソース管理を左にシフトさせるために開発された新世代のソフトウェア構成分析ツールに移行する時が来たのです。
今日のアジャイル開発環境では、オープンソースのコードスキャナに頼り続けることはできません。ウォーターフォールモデルに従っている人にとっては、新しいツールは開発チームやDevOpsチームの労力を大幅に軽減し、より多くの機能を提供し、時間の何分の一かを消費します。セネカがかつて言ったように、「すべての新しい始まりは、他の始まりの終わりから来る」。
