At GitGuardian, we are convinced that effective security requires a shared responsibility model. Developers are already overburdened with their primary tasks of writing code and delivering features, and we think it is not realistic to expect them to know everything about security, be responsible for triaging and handling incidents on their own, or consider all the implications of security.

Adding security responsibilities without proper support and integration can lead to frustration, resistance, and, ultimately, a less secure environment. Yet, their involvement in fixing code security issues is crucial and cannot be replaced by security work.

We've seen "shifting left" being misinterpreted as simply handing developers security tools and more responsibility, yet we assume adding more tools has never been a solution to security.

Our platform is built around the idea of creating a collaborative environment where security is seamlessly integrated into the development process. That's why we provide tools and processes that empower developers to write secure code without adding unnecessary toil.

In this blog, we will highlight how GitGuardian is much more than just another security scanner. It is a true end-to-end platform supporting a partnership between dev and sec.

1. Empower Developers with ggshield

Developers love to be in control of their tooling, so it's essential to provide them with flexible security tools they can integrate into their local workflow. GitGuardian's CLI, ggshield, provides just that: a scanner for the command line that can be used manually or as a pre-commit (or pre-push) hook to ensure every commit is secrets-free.

How To Use ggshield To Avoid Hardcoded Secrets [cheat sheet included]
GitGuardian’s ggshield CLI tool can help you keep your secrets away from your repos and pipelines. Download our handy cheat sheet to quickly become proficient in our CLI tool.

More importantly, the tool is always in sync with the developer's GitGuardian account, meaning that any secret ignored on the dashboard won't trigger an unnecessary alert.

With ggshield, developers are enabled to prevent many mistakes. Yet, if they decide to work around not adopting ggshield, GitGuardian will still scan code when it is pushed to a shared repository or during the Continuous Integration process, stopping vulnerabilities from falling through the cracks. GGshield covers three main use cases:

  • Secrets Scanning: Ensuring that any plaintext credentials added to the code are discovered before they leave the machine.
  • Source Composition Analysis: Scanning for vulnerabilities in new code changes, blocking when a new component or change introduces a new vulnerability.
  • Infrastructure as Code Scanning: Checking for misconfigurations in IaC tools like Terraform before committing code to the pipeline.

Further, each of these hooks has many options for further configuration, such as ignoring specific paths or only blocking Critical or High-risk CVEs in the case of SCA. Hooks can be set at a global level in Git, meaning that once installed every new Git commit will get the same level of automatic testing no matter which project the developer is focused on. 

The number of overall incidents will decrease as developers adopt these guardrails and develop better security habits. This approach serves the developers by ensuring their code reaches production more often and keeps the organization safer.

2. Ensure Consistent Findings and Create a Common Language

Nothing kills collaboration faster than a crippling lack of understanding and an endless barrage of back-and-forth communication. How to avoid that? By ensuring all parties talk about the same thing, with all the relevant context.

GitGuardian gathers all findings around a secret sprawl or dependency vulnerability event into a logical unit: the "incident." Rather than just displaying alerts in email or exporting them to a CSV or text file, the GitGuardian Platform tracks all occurrences of the same secret under the same incident in the workspace. This approach also gives developers and security teams a common language to discuss any security issues, as each incident has a unique identifier and a clear timeline to track remediation progress. 

GitGuardian Incident view

From one platform, teams can organize alerts, efficiently gather feedback from the developer at the right moment, and better coordinate the needed response. They can also introduce guardrails to the development teams, optionally blocking any problems before they can become full-blown incidents. We are here to help you throughout your security journey.

3. Partner with Developers in Incident Remediation

Gathering feedback from the developer involved is one critical juncture when remediating an incident. GitGuardian streamlines this process and gives the flexibility you need to share access to the incident. Whether you need to provide full or partial access, share incidents selectively, or seamlessly integrate with JIRA, GitGuardian empowers you to choose what works best for your team.

Option 1: Full Access

Some teams prefer to give the developers full access to the platform to see any incident the security team does. In this case, the developer can simply be invited to see the incident view directly from the GitGuardian incident dashboard.

Option 2: Partial Access

Some teams only want to invite developers to work within the dashboard for certain incidents related to specific repositories. GitGuardian's Teams feature allows you to restrict access to incidents to specific team members, giving them automatic access without the worry of unrestricted access. 

Caption: The share incident menu in the GitGuardian dashboard.

Option 3: Selective Sharing

Sometimes, the best choice is not to onboard developers to the GitGuardian workspace. For teams supervising a larger fleet of repositories, it just doesn't make sense to overwhelm developers with irrelevant alerts in their inboxes or Slack channels.

If that's the preferred solution, GitGuardian makes sharing an incident extremely efficient through our public sharing functionality.

Security team members can generate a public link that is accessible to unregistered users and provides all the details of the incident along with a feedback form. The form asks the developer who made the commit if this is an actual secret, if the secret gives access to any sensitive information or services, and if the secret has been revoked. It also gives them a text box to provide any additional relevant information. When the link is no longer needed, it can easily be revoked.

The "share publicly" interface inside the incident view in GitGuardian.
The "submit your feedback" form from the shared link.

If the commit author is trusted to close the incident themselves, then with one additional option selected from the dashboard, this same feedback form can add an additional field that will allow the developer to resolve or ignore the incident themselves.

Resolve or ignore the incident area from the shared link.

Option 4: JIRA

If you are working in an Atlassian JIRA-driven environment, it makes sense to keep everything together in one single place: GitGuardian can integrate transparently there through the GitGuardian Advanced Jira Cloud integration. GitGuardian can be configured to create a new Jira ticket using custom templates to communicate consistently with developers about needed remediation efforts.

Any further updates from the GitGuardian incident will get pushed as comments to each related Jira issue, and conversely, it's possible to configure the Jira tickets to resolve an incident in GitGuardian when a specific status is reached. It will mark the associated incident as Resolved so you can stay focused on other work.

This can help developers stay in a workflow they are very used to while working on remediating incidents. 

4. Progressive Implementation of Guardrails for Better Code Security

When your team is ready to add security earlier in the development process, we suggest introducing 'guardrails' into their workflow. Guardrails, unlike wholly new processes, can slide into place unobtrusively, providing warnings about potential security issues only when they are actionable and true positives. Ideally, you want to minimize friction and enable developers to deliver safer, better code that will pass tests down the line.

One tool that is almost universal across development and DevOps teams is Git. With over 97% of developers using Git daily, it is a familiar platform that can be leveraged to enhance security. Built directly into Git is an automation platform called Git Hooks, which can trigger just-in-time scanning at specific stages of the Git workflow, such as right before a commit is made.

By catching issues before making a commit and providing direct feedback on how to fix them, developers can address security concerns with minimal disruption. This approach is much less expensive and time-consuming than addressing issues later in the development process. This can actually increase the time spent on new code by reducing the amount of maintenance that eventually needs done. 

Conclusion: More Security, Less Toil

Empowering developers in code security is crucial for minimizing vulnerabilities and ensuring the safety of the organization. By meeting developers where they are, providing seamless integration of security tools, and fostering a collaborative approach, security teams such as GitGuardian can unlock the full potential of their security tools.

GitGuardian's ggshield and its seamless integration with developer workflows via Git Hooks offer a practical solution to the challenges of secrets security. By adopting appropriate and accurate guardrails, developers can continue to focus on building features and functionality while ensuring their code is secure.

Working together, security teams and developers can create a safer, more efficient development environment that benefits the entire organization. By embracing this collaborative approach, we can address the complexities of modern security challenges and achieve greater success in delivering secure code.