Lambda code signing verifies that a new deployment package was signed by a trusted source and has not been modified since. It blocks unsigned or tampered packages when set to Enforce. It does not tell you whether the signed code or its dependencies are safe, and it does not touch code that is already running.
What gets checked
When you attach a code signing configuration to a function, Lambda verifies new deployments using AWS Signer. The checks run at deployment time, so there is no impact on function execution. AWS lists four validations:
- Integrity: the package has not changed since signing, by comparing hashes.
- Expiry: the signature has not expired.
- Mismatch: the package was signed with an allowed signing profile.
- Revocation: the signature has not been revoked.
The UntrustedArtifactOnDeployment setting decides what happens if expiry, mismatch or revocation checks fail. Warn is the default: the deployment goes ahead, with a CloudWatch metric called SignatureValidationErrors and a CloudTrail entry. Enforce does the same and also blocks the deployment.
Two details matter. First, AWS says code signing applies to functions deployed as zip or container image packages. Second, when you turn it on, any layers you add to the function must also be signed by an allowed signing profile.
What it stops
- Someone with deploy permission uploading a package built on their laptop.
- A tampered artifact swapped between the build system and the deployment step.
- A package signed by a key you did not approve.
- A signature that was revoked after a key problem.
This is real protection for the pipeline to function step, and it pairs well with limiting who can sign.
What it does not stop
- Existing code. AWS states that a configuration only prevents new deployments of unsigned code. If you add one to a function that already runs unsigned code, that code keeps running until you deploy a new package.
- Vulnerable dependencies. A package that bundles a library with a known flaw can be signed perfectly well.
- A compromised build. If the build job that holds the signing permission is compromised, malicious code gets signed.
- Weak mode. On the default Warn setting, failures are logged and deployment continues.
Signing proves who produced the artifact. It does not prove what is inside.
A sensible setup
- Create a signing profile used only by your release pipeline.
- Grant sign permission to the pipeline role, not to people.
- Attach a code signing configuration and set it to Enforce once you have run in Warn for a while and fixed the noise.
- Sign layers with an allowed profile too.
- Watch the SignatureValidationErrors metric and alert on it.
- Add a separate step that scans dependencies before signing, so only reviewed content gets a signature.
Click through it at your own pace, or open it full screen.
Quick check
Does enabling code signing re-verify my running functions?
No. Only new deployments are checked. Existing unsigned code keeps running until you deploy a new package.
Is Warn mode enough?
It gives visibility but does not block anything. Use Enforce when you want the control to be a gate.
Safeguard's dependency scanning and policy gates can sit before the signing step, and the free scan is a quick first look.
Sources
Last reviewed: 19 October 2026.
