[{"data":1,"prerenderedAt":87},["ShallowReactive",2],{"content-svc-lambda-guides-governance-5-code-signing":3},{"markdown":4,"frontMatterAttributes":5,"bodyRaw":10,"menu":11,"menuType":81,"isCollapseableMenu":14,"nextDocItem":59,"previousDocItem":46,"contributorPaths":82,"contentName":86,"slug":58,"readingTime":55},"\u003Cp>\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fsigner\u002Flatest\u002Fdeveloperguide\u002FWelcome.html\">AWS Signer\u003C\u002Fa> is a fully managed code-signing service that allows you to validate your code against a digital signature to confirm that code is unaltered and from a trusted publisher. Signer can be used in conjunction with AWS Lambda to verify that functions and layers are unaltered prior to deployment into your AWS environments. This protects your organization from malicious actors who might have gained credentials that allow him or her to create new or update existing functions.\u003C\u002Fp>\n\u003Cp>To set up code signing for your Lambda functions, you’ll first need to start by creating an S3 bucket with versioning enabled. After that, you create a signing profile with Signer, specific Lambda as the platform and then specify a period of days in which the signing profile is valid, e.g. 30 days.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">  Signer:\n    Type: AWS::Signer::SigningProfile\n    Properties:\n      PlatformId: AWSLambda-SHA384-ECDSA\n      SignatureValidityPeriod:\n        Type: DAYS\n        Value: !Ref pValidDays\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You then use the signing profile and create a signing configuration with Lambda. You then have to specify what to do when the signing configuration sees an artifact that does not match a digital signature that it expected: warn (but allow the deployment) or enforce (and block the deployment). The example below is configured to enforce (and block deployments).\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">  SigningConfig:\n    Type: AWS::Lambda::CodeSigningConfig\n    Properties:\n      AllowedPublishers:\n        SigningProfileVersionArns:\n          - !GetAtt Signer.ProfileVersionArn\n      CodeSigningPolicies:\n        UntrustedArtifactOnDeployment: Enforce\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You now have Signer configured with Lambda to block untrusted deployments. Let’s assume you’ve finished coding up a feature request and are now ready to deploy the function. The first step is to zip the code up with the appropriate dependencies and then sign the artifact using the signing profile that you created. You can do this by uploading the zip artifact to the S3 bucket and then starting a signing job.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>aws signer start-signing-job \\\n--source 's3={bucketName=your-versioned-bucket,key=your-prefix\u002Fyour-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \\\n--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix\u002F}' \\\n--profile-name your-signer-id\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You get an output as follows, where the \u003Ccode>jobId\u003C\u002Fcode> is the object that is created in the destination bucket and prefix and \u003Ccode>jobOwner\u003C\u002Fcode> is the 12-digit account id where the job was run.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-json\">{\n  "jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",\n  "jobOwner": "123456789012"\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>And now you can deploy your function using the signed S3 object and the code signing configuration that you created.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-yaml\">  Fn:\n    Type: AWS::Serverless::Function\n    Properties:\n      CodeUri: s3:\u002F\u002Fyour-versioned-bucket\u002Fyour-prefix\u002F87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip\n      Handler: fn.handler\n      Role: !GetAtt FnRole.Arn\n      CodeSigningConfigArn: !Ref pSigningConfigArn\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You can alternatively test a function deployment with the original unsigned source zip artifact. The deployment should fail with the following message:\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>If you are building and deploying your functions using AWS SAM, the package command handles uploading the zip artifact to S3 and also handles starting the signing job and getting the signed artifact. You can do this with the following command and parameters.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>sam package -t your-template.yaml \\\n--output-template-file your-output.yaml \\\n--s3-bucket your-versioned-bucket \\\n--s3-prefix your-prefix \\\n--signing-profiles your-signer-id\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Signer allows you to verify that zip artifacts that are deployed into your accounts are trusted for deployment. You can include the process above in your CI\u002FCD pipelines and require that all functions have a code signing configuration attached using the techniques outlined in prior sections. By using code signing with your Lambda function deployments, you prevent malicious actors who might have gotten credentials to create or update functions from injecting malicious code in your functions.\u003C\u002Fp>\n",{"title":6,"order":7,"authors":8},"5. Code Signing with AWS Signer",5,[9],"Heeki Park","[AWS Signer](https:\u002F\u002Fdocs.aws.amazon.com\u002Fsigner\u002Flatest\u002Fdeveloperguide\u002FWelcome.html) is a fully managed code-signing service that allows you to validate your code against a digital signature to confirm that code is unaltered and from a trusted publisher. Signer can be used in conjunction with AWS Lambda to verify that functions and layers are unaltered prior to deployment into your AWS environments. This protects your organization from malicious actors who might have gained credentials that allow him or her to create new or update existing functions.\n\nTo set up code signing for your Lambda functions, you’ll first need to start by creating an S3 bucket with versioning enabled. After that, you create a signing profile with Signer, specific Lambda as the platform and then specify a period of days in which the signing profile is valid, e.g. 30 days.\n\n```yaml\n  Signer:\n    Type: AWS::Signer::SigningProfile\n    Properties:\n      PlatformId: AWSLambda-SHA384-ECDSA\n      SignatureValidityPeriod:\n        Type: DAYS\n        Value: !Ref pValidDays\n```\n\nYou then use the signing profile and create a signing configuration with Lambda. You then have to specify what to do when the signing configuration sees an artifact that does not match a digital signature that it expected: warn (but allow the deployment) or enforce (and block the deployment). The example below is configured to enforce (and block deployments).\n\n```yaml\n  SigningConfig:\n    Type: AWS::Lambda::CodeSigningConfig\n    Properties:\n      AllowedPublishers:\n        SigningProfileVersionArns:\n          - !GetAtt Signer.ProfileVersionArn\n      CodeSigningPolicies:\n        UntrustedArtifactOnDeployment: Enforce\n```\n\nYou now have Signer configured with Lambda to block untrusted deployments. Let’s assume you’ve finished coding up a feature request and are now ready to deploy the function. The first step is to zip the code up with the appropriate dependencies and then sign the artifact using the signing profile that you created. You can do this by uploading the zip artifact to the S3 bucket and then starting a signing job.\n\n```\naws signer start-signing-job \\\n--source 's3={bucketName=your-versioned-bucket,key=your-prefix\u002Fyour-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \\\n--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix\u002F}' \\\n--profile-name your-signer-id\n```\n\nYou get an output as follows, where the `jobId` is the object that is created in the destination bucket and prefix and `jobOwner` is the 12-digit account id where the job was run.\n\n```json\n{\n  \"jobId\": \"87a3522b-5c0b-4d7d-b4e0-4255a8e05388\",\n  \"jobOwner\": \"123456789012\"\n}\n```\n\nAnd now you can deploy your function using the signed S3 object and the code signing configuration that you created.\n\n```yaml\n  Fn:\n    Type: AWS::Serverless::Function\n    Properties:\n      CodeUri: s3:\u002F\u002Fyour-versioned-bucket\u002Fyour-prefix\u002F87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip\n      Handler: fn.handler\n      Role: !GetAtt FnRole.Arn\n      CodeSigningConfigArn: !Ref pSigningConfigArn\n```\n\nYou can alternatively test a function deployment with the original unsigned source zip artifact. The deployment should fail with the following message:\n\n```\nLambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.\n```\n\nIf you are building and deploying your functions using AWS SAM, the package command handles uploading the zip artifact to S3 and also handles starting the signing job and getting the signed artifact. You can do this with the following command and parameters.\n\n```\nsam package -t your-template.yaml \\\n--output-template-file your-output.yaml \\\n--s3-bucket your-versioned-bucket \\\n--s3-prefix your-prefix \\\n--signing-profiles your-signer-id\n```\n\nSigner allows you to verify that zip artifacts that are deployed into your accounts are trusted for deployment. You can include the process above in your CI\u002FCD pipelines and require that all functions have a code signing configuration attached using the techniques outlined in prior sections. By using code signing with your Lambda function deployments, you prevent malicious actors who might have gotten credentials to create or update functions from injecting malicious code in your functions.\n",[12],{"title":13,"collapsible":14,"isCollapsed":14,"content":15},"Governance in Depth",false,[16,28,37,46,53,59,66,73],{"title":17,"order":18,"authors":19,"callout":20,"time":24,"path":25,"id":26,"link":27},"1. Introduction",1,[9],{"title":21,"description":22,"link":23},"Watch this video","This reinvent 2023 video covers the topics of this guide in further detail.","https:\u002F\u002Fyoutu.be\u002Fqlz15v-gHFI","5 min","1-introduction","1-introduction.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F1-introduction",{"title":29,"order":30,"authors":31,"time":33,"path":34,"id":35,"link":36},"2. Proactive Controls with AWS CloudFormation Guard",2,[9,32],"Pallavi Srivastava","4 min","2-proactive-guard","2-proactive-guard.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F2-proactive-guard",{"title":38,"order":39,"authors":40,"time":42,"path":43,"id":44,"link":45},"3. Proactive Controls with AWS Config",3,[41],"Debasis Rath","6 min","3-proactive-config","3-proactive-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F3-proactive-config",{"title":47,"order":48,"authors":49,"time":24,"path":50,"id":51,"link":52},"4. Detective Controls with AWS Config",4,[41],"4-detective-config","4-detective-config.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F4-detective-config",{"title":6,"order":7,"authors":54,"time":55,"path":56,"id":57,"link":58},[9],"3 min","5-code-signing","5-code-signing.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F5-code-signing",{"title":60,"order":61,"authors":62,"time":55,"path":63,"id":64,"link":65},"6. Code Scanning with Amazon Inspector",6,[32],"6-code-scanning","6-code-scanning.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F6-code-scanning",{"title":67,"order":68,"authors":69,"time":42,"path":70,"id":71,"link":72},"7. Observability for Security and Compliance",7,[41],"7-observability","7-observability.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F7-observability",{"title":74,"order":75,"authors":76,"time":77,"path":78,"id":79,"link":80},"8. Discussion of Open Source and other AWS tools",8,[9],"1 min","8-open-source-and-other-tools","8-open-source-and-other-tools.md","\u002Fcontent\u002Fservice\u002Flambda\u002Fguides\u002Fgovernance\u002F8-open-source-and-other-tools","LIST",[83,84,85],"content\u002Fcontributors\u002Fheeki-park.json","content\u002Fcontributors\u002Fdebasis-rath.json","content\u002Fcontributors\u002Fpallavi-srivastava.json","Implementing governance in depth for serverless applications",1792578874322]