実装がすべてではない、開発者の周りから考える Web プロダクトセキュリティ

by Big Buddha

Slide 1

Slide 1 text

実装がすべてではない開発者の周りから考える Web プロダクトセキュリティ～セキュリティ・ミニキャンプ 2023 in 広島～

Slide 2

Slide 2 text

自己紹介 ● 山川森羅（OJI/oldbigbuddha） ● 放送大学 ● コミュニティ活動が好き ● VTuber が好き ● 株式会社 Flatt Security でインターン

Slide 3

Slide 3 text

私とセキュリティ・キャンプ ● セキュリティ・ミニキャンプ in 愛知 2019 受講生 ● セキュリティ・キャンプ全国大会 2022 オンライン B受講生 ● セキュリティ・ミニキャンプオンライン 2022オンラインチューター ● セキュリティ・ミニキャンプ in 広島 2023 講師 ← イマココ

Slide 4

Slide 4 text

講義の流れ 1. Introduction: 「サイバーセキュリティ」ってなに？ 2. たった一文字で情報漏洩？設定ミスが引き起こす惨劇 3. サプライチェーン理解への第一歩 4. まとめ

Slide 5

Slide 5 text

講義の方針知識よりも考え方を重要視する講義です 🙅講義を受けたからから〇〇に詳しくなった 🙆講義を受けた上で周りを見返してみたら気にすることが増えた最年少の意見であろうと最年長の意見であろうと講師の意見であろうと等しくひとつの「意見」であり発言者の属性に思考の優劣は存在しません

Slide 6

Slide 6 text

Introduction 「サイバーセキュリティ」ってなに？

Slide 7

Slide 7 text

自分なりの「サイバーセキュリティ」を考えてみよう

Slide 8

Slide 8 text

以下の問に自分なりの答えを考えてみよう Q.「サイバーセキュリティ」ってなんですか？

Slide 9

Slide 9 text

グループワーク ● 自分なりの「サイバーセキュリティ」を言語化しよう（目安: 5分） ○ 注意: 一般的な定義は使わない ○ ヒント: “Security”の語義を英英辞典（Oxford Learner's Dictionaries など）で調べてみよう ● 自分なりの「サイバーセキュリティ」をチームに共有しよう ● チームなりの「サイバーセキュリティ」を kintone へ投稿しよう終了時刻: １０:21

Slide 10

Slide 10 text

kintone を見る時間

Slide 11

Slide 11 text

個人的な「サイバーセキュリティ」サイバー空間で「起こるかもしれない悪いこと」から自分や周りを守ること

Slide 12

Slide 12 text

個人的な「サイバーセキュリティ」の背景引用: Security という英単語から考えるサイバーセキュリティ https://speakerdeck.com/oldbigbuddha/security-toiuying-dan-yu-karakao-erusai basekiyuritei

Slide 13

Slide 13 text

「サイバー空間で起こるかもしれない悪いこと」の例 ● オンラインサービスで情報漏洩が発生し、個人情報が流出した ● オンラインバンキングのフィッシング詐欺に引っかかり、全財産を窃盗されてしまった ● 自分が管理してるHPが改ざんされてしまい、脅迫文を掲示するために悪用されてしまった ● SNS アカウントが乗っ取られ、スパム活動に利用されたため周りからの信頼を失ってしまった ● サーバーが乗っ取られて本来閲覧できる情報が見れなくなった、もしくはその逆 ● などなど……

Slide 14

Slide 14 text

「サイバー空間で起こるかもしれない悪いこと」の例まとめると: 情報漏洩、情報の改ざん、乗っ取り・なりすまし ● オンラインサービスで情報漏洩が発生し、個人情報が流出した ● オンラインバンキングのフィッシング詐欺に引っかかり、全財産を窃盗されてしまった ● 自分が管理してるHPが改ざんされてしまい、脅迫文を掲示するために悪用されてしまった ● SNS アカウントが乗っ取られ、スパム活動に利用されたため周りからの信頼を失ってしまった ● サーバーが乗っ取られて本来閲覧できる情報が見れなくなった、もしくはその逆 ● などなど……

Slide 15

Slide 15 text

個人的な「サイバーセキュリティ」情報漏洩、情報の改ざん、乗っ取り・なりすましのような攻撃から自分自身や身の回りを守ること

Slide 16

Slide 16 text

