Cloud Secrets Management for Production: Keep Credentials Out of CI/CD

Cloud secrets management is the centralised control of credentials, tokens, certificates and other sensitive configuration used by applications and infrastructure. The core rule we follow is straightforward: remove hardcoded secrets wherever feasible, replace long-lived credentials with short-lived ones, and retrieve what remains at runtime from an API-gated store with automated rotation, aligned with NIST SP 800-57 key-management principles and informed by the 2025 DBIR findings on secret exposure.

TL;DR:

• The 2025 DBIR attributes 39% of disclosed secrets to web application infrastructure; 66% of those are JWTs, so protect session tokens like passwords.
• Leaked secrets in public repositories take a median 94 days to remediate; scan repositories and build artifacts, rotate discoveries immediately, and alert on access logs.
• Remove credentials through workload identities where possible; otherwise retrieve scoped, short lived tokens at runtime and secure the bootstrap identity that grants access.
• Choose a secrets manager for application credentials, but use a key management system for cryptographic keys; the tools address related, distinct lifecycle needs.
• Automate rotation only after discovery, verify every consumer handles rollover, and restrict access to Terraform state because it can contain secrets in plaintext.

Table of Contents

• What counts as a secret and which types you must manage
• Why secrets management matters now: what the breach data shows
• Core capabilities every cloud secrets solution must provide
• Design patterns that reduce secret risk at the architecture level
• A practical checklist for integrating secrets into code, CI/CD and IaC
• Secrets management versus cryptographic key management
• Operational governance: policy, monitoring and incident response
• How we approach secrets management engagements
• What this work actually requires from an organisation
• How Vicedomini Softworks can support your secrets management programme
• FAQ
• Sources

What counts as a secret and which types you must manage

A secret is any credential, token or private string that grants access or proves identity: something that must stay confidential to remain safe. Non-secret identifiers, such as usernames or public resource names, do not require the same controls and conflating the two creates unnecessary friction in engineering teams.

The categories that recur across production environments are:

• API keys: static credentials issued by a service to authenticate calling applications.
• JSON Web Tokens (JWTs): signed, often bearer tokens used for session and service-to-service authentication.
• OAuth tokens: access and refresh tokens issued during delegated authorisation flows.
• Database credentials: usernames and passwords, or connection strings, granting data access.
• TLS certificates: public key certificates and their associated private keys used to secure transport.
• SSH keys: key pairs granting shell or administrative access to servers and infrastructure.

According to the 2025 DBIR, web application infrastructure is a disproportionately high-exposure class for disclosed secrets, with JWTs forming the majority of that category. Treating JWTs with the same rigour as database passwords, rather than as disposable session artefacts, closes a gap that attackers actively probe.

Why secrets management matters now: what the breach data shows

The urgency here is not theoretical. The 2025 DBIR found that web application infrastructure accounts for 39% of disclosed secrets, and within that category, 66% are JWTs, a concentration that reflects how often session and service tokens end up in logs, repositories or client-side code where they should never persist.

Web application infrastructure accounts for a notable share of disclosed secrets, and Google Cloud API keys feature among disclosed cloud-infrastructure secrets, according to the 2025 DBIR. That concentration around a single credential type suggests many organisations are still issuing static API keys where short-lived, scoped tokens would serve the same purpose with far less residual risk.

The same report puts the median remediation time for leaked secrets in public code repositories at 94 days, a window that gives an attacker a month rather than hours to act once a credential surfaces. Third-party vendors and edge devices widen this exposure further: a secret embedded in a partner integration or a firmware update is harder to inventory and often outside the visibility of the team that issued it, which is precisely why remediation drags on.

The practical implication is unambiguous. Detection speed and rotation speed matter more than any single preventive control, because secrets will leak regardless of policy quality. A programme that can identify an exposed credential and rotate it promptly closes the exposure window that the DBIR data shows organisations can leave open.

Core capabilities every cloud secrets solution must provide

Selecting or specifying a secrets management platform comes down to a short list of non-negotiable capabilities, each of which AWS Well-Architected guidance identifies as foundational to secure secrets handling.

• Encryption at rest and in transit: secrets must never be stored or transmitted in plaintext, at any layer of the stack.
• Fine-grained access control: permissions should distinguish who can manage a secret’s lifecycle from who can merely consume it at runtime.
• Comprehensive auditing: every read, write and rotation event needs a durable, queryable log entry.
• Versioning and lifecycle controls: old secret versions must remain retrievable briefly during rollover, then expire on a defined schedule.
• Automated rotation: rotation should run on a schedule or trigger, not depend on a person remembering to act.
• Replication and availability: secrets infrastructure needs a documented replication and regional failover policy, since an outage in the secrets layer can halt every dependent service.

Extensibility matters as much as the defaults. Few organisations run only services that fit a vendor’s built-in rotation templates, so the ability to write custom rotation logic, for a legacy database driver or a bespoke third-party API, often decides whether automated rotation gets adopted at all or quietly abandoned after the first awkward integration.

