前回（No.8：GitHub Actions CI/CDで自動化）では、テストやデプロイを自動化して作業を効率化する方法を学びました。
第9回となる今回は、自動化のもう一つの柱である 「セキュリティ（DevSecOps）」 について解説します。
「ライブラリのアップデートを放置していたら、脆弱性が見つかって大騒ぎ…」
「コードの中にAWSのキーを書きっぱなしにして、不正アクセスなどの不正利用が発生した…」
こんな「エンジニアの悪夢」を、GitHubの機能を使って未然に防ぎましょう。
GitHub入門シリーズ 全10回
本記事は「GitHub入門」全10回のNo.9です。
- No.1：Git/GitHubの基本概念とGitHub導入による投資対効果(ROI)
- No.2：リポジトリとREADMEから始める
- No.3：変更を確定！コミット実行とコミットメッセージの書き方
- No.4：VS CodeでGitを使いこなす マージ・コンフリクト・便利機能
- No.5：Issue（イシュー）でタスク管理
- No.6：Pull Request（PR）とコードレビュー
- No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow
- No.8：GitHub Actions CI/CDで自動化
- No.9：Code Scanning・Dependabot セキュリティの自動化
- No.10：なぜGitHubが高パフォーマンスチームを作るのか
今回のゴール
- DevSecOps（シフトレフト）の考え方を理解する
- Dependabotでライブラリを自動更新する
- Code Scanningで脆弱性（SQLインジェクション等）を自動検知する
- 機密情報（シークレット）の正しい扱い方を学ぶ
なぜ開発者がセキュリティを気にするのか？（DevSecOps）
かつてセキュリティ診断は、開発が終わった後に専門チームが行うものでした。しかし、リリース直前に致命的な問題が見つかると、修正に膨大なコストがかかります。
そこで生まれたのが DevSecOps や Shift Left という考え方です。
開発（Dev）と運用（Ops）の中にセキュリティ（Sec）を組み込み、「コードを書いている段階（左側）」 で自動的に検査してしまおう、というアプローチです。
- 後でやる: 数年分のアップデートをまとめてやるのは大変（依存関係の地獄）
- 毎日やる: 毎日少しずつ自動でアップデートすれば、痛みは最小限
Dependabot：ライブラリの自動更新
現代の開発では、Node.jsやPythonなどの「ライブラリ（依存パッケージ）」を大量に使います。これらのライブラリに脆弱性が見つかった場合、すぐに対応する必要があります。
それを全自動でやってくれるのが Dependabot です。
何をしてくれるの？
- 使っているライブラリに新しいバージョン（または脆弱性修正版）が出たかを毎日チェック
- 自動でバージョンを上げた Pull Request（PR）を作成
- （設定すれば）CIテストが通れば自動マージも可能
設定方法
リポジトリに .github/dependabot.yml というファイルを作成するだけです。
version: 2
updates:
# npm (JavaScript/TypeScript) の設定
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily" # 毎日チェックする
open-pull-requests-limit: 10
これを入れておくだけで、翌朝には「このライブラリを更新してください」というPRが届いているはずです。
私たちはそのPRを見て、CI（自動テスト）が通っていることを確認し、マージボタンを押すだけ。これで「塩漬けライブラリ」から脱却できます。
Code Scanning：コードの健康診断
Dependabotは「外部ライブラリ」のチェックですが、Code Scanningは「あなたが書いたコード」のチェックを行います。
GitHubが開発したCodeQLというエンジンが、コードを解析し、危険なパターンを見つけ出します。
- SQLインジェクション
- クロスサイトスクリプティング（XSS）
- ハードコードされたパスワード
設定方法
- リポジトリの Security タブをクリック
- Code scanning の「Set up」をクリック
- Default setup を選択するだけでOKです（詳細設定したい場合はAdvancedを選択）
これで、PRを作るたびにセキュリティチェックが走り、脆弱性が見つかるとPR上で警告してくれます。
Secret Scanning：鍵の流出を防ぐ
初心者が一番やってしまいがちな事故。それは 「パスワードやAPIキーをコードに書いて、GitHubにPushしてしまう」 ことです。
GitHubはこれを防ぐための2つの機能を提供しています。
Secret Scanning & Push Protection
GitHubには、AWSのキーやデータベースのパスワードなどの形式を検知する機能があります。
Publicリポジトリでは標準で有効になっており、誤ってPushしようとすると 「機密情報が含まれています！」とブロック（Push Protection） してくれます。
正しい管理方法：場所に応じた使い分け
パスワードは「コード以外の場所」に置くのが鉄則です。環境に応じて適切な保管場所を選びましょう。
-
ローカル開発時：
.envファイル- 自分のPC内だけで使うファイルです
-
重要:
.gitignoreに.envを追記し、絶対にGitHubに上げないようにします
-
CI/CD（GitHub Actions）時： GitHub Secrets
- 前回紹介した通り、リポジトリ設定画面（Settings > Secrets）に登録し、暗号化して保存します
-
本番環境（クラウド）時： シークレットマネージャー
- AWSやGoogle Cloudなどのクラウドを使っている場合、サーバー内に
.envを置くのではなく、専用の管理サービスを使うのがベストプラクティスです - AWS Secrets Manager / Google Secret Manager / Azure Key Vault など
- メリット: 鍵のローテーション（定期変更）が容易になり、誰がいつアクセスしたかログも残せます
- AWSやGoogle Cloudなどのクラウドを使っている場合、サーバー内に
# 悪い例（コードに直書き）
const apiKey = "12345-secret-key";
# 良い例（コードから分離して読み込む）
const apiKey = process.env.API_KEY; // 環境変数やSecret Managerから取得
まとめ
今回は、開発を安全に進めるためのセキュリティ自動化について解説しました。
- DevSecOps: セキュリティは「最後の検査」ではなく「毎日の習慣」にする。
- Dependabot: 面倒なライブラリ更新を自動化し、負債を溜めない。
- Code Scanning: 人間が見落とす脆弱性を、ロボットに発見してもらう。
- Secrets管理: 鍵はコードに書かず、環境やクラウドの専用機能で守る。
ここまでで、Git/GitHubの操作、チーム開発のルール、自動化、そしてセキュリティまで、現場で必要な知識を一通り網羅しました。
次回はいよいよ最終回。
これまでのツールや手法を使いこなし、高いパフォーマンスを発揮するチームには、どのような 「文化」 があるのでしょうか？
「なぜGitHubが高パフォーマンスチームを作るのか」 をテーマに、シリーズを締めくくります。