Running depreciated AWS Lambda runtimes incurs both security and operational risks as well as upgrade risk should the service owner force an update to the runtime
AWS Lambda is a compute service that provides the entire execution environment, including the configuration of standard input, capture of standard output & standard error and provides the programming language runtime for code executing in the Lambda function. As programming languages, packages and runtimes evolve, they are updated to improve performance, enhance security and support general maintenance of the technology. Keeping the runtime configuration updated is essential to ensure that the provided code runs in the most secure and performant manner.
Additionally, there is operational risk in relying on outdated runtimes, as AWS acting the service provider and owner of the platform, has the authority and incentive to forcibly update runtimes to safeguard its platform. Therefore there’s a mutual benefit for both you and AWS in continuously upgrading Lambda runtimes to the latest secure versions, reducing the likelihood of vulnerabilities or disruptions.
While the Lambda service is more lenient on hosting outdated runtimes than other AWS services such as EKS, it’s still important to understand the risk inherit in running an unsupported runtime.
Updating the runtime of your Lambda function depends on the sensitivity and complexity of the code it contains. For some functions, this can be a significant undertaking - such as migrating from the Go runtime to a standard binary wrapper which requires translating the code to an entirely different runtime. For other runtimes, like Python or NodeJS, the process is often simpler and involves updating to a newer version of the programming language. In these cases, it is recommended to deploy and test the function in a separate environment using the target runtime to ensure compatibility and correct operation in the new environment. This process mirrors running code on newer versions of Python or NodeJS in compute environments outside of AWS Lambda.
Once testing is complete, the function should be rolled out according to your release policy. There are various ways to manage releases and deployments hosted in serverless environments. These deployment processes can be managed at the API level, through Lambda versioning, or by leveraging proxies and other deployment strategies.
Given the complexities involved, it may be beneficial to engage architectural support to develop an appropriate deployment pattern. This should include release versioning, rollback mechanisms, and other considerations to ensure a safe, effective, and efficient path to production that aligns with your business needs.
SkySiege Cloud Security Assessments scan for this issue and provide same-day reports..
Available for individual projects or organisations.