Unified Secrets Security with GitGuardian and AWS Secrets Manager

By: Pierre Le Clezio, Lead Product Manager – GitGuardian; Nic Gumina, Senior Security Consultant – AWS; Manu Chandrasekhar, Senior DevOps Consultant – AWS; Dan Parlin, Security Consultant – AWS

This article was originally published at AWS blogs.

The rise of AI coding assistants and Model Context Protocol (MCP) servers has accelerated the secret management challenge as developers increasingly share configuration files and context with AI tools that inadvertently expose sensitive credentials. API keys, access tokens, and credentials end up in Git repositories and CI/CD logs.

Organizations lack answers to critical questions. They don't know which vaulted secrets have been exposed in code, whether developers have shared credentials through AI tool configurations, how many duplicate credentials exist across accounts, or how many orphaned secrets remain that no application uses. The visibility gap leads to:

Credential exposure: Hardcoded secrets in version control systems create attack vectors that persist even after rotation
Secret sprawl: Duplicate credentials across accounts expand your attack surface
Compliance gaps: Inability to track secret lifecycles undermines audit requirements
Remediation delays: Without correlation between secret inventory and code exposure, security teams lack the context to prioritize and act quickly

With multi-account AWS architectures, the need for unified visibility becomes critical. Organizations need more than just a vault. They need visibility across the entire secret lifecycle, from developer workstations to production environments.

GitGuardian and AWS Secrets Manager

GitGuardian is an AWS Partner specializing in non-human identity (NHI) security, which focuses on protecting machine credentials such as API keys, service accounts, tokens, and secrets management. GitGuardian can be integrated with code repositories, container registries, package registries, documentation platforms, and messaging channels.

GitGuardian's integration with Secrets Manager addresses the visibility challenge that organizations face by bridging the gap between your secret vault and your code.

Figure 1: GitGuardian key capabilities

The key component that makes these capabilities possible is ggscout, GitGuardian's external collector that safely catalogs secrets from Secrets Manager and correlates them with exposed credentials detected across your repositories. ggscout uses the Hashed Message Secret Lookup (HMSL) protocol, a cryptographic hashing approach that converts secrets into secure fingerprints locally within your AWS infrastructure. Because only anonymized fingerprints leave your environment, your actual secrets remain within your AWS infrastructure. Only hashed fingerprints and metadata are transmitted to GitGuardian, maintaining your security posture and compliance requirements while enabling secret correlation and exposure analysis.

For most environments, ggscout can run on an Amazon EC2 t3.small instance, keeping operational costs minimal.

Key capabilities

Detect vaulted secret exposures: Identifies when secrets stored in Secrets Manager have been exposed in code. When a developer accidentally commits a credential that's already vaulted, you get an immediate alert with full context: which secret was exposed, where it appeared, and whether it's visible internally or on the public internet.
Prioritize incident response: Not all secrets pose equal risk. Prioritize remediation based on exposure severity, sensitivity level, usage context, and rotation status. For instance, a publicly exposed production database credential requires immediate rotation, while a development API key in a private repository might be scheduled for the next sprint.
Identify secret sprawl across AWS accounts: Gain visibility into identical credentials stored across multiple AWS accounts and unused secrets to decommission.
Track remediation progress: Real-time visibility into remediation status from pull requests. Teams can track pending fixes, verify secret removal, and confirm pull request activity from a single, collaborative workflow.
Establish continuous governance policies: Implement rotation policies to identify secrets that haven't been rotated within your policy time frame, set customizable thresholds to flag long-lived credentials, and automatically surface orphaned secrets for review.

Prerequisites

Before starting the implementation, ensure you have:

An AWS account with appropriate IAM permissions for Secrets Manager access (cross-account read access if using multi-account architecture)
A GitGuardian account and API credentials (sign up at GitGuardian)
Deployment infrastructure: Amazon EC2 (t3.small or larger), Amazon EKS cluster, or Docker environment
IAM permissions for cross-account Secrets Manager read access (if scanning multiple accounts)
Source control systems to connect to GitGuardian for code scanning
AWS CLI installed and configured

Implementation roadmap

Note: The resources deployed in this implementation (Amazon EC2 instances, Amazon EKS clusters, and AWS Lambda functions) will incur AWS charges. Remember to clean up resources when no longer needed to avoid ongoing charges.

Phase 1 – Deployment (1–2 days): Deploy ggscout in your AWS environment using your preferred deployment method: Amazon EC2, Docker containers, or Helm charts in an Amazon EKS cluster. Connect ggscout to your GitGuardian account. For detailed deployment steps, see the ggscout documentation.

Phase 2 – Assess (2–3 days): Configure read-only access to Secrets Manager across your accounts. Run your initial scan to catalog all secrets and their metadata. Review the baseline report to understand your current secret landscape.

Figure 2: NHI governance with criticality

Phase 3 – Analyze (3–5 days): Review detected exposures that match secrets in Secrets Manager. Identify duplicate secrets across AWS accounts. Prioritize remediation based on exposure severity and secret sensitivity.

Figure 3: Tracking secret exposure lifecycle

Phase 4 – Automate (1–2 weeks): Schedule ggscout to run daily or weekly. Configure alerts for new exposures of vaulted secrets. Set up automated notifications for secrets approaching rotation deadlines. After Phase 3 remediation is complete, expand scanning to additional AWS Regions and accounts.

Figure 4: Breached policies for secret duplication

Phase 5 – Monitor (ongoing): Track KPIs such as time-to-remediation and rotation compliance rate to move beyond reactive cleanup and identify trends across your secrets posture.

Figure 5: GitGuardian monitoring dashboard overview

Clean up resources

To avoid incurring ongoing AWS charges, delete or decommission all resources when no longer needed:

Stop and terminate Amazon EC2 instances running ggscout: Navigate to the EC2 console, select the instances, and choose Instance state then Terminate instance.
Remove the Helm release by running helm uninstall ggscout.
Delete the EKS cluster based on your provisioning method.
Remove Lambda functions created for automated remediation workflows.
Delete any associated IAM roles and policies created for ggscout access, including cross-account roles used for Secrets Manager read access.

Conclusion

The combination of AWS Secrets Manager and GitGuardian gives you visibility and automation across the secret's lifecycle, from creation to usage to rotation to decommissioning. By integrating GitGuardian with Secrets Manager, organizations gain continuous visibility into their secrets security posture, detecting exposures as they occur and establishing governance policies that prevent future incidents.

Start by deploying ggscout, running your initial scan, and reviewing the baseline report. After initial deployment, consider these next steps:

Implement automated remediation workflows: Use GitGuardian webhooks with Lambda to trigger automatic secret rotation when exposures are detected.
Integrate with your incident response pipeline: Connect GitGuardian alerts to your existing SIEM, ticketing, or ChatOps tools.

For more information: