GitHubでブランチを作成する方法を学ぶことは最初のステップです。しかし、GitHubでブランチを安全にマージする方法を習得することは、どのブランチにとっても同様に重要です。 GitHub ワークフロー。そこで、この記事では、まず、プロセス全体を順を追って説明します。 GitHubでブランチを作成する方法 そしてあなたに見せる GitHubでブランチをマージする方法 安全にマージする方法についても説明します。また、問題が見つかった場合にマージをキャンセルする方法、そして最後に、Xygeni がメインブランチに問題が取り込まれる前にすべての問題を検出するのにどのように役立つかについても説明します。
順を追って説明していきましょう。
1. GitHubでブランチを正しく作成する方法
安全なワークフローはすべて、GitHubでブランチを作成することから始まります。これにより、開発者は本番コードに影響を与えることなく、機能、修正、または実験を分離して実行できます。
GitHubでブランチを作成するには：
1. リポジトリに移動します
2. ブランチセレクターのドロップダウンをクリックします。
3. 新しい支店の名前を入力してください
4。 クリック ブランチを作成する
ここから、新しいブランチの準備が整いました。これでコードをプッシュしたり、変更を共同で行ったり、最終的には pull requestこれはGitHubの基本的な操作ですが、安全な開発環境を構築するための基盤となります。
重要なのは、GitHubでブランチを作成するたびに、それは再現可能で保護されたワークフローの一部であるべきだということです。
2.スキャン Pull Requests マージ前に自動的に
GitHubでブランチを作成し、レビューの準備をしたら、次のステップはGitHubでブランチを安全にマージする方法を理解することです。各ブランチのGitHubプッシュは自動チェックをトリガーする必要があります。しかし、マージする前に、 確認する それ このコードは脆弱性を導入しません。 単一の危険な commit アプリケーションを公開できます。 leak secretまたは、重要なインフラを破壊する。
コードをメインブランチにマージすることは、影響の大きい操作です。適切なチェックが行われていない場合、次のような深刻な結果を招く可能性があります。
- ゼロデイ脆弱性 生産段階に滑り込む
- 知られている CVE オープンソースパッケージを通じて導入
- ハードコードされた秘密 リポジトリにプッシュされました
- インフラストラクチャの設定ミス それはあなたの防御力を弱める
- 悪意のあるコードまたは改ざんされたコード 依存関係を通じて入る
ここでXygeniが真価を発揮するのです。
使用することにより、 GitHubアクショントリガーすることができます Xygeniによる自動スキャン 開発者が開くたびに pull request 保護されたブランチにマージします。GitHub の保護されたブランチとは、変更をマージする前に特定のチェックや承認が必要となるブランチのことです。
Xygeniは、 最新の実行 pull request ワークフロー 提案された変更のセキュリティ体制を検証する。これには、以下の項目の確認が含まれる。 コード、依存関係、秘密、および CI/CD 構成ブランチ全体が再スキャンされるわけではなく、最新のワークフロー結果を使用してポリシーを適用し、安全でないマージをブロックします。
これらのスキャンは、コードが安全で本番環境に対応できることを検証します。検出されるのは以下のとおりです。
統合 これらのチェックを早期に行うことで GitHubでブランチを作成してマージの準備をするときは、毎回次のようにします。 完全な可視性と制御.
以下に簡略化した設定例を示します。
on: pull_request: branches: [ main ] jobs: xygeni-scan: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Xygeni Scanner uses: xygeni/xygeni-action@3.2.0 with: token: ${{ secrets.XYGENI_TOKEN }}3. 安全でないマージをブロックする Guardrails
GuardrailsGitHubでブランチを作成したり、GitHubでブランチをマージしようとしたときに、安全な変更のみがメインブランチに反映されるようにします。Xygeniは、 マージされる内容を完全に制御できます。事前定義が可能ですcisセキュリティポリシーとリスク許容度に合わせてカスタマイズされたルール。例：
- 重大な秘密の場合はブロックしてください （AWSキー、トークンなど）が見つかりました
- ビルドに失敗する もし 新たな高リスク オープンソースパッケージが導入されました
- 非承認 pull requests それ 機密性の高いパスを変更する ような
.github/workflows/,infrastructure/またはsecrets.env - マージを防止する もし ダウングレードにより再導入される 既知の 脆弱性
- ブロック CI/CD 構成の変更 適切にラベル付けされていない限り
- マージを停止します SAST 高または高を検知します 重要な問題
- より厳格な適用 Guardrails 生産部門 開発の柔軟性を維持しながら
これらのルールは、自動化されたゲートキーパーとして機能します。これにより、チームは安全なものだけをマージでき、予期せぬ事態や手動レビュー、土壇場での緊急対応を回避できます。
ガードレールルールの例：
guardrail block_critical_secrets on secrets when severity = critical then @fail()視覚フィードバック Dashboard
透明性を確保するため、Xygeniはガードレールの状態に関する最新の評価結果を表示します。
- まず第一に緑色のアイコンは、すべての政策が可決されたことを意味します。
- 対照的に赤いアイコンは、ガードレールの条件が1つ以上違反されたことを示します。
その結果、開発者とセキュリティチームは、CIログを詳しく調べなくても、マージがブロックされた理由を即座に把握できるようになります。
実際の例 Dashboard:
例えば、リポジトリに保護されたブランチがないとしましょう。これはよくある設定ミスで、開発者がプッシュできてしまいます。 commit検証なしに情報を入手するのは、重大なリスクです。
Xygeni はこれを自動的に検出してフラグを立てます 署名済み_commits 問題の下で CI/CD カテゴリー。 の dashboard ハイライト：
- 重大度： ハイ
- 種類： 署名されました Commits
- 説明： このリポジトリには保護されたブランチはありません
- ステータス： 店は開いています
したがって、このような豊富なコンテキスト情報を含むフィードバックにより、チームはXygeniのユーザーインターフェースから、リスクを迅速に特定し、その影響を理解し、是正措置を講じることができます。
カスタマイズ 執行行動
あなたは常にコントロールできます。どの程度厳しくするかを選択してください。 Guardrails する必要があります：
--fail-on=critical: ブロックは重篤な所見がある場合にのみ統合される--never-fail: ラン Guardrails 実施前にポリシーをテストするためのドライランモード
次回GitHubでブランチを作成するときは、 Guardrails すでにそこにあり、あなたの pipeline そして、ポリシーを自動的に適用します。
GitHubアプリが安全かどうかを知るにはどうすればよいですか？
GitHubアプリをインストールする前に、その評価方法を学びましょう。
4. リスクが発見された場合、GitHubでマージを自動的にキャンセルする
リスクが検出された場合、マージはキャンセルされます。この安全対策により、すべてのブランチのGitHubプロジェクトが保護され、GitHubにおけるブランチのマージに関するベストプラクティスが徹底されます。
XygeniはGitHubのUIに直接統合されます。リスクが検出された場合：
- GitHubではチェックが失敗したと表示されています。
- GitHubの保護機能によりマージが阻止されます
- マージキューは安全でないコードをスキップします
秘密、CVE、または危険 CI/CD パターン、結果は同じです。 GitHubでマージがキャンセルされました そして、審査対象としてフラグが立てられました。
Xygeniでは詳細な結果も確認できます。
- 各支店のセキュリティ状況
- マージがブロックされた理由
- 完全なスキャン履歴
- プロジェクトページでは、ガードレールの状態が緑色（合格）または赤色（不合格）のアイコンで表示されます。
この視覚的なフィードバックにより、開発者とセキュリティチームは自信を持って対応できます。さらに詳細な情報が必要な場合は、各問題から重要度、タグ、場所、および対策に関するガイダンスが記載されたドキュメントへのリンクが提供されます。
要約：安全なものだけを統合する
まとめると、GitHubでブランチを作成した後、安全にマージする方法は次のとおりです。
- GitHubのUIを使用してブランチを作成します。
- あらゆるイベントで自動スキャンをトリガーします pull request Xygeniと共に
- 安全でないマージをブロックするには Guardrails
- より詳細な制御を行うには、サーバー側の監査ポリシーを使用してください。
- GitHubで何らかのエラーが発生した場合にマージをキャンセルする
- Xygeniで全ての結果を視覚化する dashboard
リポジトリ保護に関するその他のベストプラクティスについては、こちらをご覧ください。 GitHubセキュリティに関するよくある質問：すべての開発者が知っておくべきこと.
マージは基本的な操作ですが、安全に実行するには、真の可視性と自動化が必要です。Xygeniを使えば、単にコードをマージするだけでなく、信頼もマージできます。
GitHubのすべてのブランチを自信を持って保護する
見落とされた一つの問題 pull request 主要拠点を危険にさらす可能性があります。従来のスキャナーは、実行が遅すぎたり、重大なリスクを見逃したり、効果的なポリシーを適用できなかったりすることがよくあります。
そのため、GitHubのブランチを保護するには、スキャンするだけでは不十分なのです。
Xygeniは真の執行力を提供します。 時 pull request 保護されたブランチをターゲットにすると、Xygeni は最新の実行を分析します CI/CD ワークフロー全体を再スキャンするのではなく、最新の結果を評価し、コード、依存関係、シークレット、ワークフロー構成におけるセキュリティ上の問題をチェックします。単に警告が表示されるだけでなく、セキュリティも保護されます。
何が違うのか:
- 完全なコンテキスト検証： Guardrails 重要度、悪用可能性、ブランチメタデータなどの豊富なコンテキストを使用してポリシーを適用する。
- GitHubとの連携機能が組み込まれています。 スキャンから強制適用まで、すべてがGitHubのワークフロー内でネイティブに実行されるため、カスタムスクリプトや連携コードは必要ありません。
- サーバー側の監査： サーバ側 Guardrails アップロード後に結果を検証し、外部に第2の制御層を追加する pipeline.
Xygeniは、CI設定に頼ってすべてを捕捉するのではなく、自動化されたポリシーベースの検出を適用します。cisイオンは、メインブランチに到達する前に処理されます。
マージは基本的な操作ですが、安全に実行するには、真の可視性と自動化が必要です。Xygeniを使えば、リポジトリを保護するだけでなく、GitHubのすべてのブランチを確実に保護できます。
