Developer experience is security, our answer.

Earlier this year, we stumbled upon a short post titled Developer Experience Is Security from industry analyst Rachel Stephens. It revealed itself as an inspiring manifesto for all developers who are now increasingly expected to enhance their security practices throughout the software development lifecycle. Developers who have barely reaped the fruits of the DevOps cultural change of the past decade and now finding themselves on the cusp of yet another profound transformation.

This time, however, we want things to be different.

If you are not familiar with GitGuardian or what we do, here is your TL;DR – we help software-driven organizations keep secrets out of source code. That reads like a problem that Application Security teams should have in their never-ending list of responsibilities. But we have to keep in mind that developers are the ones checking secrets into source control. In the case of hardcoded credentials, prevention is better than the cure couldn't ring more true. It saves tens of hours on remediation and frees up security resources to focus on other sophisticated attack vectors. With the right supportive tools, we believe developers can be part of the solution to this pervasive problem and help curb the progress of secrets sprawl.

So we sat down and reflected on how we should bring about this change, and the following from Rachel’s post particularly resonated with us. It described everything our users want to experience when running ggshield, the GitGuardian CLI for developers.

“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.”

Let’s take it apart and see how our recent ggshield releases fit into the description.

Frictionless developer onboarding

The last time we asked, our users wished for easier developer onboarding. GitGuardian is part of a larger developer toolbelt, and if we want thousands to adopt it, we need to make sure the first interactions are instinctive.

“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.

In versions 1.12.0 and above, we shipped a major update. After installing the CLI, the developer can run the following command to get started with GitGuardian.

$ 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. There are no additional steps. The developer can start scanning local repositories, file directories, and Docker images or configure a pre-commit or a pre-push git hook and scan commits before pushing to the remotes.

Baked in security defaults

Similarly, our users wanted the same flow extended to their existing Single Sign-On (SSO) configuration. When onboarding hundreds or thousands of developers on a workspace, security teams need assurance and control over the permissions a user will have, especially when handling incident data.

“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.

We added the possibility for GitGuardian workspace managers to enforce identity provisioning for developers with a default role. In this example, access is restricted to the security incidents the developer is involved in or put in other words, where they are the commit author.

To login or sign up, the developer can add a specific SSO flag to the same command and the URL shared with them beforehand.

$ ggshield auth login --sso-url https://dashboard.gitguardian.com/auth/sso/d0c192e4-XXXX-4250-XXXX-XXXXXX

This 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

Remember the last time you stood in front of a gate? It’s frustrating. The wait can get long, especially when you can’t see what’s on the other side of the gate or who’s keeping it closed.

Code security is no different. At GitGuardian, we believe the tooling needs to fit into the development workflow and act informative and non-blocking, or else it will be shunned.

Secrets detection is a probabilistic problem and while we’re getting very good at it, we will sometimes raise a false positive or a test credential (ggshield can be configured to exclude test directories) – no tool is perfect. We do, however, provide a way for developers to ignore the findings and move on with their tasks.

$  ggshield secret ignore --last-found

Once this command has run, the developer can try committing or pushing again. No alerts will be raised in the IDE or terminal this time. The GitGuardian dashboard will still analyze the commit once it reaches the central repository (post-receive) and raises an incident for security teams to be aware of though.

Usability and speed

Ideate, plan, code, test, deploy, operate and monitor – this is the software development lifecycle, where developers are spending most of their time. All-day long, they're moving up and down the SDLC and going deep and wide on it. And because of this, slow tools turn 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:

• 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 down the line on incident remediation (investigation, key revocation, rotation, redeployment, etc.).

Reduced configuration areas

Secrets detectors settings

If security teams or engineering managers are expecting developers to integrate secrets scanning in their daily workflows, they should be the ones fine-tuning it.

In GitGuardian, workspace administrators can configure the secrets detectors they want to see running and add custom pattern detection (for organization-specific secrets) directly from the UI.

This global configuration will then apply to all secrets scans. No esoteric YAML is needed (of course, developers can still customize ggshield to their liking if they want to).

Smart detection

The CLI follows a learning-by-doing approach. When an incident is 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 in CI environments.

For the sake of completeness, GitGuardian will however record future occurrences of the secret (false positive in this example), if it reaches the VCS, in the dashboard. This is considered a regression and depending on the workspace settings, the previously resolved incident will be re-opened for security engineers to check.

Automation

In the age of DevOps, we couldn’t have simply built ggshield without CI pipelines in mind. Secrets detection is far more effective at prevention in local environments, but some organizations like running it in their CI jobs. Results are displayed to team members rather than individuals, raising the awareness of the problem for everyone.

$ ggshield secret scan ci

This 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, to always return a 0 (non-error) status code even if incidents are found.

In sum, developer experience

Hundreds or thousands 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 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.

P.S. Don’t forget to star the repo ⭐️

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Ziad Ghalleb. Read the original post at: https://blog.gitguardian.com/developer-experience-is-security-our-answer/