What are the signs that a serverless function may have been tampered with?

Common warning signs include unusual invocation frequency, unexpected changes in execution duration, and repeated execution errors. Those signals can indicate that the function is behaving outside its normal pattern, especially when combined with changes to code, permissions, or stored secrets. Correlation across these indicators is more useful than any single metric alone.

How to read the warning signs of serverless tampering

For serverless function, tampering often shows up as a pattern shift rather than a single obvious alert. Watch for invocation spikes that do not match normal traffic, execution times that drift without an application change, and error bursts that appear after a deployment should have stabilised. Those are the first clues that the runtime, code path, or dependencies may have been altered.

The strongest signal is correlation. A function that runs longer, fails more often, and suddenly starts touching new resources is more suspicious than any one metric on its own. In practice, that combination usually points to code injection, altered configuration, poisoned dependencies, or a changed identity boundary such as permissions or secrets.

What changes in the runtime usually accompany tampering?

Serverless tampering often leaves behavioural residue in the execution environment. That can include cold starts appearing at odd intervals, new outbound destinations, unexpected library loads, or function output that changes without a corresponding code release. If logging, tracing, or monitoring is already in place, those traces often reveal the exact step where the normal execution path diverged.

Configuration drift matters as much as code drift. A function may still deploy successfully while its environment variables, event triggers, layers, or attached permissions have been modified in a way that changes behaviour. That is why investigators should compare the active runtime state with the last known good deployment state, not just review the source repository.

When secrets are involved, tampering can also appear as authentication failures, token misuse, or calls to services the function never previously accessed. A function that suddenly begins reading different storage buckets, queueing unexpected jobs, or invoking administrative APIs deserves immediate review because those are signs that the trust boundary has changed.

Which indicators are most useful for confirming suspicion?

The most useful indicators are the ones that move together: unusual invocation frequency, altered duration, repeated exceptions, and a change in downstream dependencies. A single deviation can be noise, but a cluster of deviations usually means the function is either malfunctioning or being used in a way the original owner did not intend.

Compare those signals with deployment history, permission changes, and secret rotation events. If the metrics changed after an unrelated access change, a failed rollback, or the introduction of a new integration, the issue may be operational rather than malicious. If the same pattern appears without any authorised change, the probability of tampering rises quickly.

For deeper investigation, teams often start by checking the function package, trigger configuration, environment variables, and any external dependencies that were added recently. Cloud Workload Identity Guide is useful here because many serverless compromises become visible only when you examine how the function authenticates to other services and whether that trust has been widened.

Risk and Threat Considerations

Serverless tampering is risky because the attack surface is distributed across code, configuration, triggers, and runtime permissions. An attacker does not need to replace the whole function to cause harm, only to alter the part that changes what it can reach, what it can read, or how often it runs.

Failure mechanism: A malicious change can be introduced through deployment compromise, poisoned dependencies, exposed secrets, or an overprivileged execution role, then hidden inside normal autoscaling and event-driven behaviour.

Impact: The result can be data exposure, unauthorized downstream actions, elevated cloud cost, or a persistence path that remains active until code, permissions, and secrets are all checked together.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1059 — Command and Scripting Interpreter	Tampered functions often run altered code paths or injected logic.
Recommendation — Map unexpected execution paths to T1059 and inspect for injected script or code execution.
NIST CSF 2.0	DE.AE-01 — Anomalous Events are detected	Invocation spikes and duration drift are anomaly signals for tampering.
Recommendation — Correlate runtime anomalies to DE.AE-01 and alert on deviations from normal function behaviour.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	Tampering often appears as drift from the approved function baseline.
	SI-4 — System Monitoring	Runtime anomalies and suspicious dependencies require continuous monitoring.
	AC-6 — Least Privilege	Overprivileged function roles increase the damage from tampering.
Recommendation — Compare deployed function state against CM-2 baselines before trusting runtime behaviour. Use SI-4 monitoring to flag abnormal invocation, timing, and downstream access patterns. Apply AC-6 to limit the function’s permissions to the minimum needed.

Practitioner Guidance

What to prioritise: Start with a three-way comparison, current metrics, last known good deployment, and current permissions. If the function changed behaviour without an approved release, treat the runtime as suspect even if the source repository looks clean.

What to verify: Confirm whether the function’s invocation source, environment variables, attached role, and secret values still match the intended design. A clean code diff does not rule out tampering if the deployed configuration or identity path has changed.

Common mistake: Teams often chase the error spikes first and delay the permissions review. For serverless, that is backwards, because a small identity or secret change can explain both the strange execution pattern and the observed failures.

Practitioner takeaway: Treat behavioural anomalies as a clue, not proof. The real test is whether the function’s code, configuration, and access path still align with the trust boundary you intended to deploy.