GitHub Team customers can now start a self-serve GitHub Advanced Security trial directly from an organization’s Overview, Licensing, or completed Risk Assessment page. The September 30 change removes the sales-assisted step for eligible Team organizations and opens a 30-day window to evaluate GitHub Code Security and GitHub Secret Protection on private repositories.
The trial is useful only if the team defines its questions before starting the clock. GitHub’s setup documentation says an organization owner must launch it, and the organization must not already have paid or metered Advanced Security. A prior trial does not automatically disqualify an organization, but GitHub permits no more than one previous trial and requires that it ended at least 180 days earlier.
What the trial actually unlocks
GitHub’s product documentation divides Advanced Security into two products. Code Security includes CodeQL code scanning, Copilot Autofix, dependency review, security campaigns, and premium Dependabot controls. Secret Protection includes secret scanning, push protection, custom patterns, delegated bypass controls, and AI-detected secrets.
During the trial, license fees for those products are waived for private repositories. That does not make every associated resource free. GitHub says workflows that consume GitHub Actions minutes still draw from the organization’s included allowance, and overages are billed at the standard rate. Features using AI credits can also create usage-based charges. A team evaluating code scanning across many private repositories should watch both the security results and the Actions usage graph.
A practical 30-day sequence
Start with a small, representative repository set rather than enabling everything at once. One application with frequent pull requests, one repository with legacy dependencies, and one codebase that handles credentials can expose different parts of the product. Record the baseline: existing code-scanning alerts, known dependency findings, current secret-scanning coverage, and average pull-request cycle time.
In the second stage, enable prevention controls—not only retrospective scans. Push protection should be judged by whether it catches realistic credential patterns before they enter the repository, how often developers request bypasses, and whether delegated review reaches the right people. For Code Security, track which alerts are actionable, which fixes developers accept, and how much workflow time the scans consume.
Use the final week to review operational fit. A raw alert total does not show whether the tool improved the development path. More useful evidence includes blocked secrets, time to triage code-scanning findings, pull requests delayed by policy, accepted Autofix suggestions, and the recurring Actions cost implied by the pilot workload.
What happens at expiration
GitHub states that the trial expires automatically after 30 days if the organization does not purchase. Code Security and Secret Protection features are then disabled for private repositories. The expiration date and current use are visible on the Licensing page, so the purchase decision should be scheduled before day 30 rather than left to the final hours.
This release changes access, not the underlying products. The engineering question is whether a Team organization can now collect enough repository-specific evidence to make a buying decision without first entering a sales process. The answer depends less on the number of alerts found than on whether prevention, triage, workflow cost, and ownership can be measured inside the trial window.
