Poor secret management practices and hardcoded credentials are plaguing DevOps environments and all parts of the software development life cycle. With high-profile breaches and diverse initiatives to produce guidance on securing the software supply chain, we're now past the debate of whether secrets detection should fit into the product security roadmap and when. CISOs, Application Security engineers, DevOps – and let's not forget developers – all agree it's somewhere high up the priority list, and the time is now.

If a fellow Software Architect told me that secret detection is not a priority, I would ask what is more of a priority. Then I would point to a quick Google search with a myriad of issues and data breaches that have happened from leaked secrets. That is pretty easy to find.
Danny Cairney, Chief Software Architect

Secrets detection as a security program for application development is table stakes. You need to have it.
Don Magee, Serverless Security Engineer

Secrets sprawl is getting out of hand

Application Security and engineering leadership often know that secrets sprawl only worsens with time. The longer a team waits before implementing a secrets detection program, the more secrets will get exposed inside the SDLC, and the bigger the security debt becomes. But sometimes, this doesn't prevent them from kicking the can down the road and "pushing the initiative to the next quarter."

At GitGuardian, we understand the conditions under which such decisions are made. After scanning their entire codebase for credentials, organizations usually realize that there are more hardcoded secrets than their Application Security teams can possibly handle.

Remediating a hardcoded secret is outright tricky and stressful, and the thought of replicating the process for thousands of other instances can feel overwhelming. If we also factor in the lack of developers' contribution in the process, it becomes obvious why many security teams hold off from tackling secrets sprawl today.

The truth is, it doesn't have to be this painful. We discovered a thing or two from rolling out secrets detection programs at software-driven organizations like Instacart, Automox, Beyond Identity, and many others. Of all learnings, the most elementary was that it takes a team to solve hardcoded secrets.

Sharing the burden of remediation

Our message for AppSec engineers is simple; you're not in this alone! We have spent the last few months working on a new Role-based Access Management (RBAC) system founded on the concept of Teams. Cooperation between Application Security, DevOps, CloudOps engineers, and developers is key to conquering hardcoded secrets. With Teams, we decided to help you get everyone on board in the GitGuardian Internal Monitoring platform!

This newly released feature enables you to map repositories to developers, giving them immediate access and ownership over their hardcoded secrets incidents. From your GitGuardian workspace, you can now create and manage an unlimited number of teams, define a perimeter of monitored repositories for each, and restrict member access and permissions for incidents within their perimeter. Dwayne McDaniel, Security Advocate at GitGuardian, put together this short demo for you to get the gist of this new feature.

Teams will help you pull everyone involved closer to the process and unlock use cases like:

• Inviting ALL developers to join GitGuardian: With Teams, total data segregation is possible; developers can only see and respond to incidents inside their team's perimeter.
• Decentralizing incident response: remediating a sea of hardcoded secret incidents is impossible for a single centralized Application Security team. With Teams, your developers have direct access to their incidents and can remediate them by following the recommended instructions.
• Tackling orphan incidents: When developers leave your organization, their hardcoded secrets stay. With Teams, you can quickly identify their previous coworkers or repository owners and assign them the task of resolving the leftover incidents.

Now let's dive in and see how it works.

Creating and managing teams in GitGuardian

Step 1. Create your first team

1. Go to the Teams section in your workspace settings,

2. Click on the Create Team button,

3. Set a name; this should be the name of your development team inside the organization (e.g., "Mobile AppDev" or "Payments Service"), then click Create.

Step 2. Define the team's perimeter

The team's perimeter is the total collection of sources (GitHub repositories, GitLab projects, etc.) and the hardcoded secrets incidents occurring therein. To add sources to the perimeter of your newly created team:

1. Scroll down to the Perimeter panel and click on Add sources,

2. If you have several Version Control Systems (VCS) integrated, select the one you want to add repositories from,

3. Select the repositories you want to add to the team perimeter and confirm by clicking Add sources.

If your team contributes to multiple repositories hosted on different VCS platforms, reiterate the 2nd and 3rd steps.

Step 3. Invite developers to join

Invite your developers to join your GitGuardian workspace; a few options are available to do this:

1. Invite them via email from the Settings > Members section of your workspace;
2. Invite them via SSO by sharing your workspace's login URL with your developers;
3. Use the GitGuardian public API to send an invitation via email to your developers.

Once they're in, go back to Settings > Teams:

1. On the Team page, scroll down to the Teammates panel;

2. Click on Add teammates and select the users you would like to add to this team from the searchable dropdown list.

Step 4. Configure teammates permissions

You can control the permissions over incidents and team administration for each invited teammate with the following options:

Team management permissions

• Cannot manage: they cannot change team settings or invite/remove teammates.
• Can manage: they can manage teammates (add/remove/accept or decline team requests). They can manage team settings and even delete the team.

Incident management permissions

• Can view: they can only view team incidents.
• Can edit: they can resolve, ignore, comment, and be assigned to team incidents.
• Full access: they have the "Can edit" permissions, plus the ability to share team incidents publicly within the workspace.

Manage your teams with the GitGuardian public API

If you prefer scripting your way to manage and configure your GitGuardian workspace, you can accomplish all of the above with our public API. We have introduced new API endpoints to complete the steps described in the previous sections. Check out the API reference documentation:

• API endpoints for managing user invitations
• API endpoints for managing teams

Remediating your incidents together

Now that everyone's on board, it's time to dive into incident remediation! Read the following guide for practical tips on remediating hardcoded secrets at scale with contextual prioritization and collaboration.

How to remediate thousands of hardcoded secrets incidents

This article aims to provide application security teams with a guide to effectively prioritize, investigate and remediate hardcoded security incidents at scale.

GitGuardian Blog - Automated Secrets DetectionZiad Ghalleb