Full Report
According to research from GitGuardian and CyberArk, 79% of IT decision-makers reported having experienced a secrets leak, up from 75% in the previous year's report. At the same time, the number of leaked credentials has never been higher, with over 12.7 million hardcoded credentials in public GitHub repositories alone. One of the more troubling aspects of this report is that over 90% of valid
Analysis Summary
# Best Practices: Secrets Management and Non-Human Identity Security
## Overview
These practices address the significant risk posed by **secrets sprawl** (the proliferation of hardcoded credentials, API keys, and other sensitive access methods) and the associated crisis of **Non-Human Identities (NHI)** management. The goal is to reduce the high incidence of leaked secrets, decrease the average remediation time (currently 27 days), and establish clear ownership and proper permission management for machine identities.
## Key Recommendations
### Immediate Actions
1. **Scan All Public Repositories:** Immediately use secrets scanning tools to identify and inventory all hardcoded credentials currently exposed in public locations (e.g., GitHub).
2. **Prioritize Remediation of Exposed Secrets:** Immediately begin the process of revoking and rotating any secrets identified in public or untrusted environments.
3. **Establish Remediation SLAs:** Define a strict Service Level Agreement (SLA) for credential rotation. Given that over 90% of leaked secrets remain valid for over 5 days, aim for a maximum remediation time under 24 hours for publicly exposed secrets.
4. **Inventory High-Risk NHIs:** Begin tracking all critical Non-Human Identities (NHIs) that possess broad permissions (e.g., `Overall/Administer` level access).
### Short-term Improvements (1-3 months)
1. **Implement Pre-Commit Scanning:** Integrate secrets scanning tools (e.g., GitGuardian) directly into developer workflows (IDE plugins, pre-commit hooks) to prevent secrets from ever reaching source control systems.
2. **Automate Credential Rotation Policy:** Implement automated tooling for the regular rotation of secrets for critical services and NHIs, reducing reliance on manual intervention.
3. **Map Key NHI Permissions:** For the Top N most critical services, map out the exact permissions granted to their associated secrets/credentials to identify over-privileged access.
4. **Initiate Shared Responsibility Training:** Conduct mandatory cross-functional workshops involving development, operations, and security teams to clarify roles in secrets management.
### Long-term Strategy (3+ months)
1. **Adopt a Centralized Secrets Management Platform:** Implement a centralized platform (e.g., HashiCorp Vault, cloud-native secret managers) to dynamically provision and manage secrets, eliminating hardcoding entirely.
2. **Implement Principle of Least Privilege (PoLP) for NHIs:** Systematically review and downgrade permissions for all NHIs to ensure they only possess the minimum access required to perform their specific function (aiming to address the finding that only ~2% of granted permissions are used).
3. **Establish Documented Permission Lifecycle Standard:** Create a clear, standardized, and enforced documentation template for recording the necessary permissions and lifecycle management plan for every new NHI deployed.
4. **Formalize NHI Governance:** Integrate NHI lifecycle management (creation, access review, decommissioning) into CI/CD pipelines and standard operational procedures.
## Implementation Guidance
### For Small Organizations
* **Focus on Prevention:** Prioritize implementing free or low-cost secrets scanning in the CI/CD pipeline immediately.
* **Manual Inventory:** Since central tooling might be expensive, mandate a simple, centralized spreadsheet log for tracking and documenting all presently used API keys and credentials until a dedicated solution is feasible.
* **Developer Accountability:** Empower developers directly; ensure every developer knows how to securely store keys (e.g., using environment variables instead of file checks).
### For Medium Organizations
* **Tool Integration:** Fully integrate secrets scanning tools across Git repositories and deployment environments.
* **Pilot Rotation Program:** Select one critical application and implement full, automated secrets rotation for its associated credentials as a proof-of-concept.
* **Define Ownership Triage:** Clearly document initial ownership expectations: Security owns the scanning tool; Development owns the secrets used in their code; Operations/Platform owns the infrastructure secrets vault.
### For Large Enterprises
* **Comprehensive Visibility Platform:** Deploy a robust platform providing end-to-end visibility into non-human identity lifecycles, utilization, and dynamic injection.
* **Establish Platform Engineering Standards:** Mandate that all application teams utilize platform-provided, ephemeral credentials/tokens managed by the central service, rather than introducing new static secrets.
* **Audit Rights and Usage:** Regularly audit access logs to measure the actual usage of granted permissions against documented entitlements to enforce PoLP hygiene organization-wide.
## Configuration Examples
*(Note: Specific configuration examples require knowledge of proprietary tooling. The following reflects general best practice configuration principles derived from the need to manage secrets effectively.)*
**Best Practice for Dynamic Secret Creation (Conceptual)**
Instead of hardcoding:
API_KEY = "AKIAIOSFODNN7EXAMPLE"
SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
Configure the application to fetch credentials at runtime from a secret manager:
python
# Pseudocode for fetching dynamic credentials
import secret_manager
# Application requests credentials for 'service_A' tagged for 'database_write' permissions
credentials = secret_manager.fetch_creds(
identity="https://service_A.internal.net",
scope="database_write"
)
db_connection_string = configure_db(credentials)
## Compliance Alignment
The recommendations align with security standards that emphasize access control, configuration management, and vulnerability management:
* **NIST SP 800-53 (AC family):** Focus on Access Control and Session Management, especially for non-person entities.
* **ISO/IEC 27001 (A.9 & A.12):** Requirements for access control and secure system engineering principles.
* **CIS Benchmarks:** Specific benchmarks related to secure configuration and vulnerability management, particularly in cloud environments where NHIs are prevalent.
## Common Pitfalls to Avoid
* **Assigning Ownership to Security Only:** Do not allow Security teams to solely own the problem. Secrets management is a shared responsibility; Developers must be equipped and incentivized to build securely.
* **Ignoring High-Privilege NHIs:** Focusing only on developer-created secrets while ignoring powerful, long-lived, system-level credentials (the "machine identity crisis").
* **Remediation Blind Spots:** Assuming that deleting the code file where a secret was found eliminates the risk. Secrets may be cached, logged, or present in build artifacts long after removal from source control.
* **"Hope and Documentation":** Relying on tribal knowledge or hoping the original creator is available to explain complex, poorly documented permissions structures.
## Resources
* **GitGuardian Secrets Scanning Documentation:** For setting up source code scanning and pre-commit hooks. (Defanged URL: `https://www.gitguardian.com/book-a-demo`)
* **CyberArk Documentation on Non-Human Identities (NHI):** For understanding the scope of machine identity risks. (Defanged URL: `https://www.cyberark.com/threat-landscape/`)
* **Secrets Management Platform Documentation:** Evaluate and implement leading platforms like HashiCorp Vault or cloud provider equivalents (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) for centralized control.