GitGuardian announced a series of new features to address developer experience in securing the software development lifecycle.
To reduce the risks of exposure of secrets in the software development lifecycle, GitGuardian is betting on what it has framed as the Application Security Shared Responsibility Model. The company is helping security teams partner with development teams to remediate swaths of existing vulnerabilities and prevent ones in the future. By getting the developer experience right, GitGuardian is turning the problem of secrets sprawl into an opportunity to break down organizational silos and infuse security in the software development lifecycle.
“As dev teams take greater ownership of the day-to-day application security issues, the security team must let go of the tactical and take the opportunity to play a more strategic role in product security” Forrester The State Of Application Security, 2022
On top of an integrated platform, GitGuardian comes with ggshield – an open-source command-line interface (CLI) built for developers. Widely adopted by developer communities, ggshield helps thousands of developers and DevOps engineers keep secrets out of source code. To date, it is the most effective solution for preventing secrets from leaving developers’ workstations and getting exposed – saving security teams hours on investigation, remediation, and expensive paperwork.
To help large organizations deploy secrets detection and remediation on perimeters consisting of thousands of developers, GitGuardian is introducing:
- A new developer onboarding experience with an automated API key provisioning mechanism alongside a browser-based authentication flow for ggshield (GitGuardian CLI) – removing all barriers to enterprise adoption.
- Deeper integration with GitHub, to reveal the results of its security scans in the context of pull requests and provide developers with custom remediation guidelines.
- An easier configuration of ggshield (GitGuardian CLI) for pre-receive hooks to implement preventive secrets scanning (a.k.a. push protection) on GitHub Enterprise and GitLab self-hosted instances. This enables Version Control Systems administrators to deploy blocking checks for all incoming code contributions with a single setup.
- An improved RBAC system, supporting 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.
Poor secret management practices and hardcoded credentials, in particular, are pervasive in the DevOps and cloud-native era. GitGuardian’s research published earlier this year in March, The State of Secrets Sprawl 2022, shows that there are more hardcoded secrets than application security teams can handle. The data reveals that on average, in 2021, a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase.
With each secret having 13 different occurrences, the effort required for remediation exceeds available resources within security teams (1 AppSec engineer for 100 developers) hence the need for a shared responsibility model involving developers.
In addition, when comparing public corporate codebases to private ones, GitGuardian found the latter to be four times more likely to expose a secret. The company concludes that, in the current state, private repositories permeate a false sense of security and are a (ticking) time bomb waiting to go off at any moment. Additional analysis by GitGuardian of the recent wave of source code leaks from companies like Twitch, Samsung and Nvidia, and Microsoft confirms this.