Track whether code-level fixes reduce exposed secrets, hardcoded credentials, and weak service account handling. Those are identity control failures expressed through application code, so they need to be measured as part of both AppSec and NHI governance. If those exposures do not fall, the programme may be improving developer flow without improving identity security.
Why This Matters for Security Teams
AppSec metrics often stop at code quality, while NHI risk shows up in runtime behaviour: exposed secrets in source, hardcoded credentials, weak service account handling, and over-privileged automation. That gap matters because identity failures embedded in code can survive every dependency scan and still hand attackers a live path into production. NIST’s NIST Cybersecurity Framework 2.0 treats identity and access as operational controls, not just configuration details, which is the right lens for connecting AppSec and IAM outcomes.
NHIMG research shows the scale of the problem: in Ultimate Guide to NHIs, 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools. That means a “clean” AppSec dashboard can still hide an identity exposure problem if the team is not measuring secret removal, credential hygiene, and service account sprawl together. Security teams usually miss this because the code fix looks complete, but the identity risk remains live in pipelines and deployments. In practice, many security teams encounter NHI compromise only after code changes have already shipped and been exploited, rather than through intentional measurement.
How It Works in Practice
The practical connection is to turn AppSec findings into identity-risk metrics that IAM can own and action. Start by classifying code issues into identity-relevant buckets: secrets committed to repos, credentials embedded in application code, insecure token handling, excessive permissions in service account code, and weak rotation logic. Then track whether those findings decline release over release, not just whether a scanner flags them. NHI governance should treat these as control failures, because the code is where the identity is created, stored, or abused.
A useful operating model is to pair engineering metrics with identity outcomes:
- Secrets exposed per repository, service, or pipeline
- Mean time to remove hardcoded credentials after detection
- Percentage of services using ephemeral credentials or short-lived tokens
- Percentage of service accounts mapped to an owner, purpose, and expiration
- Number of builds blocked because of identity-risk findings
This is where AppSec and IAM have to share evidence. AppSec tools can detect code patterns, while IAM can confirm whether the underlying identity was rotated, revoked, or re-scoped. Current guidance suggests measuring both detection and remediation, because a finding that is never removed is still an active access path. NIST SP 800-53 Rev. 5 Security and Privacy Controls is a useful reference point for linking secure development, access control, and auditability into one control narrative. For deeper NHI lifecycle context, see 52 NHI Breaches Analysis. These controls tend to break down when secrets are generated dynamically in CI/CD and later copied into configs or tickets, because the original detection point no longer matches the final exposure point.
Common Variations and Edge Cases
Tighter measurement often increases engineering and governance overhead, requiring organisations to balance stronger identity assurance against developer velocity and alert fatigue. The right model depends on where the identity risk enters the software lifecycle. In some environments, the dominant issue is committed secrets in source control; in others, it is service accounts created by platform teams without a clear owner or expiry. Best practice is evolving, and there is no universal standard for how to weight these metrics across AppSec and IAM.
Two edge cases matter. First, third-party integrations and CI/CD robots can create identity exposure without any obvious code smell, so a repo may look clean while the runtime posture remains weak. Second, auto-remediation can mask risk if it rotates a credential but leaves the service account over-privileged or undiscovered elsewhere. That is why teams should connect vulnerability management, secret scanning, identity inventory, and access reviews into one reporting chain. NHIMG’s Top 10 NHI Issues reinforces that visibility, rotation, and privilege excess are usually linked, not separate problems. The most reliable programme signal is not how many findings were created, but whether exposed credentials, stale service accounts, and excessive permissions are trending down together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Secrets in code and weak service accounts are direct NHI exposure paths. |
| OWASP Agentic AI Top 10 | Automated code and pipeline actors can create identity risk at runtime. | |
| CSA MAESTRO | Agentic and automated workflows need runtime governance across identity and tools. | |
| NIST AI RMF | GOVERN | Cross-team accountability is needed to manage application-driven identity risk. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access oversight are central to NHI risk reduction. |
Map code-derived identity issues to access-control metrics and track privilege reduction over time.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