Pro Tip: Score candidate secrets managers against encryption, access control, auditing and rotation extensibility before comparing price or vendor ecosystem; a low-cost option that cannot automate rotation for your actual stack may create additional operational work.

Design patterns that reduce secret risk at the architecture level

AWS Well-Architected guidance frames the architectural goal as a three-step discipline: remove, replace, rotate. Each step reduces risk independently, and together they form the backbone of a defensible secrets strategy.

1. Remove the secret entirely where an alternative exists: an EC2 instance role or a Kubernetes service account can authenticate to cloud APIs without any stored credential at all.
2. Replace what cannot be removed with short-lived, scoped credentials: a third-party integration that once used a permanent API key can often use a token issued for a single session or a bounded time window instead.
3. Rotate whatever remains on a schedule tight enough that a leaked value is useless by the time anyone finds it.

The runtime retrieval model, sometimes called credential vending, underpins all three steps. Instead of baking a secret into a configuration file, a container image or a CI/CD variable, the application requests it from the secrets API at startup or on demand. This keeps the credential out of source control, out of build logs and out of the container registry, which is where most accidental disclosures originate in practice.

Runtime retrieval raises an obvious circularity: the application needs a credential to fetch its credentials. This is the bootstrap problem, and the OWASP Secrets Management cheat sheet is direct about the risk of solving it badly: a hardened vault can still be at risk if the bootstrap credential that unlocks it is not adequately protected. The mitigations that avoid a hardcoded bootstrap secret include cloud instance metadata services, IAM Roles Anywhere for workloads running outside the cloud provider, ephemeral credentials issued at deployment time, and hardware-backed enclave keys for the highest-sensitivity cases. For organisations that need a physical root of trust rather than a software-only bootstrap, hardware security devices such as the YubiKey and YubiHSM range, detailed on Smartmanagement, offer FIPS-certified options for anchoring that initial authentication step.

A final structural safeguard is the separation of administrative and runtime roles. Separating the principal that manages a secret from the one that reads it to serve traffic can limit the risk that a compromised runtime service account can rotate or delete credentials. This separation limits blast radius without adding operational overhead once it is built into the IAM policy from the start.

Pro Tip: Audit every long-lived credential in your estate and ask whether it can be removed outright before deciding how to rotate it; removal beats rotation every time it is available.

A practical checklist for integrating secrets into code, CI/CD and IaC

Rolling secrets management into an existing engineering workflow follows a reasonably consistent sequence regardless of cloud provider.

1. Discovery: scan repositories, build artefacts and infrastructure-as-code state for embedded secrets, and rotate anything found immediately rather than waiting for a scheduled cycle.
2. Code integration: replace hardcoded values with calls to the secrets API at runtime, using the client libraries the platform provides and a short-lived, safe caching layer to avoid hammering the API on every request.
3. CI/CD integration: issue ephemeral credentials scoped to a single pipeline run, suppress secret values from build logs, and run jobs under service accounts with the narrowest permissions the job needs.
4. Infrastructure as code: avoid writing secrets into Terraform state wherever possible; AWS prescriptive guidance notes that tfstate can hold sensitive values in plaintext, so if a secret does land in state, restrict access to that state file and rotate the secret immediately afterwards.
5. Automation: schedule rotation and attach rotation hooks (a Lambda function or equivalent) so credentials change without manual intervention, and confirm that every consumer can handle a rollover gracefully rather than failing on the old value.
6. Networking: route secrets API traffic over private endpoints, such as AWS PrivateLink or VPC endpoints, and restrict network paths so only authorised workloads can reach the secrets service at all.

A few supporting habits make this checklist durable rather than a one-off cleanup:

• Tag every secret with an owning team and a rotation cadence at creation time, not retroactively.
• Fail builds automatically when a secret-scanning check detects a credential pattern in a commit.
• Treat any secret that appears in a log, ticket or chat message as compromised and rotate it, regardless of how it got there.

None of these steps is exotic engineering. What tends to fail is sequencing: teams automate rotation before they have finished discovery, or they lock down network paths before CI/CD has stopped printing secrets to logs. Working through the list in order avoids most of that churn.

Secrets management versus cryptographic key management

Secrets management and cryptographic key management solve adjacent but distinct problems, and conflating them leads to the wrong tool being specified for the job. A secrets manager stores and serves credentials and tokens, strings and blobs that applications consume as-is. A cryptographic key management system (CKMS) governs the full lifecycle of cryptographic keys: generation, distribution, usage, storage and eventual destruction.

NIST SP 800-57 sets the standard for the latter, distinguishing key management from general secrets handling and requiring automated lifecycle controls for cryptographic keys rather than manual oversight. Google Cloud’s own documentation draws the same line: secrets managers handle confidential configuration data, while key management systems focus specifically on cryptographic key lifecycle, and the two sometimes need separate tooling entirely.

• Use a secrets manager for API keys, database passwords, OAuth tokens and similar runtime credentials.
• Use a key management system, and a hardware security module (HSM) or bring-your-own-key (BYOK) arrangement where regulatory or contractual terms demand it, for encryption keys that protect data at rest or in transit.
• Treat the two as complementary layers: a secrets manager might itself be encrypted using keys governed by a CKMS underneath it.

