GitHubは、「GitHub」のネイティブツールや機能を活用してより安全なソフトウェアを作成する5つの方法を紹介した。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
GitHubは2022年4月22日(米国時間)、「GitHub」を使ってより安全なソフトウェアを作成する5つの方法を公式ブログで紹介した。
「GitHubには、安全なソフトウェアの作成と提供を容易にするネイティブツールや機能が多数用意されている」と、同社は述べている。これらを使う、以下の5つの方法によってワークフローにセキュリティを組み込めば、作業速度を犠牲にすることなく、より安全なソフトウェアを簡単に作成できるとしている。
GitHubの静的コード解析エンジン「CodeQL」は、コードをデータのように扱い、クエリ可能にする。既知のセキュリティ脆弱(ぜいじゃく)性パターンに対応したオープンソースソフトウェア(OSS)のクエリライブラリを使用してコードをスキャンし、潜在的な問題を特定する。
GitHubのCI/CD(継続的インテグレーション/継続的デリバリー)プラットフォーム「GitHub Actions」で、「CodeQL Analysis」というコードスキャンワークフローを任意のGitHubリポジトリに追加することで、開発環境におけるコードスキャンを自動化できる。新しいコードをプッシュしたときや、メインブランチに変更をコミットしたときなど、ニーズに合わせて任意のタイミングでコードスキャンを実行するようにワークフローを調整できる。
CodeQLによるコードスキャンで使用されるクエリライブラリは、新たな脆弱性の発生に対応してOSSコミュニティーが拡充を進めている。このため、CodeQLワークフローでコードスキャンの自動実行を設定しておけば、コードを新たな脆弱性から保護できる。
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のバージョン更新を有効にしていた開発者は、元のプルリクエストを見逃した場合でも、自動更新の恩恵を受けることができた。
単独のプロジェクトでも、大規模なOSSプロジェクトでも、あるいは職場で何かを作っている場合でも、保護されたブランチを追加することで、プロジェクトのセキュリティを高めることができる。
保護されたブランチには、次の2つの大きな効果がある。
OSSの世界では、誰もがどこでもGitHub Actionsを利用できる。だが、プロジェクトの全てのコントリビューターにアクセスを開放してよいわけではない。残念ながら、悪意ある人もいるからだ。
一部のOSSコミュニティーでは、プロジェクトで悪意ある人がGitHub Actionsを使う恐れがあるので、GitHub Actionsを使える人と、リポジトリで使えるアクションを制限することが重要だ。例えば、GitHub Actionsをオフにして、初めてのコントリビューターには使わせないことで、混乱が起こるのを防げる。
また、リポジトリで実行できるGitHubアクションを制限したり、セルフホステッドランナーで実行できるワークフローを制限したりすることもできる。これらによって、CI/CDワークフローのセキュリティをより強固にすることが可能だ。
「GITHUB_TOKEN」はGitHub Actionsで、ワークフローで認証が必要なジョブにセキュリティを付加するために使用できる。これは事実上、インストールアクセスが必要なジョブごとに自動生成される、特別なアクセストークンだ。ジョブが完了すると、このトークンは自動的に失効し、リスクの可能性を低減する。
PAT(Personal Access Token)は安全性が低いので、より安全性の高いGITHUB_TOKENの使用を検討すべきだ。
さらに、GITHUB_TOKENを使用するメリットはもう一つある。最小ワークフローの原則に従って読み取りと書き込みの権限を制御し、リスクを軽減できることだ。次のように、その方法は2つある。
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
Copyright © ITmedia, Inc. All Rights Reserved.