【再掲】講義の方針 ● 知識よりも思考を重要視する講義です ○ 󰢄講義を受けたからから〇〇に詳しくなった ○ 󰢎講義を受けた上で周りを見返してみたら気にすることが増えた ● 最年少であろうと年上であろうと講師であろうと等しくひとつの「意見」であり発言者の属性に思考の優劣は存在しません

Slide 17

Slide 17 text

一般的な「サイバーセキュリティ」　サイバーセキュリティという言葉は、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。　機密性とは、ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保すること。完全性とは、情報が破壊、改ざん又は消去されていない状態を確保すること。可用性とは、情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することをいいます。引用: サイバーセキュリティって何？｜国民のためのサイバーセキュリティサイト https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/intro/intro_security.html

Slide 18

Slide 18 text

情報の機密性ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保すること。情報の機密性が確保されている例 ● 会社の内部情報は決められた従業員だけしか閲覧することができない ● EC サイトの購入履歴や発送先住所、支払い情報は本人しかみることができない ● 未公開のイベント情報を一般人は知ることができない

Slide 19

Slide 19 text

情報の完全性情報が破壊、改ざん又は消去されていない状態を確保すること。情報の完全性が確保されている例 ● 受信したメールが改ざんされていない ● 過去に編集したデータがその時の状態で閲覧することができる ● ダウンロードしてきたソフトウェア・アプリが開発者が意図したファイルである（何者かによって差し替えられたふぁいるではない）

Slide 20

Slide 20 text

情報の可用性情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保すること情報の可用性が確保されている例 ● イベント参加者が正しいスケジュールを見たいときに確認できる ● プロジェクト関係者が開発中の資料を見たいときに閲覧できる ● 正しい抽選結果を抽選参加者が確認できる

Slide 21

Slide 21 text

選考課題振り返り

Slide 22

Slide 22 text

● 「視野を広げる」という講義に合わせて設計した課題 ○ 見直すと自分なりの新しいアイディアがでるかも？ ● 全国大会を意識した課題 ○ 明確な答えは存在しないからこそ、自分の考えを明確にすることが重要そもそもなぜ振り返る？

Slide 23

Slide 23 text

1. 攻撃者はログイン中の PC からどのような情報を抜き取ることができるでしょうか？窃取できる情報の種類だけではなく、なぜその情報を攻撃者が PC から窃取できるかも合わせて答えてください。 2. 利用者のアカウント情報をデータベースに保存する際に気を付けることを調べて答えてください。本問題には LLM を利用せず、Web 上の情報や本、自らの体験などを元に回答を考えてください。講師が設定した選考課題（一部省略）

Slide 24

Slide 24 text

1. 攻撃者はログイン中の PC からどのような情報を抜き取ることができるでしょうか？窃取できる情報の種類だけではなく、なぜその情報を攻撃者が PC から窃取できるかも合わせて答えてください。 → 普段利用している情報端末にどのような情報が保存されているかを考え直してもらうための問題 2. 利用者のアカウント情報をデータベースに保存する際に気を付けることを調べて答えてください。本問題には LLM を利用せず、Web 上の情報や本、自らの体験などを元に回答を考えてください。 → 前問を少し発展させた問題、作問当時は DB にパスワードを保存する際の手法で一部の界隈が盛り上がっていたので情報収集しやすいかなと思った OJI が設定した選考課題（一部省略）

Slide 25

Slide 25 text

1. 攻撃者はログイン中の PC からどのような情報を抜き取ることができるでしょうか？窃取できる情報の種類だけではなく、なぜその情報を攻撃者が PC から窃取できるかも合わせて答えてください。 A. 日常的にしている会話のログ（Slack、Discord、メール）、ログイン中のオンラインサービスのセッション情報、Password Manager に登録している情報 2. 利用者のアカウント情報をデータベースに保存する際に気を付けることを調べて答えてください。本問題には LLM を利用せず、Web 上の情報や本、自らの体験などを元に回答を考えてください。 A. パスワードにユーザーごとに決められた値（Salt）を付与した上で、任意の回数ハッシュ化（Stretching）を行う、DB外に保存している値（Papper）を鍵とした暗号化を行うことによりオフライン攻撃に対してさらに強くなる講師的な回答（これが絶対的な正答ではない）

Slide 26

Slide 26 text

