Earlier this year, we stumbled upon a short post titled Developer Experience Is Security from industry analyst Rachel Stephens. Little did we know that this post would serve as an inspiring manifesto for developers, who are increasingly expected to bolster security practices throughout the software development lifecycle. Developers who have just begun to embrace the cultural shift of DevOps over the past decade now find themselves on the brink of another profound transformation.
Yet, this time, we're determined to make a difference.
If you are unfamiliar with GitGuardian or what we do, here is your TL;DR – We help software-driven organizations protect their software supply chain from hardcoded secrets. This may sound like a challenge that primarily falls on the shoulders of Application Security teams. Still, it's crucial to remember that developers are often responsible for exposing these secrets. With hardcoded secrets, the age-old adage 'prevention is better than cure' couldn't be more accurate. It saves tens of hours on remediation and frees up security resources to focus on other sophisticated attack vectors. So, with the right tools and support, developers can become an integral part of the solution and help curb the progress of secrets sprawl.
So, we gathered around the drawing board, pondering how to bring about this transformation. Rachel's post particularly resonated with us with her insights into what developers should experience when running security tools.
“If we are asking developers to be increasingly responsible for building secure apps, we have to make it as frictionless as possible for them to do so. We need platforms and software with baked-in security defaults. We need to embed principles of least privilege. We need guardrails, not gates. We need a focus on usability and speed. We need reduced configuration areas exposed to developers. We need automation. We need developer experience.”
It perfectly described everything we aspired to when building ggshield, the GitGuardian CLI for developers. Let's take it apart.
Frictionless developer onboarding
In cloud-native software development, every minute counts, and developers often face the challenge of integrating new tools into their workflow. With ggshield, we've taken this challenge head-on.
“It could be easier. They have a CLI tool that engineers can run on their laptops, but getting engineers to install the tool is a manual process. The rest of it is perfect. I would rate GitGuardian Internal Monitoring as 9 out of 10.”
Don Magee, Senior Security Engineer
We heard from our users, and in recent updates, starting from version 1.12.0 and above, we've simplified the onboarding process for developers. Once the ggshield CLI is installed, developers can kickstart their journey with this command:
$ ggshield auth loginThis initiates a browser-based authentication flow, allowing developers to log in to their existing workspace or sign up for a new one. Behind the scenes, ggshield quietly provisions a personal access token and stores it locally.
That's it. There are no additional steps—developers can immediately start scanning local repositories, file directories, and Docker images! They can also configure pre-commit or pre-push git hooks to check commits before pushing to remotes.
Baked in security defaults
Security teams and administrators often grapple with managing permissions and ensuring secure access control for their development teams.
“They could give a developer access to a dashboard for their team's repositories that just shows their repository secrets. I think more could be exposed to developers.”
Jon-Erik Schneiderhan, Senior Site Reliability Engineer
With ggshield, we've extended the same seamless onboarding experience to the existing Single Sign-On (SSO) configuration. Workspace managers can now enforce identity provisioning for developers with default roles. This means that access is granted based on the specific security incidents a developer is involved in, streamlining access control.
Developers can log in or sign up using a specific SSO flag provided in advance, ensuring they can access only what's relevant to their role.
$ ggshield auth login --sso-url https://dashboard.gitguardian.com/auth/sso/d0c192e4-XXXX-4250-XXXX-XXXXXXThis logic also works the other way around. When a developer leaves the company, workspace administrators will deactivate their account, and all associated personal access tokens will, in turn, get automatically revoked.
Guardrails, not gates
Security shouldn't come at the cost of slower development. We understand that false positives can sometimes be frustrating, but they are an inevitable part of secret detection. That's why ggshield provides a solution that balances security and developer productivity.
When ggshield raises a false positive or detects a test credential, developers can easily dismiss the findings and proceed with their tasks.
$ ggshield secret ignore --last-foundNo more waiting at closed gates; no alerts will be raised in the IDE or terminal this time, and developers can continue their work uninterrupted. Behind the scenes, GitGuardian still analyzes the commit once it reaches the central repository (post-receive hook) and alerts security teams if necessary.
In addition to this option, we designed the ggshield CLI to be "stateful," meaning that when scans are performed, they are informed of the context of all past findings–leveraging the collective intelligence of all developers and security engineers. A secret flagged as a false positive in the GitGuardian UI will no longer raise future alerts in the developers' consoles.
Usability and speed
Ideate, plan, code, test, deploy, operate, and monitor–this is the software development lifecycle, where developers spend most of their time. They're moving up and down the SDLC all day long and going deep and wide on it. Because of this, slow tools become unusable.
Looking at our stats for the last 90 days, we counted 48 million API calls (from developer workstations or in CI pipelines) and saw the following:
- The average running time of a scan is 238ms
- 25th percentile sits at 85ms
- 99th percentile sits at 1,69s
On average, it's unnoticeable. In the worst cases, we believe an extra second or two is worth the wait, saving hours on incident remediation (investigation, key revocation, rotation, redeployment, etc.).
Reduced configuration areas
Secrets detectors settings
If security teams or engineering managers expect developers to integrate secret scanning into their daily workflows, they should fine-tune it.
In GitGuardian, workspace administrators can configure the secrets detectors they want to see running and directly add custom pattern detection (for organization-specific secrets) from the UI.
This global configuration will then apply to all scans. Say goodbye to clunky YAML files (of course, your developers can still customize ggshield to their liking if they want to).
Context-aware detection
The CLI follows a learning-by-doing approach. When an incident is ignored and flagged as a false positive in the GitGuardian dashboard, this information will be shared with all users of ggshield. The CLI will no longer pick up the secret in subsequent scans performed on developers' machines or CI environments.
However, for complete visibility, ggshield continues to track future occurrences of flagged secrets in the GitGuardian dashboard, marking them as regressions. Depending on your workspace settings, previously resolved incidents may be re-opened for security engineers to review, ensuring that your security remains proactive and adaptable.
Automation
In the age of DevOps, we couldn't have built ggshield without CI pipelines in mind. Secrets detection is far more effective at prevention in local environments. Still, engineering teams have learned to enjoy the benefits of running it in their CI jobs. Results are displayed to teams rather than individuals, raising awareness of the problem for everyone on board. We have noticed that showing non-blocking scan results to developers contributes to the drop in new secrets over time. Nudge theory works!
$ ggshield secret scan ciThis command will scan each commit since the last build in your CI – keeping the job light for your workers. Exit codes can also be configured, for example, always to return a 0 (non-error) status code even if incidents are found.
In sum, developer experience
Hundreds of hours have been likely logged talking to our users, sweating the design details, and improving ggshield since the first release two years ago. We never really counted. It just makes us happy to see our users experience security tooling built by and for developers.
If you haven't tried it yet, now is the time.
The project has been and always will be open-source. You can find the code on GitHub, open issues, submit a PR, and contribute to better developer security tooling.
PS If you enjoy ggshield's protection, don't forget to star the repo ⭐️
