Security tooling has a familiar adoption problem. The organizations that need it most — the ones scaling fast enough that their attack surface is outgrowing their process — are often the same ones that can’t justify a sales call and a signed contract just to see whether a product fits. They want to turn it on, run it against real repositories, and see what it actually finds before anyone talks pricing. GitHub just made that path available to a lot more of them.
The company raised the eligibility ceiling for self-serve GitHub Advanced Security (GHAS) trials, moving the cap from enterprises with up to 100 licenses to those with up to 300. Any GitHub Enterprise Cloud organization under that new threshold can start a 30-day trial directly from the “Billing and licensing” page in their enterprise settings, no sales conversation required. During the trial, an organization can add any number of committers and turn on both GitHub Secret Protection and GitHub Code Security across every organization it runs. If nothing is purchased by day 30, the trial simply expires.
That 100-to-300 jump sounds like a technicality, but it changes who gets to kick the tires without an approval chain. A 100-license cap puts self-serve trials mostly within reach of small teams and early-stage companies. Bump that to 300, and you’ve pulled in a much bigger band of the market: engineering organizations that are past the startup phase, running dozens of repositories, and dealing with exactly the kind of secret sprawl and dependency risk that GHAS is built to catch.
For anyone who hasn’t looked at GHAS lately, the trial covers the two pieces GitHub split out of the old bundled product last year: Code Security and Secret Protection. Code Security runs CodeQL scanning across a repository to flag vulnerable patterns and risky dependencies before they ship. Secret Protection scans for exposed credentials and API keys, and can block a pull request outright when it finds one, rather than just filing a report after the fact. Neither is new. What’s new is how many organizations can now turn both on, across every repository they own, without a purchase order in front of them first.
This isn’t GitHub’s first move to lower that friction this year. Back in May, the company let eligible admins launch a trial straight from a Secret Protection or Code Security risk assessment, instead of routing through a separate setup flow. In December, it opened trial eligibility to more Enterprise customers generally. It set a 180-day cooldown so organizations that tried GHAS once and passed could come back and try again later, rather than being locked out for good. Taken together, the pattern is consistent: GitHub keeps shortening the distance between “I’m curious about this” and “I’m actually running it against my code.”
Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, reads the change as more of a distribution play than a product one. “Widening self-serve trials is a distribution move that targets the real bottleneck in security tooling evaluations, which is usually procurement,” Ashley said. “Teams in that 100-to-300 band already carry the secret sprawl GHAS is built to find.” He also thinks the change resets what a trial actually needs to prove. “What a trial has to answer has changed. Scan-find-fix was built for code written at human speed,” he said. “Watch whether teams judge this on what it blocks at commit rather than what it reports on day 30.”
That second point is the sharper one. GHAS grew up around a scan-find-fix loop: code gets committed, a scanner catches what’s wrong, someone fixes it after the fact. That loop assumed code arriving at roughly the pace a person types it. With AI-assisted and agentic coding tools now generating a growing share of commits, a summary report on day 30 doesn’t say much about whether a tool keeps up when commits are landing faster than any one engineer can review. What Secret Protection blocks at the moment of commit — before an exposed key ever lands in a repository — is a more honest test of that than a scan tally at the end of the trial window.
There’s a practical caveat worth flagging for any team that’s been burned by “free trial” fine print before: GHAS trials are one-time-ish. An organization gets one shot, and if it lets that 30 days lapse without buying, the next attempt is 180 days out. That’s not a dealbreaker, but it does mean a team should treat the trial window as something to plan for, not something to click into on a slow afternoon. Point it at the repositories that actually matter — the ones with production traffic, the ones with the messiest dependency trees — instead of a clean demo repo that won’t tell you anything.
It’s also worth setting expectations before day one starts counting down. Thirty days sounds generous until a team accounts for the ramp-up: configuring both tools across dozens of repos, tuning out the false positives that show up in any first scan of a codebase nobody’s audited in a while, and getting enough eyes on the results to make an actual buy-or-pass decision. Teams that treat the first week as setup and the last as a decision meeting tend to get more out of a trial than ones that wait until day 25 to look at the dashboard.
None of this changes what GHAS is built to do. It still hunts down exposed secrets before they leak, and it still flags vulnerable and risky dependencies before they ship. What’s changed is who gets an easy, no-commitment way to find out whether it does that fast enough to matter — and, per Ashley, the bar for judging that just moved from the report to the moment of commit. For a mid-size engineering org that’s been putting off this evaluation because it didn’t want to sit through a sales pitch, that barrier just got a lot smaller.
