The Importance of Free Secret Detection, Even for Private Repositories

Introduction: The Good, Bad, and Ugly about secrets scanning in source code

The good thing about secrets scanning is that has become a commodity. Popular open-source initiatives, such as GitLeaks, Git-Secrets and Detect-Secrets, have become embedded in the development lifecycle as a required Pull Request check prior merging code and kicking off CI/CD pipelines.

The bad thing about these scanners is that most of them introduce a tremendous volume of false positives, which results in alert fatigue for anyone responsible for reviewing them.

The ugly is that secrets scanning needs to be individually integrated into each repository. Any configuration drift or newly created repositories require manual adjustment. Commercial tools can ease the process by acting as an app to make it an easy-button solution, but the scanning is limited to public repositories only..

Secret scanning metrics that actually matter

Category	Meh	Nice	Woot Woot!
Coverage	Integrate an open-source project as a Pull Request check on each repository, separately.	Integrate a product as a Pull Request check on each repository, centrally.	Install an application with visibility across all repositories and branches in the organization.
Findings Management	Manage findings in a configuration file.	Manage findings centrally via basic rules, e.g. ignore a specific path.	Manage findings centrally with pre-defined and advanced rules, e.g. automatically ignore certificates in a folder with the word examples.
Secrets Validation	Regex-based.	Regex-based, complemented by validation.	Regex-based, complemented by context from validation, e.g. the user behind the secret iam::1234:user/GitGoat.
Risk Mitigation	General error message on a failed Pull Request check.	Alert user on a new commit in any branch when it is pushed to Git.	Alert user on a new commit in any branch when it is pushed to Git and require an action within a given time. If not acted upon within the time frame, take more proactive action, e.g., kickoff an incident.

Metrics that are just “Meh”

Count of secret types: most of us will focus on access to production data and workflows.
Any false positives metric: all secrets must be valid. Users should choose which ones are relevant.

Other “Nice” metrics

Breadth of scanning: Scan secrets through all historical commits across all branches is a good feature that can find secrets that were not rotated, but only removed from the main branch.
On prem: on-premises secret detection may be important for certain companies, mainly to these that host an on-premises version of their Source Code Management (SCM) tools.

Secrets scanning needs to be free!

The problem with most security and monitoring tools is that companies charge you for visibility in a “single pane of glass” but don’t actually address the risks you face or reduce your total cost of ownership (TCO) across your developer tool stack.

At Arnica, we are taking a different approach. Visibility is free! Free forever for everyone and for every deterministic piece of code we run whether you are identifying secrets on public or private repositories, observing excessive permissions to source code, or even identifying which repository branches have misconfigured CODEOWNERS.