This article is part of a series on adopting GitHub Advanced Security at scale. For the previous article in this series, see "Phase 2: Preparing to enable at scale."
About pilot programs
We recommend you identify a few high-impact projects or teams to use in a pilot rollout of GHAS. This allows an initial group within your company to get familiar with GHAS and builds a solid foundation for GHAS before you roll it out to the remainder of your company.
The steps in this phase will help you enable GHAS on your enterprise, begin using its features, and review your results. If you’re working with GitHub Professional Services, they can provide additional assistance through this process through onboarding sessions, GHAS workshops, and troubleshooting as needed.
Before you start your pilot projects, we recommend that you schedule some meetings for your teams, such as an initial meeting, midpoint review, and a wrap-up session when the pilot is complete. These meetings will help you all make adjustments as needed and ensure your teams are prepared and supported to complete the pilot successfully.
If you haven't already enabled GHAS for your GitHub Enterprise Server instance, see "Enabling GitHub Advanced Security for your enterprise."
Piloting all GitHub Advanced Security features
You can quickly enable security features at scale with a security configuration, a collection of security enablement settings you can apply to repositories in an organization. You can then further customize GitHub Advanced Security features at the organization level with global settings. See "About enabling security features at scale."
Piloting code scanning
To enable code scanning on your GitHub Enterprise Server instance, see "Configuring code scanning for your appliance."
You can quickly configure default setup for code scanning across multiple repositories in an organization using security overview. For more information, see "Configuring default setup for code scanning at scale."
You can also choose to enable code scanning for all repositories in an organization, but we recommend configuring code scanning on a subset of high-impact repositories for your pilot program.
For some languages or build systems, you may need to instead configure advanced setup for code scanning to get full coverage of your codebase. However, advanced setup requires significantly more effort to configure, customize, and maintain, so we recommend enabling default setup first.
If your company wants to use other third-party code analysis tools with GitHub code scanning, you can use actions to run those tools within GitHub. Alternatively, you can upload results, which are generated by third-party tools as SARIF files, to code scanning. For more information, see "Integrating with code scanning."
Piloting secret scanning
GitHub scans repositories for known types of secrets, to prevent fraudulent use of secrets that were committed accidentally.
To enable secret scanning for your GitHub Enterprise Server instance, see "Configuring secret scanning for your appliance."
You need to enable secret scanning and push protection for each pilot project. You can do this with a security configuration. For more information, see "Creating a custom security configuration."
If you plan to configure a link to a resource in the message that's displayed when a developer attempts to push a blocked secret, now would be a good time to test and start to refine the guidance that you plan to make available.
Start to review activity using the push protection metrics page in security overview. For more information, see "Viewing metrics for secret scanning push protection."
If you have collated any custom patterns specific to your enterprise, especially any related to the projects piloting secret scanning, you can configure those. For more information, see "Defining custom patterns for secret scanning."
To learn how to view and close alerts for secrets checked into your repository, see "Managing alerts from secret scanning."
For the next article in this series, see "Phase 4: Create internal documentation."