たった一文字で情報漏洩？設定ミスが引き起こす惨劇

Slide 27

Slide 27 text

まずは体験してみよう

Slide 28

Slide 28 text

● 会員制のサイトを運営するために nginx を利用 ● nginx の設定を行った際にひと文字だけ抜けていた ● 設定上問題がないため、nginx は正常に動作する ● 設定ミスのためエイリアストラバーサルによる攻撃余地を生んでしまい、アクセスログを窃取された ● URL には一部機密情報（トークンやフォームの入力内容など）が含まれていたため、個人情報が漏洩したシナリオ

Slide 29

Slide 29 text

● Apache と並んで世界的に有名な Web サーバー ● Web サイトの三割に nginx が使われている nginx について引用: https://w3techs.com/technologies/overview/web_server

Slide 30

Slide 30 text

● nginx の設定ミスによって発生する有名な脆弱性 ● ディレクトリトラバーサルの一種で、外部から見れないはずのファイルを取得できる ● 他のトラバーサル攻撃に比べて親ディレクトリしか参照できないという制約がある ● 具体的な話はハンズオン用の資料に書いたので、読みながら理解しよう！エイリアストラバーサルについて

Slide 31

Slide 31 text

ハンズオン ● kintone で共有される資料を参考にエイリアストラバーサルを体験しよう ● 少しでも分からなくなったら手をあげよう ○ 講師やチューターが助けに行くよ ● 早く終わった人はグループ内の人を助けてあげてね終了時刻: 11:15

Slide 32

Slide 32 text

グループワーク ● 以下のお題に対して自分の意見をチームで共有する ○ この設定ミスが再発しないためにするべきことはなにか？ ■ 偶数チーム ○ 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ■ 奇数チーム終了時刻: 11:35

Slide 33

Slide 33 text

kintone を見る時間

Slide 34

Slide 34 text

個人的な回答 ● この設定ミスが再発しないためにするべきことはなにか？ ○ gixy などの検査ツールを用いる ○ このミスが発生したことを文書化する（会社などの場合） ● 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ○ nginx の設定以外で防ぐことは可能！ ○ 機密情報を URL に含めない ■ どうしても含める必要があれば短命なものにする ○ alias に設定するディレクトリを独自のものにする ■ 例: /data/images など

Slide 35

Slide 35 text

yandex/gixy yandex/gixy: Nginx configuration static analyzer https://github.com/yandex/gixy

Slide 36

Slide 36 text

OJI はなぜこの答えにたどり着いたのか？ ● この設定ミスが再発しないためにするべきことはなにか？ ○ gixy などの検査ツールを用いる ○ このミスが発生したことを文書化する（会社などの場合） ● 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ○ nginx の設定以外で防ぐことは可能！ ○ 機密情報を URL に含めない ■ どうしても含める必要があれば短命なものにする ○ alias に設定するディレクトリを独自のものにする ■ 例: /data/images など

Slide 37

Slide 37 text

これは何 ● この設定ミスが再発しないためにするべきことはなにか？ ○ gixy などの検査ツールを用いる ○ このミスが発生したことを文書化する（会社などの場合） ● 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ○ nginx の設定以外で防ぐことは可能！ ○ 機密情報を URL に含めない ■ どうしても含める必要があれば短命なものにする ○ alias に設定するディレクトリを独自のものにする ■ 例: /data/images など

Slide 38

Slide 38 text

Defense in depth （多層防御）

Slide 39

Slide 39 text

“ 「多層防御」（DiD）とは、複数のセキュリティ製品や手法を駆使して、組織のネットワーク、Webプロパティ、リソースを保護するサイバーセキュリティ戦略のことです。多層防御とは？| 階層型セキュリティ | Cloudflare https://www.cloudflare.com/ja-jp/learning/s ecurity/glossary/what-is-defense-in-depth/

Slide 40

Slide 40 text

Defense in depth（多層防御） ● 複数の防御策を取ることでより堅牢に様々な攻撃から情報を守る戦略 ● ひとつの場所ですべてを守りきるのではなく、その層に適した守り方を重ねたほうが良い ● セキュリティを考える上で基本的な考え方のひとつ

Slide 41

Slide 41 text

