GHAS

公表内容DB のアクセスキーを含むコードが GitHub 上で公開。2017年12月から2022年9月まで露出。第三者のデータアクセスは未確認。

GitHub の対策Secret Protection ↗：コードと履歴のキーを検出。Push protection ↗：対応する secret の push をブロック。検出範囲は形式と設定に依存。

公表内容漏えいした GitHub 認証情報でリポジトリをコピーされた。コード内の認証キーとパスワードを無効化し、再発行。

GitHub の対策Secret Protection ↗：侵害前にコード内の認証情報を検出して rotate。Push protection で対応 secret の追加を防ぐ。初期侵入ではなく侵害後のアクセス拡大を抑える。

公表内容動画変換処理のコマンドインジェクション。実際の送信件数は不明。

GitHub の対策Code Security / CodeQL ↗：対応コードで、この種の入力処理の弱点を検出。

公表内容メールアドレスが漏えい。第三者製ソフトの脆弱性は検知時点でベンダー未把握。

GitHub の対策Dependabot ↗：対応依存関係の既知の脆弱性が対象。未知の脆弱性を防ぐものではない。

やることEnterprise → Policies → Advanced Security → Policies タブ → dropdown を Allow for selected organizations にして許可する org だけ残す

なぜ先に禁止しても既に有効な repo は無効化されない。止められるのは追加のリポジトリだけなので、配った後では手遅れ

効く相手repository administrator だけ。org owner と security manager はポリシーに関係なく有効化できる

止まるgit push・GitHub UI 上のコミット・ファイルアップロード・REST API 経由のリクエスト

止まらないgit pull・git clone・git fetch。「secret に引っかかって pull できなくなる」は誤解

デフォルトwrite 権限を持つ全員が理由を選んで bypass 可能。ただしアラート + 監査ログ + owner へのメールが必ず残る

絞るにはconfiguration の Bypass privileges を Specific actors に(= delegated bypass)。指定外の人は申請 → 承認フロー(申請は 7 日で失効)

いつ走るdefault / protected branch への push のたび・同ブランチ宛て PR の作成とコミットのたび(fork からの PR は除く)・週 1 回のスケジュール

コスト全社展開でいちばん効いてくる要因。CodeQL 対応言語を含まない repo はスキャンも Actions 分も 0

注意code scanning 自体は merge をブロックしない

設定場所Policies → Repository → Rulesets → Require code scanning results

ブロック条件指定 severity のアラート検出・解析が実行中・ツールがそのリポジトリで未設定

落とし穴CodeQL 未設定の repo に当てるとアラート 0 件でも全 PR がブロック

Evaluate とはブロックせず記録だけ取るお試しモード。Rule Insights ページで「Active だったら何が弾かれたか」を確認できる。残りは Active(即適用)と Disabled(無効)

やることPolicy → Use as default for newly created repositories を設定。Code scanning は Enabled with advanced setup allowed を選ぶと既存の CodeQL workflow を壊さない

効く範囲新規リポジトリのみ。既存リポジトリには一切効かない

やることConfigurations 一覧 → Apply to → All repositories without configurations

enterprise 限定この選択肢は enterprise レベルでのみ表示。既に config が当たっている org を壊さず、未設定の repo だけカバーできる

強制適用Policy → Enforce configuration で Enforce for repository and organization owners を選ぶと、適用した既存 repo でも org / repo 管理者による上書きを防げる(全 repo に強制するなら Apply to → All repositories)

対象archived リポジトリにも適用される(secret scanning は archived でも動くため)

repo 単位org のリポジトリ一覧から、enterprise で作成した configuration も選択した repo に適用できる。選択する画面が org レベルなだけで、config の作成元は org に限定されない

やり方Organization → Settings → Advanced Security → Configurations → Repositories タブで repo を絞り込んで選択 → Apply configuration → org または enterprise の config を選ぶ → Apply

どちらが優先enterprise 側の変更が org configuration と衝突すると repo は removed_by_enterprise になり org config が外れる。enterprise が優先

基本ルールマージや重ね掛けはなく、1 リポジトリに紐づく configuration は常に 1 つだけ。別の config を当てると Detach 不要で後から適用した方が上書きする（Detach の仕様 ↗）。なお Detach だけでは有効化済みの機能は OFF にならない

優先と競合既存 repo に enterprise で All repositories を当てると org の設定を上書きする（All repositories without configurations なら維持）。新規 repo のデフォルトは enterprise-enforced な enterprise デフォルトが org デフォルトに優先（Enforcement の仕様 ↗）。競合時は removed_by_enterprise になる（ステータス一覧 ↗）

Org で確認Organization → Settings → Advanced Security → Configurations → Repositories タブで、各 repo の適用中 configuration 名とステータス（Enforced, Removed, No configuration）を確認し、Configuration status で絞り込める（診断手順 ↗）

API で確認1 repo の適用 config は GET /repos/{owner}/{repo}/code-security-configuration（REST API ↗）、ある config の対象 repo 一覧は GET /orgs/{org}/code-security/configurations/{configuration_id}/repositories（enterprise 版も同様、REST API ↗）