New: Pressure test your SOC 2 report against buyer requirements
Free check
Free SAST, SCA, secrets, and GitHub config scanning for public repositories. No credit card. Works with SecretSpec for better secrets management.
By Tim Olshansky, Co-Founder, Fencer
It is far harder to add secrets management later than to do it at the beginning. People still get it wrong constantly: secrets committed to source, secrets in unprotected environment variables, secrets sitting in a cloud console. I wrote that in the field guide because I kept watching it happen, including on teams I ran.
When the repository is public, that mistake is worse. A leaked API key in a public repo is not a private incident. Anyone can find it. A CVE in a dependency does not care that you aren't charging for the software.
Open source maintainers get the same class of findings a well-funded security team gets, minus the budget. The commercial tools that would help are priced for the companies consuming the code, not the people writing it.
So we made the parts of Fencer that belong on public code free.
Fencer for Open Source is a free plan. No credit card. It doesn't expire.
If the repository is public, and stays public, you get:
PR scanning and daily scheduled scans are run by default. Popular projects with a lot of committers stay on the plan.
Eligibility is enforced in the product. If a public repo goes private, SAST, SCA, and secrets stop. Historical findings stay. New scans resume when it's public again.
In April, William Woodruff at Astral wrote how they harden uv, ruff, and the rest of that stack against the class of attack that hit Trivy and LiteLLM. The pattern is familiar. A public repo. A workflow trigger that is a little too privileged. An Action pinned to a moving tag. A publish token sitting at the org level. Then a compromised job ships a malicious release, and every project that trusted the tag is in the blast radius.
That is not a code bug. It is a configuration problem. Public open source is the easiest place to find it, because the workflows and the org settings are sitting there.
Fencer's SaaS scan on a connected GitHub org looks for those misconfigurations. Dangerous triggers like pull_request_target and workflow_run. Actions pinned to a tag instead of a full commit SHA. Workflows that start with write permissions. Publish secrets at the repo or org level instead of a deployment environment. Missing branch protection on main. Tags that can be rewritten. Releases that can be swapped after they ship. Long-lived registry tokens instead of Trusted Publishing. Caching on a release job. A release environment one compromised account can approve alone.
We also look at the adjacent issues that turn those settings into an incident: leaked credentials in the public repo, known-vulnerable or malicious dependencies, a public image that already has a CVE.
The Astral post is a good field guide for what "good" looks like. The point of putting this on the free plan is that you should not have to read that post and then click through every org setting by hand.
Fencer's job on secrets is detection. Connect a public repo, scan it, tell you the file, the line, how long the credential has been sitting there, and what to do next. That work is necessary. It is also downstream of the actual mistake.
The mistake is treating environment variables and .env files as a secrets strategy.
That pattern is how keys end up in git, in CI logs, in a laptop backup, and, in 2026, in the working directory of an AI agent that was never supposed to see them. The whole "secrets in environment variables" pattern was already weak. With agents in the picture, a secret on disk is a secret the agent can read.
SecretSpec separates what an application needs from where those values live. You commit a secretspec.toml. The values stay in a provider: a system keyring, 1Password, a cloud secret manager, whatever that environment actually uses. Same declaration in development, CI, and production. Different storage. Apache 2.0, built in the open by the Cachix team.
Most teams skip that split. They pick a vault, or they don't, and the application still learns about secrets by reading the process environment. SecretSpec makes the declaration the source of truth instead.
The overlap is public open source, and secrets specifically.
SecretSpec is doing outreach across open source projects to raise the bar on how those projects declare and store secrets. Where that work turns up credentials that already leaked, Fencer is the scanner we want pointed at the repo: SAST, SCA, secret detection, and the GitHub misconfigurations that make a leak into a supply-chain incident, for free.
When a maintainer is ready to stop using .env as the system of record, SecretSpec is what we will point them at.
Finding problems was never the hard part. Doing the work is. For public open source, that work starts with seeing what's already in the repo, then stopping the next key from landing in git.
If you maintain a public project, start with Fencer for Open Source: connect the public repos, and look at what SAST, SCA, secrets, and GitHub configuration scanning actually finds. Then read SecretSpec before you add the next API key to a dotenv file.
Secrets hygiene eats maintainer hours. This gives them back.
