AWS | Cloud | Technology
Sync AWS CodeCommit repositories 
Joris Conijn 12 Apr, 2022
Share 
Fresh from re:Invent 2022. Just left the pop-up session organized just after the announcement by the AWS Inspector team Rick Anthony and Kashish Wadhwa. After the session was able to ask Rick Anthony a few questions.
Why is this important
More and more customers are moving to serverless workloads on AWS, moving away from EC2 instances and containers. Lambda usage is increasing every year and there are hardly any native security features for this service. This is why it becomes critical to address these vulnerabilities.
What does inspector do
Inspector can already scan EC2 instances and ECR images for vulnerabilities. Now scanning Lambdas is also supported. Security Hub can be configured to accept the findings from Inspector so you can have one place where all security findings will be aggregated.
Inspector decides what and when to scan instead of you scheduling. Also brand new vulnerabilities can be reason for AWS Inspector to decide to rescan. In the case of Lambda this means whenever the function is created or updated a scan will be performed. When a lambda is not called the last 90 days it will no longer be scanned (mothly cost will then also no longer apply). Currently scanning for the following run-times is supported: Python, nodejs and Java. Also scanning layers is supported, findings from layers will be reported for all functions where the layer is used and the finding will indicate that the cause of the vulnerability is from a layer.
Vulnerabilities
Vulnerabilities in Lambda are not related to the operating system (unless you are using custom run-times, which are not supported by the new feature) but come from the packages used for the programming language chosen. If, for example, you are using Java run-time and are using the log4j package you could have a vulnerability if you are using the unpatched version of the library. Inspector scans the artifacts the package tooling leaves behind (package.json for nodejs projects for example).
Exploitability
Not all vulnerabilities in Lambda can be exploited easily because the OS firecracker is well hardened. Also the attack plane is limited because calling a lambda requires IAM authorization when calling it the regular way. If you are using the new function URL functionality though without authentication the attack plane is a little larger. Also if called through API Gateway and you are not using the request validation you could be vulnerable to an attack. Inspector takes into account the network reachability of the lambda in the score of the finding. The resulting score gives an indication of the priority with which this finding should be treated. Currently the AssumeRole policy of the Lambda execution role is not taken into account for the scoring and also the fact that FunctionUrls are used or not. AWS monitors 50 sources that publish vulnerabilities and they add some intelligence to it. The score which also takes into account the exploitabilty. A network scan is also done where the VPC edges are inspected for network reachability. It is correlated with CVE data. If the CVE is only exploitable remotely but the resource is local, the score is lowered.
Live runtimes
Lambda containers are recycle after a period of time so when successfully attacked the attack needs to be re-executed after a recycle. But if the vulnerability involves code injection an attacker can basically infect each newly spun up lambda execution environment. The running lambda environments themselves are not scanned. Like with ECR this is an agentless solution. This also means that if you install extra python packages using a sub-command in python these will not be detected. (You shouldn’t do that).
What should you do if there are findings
If you have a vulnerability in a Lambda the following steps should be taken:
- inspect the Lambda code if the vulnerable part of the library is actually used. If not you could suppress the finding.
- If you find that the vulnerability can be exploited. The lambda needs to be redeployed using patched libraries and packages.
Enabling for the Organization
Enabling Lambda scanning by Inspector for your whole organization is just a few clicks: In the delegated admin account check the checkbox to include lambda scanning (also check the box for auto-enabling for new accounts). Be aware though that the pricing if $0.30 per function per month so you might want to exclude some functions before enabling this for all your accounts.
Current features
- nodejs, python and java runtimes
- lastest version scanning on update or create
- rescanning when there are new threats
- AWS Organizations support
- network reachability included in score
- scoring the vulnerabilities (priority)
Future
For the future the Rick from the Inspector team said they are looking into supporting the following features in the future:
- add an option to scan all versions of the Lambda (currently only latest is scanned)
- adding lambda accessability (AssumeRolePolicy of the execution role or FunctionUrls) might be included in the scoring calculation
- making the stale function scanning period adjustable
by Jacco Kulman
Jacco is a Cloud Consultant at Binx.io. As an experienced development team lead he coded for the banking- and hospitality- and media-industries. He is a big fan of serverless architectures. In his free time he reads science fiction, contributes to open source projects and enjoys being a life-long-learner. 
