CI/CD security focuses on preventing known problems before release, such as vulnerable code, malware, misconfigurations, embedded secrets, and excessive permissions. Runtime security focuses on what the function is allowed to do after deployment, using controls such as activity whitelisting and inspection of live execution behaviour. Effective serverless defence needs both layers, because each catches a different class of risk.
Why CI/CD and runtime serverless security are different controls
Securing Lambda in CI/CD is about stopping bad code, bad configuration, and bad secrets before they are released. That includes scanning source, build artefacts, dependencies, and deployment manifests so the function arrives with fewer flaws and less privilege than it started with. Runtime security starts after deployment, when the real question is what the function can actually do, and whether its live behaviour matches that expectation.
That difference matters because CI/CD can only inspect what is known at build or release time, while runtime has to deal with live traffic, live credentials, and live abuse. A function can be built from clean code and still be dangerous if it is over-permissioned, invoked unexpectedly, or coerced into making calls it should not make.
For serverless environments, the security boundary therefore shifts. Build-time controls reduce the chance that you ship a known defect; runtime controls reduce the impact if the deployed function is misused, manipulated, or exposed through an overlooked path. The strongest programmes treat those as complementary layers, not substitutes.
What each layer is best at catching
CI/CD security is strongest at static and repeatable checks. It is the place to catch vulnerable dependencies, embedded secrets, misconfigured deployment templates, insecure defaults, and overly broad permissions before those issues are propagated into production. It is also where supply-chain integrity matters most, because the build path determines what code and configuration will be trusted at release.
Runtime security is strongest at observing behaviour, not intent. It can detect abnormal API calls, unexpected data access, suspicious network destinations, and execution patterns that do not belong to the function’s approved purpose. For Lambda, that often means constraining or inspecting what the function is allowed to do after it starts, rather than assuming the release pipeline already guaranteed safe behaviour.
These layers answer different questions. CI/CD asks, “Should this be released?” Runtime asks, “Should this be doing that right now?” When the same control is asked to answer both, blind spots appear quickly.
For build integrity and release provenance, practitioners often pair pipeline controls with supply-chain guidance such as SLSA. For runtime risk, the relevant focus shifts to live enforcement and observability, which is why NIST SP 800-190 Container Security remains a useful reference even when the workload is serverless, because it separates image and build trust from runtime behaviour and control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 2 — Inventory and Control of Software Assets | Covers build-time dependency and artifact governance for Lambda delivery. |
| CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Applies to Lambda deployment templates, permissions, and secure defaults in CI/CD. | |
| CIS Control 8 — Audit Log Management | Supports runtime visibility into Lambda execution and suspicious behaviour. | |
| Recommendation — Inventory and approve build inputs before deployment to reduce release of untrusted code. Harden deployment configuration and enforce secure defaults before release. Centralise and review function activity logs to spot unexpected execution patterns. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Relevant to protecting secrets and sensitive data in build and runtime paths. |
| PR.AC — Access Control | Applies to restricting Lambda permissions and limiting live action at runtime. | |
| DE.CM — Continuous Monitoring | Supports runtime detection of unusual Lambda behaviour and misuse. | |
| Recommendation — Protect secrets and sensitive data across pipeline and execution environments. Restrict function permissions so deployed code can only access approved resources. Monitor live function activity for deviations from expected behaviour. | ||
Practitioner Guidance
What to prioritise: Start by deciding which failures are most expensive in your environment: bad code reaching production, or good code being abused after release. If the dominant concern is secret leakage, dependency risk, or release integrity, put more effort into pipeline gates and artifact provenance. If the dominant concern is post-deploy misuse, prioritise runtime allowlisting, event-level visibility, and privilege reduction.
What to verify: Check whether your CI/CD controls actually prevent release of embedded credentials, excessive permissions, and untrusted dependencies, or whether they only report them after the fact. Then verify that runtime controls are tied to observed Lambda behaviour, not just generic cloud logging, so blocked or unexpected actions can be distinguished from normal execution.
Common mistake: Teams often assume a hardened pipeline makes runtime controls optional. In practice, serverless functions are frequently exposed through event sources, permissions, and integrations that only become meaningful once the function is live. A clean build does not reduce the blast radius of a compromised invocation path.
Practitioner takeaway: Treat CI/CD as the filter for what should be deployed, and runtime as the brake for what is allowed to happen after deployment. You need both, because they fail in different ways and protect against different classes of Lambda risk.
Related resources from NHI Mgmt Group
- What is the difference between CI/CD security assessment and runtime guardrails for AI applications?
- What is the difference between syncing secrets into GitLab CI/CD variables and fetching them at runtime with OIDC?
- What is the difference between shift-left security and runtime security in CI/CD pipelines?
- What is the difference between securing IDE and CLI agents and securing headless agents in CI/CD?