Operational governance: policy, monitoring and incident response

Technology alone does not sustain a secrets programme; governance does. A workable policy defines naming conventions, assigns an owner to every secret, sets a rotation cadence appropriate to its sensitivity, and specifies when a secret gets retired rather than left dormant indefinitely.

• Monitoring: route secrets access logs into a central SIEM and alert on anomalous access patterns, such as a sudden spike in reads from a principal that normally fetches a credential once a day.
• Incident response: on any suspected exposure, rotate the affected secret immediately, revoke the specific session or token rather than an entire service account where possible, and preserve logs for forensic review.
• Third-party risk: issue vendors and partners limited-scope credentials rather than broad access, prefer cross-account IAM roles over shared static keys, and segment networks so a compromised partner integration cannot reach unrelated systems.

Given that the 2025 DBIR puts median remediation at 94 days, the governance layer’s main job is compressing that number, through faster detection, clearer ownership and rehearsed incident playbooks, rather than adding more policy documentation that nobody consults during an actual breach.

Pro Tip: Run tabletop exercises against simulated leaked credentials; the gap between a written incident playbook and a team that can execute it under pressure only shows up when you test it.

How we approach secrets management engagements

A typical engagement starts with discovery: a structured inventory of every credential, token and certificate across an organisation’s repositories, pipelines and infrastructure, often surfacing exposures that predate the audit by months. From there, short-term remediation closes the most urgent gaps, rotating anything found exposed and removing hardcoded credentials from active code paths.

Longer-term work focuses on automation and durability: wiring rotation into CI/CD, hardening Terraform state handling, and integrating secrets audit logs into existing monitoring. The deliverables we aim for are concrete: a complete secrets inventory, automated rotation for the credentials that matter most, and runbooks the internal team can run without us once the engagement ends.

What this work actually requires from an organisation

The technical patterns here are well documented. What slows adoption is rarely the architecture, it is ownership disputes over who rotates what, legacy secrets nobody wants to touch for fear of breaking production, and CI/CD pipelines too tangled to retrofit cleanly. A realistic plan starts with discovery and quick wins, then adds automated rotation for the highest-risk credentials and monitoring integration as the work progresses.

— Pepe F.

How Vicedomini Softworks can support your secrets management programme

We bring the same engineering-first model to secrets management that we apply across our work: you talk directly to the engineers doing the discovery, the remediation and the automation, not to an account manager relaying updates secondhand. For organisations preparing production workloads or cleaning up after years of ad hoc credential sprawl, that direct line tends to shorten the distance between finding a problem and fixing it.

Our relevant services cover the full arc of this problem:

• Code audit and technical debt review to surface hardcoded secrets and insecure patterns across an existing codebase.
• Architecture and technology stack work to design the runtime retrieval, rotation and IAM role structure a secrets programme needs.
• Custom software development to build rotation hooks, CI/CD integration and monitoring that fit your existing stack rather than forcing a rebuild.
• CTO Advisory, for organisations that want ongoing architectural guidance without a full-time hire.

If you want a structured starting point, our initial assessment can help you define next steps before any longer engagement begins. You can review the full range of options and get in touch through our CTO in abbonamento page.

FAQ

What is cloud secrets management?

Cloud secrets management is the centralised, API-gated control of credentials, tokens, certificates and other sensitive configuration, with encryption, access control and auditing built in. The dominant practice, per AWS Well-Architected guidance, is to remove secrets where possible, replace what remains with short-lived credentials, and rotate everything else on a schedule.

What is the difference between a vault and a secrets manager?

In practice, “vault” and “secrets manager” describe the same category of tool: a centralised, encrypted store for credentials with access control and audit logging. Vendors differ in features such as dynamic secret generation, rotation extensibility and deployment model, but the underlying job, keeping secrets out of code and configuration files, is the same.

Why do leaked API keys and tokens matter so much?

Leaked credentials give an attacker direct access without needing to exploit a separate vulnerability first. The 2025 DBIR found that web application infrastructure accounts for a notable share of disclosed secrets, with JWTs making up a majority of that category, and that leaked secrets in public repositories can take a long time to remediate, creating a window for misuse.

How is secrets management different from key management?

Secrets management handles credentials and tokens that applications consume directly, while key management, governed in detail by NIST SP 800-57, covers the full lifecycle of cryptographic keys, from generation to destruction. The two are complementary: a secrets store is sometimes itself encrypted with keys that a separate key management system controls.

How often should secrets be rotated?

Rotation cadence should match a secret’s sensitivity and blast radius rather than a single fixed rule, with the highest-privilege credentials rotated most frequently and automatically wherever the secrets platform supports it. AWS guidance treats automated rotation as a baseline requirement rather than an optional enhancement for any credential that cannot be removed entirely.

Sources

• 2025 Data Breach Investigations Report
• SEC02-BP03 Store and use secrets securely
• SP 800-57 Rev. 6, Recommendation for Key Management: Part 1 – General | CSRC

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.