Going Further with SLSA

The SLSA security framework (pronounced salsa, short for Supply chain Levels for Software Artifacts) is “a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure.” SLSA is all about going from “safe enough” to maximum resiliency across the entire software supply chain.

If you’re at a fairly high level of security maturity, you may find it useful to use this framework to measure and improve the security of your software supply chain. Follow the SLSA documentation to get started. The Software Component Verification Standard (SCVS) from OWASP is another framework for measuring supply chain security.

Lambda Code Signing

The last mile in the software supply chain is packaging and deploying your function code to the cloud. At this point, your function will usually consist of your business logic (code you have authored) and any third-party libraries listed in the function’s dependencies (code someone else has authored).

Lambda provides the option to sign your code before deploying it. This enables the Lambda service to verify that a trusted source has initiated the deployment and that the code has not been altered or tampered with in any way. Lambda will run several validation checks to verify the integrity of the code, including that the package has not been modified since it was signed and that the signature itself is valid.

To sign your code, you first create one or more signing profiles. These profiles might map to the environments and accounts your application uses—for example, you may have a signing profile per AWS account. Alternatively, you could opt to have a signing profile per function for greater isolation and security. The CloudFormation resource for a signing profile looks like this, where the PlatformID denotes the signature format and signing algorithm that will be used by the profile:

{
“Type”
:
“AWS::Signer::SigningProfile”
,
“Properties”
:
{
“PlatformId”
:
“AWSLambda-SHA384-ECDSA”
,
}
}

Once you have defined a signing profile, you can then use it to configure code signing for your functions:

{
“Type”
:
“AWS::Lambda::CodeSigningConfig”
,
“Properties”
:
{
“AllowedPublishers”
:
[
{
“SigningProfileVersionArns”
:
[
“arn:aws:signer:us-east-1:123456789123:/signing-profiles/my-profile”
]
}
],
“CodeSigningPolicies”
:
{
“UntrustedArtifactOnDeployment”
:
“Enforce”
}
}
}

Finally, assign the code signing configuration to your function:

{
“Type”
:
“AWS::Lambda::Function”
,
“Properties”
:
{
“CodeSigningConfigArn”
:
[
“arn:aws:lambda:us-east-1:123456789123:code-signing-config:csc-config-id”
,
]
}
}

Now, when you deploy this function the Lambda service will verify the code was signed by a trusted source and has not been tampered with since being signed.