KSI-SVC-ASM—Automating Secret Management
Formerly KSI-SVC-06
>Control Description
>NIST 800-53 Controls
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express attack surface management through quantified dashboards — ASM platforms continuously discovering external-facing assets, attack surface graph metrics (nodes, edges, attack paths) tracked as indicators, and shadow IT detection findings remediated through automated workflows. Attack surface becomes quantifiable and measurable.
External Attack Surface Dashboard
Dashboard expressing attack surface posture — external-facing assets, exposed services, attack surface trends, and shadow IT detection
Attack Surface Management Program
ASM program expressing how external attack surface is discovered and managed — backed by continuous scanning
Penetration Testing Reports
Penetration testing results expressing scope, findings, and remediation status
>Programmatic Queries
CLI Commands
vault secrets list -format=json | jq 'to_entries[] | {path: .key, type: .value.type}'vault audit list -format=json | jq 'to_entries[] | {path: .key, type: .value.type}'vault policy list>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does automated secret management cover all secret types — API keys, database credentials, TLS certificates, SSH keys, encryption keys, OAuth tokens, and webhook secrets?
- •Are there secrets managed manually or stored outside the centralized secret management platform, and how are those exceptions tracked?
- •How do you ensure secret rotation covers all environments (production, staging, development, CI/CD) and not just production?
- •When new services or integrations are added, what process ensures their secrets are onboarded into the automated management system before deployment?
Automation & Validation:
- •What automated rotation schedules are defined for each secret type, and what happens if a rotation job fails — how is the failure detected and retried?
- •How do you detect hardcoded secrets in source code, container images, IaC templates, and configuration files — at what stage (pre-commit, CI/CD, runtime)?
- •What happens when a secret is suspected of being compromised — can it be rotated immediately across all consuming services without downtime?
- •How do you validate that rotated secrets are properly picked up by all consuming applications without causing authentication failures?
Inventory & Integration:
- •What secrets management platform (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) is in use, and how does it integrate with workload identity for secret retrieval?
- •How do you maintain an inventory of all secrets, their types, rotation schedules, and consuming services?
- •What tools scan for secret sprawl — secrets that were provisioned but are no longer in use, or secrets stored in unauthorized locations?
- •How does your secrets management integrate with your CI/CD pipeline to inject secrets securely without exposing them in logs or environment variables?
Continuous Evidence & Schedules:
- •What evidence demonstrates that all secrets have been rotated within their defined rotation periods over the past 90 days?
- •Is secret rotation and management data (rotation dates, consuming services, expiration status) available via API for assessor review?
- •How do you detect when a secret approaches expiration or exceeds its rotation schedule without being rotated?
- •What evidence shows that secret scanning has been active across all code repositories and deployment pipelines, with findings remediated?
Update History
Ask AI
Configure your API key to use AI features.