Introducing Amazon Inspector code scans for Lambda functions
Tags: aws, serverless, security, java
Published: 2023-03-06 16:45:23

##Introduction

In this [blog post](https://dev.to/aws-builders/deep-dive-into-amazon-inspector-for-aws-lambda-264g) I did a deep dive into Amazon Inspector for AWS Lambda. Shortly [code scans](https://aws.amazon.com/de/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) for Lambda functions within Amazon Inspector has been introduced and is now in preview. So let's explore this feature.

## What is code scans for Lambda functions within Amazon Inspector

This scan type scans the custom application code in your functions and layers for code vulnerabilities. Code vulnerability findings identify lines in your code that attackers could exploit. Code vulnerabilities include **injection flaws, data leaks, weak cryptography, or missing encryption** in your code.

Amazon Inspector evaluates your Lambda function application code using automated reasoning and machine learning that analyzes your application code for overall security compliance. It identifies policy violations and vulnerabilities based on internal detectors developed in collaboration with **Amazon CodeGuru**.

If Amazon Inspector detects a vulnerability in your Lambda function application code, Amazon Inspector produces a detailed Code Vulnerability type finding. This finding type includes the issue's exact location in the code, a code snippet showing the issue, and an actionable recommendation to remediate the vulnerabilitym, see [https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html](url)

## Supported runtimes and eligible functions

For a list of runtimes Amazon Inspector supports for Lambda scanning, [see Supported programming languages: AWS Lambda function scanning](https://docs.aws.amazon.com/inspector/latest/user/supported.html#supported-programming-languages-lambda).

In addition to having a supported runtime, a Lambda function needs to meet the following criteria to be eligible for Amazon Inspector scans:

-     The function has been invoked or updated in the last 90 days.
-     The function is marked $LATEST.
-     The function isn't excluded from scans by tags. To exclude a Lambda function from Lambda standard scanning, tag the function with the following key-value pair:  Key:InspectorExclusion
Value:LambdaStandardScanning

## Activating Lambda code scanning

To complete this procedure for a multi-account environment, follow these steps while signed in as the Amazon Inspector delegated administrator.

1. Open the Amazon Inspector console at  https://console.aws.amazon.com/inspector/v2/home
2. Using the AWS Region selector in the upper-right corner of the page, select the Region where you want to activate Lambda code scanning.
3. In the navigation pane, choose Settings, and then choose Account management.
4. In the Account management page, select the accounts for which you would like to activate Lambda code scanning. 
5. Choose Activate and select AWS Lambda code scanning, see
![AWS Lambda scanning](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/je50rscqgk0qcj7v7v3v.png)

## Code scans for Lambda functions within Amazon Inspector in action

Let's add some code in Java programming language and explore whether Amazon Inspector will find some intentially produced code vulnerabilities.  We'll add resource leaks, weak cryptography and some bad practices in our examples.

1) Weak cryptography. Let's add this code to our Lambda function.

```
	public static byte[] digestString() throws NoSuchAlgorithmException {
		String data = "This is a message to be digested using MD5";
        MessageDigest messageDigest = MessageDigest.getInstance("MD5");
        messageDigest.update(data.getBytes());
        return messageDigest.digest();
	}
	
	public static Cipher getCipher() throws NoSuchAlgorithmException, NoSuchPaddingException {
	   return Cipher.getInstance("DES");
	}
```
2) For the resource leak (not closed Reader) we add the following code.

```
	    private static String readFileContents() {
	        BufferedReader reader = null;
	        String fileContents = "";
	        try {
	            reader = new BufferedReader(new FileReader(
	                    "C:\\example.txt"));
	 
	            while (true) {
	                fileContents += reader.readLine();
	                if (fileContents == null || fileContents.equals("")) {
	                    break;
	                }
	            }
	        } catch (IOException e) {
	            System.out.println("Something went wrong");
	        }
	        return fileContents;
	    }
```

3) For the bad code practices we'll create the AmazonS3 client during each Lambda function invocation instead of creating it in the static initializer block of the Lambda function once and then reusing it.

```
final AmazonS3 s3 = AmazonS3ClientBuilder.defaultClient();
s3.putObject(bucket_name, key_name, new File(fileContents));
```

Let's deploy the code and wait several minutes until Amazon Inspector Lambda code scanning has finished its work.

The results look like this :

![Code Vulnerabilities](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xltlve7hmiv5jlza8f5f.png)

We see that several critical and medium code vulnerabilities have been detected. Let's look into them :

1) Weak cryptography

Insecure hashing algorithm has been correctly recognized. Here is the exact description of the code vulnerability

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xegqre01292rslqoe1ws.png)

and exact code place and suggestion how to fix it

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1dsbgqd2880l4rzk8k3e.png)

The same is true for the insecure cryptography. Here is the exact description of the code vulnerability

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/079omq53zeddif67vwlq.png)

and exact code place and suggestion how to fix it

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kio98f1m9lv60x8x28x9.png)

2) The resource leak (not closed Reader) has been recognized as well 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wlvgc9znfvuzzsnkxg63.png)

3) Creation of AmazonS3 client during each Lambda function invocation instead of creating it in the static initializer block of the Lambda function once and then reusing it has also been recognized


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/an3p662ctwpnotlunslo.png)

## Conclusions
In this blog post we introduced code scans for Lambda functions within Amazon Inspector, explained which findings it can produce, how to conigure it and ran several tests to see the detected findings. We saw on several examples that the code vulnerabilities like weak cryptography, resource leak and bad code practices have been correctly detected.  

But this is **currently** not the whole story. I intend to write a  separate blog post series about Amazon CodeGuru (used by Amazon Inspector for Lambda code scanning as well) as I exprimented with it quite a bit using Java programming language and also gave several talks about good and bad parts of Amazon CodeGuru. I have additionally generated some very obvious examples of vulnerabilities like SQL injection and used the static access and secret key in the Lambda function that have not been recognized by Lambda code scanning so far. If I used Amazon CodeGuru directly to scan the same code in AWS CodeCommit repository some of those vulnerabilities have been indeed detected. So I see a huge room for improvements with interplay of Amazon Inspector code scans for Lambda functions (which is in preview) and Amazon CodeGuru.  We'll explore it in one my next blog posts in more depth. Stay tuned!