多層防御的な発想 ● この設定ミスが再発しないためにするべきことはなにか？ ○ gixy などの検査ツールを用いる ○ このミスが発生したことを文書化する（会社などの場合） ● 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ○ nginx の設定以外で防ぐことは可能！ ○ 機密情報を URL に含めない ■ どうしても含める必要があれば短命なものにする ○ alias に設定するディレクトリを独自のものにする ■ 例: /data/images など

Slide 42

Slide 42 text

プラクティス・ナビ IPA 情報処理推進機構 https://www.ipa.go.jp/security/economics/practice/practices/Practice213/

Slide 43

Slide 43 text

これは何？ ● この設定ミスが再発しないためにするべきことはなにか？ ○ gixy などの検査ツールを用いる ○ このミスが発生したことを文書化する（会社などの場合） ● 万が一ミスが発生した場合、情報漏洩は本当に防げないのか？ ○ nginx の設定以外で防ぐことは可能！ ○ 機密情報を URL に含めない ■ どうしても含める必要があれば短命なものにする ○ alias に設定するディレクトリを独自のものにする ■ 例: /data/images など

Slide 44

Slide 44 text

ポストモーテム

Slide 45

Slide 45 text

“ ポストモーテムとは、インシデント、その影響、それを軽減または解決するために取られた措置、根本原因、およびインシデントの再発を防止するためのフォローアップ措置についての書面による記録である。 Google - Site Reliability Engineering https://sre.google/sre-book/postmortem-culture/ DeepL 訳

Slide 46

Slide 46 text

ポストモーテム ● インシデント（事件、事故）が発生した際に根本原因を十分に理解・解析し、チーム向けにまとめた文書 ● 過ちを批判するのではなく、徹底的に分析し次へ繋げていく姿勢が大事 ● セキュリティに直接的に紐づく手法ではないが過去から学ぶ姿勢・文化は非常に重要

Slide 47

Slide 47 text

danluu/post-mortems: A collection of postmortems. Sorry for the delay in merging PRs! https://github.com/danluu/post-mortems

Slide 48

Slide 48 text

README に書いてある目次、Config Error もある設定ミスが Facebook と Instagramのダウンを引き起こした Facebook Outage Deep Dive | ThousandEyes https://www.thousandeyes.com/blog/faceb ook-outage-deep-dive

Slide 49

Slide 49 text

前半まとめ ● 設定ミスなど運用の問題によって情報漏洩などは起こりえることを体験した ● それを防ぐためには根本的な原因を分析し仕組み的な対策をするのが良い ● 高度で複雑化した現代においてはひとつで何でもカバーではなく、多層防御が大切

Slide 50

Slide 50 text

前半戦、お疲れ様でした！（少し休憩）

Slide 51

Slide 51 text

後半戦スタート！

Slide 52

Slide 52 text

サプライチェーン理解への第一歩

Slide 53

Slide 53 text

Q. 鎖の強度はどこで見る？ C₁、C₂、C₃ …… 1. 一番小さい値（min(C₁, C₂, C₃, …)） 2. 平均値（average(C₁, C₂, C₃, …)） 3. 合計値（sum(C₁, C₂, C₃, …)） 4. 一番大きい値（max(C₁, C₂, C₃, …)）

Slide 54

Slide 54 text

Q. 鎖の強度はどこで見る？ C₁、C₂、C₃ …… 1. 一番小さい値（min(C₁, C₂, C₃, …)） 2. 平均値（average(C₁, C₂, C₃, …)） 3. 合計値（sum(C₁, C₂, C₃, …)） 4. 一番大きい値（max(C₁, C₂, C₃, …)）鎖の中で一番脆い部分が鎖全体の強度！

Slide 55

Slide 55 text

現実世界も鎖と同じ企画準備作成運搬・・・連なりが途切れちゃうとすべてが止まる

Slide 56

Slide 56 text

サプライチェーン（Supply Chain）

Slide 57

Slide 57 text

サプライチェーンの概念図生産者消費者へ届けるための任意のプロセス消費者色々な要素が連なっている色々な要素へ依存している

Slide 58

Slide 58 text

サプライチェーンの概念図生産者消費者正常正常正常正常正常インシデント一箇所でも問題が起こると供給が止まる

Slide 59

Slide 59 text

現実世界で考えてみよう

Slide 60

Slide 60 text

