SOSS Fusion セッション報告

日立製作所 研究開発グループ 下沢 拓氏
2024年12月12日開催 OSSセキュリティMeetup 講演資料

Transcript

1. SOSS Fusion セッション報告 OSSセキュリティMeetup (第4回) 日立製作所 研究開発グループ 2024/12/12 下沢 拓
2. 1 SOSS Fusion (Oct 20-22, 2024) • オープンソースのセキュリティに関する、OpenSSF主催の会議 – Open Source Summit併設のSOSS Community Day (旧OpenSSF Day)は、 何度か実施しているが、単独での会議は初 • 会場 – Alpharetta Conference Center • Alpharetta, GA – 空港から35mi程度 (56km) アトランタ国際空港 (ATL) Map data ©2024 Google
3. 2 会場: Avalon @ Alpharetta • 郊外型の新規開発のショッピングモール＋アパート・住宅地
4. 3 参加者・スポンサーなど • 参加者数 : 110名前後 – 北米からの参加者が主。ヨーロッパ・アジア等からの発表者・参加者は、 Open Source Summit NAなどと比べて割合としてかなり少なかった – 会議開催一週間前から直前に無料割引券を配布しているくらいだっ たので、集客に苦労していたように思われる – セッションは、3並列と参加者規模の割に 多めであった – オープンソースセキュリティに関する総合的な 会議という目的に対しては、SOSS Community Day NA+くらいの印象 – 次回開催などは(まだ)アナウンスされず • スポンサー: 3社 – Defense Unicorns, SentinelOne, FOSSA • 期間: 2日間 – 0日目にScorecard Workshopあり
5. 4 Oct 20: OpenSSF Scorecard Workshop • OpenSSF Scorecard Workshop – メンテナ自らがScorecardを解説し、参加者が 手を動かしてコントリビューションできるように するためのワークショップ – 10人ほどの参加者 – 概要と内部構造などの解説、実際に動かしてみるなどの後はフリー議論 – 貢献ネタとしてはサイズの小さなほうから • Probeの更新 • Probeの追加 • Checkの追加 • 新しいプラットフォーム(Azure DevOps, BitBucketなど)の対応 ここまでが1PRのサイズ Raghav Kaul (Google)
6. 5 Oct 21: Keynotes • Opening Remarks (Todd Moore [Linux Foundation]) [Recording] – オープンソース全般、LFの役割に関する説明からOpenSSFの解説まで – OpenSSFのGeneral Managerが不在のため、暫定GMでLFのSVP(Community Operations)が解説 • Decoding the AI Revolution; Implications for Security and Society: AI Security Matters (Bruce Schneier) – 今のAIは「予測エンジン」である。AIの間違いについて、人と同じようなミスは人類の歴史で経験があるが、それと は違うタイプのミスについて考えていかないといけない – AIが社会に与える影響の方向性は二つ可能性（平均を良くしていくのか、最良を良くしていくのか）があり、どち らになるかは見て行かないといけない • There Is Just One Way to Do Open Source Security: Together (Marten Mickos) [Recording] – オープンソースのセキュリティのためには、関係する人々が協力するしていくことが必要 • Enshittification Was a Choice (Cory Doctorow) [Recording] – インターネットが汚染されている（広告・スパム・トラッキング・虚偽製品・・・）という話 – (健全な)競争、法規制、デジタル技術・OSSのインターオペラビリティがEnshittificationへの防止策 • Government’s Continuing Path Contributing Towards a Secure Open Source Ecosystem (Timothy Pepper [CISA]) [Recording] – CISAのオープンソースに対する活動の説明 – イノベーションを担う4つの要素（プライベートセクター・アカデミア・オープンソース・政府）の一つとして、スティア リグをし、間をつなぐ活動 – セキュリティを高める使命として、発行しているドキュメントの説明
7. 6 Oct 22: Keynotes (1) • Stop Peeing in the Pool (Dan Lorec) [Recording] – “Fauxpen source license”に対する批判 – よくある”fauxpen source license”は(OSIの)オープンソースライセンスの定義 に反している • 典型的な違反 – 1. 自由な再配布 – 5. 特定の個人・グループに対する差別 – 6. 特定の活動分野(ビジネス・学術・・・)に対する差別 – 8. 特定のプロダクトに特有なライセンス – 9. 他のソフトウェアに対する制限 – 健全なプロジェクトは、競争相手が一緒に作り上げているもの • Kubernetes: Google, RedHat, VMWare, Microsoft, IBM, Amazon.. • Linux kernel: Intel, RedHat, Linaro, Samsung, SUSE, IBM,… – オープンのような顔をするな、“Go pee in your own pool”
8. 7 Oct 22: Keynotes (2) • Back to Security Basics (Katherine Druckman [Intel]) [Recording] – オープンソースセキュリティで難しい点は多くの人が関わっていること • コードは簡単な方であり、人の関わり・共同作業が難しいところ – オープンソースのセキュアな”消費”はどうするか？ • 基本的なプロジェクトの健康さ、ガバナンス、メンテナス・リリースの仕方などの チェック • CVE Binary ToolやScorecardを動かしてみる • S2C2Fなどの枠組みも – Developers don’t owe you anything. You’re using. You owe it. • Setting the Standard (Brenton Stevens [Fannie May]) [Recording] – ファニーメイにおけるOSPOについて – 上記と同様にOSSプロジェクトをどのように評価すべきか – 健全なガバナンスの行われているプロジェクトは、貢献への信頼をもたらす
9. 8 キーノート所感 • AIの話 – オープンソース的な話に加えて、学習データやモデルに対する安全性と いうものも重要になる • オープンソースソフトウェアプロジェクトの健全さへの着目 – xz-utilsの件なども一つのきっかけと考えられる – 消費者としても、プロジェクトの健全さを評価する必要がある – （そして可能であれば、ちゃんと参加していくべき） • 政府系の話 – セキュリティということもあり、国防総省(DoD)・米軍関係の話もあり – 貢献の話もあるが、上記のように、利用にあたっての評価が必要という 話も多かった
10. 9 Sessions
11. 10 An Inside and Outside Look at the Government’s Ongoing Journey with Open Source Tech (1) • 政府機関としてのOSSに対する姿勢を紹介 • 利用におけるリスクの評価 – ライセンス、ダイバーシティ、活動の活発さ、 コミュニティとの姿勢 – 悪意あるコードの可能性 (SBOM, ツールによるスキャニング…) • イノベーションの公開 – 国防総省(DoD)は、カスタマイズしたソフトウェアの一定の割合をオープン するにすることを求めている • “Open by Default” – DoDでは、公務としてオープンソースへの貢献が許されている – DoD独自のフォークは良くないこと Austen Bryan (Defense Unicorns) Camdon Cady (US Air Force) [Slides] [Recording]
12. 11 An Inside and Outside Look at the Government’s Ongoing Journey with Open Source Tech (2) • オープンソース化できなった例 – 内部で開発していたプロジェクトの処分 – 小規模チームで10年ほど開発、ｓｖｎのまま移行できず、複数の内部環境向け リリース – 結局オープンソース化できなかった • 特定の環境でビルドしており、他の環境でビルド再現ができなかった • 環境特有の設定がソースコードとして大量に書かれていた • 開発を継続できない＝コミュニティを維持できるリソースがない – 「完成した」(done)ソフトウェアをオープンソースしてはいけない • オープンソースへの貢献の成功例 – DoDの主要なソフトウェアで、依存している商用ソフトとOSSコンポーネントで 非互換な点があった → コミュニティと協力して修正・マージ – ソフトウェアツールでの問題を発見 → GitHubでイシューをオープン、PRを作 成・マージ
13. 12 Solving Air-Gap Problems the Cloud Native Way with Zarf • Zarfの紹介 (https://zarf.dev/) – OpenSSFのSandboxプロジェクト – エアギャップ環境でのKubernetesを構築 • 解決するエアギャップ環境における課題 – ツール類を揃えるのが難しい (Docker, kubectl, OCIレジストリ・・・) – インターネット、その他ドキュメントやチャットボット等使えない環境 • レジストリ (鶏と卵問題) – K8sクラスタを作成するのにはイメージが必要→レジストリが必要 – レジストリをちゃんと動作させるにはクラスタなどが必要 • Zarf – クラスタとレジストリを二つのバイナリ(Zarf, Zarf init package)で構築 – 宣言的な設定 Austin Abro (Defense Unicorns) [Recording]
14. 13 Secure Numerical Computing is Hard: Lessons from 10 Years of Open Data Science & the Long Road Ahead • セキュアな数値計算の難しさについての紹介 • 数値計算の特徴 – データの値がアプリの正しさの基本 (⇔一般的なアプリはデータの中身より形式の変換が基本) – 性能が入力に依存する – 性能も正しさの一つの要素となる – アルゴリズムは複雑でハードウェア依存 (⇔ 一般的なアプリは比較的単純) • 多くがプログラマではなく、データアナリストや科学者によって書かれる • 現在では、Pythonが広く使われている – ネイティブ言語(C, C++等)との接続性が重要 – 過去50年のOSの課題をそのまま引きずっている • (他人の書いた)コードのコンパイルが困難 – ランタイム環境・ハードウェアに依存。他人が動作させることをあまり考慮しない – （CS以外の大学院生などが書くことが多く）動けばよいという考え Peter Wang (Anaconda) [Recording]
15. 14 • 発生した問題の例 – GCCのバグによって、インポートする順番によって演算精度が落ちる – サードパーティのライブラリが、マイナーバージョンアップデートでシンボルを 削除する – 16進文字列として、共有ライブラリが埋め込み – データ変換ライブラリがPDF出力のためにChromiumを必要とする – 日によってビルドした結果が変わるパッケージ • Conda – このような状況のもとでPython向けの標準化された環境を提供する – エンタープライズ向けに、どのようなパッケージが使われているかを管理 • 将来(AI/LLMに向けて) – 数値計算と同じような問題が存在（データの内容が重要） – ＋データポイズニングなど新たな問題 Secure Numerical Computing is Hard: Lessons from 10 Years of Open Data Science & the Long Road Ahead (2)
16. 15 The Current State of SBOMs for End Users (1) • SBOMを扱う上でのエンドユーザー側からの 問題点を提起 • SBOMを利用する必要性 – 法規的理由 (大統領令14028, FedRAMP, EU CRA) – セキュリティのため (脆弱性検知など) • 2024年の状況 – Zarf: 10個のコンテナからなる → 10個のSBOMが生成される – 脆弱性ツールで10個のSBOMをスキャンして統合するか、10個のSBOMを統合してス キャンするか – いずれにしても、どちらにするべきかという問題は2022年から変わっていないし、適 切なツールも存在しない • SBOMの規格 (SPDX, CycloneDX等) – 規格の完全性にフォーカスしている – 学術的な方向性に偏っており、「いつか必要になる」機能にこだわっている – エンドユーザーや、実用するユーザー、相互互換性を向いていない。 Eddie Zaneski (Defense Unicorns) [Slides] [Recording]
17. 16 The Current State of SBOMs for End Users (2) • 法規制 – チェック項目に留まる • 極端にいえば、空のsbom.jsonでも、手で書いたsbom.docxでもよい • ツール – 特にスタンダードなものはなく、自分で探す・作る必要がある – Cyclone DX関連でツールがいくつかあるが、out of date – syft: SBOM生成ツールのベースラインである – protobomやbomctlといったツールが生まれつつはある • （後での会話でも) syftが一番ましで、protobomが一番注目すべきものである という考え
18. 17 Current State of SBOM for End Users (3) • 発表者の考え – ガイダンスが必要 • SBOMのベストプラクティスが何か (複数のSBOM、各レイヤーのものをどう扱 うべきかなど） • リファレンス実装 • どうやって使うのかからさかのぼって考えることが必要 – SBOMの(あるべき)未来 • 単一のフォーマット • Ubiquitous & Boring • 実利用にフォーカスしたもの
19. 18 ClearlyDefined: A Crowdsourced Database of Licensing Metadata • ClearlyDefinedの紹介 (https://clearlydefined.io/) – OSIのプロジェクト • クラウドソースによるライセンスメタデータのデータベース – 利用者は間違いを訂正するリクエストを送ることで貢献できる • データの利用 – Web UI / REST APIでパッケージ名 (例: npm/npmjs/-/lodash/4.17.21)でクエリ可能 • データのキュレート – ライセンス情報が間違っている場合には、Web UI / REST APIで修正案を送ることがで きる – 内部的にはGitHubのPull Requestになり、メンテナによってレビューをされて(Acceptさ れれば)DBに反映される • GUACとの統合 – GUACからClearlyDefinedに登録されているライセンスのメタデータを利用可能 Qing Tomlinson (SAP) Lynette Rayle (GitHub) Nick Vidal (Open Source Initiative) [Recording]
20. 19 Project Copacetic: Directly Patch Container Image Vulnerabilities • Copaの紹介 (https://github.com/project-copacetic/copacetic) – CNCFのSandboxプロジェクト – コンテナイメージに対して、脆弱性があることを検知した場合に、直接「パッチレイヤー」を生 成してアップデートするツール • 既存のイメージアップデート方法 – ビルドしなおす → 時間とリソースが必要 – ベースイメージのアップデートを待つ → 予測できない。待てない場合も – アップデートコマンドを実行する • Copa – trivyによってコンテナイメージをスキャンし、脆弱性を発見した場合には、アップデートを行 い、パッチレイヤーを追加したイメージを生成する – 全てのパッケージをアップデートするという選択もできる • 制限 – アプリケーション(言語レベル)の脆弱性にのみ対応 – Windowsイメージには非対応 – 各言語のパッケージマネージャに依存 Ashna Mehrotra (Microsoft) [Slides] [Recording]