Sylwia’s post — est. reading time: 9 minutes

Introduction

As organisations race to modernise and adopt serverless computing and event-driven architectures, they unlock a new realm of agility, scalability, and cost efficiency. These paradigms promise frictionless scaling, near-instant execution, and seamless responsiveness to real-time demands. However, buried within these advances lies a subtle but growing threat—secrets in motion. Unlike static infrastructures, these new architectures operate on transient workloads, with credentials moving rapidly between services, environments, and memory states. And therein lies the risk: secrets are no longer only at rest—they are constantly in flight, dynamic, and difficult to govern.

Traditional secrets management frameworks, built for infrastructure that persists, struggle in this new domain. In serverless and event-driven environments, there is no permanent container to protect, no fixed boundary to monitor, and no clear timeline for execution. The very features that make these architectures powerful—their ephemerality, scalability, and decentralisation—also render secrets management complex and error-prone.

The Growing Complexity of Serverless Security

Serverless functions do not operate in isolation. They are often components of wider event-driven systems, where one event triggers another, often across multiple services, accounts, or even platforms. This introduces an environment of extreme fluidity. Secrets such as API keys, tokens, and database credentials may be injected at runtime, passed between event handlers, and potentially logged or cached—often without central oversight. The velocity of change, coupled with the invisibility of transient data states, makes conventional security tooling ineffective or blind.

Consider the case of a prominent retail technology firm. The company adopted a serverless-first strategy to support dynamic retail operations across global locations. During a routine deployment, a function triggered by a payment event logged a temporary authentication token to an observability platform. The token, designed to expire within minutes, was accessible via a shared dashboard. An internal user, with no privileged access, retrieved the token and leveraged it to access sensitive customer routing data. There was no breach of the secrets vault. Instead, there was an inadvertent creation of an unguarded path—a secret exposed mid-flight, logged unintentionally in a place no one thought to look.

Secrets in Motion: What Makes the Threat Unique

What makes secrets in motion such a persistent problem is not just technical—it’s architectural. In a traditional setup, secrets live in well-defined locations: environment files, vaults, encrypted databases. Access patterns are known. Monitoring can be comprehensive. But in a serverless architecture:

• Secrets are often ephemeral, existing only for the lifespan of a function execution—sometimes just milliseconds.
• They may be passed via environment variables, dynamically fetched from secrets managers, or embedded by accident in source code.
• Logging systems, monitoring tools, and error handlers may inadvertently store secrets in plaintext during error capture or performance tracing.

Secrets are no longer just data at rest—they are part of the runtime fabric. This introduces a shift in thinking. We must now protect secrets in motion, not merely in storage.

Why Traditional DevSecOps Breaks Down

DevSecOps practices evolved alongside long-lived virtual machines and containers—resources that persisted long enough to scan, secure, and audit. Static analysis, infrastructure as code scanning, and runtime intrusion detection made sense in those contexts. But serverless and event-driven systems behave differently. They spawn fast, execute autonomously, and vanish before traditional tooling can take effect. Moreover, function code is often stored in source control, CI/CD systems, and artifact repositories—each a potential vector for secret exposure if not properly governed.

In many cases, DevSecOps teams rely on post-deployment scans or centralised secrets vaults. Yet in these modern pipelines, secrets may bypass the vault entirely. They may be fetched in real-time from APIs, rotated by external triggers, or composed on-the-fly from multiple systems. Secrets become transient and distributed—hard to track, harder to revoke.

Case Study: The Phantom Token Trail

One global logistics provider discovered the consequences of misplaced secrets when their event-driven fulfilment engine began throwing errors during peak season. A developer had added a debug log in a retry handler to trace failed deliveries. Unbeknownst to them, the function also logged temporary access credentials retrieved from an identity service. The logs were retained for diagnostics and shared with a vendor support team. The vendor, while legitimate, had no authorisation to access live systems. But the logs gave them access nonetheless—briefly, and without intent.

The resulting breach didn’t stem from malice or poor infrastructure—it stemmed from a failure to design for motion. Secrets, in this case, travelled through systems not designed to protect them. Detection came too late. Revocation took too long. The vendor had acted in good faith, but trust had already been compromised.

Securing Secrets at the Speed of Events

The modern enterprise must now approach secrets management not as a static control but as a dynamic capability. Secrets need to travel securely, with policies and automation that align to the velocity of serverless and event-based execution.

Key strategies include:

1. Runtime Injection with Secure Boundaries

Secrets should be fetched dynamically at runtime via secure channels and access policies based on identity and context. Static injection—embedding secrets in code or configuration—must be eliminated.

2. Never Log, Never Cache, Never Store

Organisations must enforce strict controls on how logs are handled across observability and monitoring platforms. Sensitive data should never be logged, even during failures. Logging systems should include filters and redaction mechanisms to prevent the capture and storage of secrets. Similarly, secrets must not be cached in memory, persisted across invocations, or exposed to downstream services unintentionally.

3. Real-Time Revocation and Rotation

Secrets must be revocable and rotatable in real time. When misuse is detected or compromise is suspected, credentials should be rendered invalid immediately. This requires integration between runtime monitoring, authentication infrastructure, and secrets provisioning logic.

4. Automated Guardrails in CI/CD Pipelines

CI/CD pipelines must be equipped to detect secrets in code, templates, or environment files at every stage of deployment. Beyond detection, pipelines should be capable of halting deployments, flagging violations, and enforcing best practices through policy-as-code.

5. Principle of Least Privilege for Everything

Each function or event handler should operate with only the permissions it strictly needs. Overly broad roles and permissions widen the impact of an exposed secret. Fine-grained, context-aware access controls should be the standard, not the exception.

The Role of Engineering Culture in Secret Hygiene

Technical enforcement must be matched by a culture of accountability and awareness. Developers should understand the risks of secrets in motion and avoid practices such as hardcoding credentials, sharing secrets informally, or exposing sensitive data in logs. Code reviews, automated checks, and team training all contribute to a culture where secrets management is a first-class design consideration.

Reusable patterns and templates should be developed across the engineering organisation, reflecting security by design. When a new service is deployed, the default should be secure secret handling—not an afterthought.

Bringing CIOs into the Secrets Conversation

CIOs must move beyond infrastructure oversight and into digital trust orchestration. Securing credentials is no longer simply an operational matter—it is central to protecting customer data, brand integrity, and enterprise agility.

Ask the strategic questions:

• Are we tracking where secrets are used, not just where they’re stored?
• Do our architectures make it easy to detect misuse and revoke credentials quickly?
• Have we aligned our tooling and governance to match the transience of modern workloads?
• Are we building trust into every transaction—or simply hoping for security by default?

Conclusion: Building for Transience Without Compromise

Ephemeral systems require permanent diligence. As functions scale in seconds and events cascade across platforms, secrets must remain safeguarded in motion as well as at rest. The ability to secure these dynamic credentials is now a key measure of security maturity.

Organisations that combine technical rigour with cultural awareness—and align both to the realities of serverless and event-driven design—will not only avoid breaches, but earn trust.

So the question for the business is this: In a world where services live for seconds and secrets are everywhere—are you architecting for control, or simply hoping for containment?