Teams inherit avoidable risk because vulnerable packages, exposed secrets, and overprivileged functions may already be deployed before controls see them. Runtime monitoring is still necessary, but it is a second layer, not a substitute for prevention. Without CI/CD checks, the organisation spends more time responding to misconfigurations that could have been blocked earlier.
Why runtime-only controls leave the weakest point unguarded
When serverless security starts only after deployment, the riskiest defects are already in the execution path. Runtime sensors can alert on abuse, but they do not prevent vulnerable dependencies, hardcoded credentials, excessive permissions, or unsafe configuration from reaching production in the first place.
The practical problem is timing: serverless functions are short-lived, ephemeral, and often deployed in high volume, so the blast radius can grow quickly when security checks are deferred. Runtime visibility is useful, but it is not a substitute for prevention in the pipeline.
What CI/CD must catch before a function ever runs
CI/CD is the control point that can block known-bad artefacts before they become live attack surface. That includes secret scanning, dependency review, policy checks for infrastructure templates, permission review for function roles, and validation of packaging and source integrity. If these checks are missing, runtime becomes the first meaningful place where the organisation notices a problem, which is usually too late for clean prevention.
This matters especially for serverless because a small code change, dependency update, or template edit can introduce disproportionate exposure. A function that looks harmless in development can still invoke sensitive services, exfiltrate data, or reach internal resources once deployed with broad permissions or leaked tokens.
Why runtime monitoring still matters, but only as a second layer
Runtime controls remain necessary because not every issue is visible before release. Suspicious invocations, anomalous API calls, unusual network destinations, and privilege abuse can still be detected after deployment, and that is often where containment begins. But runtime monitoring is detection and response, not a replacement for build-time guardrails.
The strongest operating model is layered: use CI/CD to stop preventable weaknesses, then use runtime monitoring to detect what escaped, what changed unexpectedly, and what was abused after release. That division of labour reduces both exposure time and mean time to containment.
Risk and Threat Considerations
Runtime-only protection creates a predictable gap between introduction of a weakness and its detection. In serverless environments, that gap can be enough for exposed secrets, overprivileged roles, or vulnerable packages to be exercised immediately after deployment, before investigators have a clean chance to block or quarantine them.
Failure mechanism: Security checks that run only after release allow misconfigured functions, leaked credentials, and dangerous dependencies to become live attack paths. Attackers and opportunistic abuse do not wait for the monitoring stack to catch up, especially when deployment is automated and execution begins almost immediately.
Impact: The organisation absorbs avoidable compromise potential, faster lateral access through overbroad permissions, and more expensive incident response. The longer the gap between deployment and detection, the more likely remediation becomes reactive cleanup instead of controlled prevention.
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 and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CI/CD secret scanning directly addresses leaked secrets in serverless releases. |
| NHI-05 — Overprivileged NHI | Overprivileged serverless functions are a central pre-deploy risk in this question. | |
| NHI-07 — Long-Lived Secrets | Runtime-only handling leaves long-lived secrets in deployed code or config without early control. | |
| Recommendation — Scan builds and deployment inputs for secrets before release and block any exposed credentials. Review function permissions in CI/CD and fail deployments that exceed least privilege. Enforce secret rotation and short-lived credentials before artefacts reach runtime. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Serverless misconfiguration is prevented most effectively through pipeline policy and configuration checks. |
| CIS-7 — Continuous Vulnerability Management | Dependency review in CI/CD is needed to stop vulnerable packages reaching production. | |
| Recommendation — Validate serverless configuration in CI/CD and block insecure defaults before deployment. Scan dependencies during build and deployment and reject releases with known critical flaws. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Build-time testing and evaluation are needed to catch flaws before serverless deployment. |
| CM-3 — Configuration Change Control | The question centers on preventing insecure changes from reaching production through CI/CD. | |
| Recommendation — Integrate pre-release testing that validates serverless code, dependencies, and configuration. Require approval and validation for serverless configuration changes before deployment. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Serverless functions expose API-like attack surface when insecure configuration is deployed. |
| API2 — Broken Authentication | Leaked credentials and poor secret handling can undermine authentication to serverless services. | |
| Recommendation — Validate function and API configuration before release to stop misconfiguration from going live. Fail builds that introduce exposed or weak authentication material into serverless deployments. | ||
| SLSA | Supply chain integrity | Preventing bad artefacts before runtime depends on build provenance and deployment integrity. |
| Recommendation — Verify build provenance and enforce artifact integrity checks before deploying serverless workloads. | ||
Practitioner Guidance
What to prioritise: Put secret scanning, dependency checks, and least-privilege review into the pipeline gate before runtime alerting is considered complete. For serverless, the most useful pre-deploy checks are the ones that stop a function from shipping with credentials, unvetted packages, or permission sprawl.
What to verify: Confirm that CI/CD is actually blocking failed checks rather than just reporting them, and that function roles are reviewed with the same discipline as code. If a control only raises a ticket after deployment, it is a detection aid, not a preventive safeguard.
Practitioner takeaway: Treat runtime as the backstop. If the pipeline cannot stop a bad function from shipping, the organisation is relying on detection to compensate for preventable exposure, and that is a weaker security posture than most teams realise.
Related resources from NHI Mgmt Group
- What happens when self-hosted CI/CD runners are left without runtime security and access controls?
- What happens when Kubernetes security is handled after deployment instead of in CI/CD and design?
- How should security teams implement runtime credential brokering for CI/CD workloads?
- How should security teams implement runtime testing in CI/CD pipelines?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
