Introduction
Preventing security incidents is less costly and less disruptive than responding to them. By proactively hardening your environment on GitHub, you reduce your exposure to threats such as exploited credentials, unauthorized access, and supply chain attacks.
This guide primarily focuses on the protective measures you can apply across organizations that are part of an enterprise on GitHub Enterprise Cloud. To trial GitHub Enterprise Cloud, see GitHub Enterprise Cloud の試用版の設定.
Many of GitHub's security features mentioned here, such as security configurations, branch rulesets and access controls, can be configured at both the organization level or enterprise level.
Immediate actions
These are high-impact actions you can take right now to establish a security baseline across an organization.
- Establish security coverage
- Tighten controls
- Review and restrict access
- Run a secret risk assessment
Establish security coverage
Ensure that GitHub's GitHub Advanced Security tools are active across all repositories. Rather than enabling tools one by one, you can create and apply a security configuration, which is a collection of security settings that can be applied to repositories across your organization or enterprise in a single action.
A strong configuration might include:
- Secret scanning and push protection to detect secrets that have already been committed to your codebase, and prevent new secrets from being pushed. Leaked credentials are one of the most common causes of security breaches.
- Code scanning to identify vulnerabilities and coding errors in your source code before they reach production.
- Dependabot alerts and Dependabot security updates to notify you of known vulnerabilities and malware in your dependencies and automatically open pull requests to update vulnerable dependencies.
See カスタム セキュリティ構成を作成する (organizations) and Enterprise 用のカスタム セキュリティ構成の作成 (enterprises).
Tighten controls
GitHub gives you a range of controls that govern what can happen in your repositories and organization. Ensuring these controls are configured appropriately is essential for reducing risk.
Protect critical branches with rulesets
Rulesets let you define protection rules for branches and tags across one or more repositories. Use them to enforce requirements such as pull request reviews and status checks (such as automated security scans). This can help prevent unauthorized changes from reaching production code, including changes from compromised accounts.
See 組織内のリポジトリのルールセットを作成する (organizations) and Enterprise でルールセットを使ってコード ガバナンスを適用する (enterprises).
Control who can bypass push protection
When you enable push protection, contributors who attempt to push a detected secret are blocked but, by default, they have the option to bypass the block. Delegated bypass requires that bypass requests pass through a review and approval cycle, so no bypass can happen without an explicit, audited decision.
Enforce dependency review on pull requests
The dependency review action lets you catch vulnerable dependencies before they're merged, by surfacing known vulnerabilities in a pull request's dependency changes. Like push protection for secrets, it acts as a gate rather than an after-the-fact alert. You can enforce dependency review on pull requests across your organization.
See 依存関係の確認について and organization 全体で依存関係レビューを実施する.
Review and restrict access
Access that was appropriate when it was granted may no longer be necessary. Regularly reviewing who and what has access to an organization reduces the risk of unauthorized actions.
Audit member access and follow the principle of least privilege
Ensure that members of organizations have only the access they need. Remove members who no longer require access, downgrade roles where broader permissions aren't justified, and review outside collaborator access. Overly permissive access increases the blast radius of any compromised account.
If the default roles are more permissive than an organization requires, you can create custom roles that grant only the specific permissions each team needs. This is especially valuable for organizations adopting a zero trust security model.
See 企業で必要なロールの識別.
Review authorized applications
OAuth apps and GitHub Apps that are installed in an organization can access data. Review the list of authorized applications and remove any that are no longer needed or no longer trusted. Stale integrations represent an often-overlooked attack surface.
See インストールされている GitHub Apps の確認と変更 and OAuth アプリのアクセス制限について.
Restrict network access with IP allow lists
For organizations on GitHub Enterprise Cloud, if your organization operates from known network ranges, configure an IP allow list to restrict access to GitHub resources from those ranges only. This adds a layer of defense against compromised credentials being used from unexpected locations.
See 組織に対する許可 IP アドレスを管理する and IP 許可リストを使用して Enterprise へのネットワーク トラフィックを制限する.
Near-term actions
These actions are also important for your security posture, but may require more preparation and coordination before you can roll them out.
Strengthen authentication
Weak or compromised authentication is one of the most common causes of account takeover. Requiring strong authentication across your organization significantly reduces this risk.
Require two-factor authentication (2FA) for all members, which ensures that a compromised password alone is not enough to access an account. Before enforcing the requirement, communicate with your organization so members have time to set up 2FA.
Organizations on GitHub Enterprise Cloud can go further by enforcing single sign-on (SSO), which centralizes authentication through your identity provider.
See Organization で 2 要素認証を要求する and SAML シングルサインオンを使うアイデンティティおよびアクセス管理について.
Harden your GitHub Actions workflows
GitHub Actions workflows often have access to secrets, deployment credentials, and write permissions to your repository. Without careful configuration, a compromised or malicious action can exfiltrate data or inject malicious code.
Explicitly declare workflow permissions
By default, workflows may receive broad permissions through the GITHUB_TOKEN. Explicitly declare the minimum permissions each workflow needs using the permissions key in your workflow files. This limits the damage that a compromised workflow step can cause.
Pin third-party actions to commit SHAs
When you reference a third-party action by tag (for example, v1), the tag can be moved to point to different code. Pinning actions to a full commit SHA ensures you always run the exact code you reviewed and approved. This protects against supply chain attacks where a tag is hijacked.
Restrict which actions can run
Configure policies at the organization or enterprise level to control which actions are allowed to run. You can limit actions to those created by GitHub, actions from verified creators, or a specific allowlist.
For more information on all of these practices, as well as additional secure use practices for GitHub Actions specifically, see セキュリティで保護された使用に関するリファレンス.
Ongoing security practices
These practices should become part of your regular operational rhythm.
- Monitor your security posture with security overview
- Run regular security campaigns to reduce security debt
- Continue to audit access and permissions
- Keep dependencies up to date
- Rotate secrets and enforce expiration
Monitor your security posture with security overview
Security overview gives you a centralized view of an organization's and enterprise's security landscape. Use it to track which repositories have security features enabled and identify repositories with open alerts, so that emerging risks don't go unnoticed.
See セキュリティの概要について.
Run regular security campaigns to reduce security debt
Over time, security alerts can accumulate. Security campaigns let you organize and prioritize remediation efforts, assign groups of alerts to developers (with the help of Copilot-generated fixes), or assign alerts directly to Copilot.
Security campaigns are available to organizations on GitHub Team or GitHub Enterprise Cloud with GitHub Advanced Security enabled. See セキュリティ キャンペーンの作成と管理.
Continue to audit access and permissions
As people join and leave an organization, and as projects evolve, access requirements change. Schedule periodic reviews of:
- Organization membership and roles.
- Outside collaborator access.
- Repository-level permissions and team assignments.
- Authorized OAuth and GitHub Apps.
This ensures that access remains aligned with the principle of least privilege, even as your organization changes.
Keep dependencies up to date
Vulnerable dependencies are a common entry point for attackers. Dependabot can automatically open pull requests to update dependencies with known vulnerabilities, but those pull requests still need to be reviewed and merged promptly.
Establish a process for triaging and merging Dependabot pull requests so that security updates don't stall.
See Dependabot 自動トリアージ ルールについて and 依存関係の更新に関するPull Requestを管理する.
Rotate secrets and enforce expiration
The longer a credential exists, the more opportunity there is for it to be exposed or stolen. Where possible:
- Set expiration dates on personal access tokens.
- Rotate secrets on a regular schedule.
For information on managing tokens, see 個人用アクセス トークンを管理する and トークンの有効期限と取り消し.
Next steps
- Even with strong preventive controls in place, security incidents can still occur. There are several critical tools and response processes that you should ensure are set up in advance. See Preparing for a security incident.