Skip to content
1. Improper Offboarding
- When NHIs (Non-Human Identities) like service accounts, API keys, and machine credentials are not properly offboarded, they can become a security risk.
- This includes failing to deactivate old or deprecated secrets, leading to “zombie NHIs” that attackers can exploit.
- Automating the NHIs lifecycle ensures stale secrets are discovered and revoked, reducing attack surfaces.
2. Secret Leakage
- NHIs often store sensitive credentials (secrets) in multiple locations. If these secrets are not properly managed, they can leak into public repositories, logs, or insecure environments.
- Automated secret detection helps in identifying and remediating such leaks before they become a threat.
3. Vulnerable Third-Party NHI
- NHIs are often used to interact with third-party services. If third-party integrations are not secured, attackers can exploit weak NHIs to access sensitive data.
- Mapping and inventorying NHIs across third-party assets help track potential vulnerabilities.
- Honeytokens (decoy credentials) can be used to detect unauthorized access and improve incident response.
4. Insecure Authentication
- Weak authentication methods for NHIs, such as using outdated hash algorithms (e.g., SHA1), low-entropy secrets, or hardcoded credentials, increase the risk of compromise.
- Enforcing strong authentication mechanisms, such as rotating credentials and using stronger encryption algorithms, enhances security.
5. Overprivileged NHI
- Granting NHIs excessive permissions increases the risk of lateral movement in case of compromise.
- Enforcing the principle of least privilege ensures NHIs only have the minimum access required to perform their functions.
- Secret analyzers and permission monitoring tools help in managing access rights efficiently.
6. Insecure Cloud Deployment Configurations
- NHIs used in cloud deployments may have misconfigured permissions, static secrets, or inadequate access controls.
- CI/CD pipelines should enforce security best practices, such as detecting hardcoded secrets, enabling secret vaulting, and ensuring proper permission scoping.
7. Long-Lived Secrets
- NHIs using long-lived credentials (e.g., API keys that don’t expire) pose a high security risk.
- Implementing automated secret rotation policies and enforcing expiration best practices mitigate these risks.
8. Environment Isolation
- NHIs should not have access to multiple environments (e.g., development, testing, production) unless absolutely necessary.
- Monitoring and enforcing strict environment-specific access controls prevent unauthorized data exposure.
9. NHI Reuse
- Reusing the same NHI (e.g., API key or service account) across multiple applications increases security risks.
- Vault integrations should be used to enforce unique NHIs per application, reducing exposure in case of a breach.
10. Human Use of NHI
- NHIs are meant for automated systems, but when humans misuse them (e.g., manually using service accounts for access), it leads to security gaps.
- Audit logs should track NHI activity, and identity access should be enforced using robust frameworks like SPIFFE (Secure Production Identity Framework for Everyone).