自動車で考えてみる ● 自動車は一箇所で作られるわけではない ● まずは顧客がお店で注文をする ● お店が製造会社へ発注する ● 製造会社は工場で生産するために、大きな部品を発注する ● 発注された部品メーカーは更に別のメーカーへ部品・素材を発注する ● 場合によっては更に別のメーカーへ発注する

Slide 61

Slide 61 text

自動車で考えてみる製造メーカー部品メーカー素材・部品メーカーお店へ車

Slide 62

Slide 62 text

どこかでインシデントが発生すると？製造メーカー部品メーカー素材・部品メーカーお店へインシデント車

Slide 63

Slide 63 text

どこかでインシデントが発生すると？製造メーカー部品メーカー素材・部品メーカーお店へインシデント部品作れん…… 車

Slide 64

Slide 64 text

どこかでインシデントが発生すると？製造メーカー部品メーカー素材・部品メーカーお店へインシデント部品作れん…… 車作れん…… 車

Slide 65

Slide 65 text

どこかでインシデントが発生すると？製造メーカー部品メーカー素材・部品メーカーお店へインシデント部品作れん…… 車作れん…… 車来ない…… 車

Slide 66

Slide 66 text

どこかでインシデントが発生すると？製造メーカー部品メーカー素材・部品メーカーお店へインシデント部品作れん…… 車作れん…… 車来ない…… 車を注文したのになかなか来ない……

Slide 67

Slide 67 text

サプライチェーンの概念図生産者消費者正常正常正常正常正常インシデント一箇所でも問題が起こると供給が止まる

Slide 68

Slide 68 text

「サイバーセキュリティ」とどう関係する？

Slide 69

Slide 69 text

サプライチェーンとセキュリティ ● サプライチェーンの脆弱な部分へのサイバー攻撃 ○ 組織向け情報セキュリティ10大脅威 2023 第2位 ○ 2020年時点では4位、どんどん順位が上がってる ● ソフトウェアサプライチェーン ○ ソフトウェアにも「サプライチェーン」が存在している ○ 全国大会へ行くと関連講義が受けれるかも？

Slide 70

Slide 70 text

Slide 71

Slide 71 text

最近あったサプライチェーン攻撃トヨタの工場を止めたサイバー攻撃　サプライチェーン攻撃のリスクが露呈 | 日経クロステック（xTECH） https://xtech.nikkei.com/atcl/nxt/mag/nc/18/092400133/030900072/

Slide 72

Slide 72 text

何が起こった？ ● トヨタ自動車のサプライヤー（部品メーカー）がマルウェアの被害を受けた ● 被害を受けた会社は社内サーバーを全停止 ● トヨタ自動車が持つ「サプライチェーン」の一箇所でインシデントが発生したことにより、他の生産ラインも一時ストップ ● この影響により1万3千台以上の生産が見送りになった

Slide 73

Slide 73 text

自動車サプライチェーン製造メーカー部品メーカー素材・部品メーカーお店へ車

Slide 74

Slide 74 text

みんなもサプライチェーンを調べてみよう

Slide 75

Slide 75 text

グループワーク ● サプライチェーンについて調べてみよう！ ● 調査のとっかかり ○ どのような業界でサプライチェーンが存在している？ ○ サプライチェーンが止まってしまった事件は？ ○ どういう対策が提案されている？ ● グループで調べて、kintone にまとめよう！終了時刻: HH:MM

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

