Log4j脆弱性に55万件のアラート送信も――GitHubで安全なソフトウェアを作成する5つの簡単な方法とはCodeQL、Dependabot、GitHub Actionsなどを活用

GitHubは、「GitHub」のネイティブツールや機能を活用してより安全なソフトウェアを作成する5つの方法を紹介した。

» 2022年05月17日 10時25分 公開
[@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 GitHubは2022年4月22日(米国時間)、「GitHub」を使ってより安全なソフトウェアを作成する5つの方法を公式ブログで紹介した。

 「GitHubには、安全なソフトウェアの作成と提供を容易にするネイティブツールや機能が多数用意されている」と、同社は述べている。これらを使う、以下の5つの方法によってワークフローにセキュリティを組み込めば、作業速度を犠牲にすることなく、より安全なソフトウェアを簡単に作成できるとしている。

1. CodeQLをワークフローに組み込む

 GitHubの静的コード解析エンジン「CodeQL」は、コードをデータのように扱い、クエリ可能にする。既知のセキュリティ脆弱(ぜいじゃく)性パターンに対応したオープンソースソフトウェア(OSS)のクエリライブラリを使用してコードをスキャンし、潜在的な問題を特定する。

 GitHubのCI/CD(継続的インテグレーション/継続的デリバリー)プラットフォーム「GitHub Actions」で、「CodeQL Analysis」というコードスキャンワークフローを任意のGitHubリポジトリに追加することで、開発環境におけるコードスキャンを自動化できる。新しいコードをプッシュしたときや、メインブランチに変更をコミットしたときなど、ニーズに合わせて任意のタイミングでコードスキャンを実行するようにワークフローを調整できる。

GitHubのCodeQLワークフローを使ってコードの既知の脆弱性を特定(提供:GitHub

 CodeQLによるコードスキャンで使用されるクエリライブラリは、新たな脆弱性の発生に対応してOSSコミュニティーが拡充を進めている。このため、CodeQLワークフローでコードスキャンの自動実行を設定しておけば、コードを新たな脆弱性から保護できる。

2. Dependabotで全ての依存関係を最新に保つ

 GitHubの「Dependabot」は依存関係を自動的にスキャンし、GitHubの「Advisory Database」と照合し、依存関係に脆弱性が見つかった場合はアラートで知らせる。また、Dependabotのセキュリティアップデート(プルリクエスト)は、その依存関係を安全なバージョンに更新するのに役立つ。

 Dependabotは依存関係の自動バージョン更新もサポートしており、これは設定ファイルのdependabot.ymlで設定できる。Dependabotがどのように依存関係を更新するか(どのエコシステムを有効にするかなど)、どんな頻度で新しい更新を探すかなどを指定することが可能だ。

 こうしたDependabotは、CodeQLを補完するものといえる。CodeQLがコードのセキュリティ問題を検出するのに対して、Dependabotは、プロジェクトの依存関係に起因する脆弱性を検出するからだ。

 最近の例では、Javaベースのロギングツール「Apache Log4j」の脆弱性が多くのパッケージのレジストリや依存関係に影響し、業界で大きな問題となった。だが、Java用プロジェクト管理ツール「Apache Maven」とDependabotを使用しているJava開発者は、比較的容易に対応できた。

 この脆弱性が公表されると、Dependabotは、Javaの依存関係管理のためにビルド自動化システム「Apache Gradle」とMavenを使用し、この脆弱性の影響を受けるリポジトリに、Log4jパッケージを更新するようプルリクエストを出した。

 GitHubはLog4jのCVE公開に対応し、Dependabotで合計55万件のアラートを送信し、アクティブなリポジトリの約半数が、アラート送信から7日以内に問題を修正したことを確認した。また、Dependabotのバージョン更新を有効にしていた開発者は、元のプルリクエストを見逃した場合でも、自動更新の恩恵を受けることができた。

3. 保護されたブランチをリポジトリに追加する

 単独のプロジェクトでも、大規模なOSSプロジェクトでも、あるいは職場で何かを作っている場合でも、保護されたブランチを追加することで、プロジェクトのセキュリティを高めることができる。

 保護されたブランチには、次の2つの大きな効果がある。

  • 本番リリース前の環境でのテストが容易になる
  • 保護されたブランチでは、「誰がコード変更を本番環境にプッシュできるか」を制御できる

4. リポジトリでのGitHub Actionsの使い方を定義する

 OSSの世界では、誰もがどこでもGitHub Actionsを利用できる。だが、プロジェクトの全てのコントリビューターにアクセスを開放してよいわけではない。残念ながら、悪意ある人もいるからだ。

 一部のOSSコミュニティーでは、プロジェクトで悪意ある人がGitHub Actionsを使う恐れがあるので、GitHub Actionsを使える人と、リポジトリで使えるアクションを制限することが重要だ。例えば、GitHub Actionsをオフにして、初めてのコントリビューターには使わせないことで、混乱が起こるのを防げる。

 また、リポジトリで実行できるGitHubアクションを制限したり、セルフホステッドランナーで実行できるワークフローを制限したりすることもできる。これらによって、CI/CDワークフローのセキュリティをより強固にすることが可能だ。

リポジトリにおけるGitHub Actionsの権限を設定する方法(提供:GitHub

5. GitHub ActionsのGITHUB_TOKENにリポジトリレベルでの権限を設定する

 「GITHUB_TOKEN」はGitHub Actionsで、ワークフローで認証が必要なジョブにセキュリティを付加するために使用できる。これは事実上、インストールアクセスが必要なジョブごとに自動生成される、特別なアクセストークンだ。ジョブが完了すると、このトークンは自動的に失効し、リスクの可能性を低減する。

 PAT(Personal Access Token)は安全性が低いので、より安全性の高いGITHUB_TOKENの使用を検討すべきだ。

 さらに、GITHUB_TOKENを使用するメリットはもう一つある。最小ワークフローの原則に従って読み取りと書き込みの権限を制御し、リスクを軽減できることだ。次のように、その方法は2つある。

  • GitHub ActionsのYMLファイルに次の構文を追加し、ワークフロー設定において、GITHUB_TOKENの権限を直接変更する
permissions:
actions: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
issues: read|write|none
packages: read|write|none
pull-requests: read|write|none
repository-projects: read|write|none
security-events: read|write|none
statuses: read|write|none
  • 組織の設定にアクセスし、次のように、GITHUB_TOKENワークフローの権限を読み取りアクセスのみに変更する(既定では、読み取りアクセスと書き込みアクセスの両方)
GITHUB_TOKENワークフローの権限の設定(提供:GitHub

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。