Exploring your enterprise trial of code scanning

This guide assumes that you have planned and started a trial of GitHub Advanced Security for an existing or trial GitHub enterprise account, see Planning a trial of GitHub Advanced Security.

Introduction

Code scanning and dependency analysis work in the same way in public repositories and in private and internal repositories with GitHub Advanced Security enabled. In addition, GitHub Advanced Security enables you to create security campaigns where security specialists and developers can collaborate to effectively reduce technical debt.

This article focuses on how you can combine these features with enterprise-level controls to standardize and enforce your development process.

Refine your security configurations

In contrast to secret scanning, where a single security configuration is typically applied to all repositories, you probably want to fine-tune the configuration of code scanning for different types of repositories. For example, you might need to create additional configurations so that:

• Code scanning uses runners with a specific label to apply to repositories that require a specialized environment or that use private registeries.
• Code scanning is "Not set" to apply to repositories that need to use advanced setup or that require a third-party tool.

For your trial, it's simplest to create a primary enterprise-level security configuration and apply it to your test repositories. Then you can create any additional security configurations you need and apply them to a subset of repositories selected using code language, custom property, visibility, and other filter options. For more information, see Enabling security features in your trial enterprise and 删除自定义安全配置.

Provide access to view results of code scanning

By default, only the repository administrator and the organization owner can view all code scanning alerts in their area. You should assign the predefined security manager role to all organization teams and users who you want to access the alerts found during the trial. You may also want to give the enterprise account owner this role for each organization in the trial. For more information, see 管理组织中的安全管理员 and 使用组织角色.

Evaluate and refine results from the default setup

The default setup for code scanning runs a set of high confidence queries. These are chosen to ensure that, when you roll out code scanning across your whole codebase, developers see a limited set of high quality results, with few false positive results.

You can see a summary of any results found in the organizations in your trial enterprise in the Code security tab for the enterprise. There are also separate views for each type of security alert, see 查看安全见解.

If you don't see the results you expect for code scanning, you can update default setup to run an extended query suite for repositories where you expected to find more results. This is controlled at the repository level, see 编辑默认设置配置.

If the extended suite still fails to find the results you expect, you may need to enable advanced setup so you can customize the analysis fully. For more information, see 关于代码扫描的工具状态页 and 配置代码扫描的高级设置.

Enforce automated analysis of pull requests

There are three different types of automated analysis of pull requests built into GitHub:

• Code scanning analysis uses queries to highlight known bad coding patterns and security vulnerabilities. Copilot Autofix suggests fixes to problems identified by code scanning.
• Dependency review summarizes the dependency changes made by the pull request and highlights any dependencies with known vulnerabilities or that do not meet your development standards.
• Copilot code review uses AI to provide feedback on your changes with suggested fixes where possible.

These automated reviews are a valuable extension to self-review and make it easier for developers to present a more complete and secure pull request for peer review. In addition, code scanning and dependency reviews can be enforced to protect the security and compliance of your code.

Code scanning analysis

When code scanning is enabled, you can then block merges into important branches unless the pull request meets your requirements by creating a code ruleset for the enterprise or organization. Typically, you would require that results from code scanning are present and that any important alerts are resolved.

• Type of ruleset: Branch.
• Require code scanning results: Enable to block merging until results are successfully generated for the commit and the reference the pull request targets.
• Required tools and alert thresholds: Define the level of alerts that must be resolved before a pull request can be merged for each code scanning tool you use.

As with all rulesets, you can control exactly which organizations (enterprise-level), repositories, and branches it acts on and also define roles or teams who can bypass the rule. For more information, see 关于规则集.

Dependency review

When GitHub Advanced Security and dependency graph are enabled for a repository, manifest files have a rich diff view which shows a summary of the dependencies that it adds or updates. This is a useful summary for human reviewers of the pull request but does not provide any control of which dependencies are added to the codebase.

Most enterprises put automatic checks in place to block the use of dependencies with known vulnerabilities or unsupported license terms.

1. Create a private repository to serve as a central home where you can store reusable workflows for the enterprise.
2. Edit the actions settings for the repository to allow all private repositories in the enterprise to access workflows in this central repository, see Allowing access to components in a private repository.
3. In the central repository, create a reusable workflow to run the dependency review action, configuring the action to meet your business needs, see 配置依赖项评审操作.
4. In each organization, create or update branch rulesets to add the new workflow to the required status checks, see 在整个组织内强制实施依赖项审查.

This allows you to update the configuration in a single location, but use the workflow in many repositories. You may want to use this central repository to maintain other workflows. For more information, see 重新使用工作流.

Copilot review

By default, users request a review from Copilot in the same way as they do from human reviewers. However, you can update or create an organization-level branch ruleset to automatically add Copilot as a reviewer to all pull requests made to selected branches in all or selected repositories. For more information, see 使用 GitHub Copilot 代码评审.

Copilot leaves a review comment on each pull request it reviews, without approving the pull request or requesting changes. This ensures that its review is advisory and will not block development work. Similarly, you should not enforce the resolution of suggestions made by Copilot because AI suggestions have known limitations, see 负责任地使用 GitHub Copilot 代码评审.

Define where Copilot Autofix is allowed and enabled

Copilot Autofix helps developers understand and fix code scanning alerts found in their pull requests. We recommend that you enable this feature for all repositories to help developers resolve alerts efficiently and increase their understanding of secure coding.

There are two levels of control:

• Enterprises can allow or block use of Copilot Autofix throughout the enterprise using the "Code security" policy, see: 强制实施企业的代码安全性和分析策略.
• Organizations can enable or disable Copilot Autofix for all organization-owned repositories in the "Global settings" for the organization, see 配置组织的全局安全设置.

Engage developers in security remediation

Security campaigns provide a way for security teams to engage with developers to remediate security technical debt. They also provide a practical way to combine education in secure coding with examples of vulnerable code in code that your developers are familar with. For more information, see 关于安全性活动 and 大规模处理和解决安全警报的最佳做法.

Provide a secure development environment

The development environment has many components. Some of the most useful features for scaling and standardizing a secure development environment in GitHub are:

• Security configurations: define the setup of security features for the enterprise, an organization, a subset of organization repositories, or new repositories, see Refine your security configurations.
• Policies: protect and control use of resources for the enterprise or an organization, see 为企业实施策略.
• Rulesets: protect and control branches, tags, and pushes for an organization, a subset of organization repositories, or a repository, see 创建组织中存储库的规则集.
• Repository templates: define the security workflows and processes needed for each type of environment, see 创建模板仓库. For example, each template might contain a specialized:
  • Security policy file defining the company's security stance and how to report any security concerns.
  • Workflow to enable Dependabot version updates for package managers used by the company.
  • Workflow defining advanced setup for code scanning for supported development languages where the default setup results are not enough.

In addition, when a developer creates a repository from a template they must define the value of any required custom properties. Custom properties are very useful for selecting a subset of repositories that you want to apply configurations, policies, or rulesets to, see 管理企业中仓库的自定义属性.

Next steps

When you have finished exploring these options and secret scanning features, you are ready to test your discoveries so far against your business needs, and then explore further.

Further reading

• GitHub Actions 的安全强化
• 为企业实施策略
• 治理人员如何在企业中使用仓库
• Enforce GitHub Advanced Security at Scale