把握しきれない依存先 ● エディタ ● 開発補助ツール ● ビルドツール ● ライブラリ ○ ライブラリが依存しているライブラリが依存している(ry ● クラウド ● 開発者に必要なオンラインサービス ● more and more……

Slide 79

Slide 79 text

ソフトウェアで考えてみる開発者ライブラリ・ツールオンラインサービスライブラリ・ツール利用者の元へソフトウェア

Slide 80

Slide 80 text

最近も悪意あるライブラリが発見された悪意のあるPythonパッケージ27種を確認、日本も被害の可能性 | TECH+（テックプラス） https://news.mynavi.jp/techplus/article/20231120-2823025/

Slide 81

Slide 81 text

ソフトウェアサプライチェーン開発者ライブラリ・ツールオンラインサービスライブラリ・ツール利用者の元へソフトウェアここらへん

Slide 82

Slide 82 text

技術者はどう対応していけば良い？ ● ソフトウェアサプライチェーン攻撃は近年活発化 ● ここ2年ほどで対策を考えられてきているが、まだ一般化はしていない（まさにこれからの話題） ● 細かいお話はここでは割愛 ○ 気になる人は目指せ全国大会！ ● 自分で調べるならキーワードはここらへんかも？ ○ SLSA、sigstore、OpenSSF、CI/CD

Slide 83

Slide 83 text

後半まとめ ● サプライチェーンという捉え方をお伝えした ● 現実世界ではすでにサプライチェーンに対する攻撃が始まっている ● 特に「ソフトウェアサプライチェーン」はここ数年で出てきた超ホットな話題

Slide 84

Slide 84 text

講義まとめ ● 運用ミス、サプライチェーンなど実装とは関係ない部分に注視してシステムが攻撃される余地をお話しました ● 既知の脆弱性への対策はもちろん必須ですが、技術者としてなにを気をつけないか？を自分なりに考えることは非常に大切です ● 皆さんの「世界を見る目」が少しでも変わればこの講義を受講した価値があると思います

Slide 85

Slide 85 text

長時間の受講お疲れ様でした！小竹さんの講義もお楽しみに😁

Slide 86

Slide 86 text

※ これから先は没になったスライドですほとんど未完成ですので、参考程度に……

Slide 87

Slide 87 text

色々な文脈で使われるサプライチェーン ● 製造業サプライチェーン ● 産業サプライチェーン ● ソフトウェアサプライチェーンサプライチェーン対策のための国内投資促進事業費補助金（METI/経済産業省） https://www.meti.go.jp/covid-19/supplychain/ サプライチェーン｜用語集｜物流事例・お役立ち情報｜大和物流株式会社 https://www.daiwabutsuryu.co.jp/useful/words/supply-chain

Slide 88

Slide 88 text

色々な文脈で使われるサプライチェーン ● 製造業サプライチェーン ● 産業サプライチェーン ● ソフトウェアサプライチェーン SLSA • Supply-chain Levels for Software Artifacts https://slsa.dev/

Slide 89

Slide 89 text

2020年頃から急増ソフトウェアサプライチェーン攻撃の歴史 Watch - メモリも暗号化してソフトウェアサプライチェーンリスクを防ぐ方法について https://cloudonair.withgoogle.com/events/security-summit/watch?talk=d2-05 昔から存在はしていた

Slide 90

Slide 90 text

様々な組み合わせによって実現されるモダンな環境ソースコードビルド/デプロイ実行環境開発者様々なライブラリ・ツール依存依存依存依存依存依存

Slide 91

Slide 91 text

ソースコードビルド/デプロイ実行環境開発者様々なライブラリ・ツール依存依存依存依存依存依存どこ気にすればええねん

Slide 92

Slide 92 text

近年出てきた「フレームワーク（= 考え方）」 ● Supply-chain Levels for Software Artifacts（SLSA） ○ 個人、企業を問わず活用できるチェックリスト及びツール群 ● Secure Supply Chain Consumption Framework (S2C2F) ○ OSS を消費（利用）する場面に注目したフレームワーク ● CIS Software Supply Chain Security Benchmark ○ まだ GitHub に関するチェックリストしか存在しない CIS 自体は色々な分野のベストプラクティスを提供していることで有名

Slide 93

Slide 93 text

Slide 94

Slide 94 text

SLSA による脅威が発生しえる箇所の定義 SLSA • Supply chain threats https://slsa.dev/spec/v1.0/threats-overview

Slide 95

Slide 95 text

SLSA が開発現場へもたらすもの ● ソフトウェアサプライチェーンに関する共通認識・語彙 ● For 生産者: ベストプラクティスやチェックリスト ● For 消費者: ソフトウェアの信頼度 ○ SLSA がセキュリティレベルを段階的に定めている

Slide 96

Slide 96 text

SLSA の原則 ● Trust platforms, verify artifacts ○ プラットフォームを信頼し、成果物を検証する ● Trust code, not individuals ○ 個人ではなくコードを信頼する ● Prefer attestations over inferences ○ 推測ではなく証明を優先する

Slide 97

Slide 97 text

過去の事件と SLSA の脅威モデル ● SolarWinds 事件 ○ “Compromise Build Process”（ビルドプロセスへの侵害） ○ ● CodeCov 事件 ○ “Upload modified package”（ビルド成果物とは異なるパッケージ） ● 他の6つのモデルも現実の事件と照らし合わせながら紹介されている