Q2 Product Roundup – Making secrets detection programs a reality for the enterprise

Rolling out an organization-wide secrets detection and remediation program can be a complex undertaking for security and engineering teams. Proof of Concept exercises and initial pilots are great for sizing up the problem of secrets sprawl, assessing a vendor, and defining incident response workflows. But all such efforts should eventually lead to the deployment of secrets detection for every contributing developer, and by extension, for every code commit.

Let's take a look at some of the challenges awaiting software-driven organizations of thousands of developers and how we're addressing them with our latest feature releases.

Challenge #1: Dev Experience makes or breaks

Challenge: Developers are taking greater ownership of the day-to-day application security issues, but let's not forget that their mantra is to get things done and that any tool or process getting in their way will be rightfully ignored. Getting the developer experience right is essential for the successful adoption of secrets scanning in their daily workflows.

Answer 1: The GitGuardian CLI, ggshield, has undergone a major overhaul to reduce friction in developer onboarding. After installing ggshield (version 1.12.0 and above), the developer can run the following command to get started.

$ ggshield auth login

This kicks off a browser-based authentication flow, where the developer can log in to an existing workspace (personal or company-owned) or sign up for a new one. In the background, GitGuardian will silently provision a personal access token and store it in the local environment.

That’s it. No additional steps are needed to start scanning local repositories, file directories, and Docker images. If they wish to take things further and trigger scans on all contributions before pushing them to shared repositories, they can configure a global pre-commit git hook by running:

$ ggshield install --mode global

Learn more about how ggshield, the GitGuardian CLI, is built with developer experience in mind.

Answer 2: GitGuardian also perfectly integrates with GitHub (our app even ranks #1 in the security category on the GitHub Marketplace!). Once connected to an organization's GitHub repositories, GitGuardian will trigger security checks on future pull requests and reveal any hard-coded secrets in the branch's commits.

Developers can choose to skip the checks if they believe the alert to be a false positive or if they insist on committing (a non-sensitive) secret. Or, they can follow the guidelines to revoke and rotate the key before pushing and re-running the checks on the same pull request again.

Security teams can also customize the remediation guidelines displayed in the results of GitGuardian's security checks to make sure developers will follow internal procedures.

Challenge #2: Curbing the progress of secrets sprawl

Challenge: Security and development teams must agree that the endgame of a secrets detection program is, curbing the progress of secrets sprawl. Focusing on resolving past incidents (secrets found deep in the Git history) while doing nothing to prevent new ones will not have the intended effects of lowering the total count of exposed secrets and, in turn, reducing the amount of time and effort spent on remediation in the future.

Answer: In the case of hard-coded credentials, prevention is better than the cure couldn't ring more true. Security and engineering teams must do everything they can to stop secrets from reaching the shared codebase.

While our focus has been on getting the experience right with ggshield, the GitGuardian CLI, for secrets detection to be adopted on local workstations (in pre-commit or pre-push checks), we also worked on making it available to run on the servers hosting the version control system.

On GitHub Enterprise Server (GHES) and GitLab self-hosted instances, administrators can now configure ggshield with a pre-receive hook to deploy blocking checks for all incoming code contributions. This one-time setup on the server-side guarantees secrets scanning will run on every single push event and block credentials from reaching the codebase. To date, it is the most effective method to reach a "zero-hardcoded secrets policy".

Challenge #3: Teaming up for incident remediation

Challenge: Application Security engineers are heavily outnumbered by developers – they cannot possibly handle all the vulnerabilities introduced, let alone the thousands of hardcoded secrets that were previously unknown to them.

Answer: To enable an Application Security Shared Responsibility Model, where developers are expected to contribute their fair share to incident remediation, we're making it easier for organizations to invite and manage developers in their GitGuardian workspace.

With an improved RBAC system, we want to support the creation of teams within the GitGuardian workspace to reflect security and engineering organizations. Each team will have a perimeter with its sources (e.g. GitHub, GitLab, or Bitbucket organizations or repositories) with team members having different levels of permission on incidents, according to their role in the organization. This will facilitate collaboration between security engineers and developers and shorten feedback loops on open incidents.

This feature is currently in private beta and is due to be released in early Q3. If you want to try it out please reach out to your Account Manager or contact@gitguardian.com.

Before you go

The above is only a small share of the challenges awaiting large organizations that are looking to implement an effective program to reduce the risks of exposure of secrets, enhance their security posture across the SDLC, and instill a DevSecOps culture.

If you want to learn more about the challenges and common pitfalls of implementing secrets detection, get in touch with one of our experts.