Is the AWS Inpector's Lambda code scanning feature worth its price?
Tags: aws, security, serverless, codequality
Published: 2023-09-20 09:53:33

**Or why CodeGuru is often a better option for static code analysis**

_Written by_ @samudurand 

## Introduction

If you have been following IT news the last few years, you might have noticed that hardly a week passes without some big company [being hacked](https://edition.cnn.com/2023/08/10/politics/dhs-hacking-report/index.html) and their data stolen, or subjected to ransomware. In many cases, the reason these attacks could happen was due either to some __vulnerability in a popular library__ (we all remember the infamous [Log4J vulnerability](https://builtin.com/cybersecurity/log4j-vulerability-explained)) or to [vulnerabilities](https://owasp.org/www-community/vulnerabilities/) __introduced in the in-house code__. This should be no surprise then that security is one of the hottest IT topics again this year.

Fitting right into this topic is the [Amazon Inspector](https://aws.amazon.com/inspector/). This AWS service is designed to __identify and report security vulnerabilities__ in running EC2 instances, as well as in ECR images. [At the end of last year](https://aws.amazon.com/about-aws/whats-new/2022/11/aws-amazon-inspector-support-aws-lambda-functions/), AWS added the capability to scan Lambda dependencies to find vulnerabilities, and even more recently, to [scan the code](https://aws.amazon.com/about-aws/whats-new/2023/06/amazon-inspector-code-scans-aws-lambda-function/) of the Lambda itself.

![amazon inspector](//images.ctfassets.net/hqu2g0tau160/5abUDlAWKxm3LASfRvg474/3edf34ac3d72f8a958564a8fe05a88fa/amazon_inspector.png)

The cost of this new feature varies drastically depending on if you only use the basic dependency scanning, or if you also enable the optional code scanning. __Is it worth the price__ or is there a better and cheaper alternative to achieve the same results?

The goal of this article is to explain that. While you __should use the Amazon Inspector to scan your Lambdas__ dependencies and improve your security, you should also consider carefully the optional __code scanning feature__ before using it, since there is another AWS service that provides comparable features and could be cheaper or more adequate depending on your situation.

## Lambda scanning types

The Amazon Inspector offers [two scanning types](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html) when it comes to Lambdas: __standard__ or __code__ scanning.

Once triggered, the __standard scanning__ will analyze all the Lambda's dependencies (i.e. Log4J, Pandas...) and identify the vulnerable ones by using the [National Vulnerability Database](https://nvd.nist.gov/) (NVD), which contains all the known [Common Vulnerabilities and Exposures](https://cve.mitre.org/) (CVEs). It will then generate findings describing the severity of the issue and what can be done to fix it (once more by using the NVD score and documentation).

The __standard+code scanning__ includes the standard scanning, but will also scan the Lambda code itself by using __static code analysis__ (SAST) to find security vulnerabilities, such as hard-coded credentials or XSS injection possibilities. Under the hood, it relies on the [CodeGuru detector Library](https://docs.aws.amazon.com/codeguru/detector-library/) to identify vulnerable code. Note that the detectors used during the code scanning __do not take into account any NVD/CVE__ dependency vulnerabilities. The goal is to identify harmful or dangerous coding patterns, regardless of the external dependencies.

## How often are scans performed?

The Inspector performs what AWS calls a "continuous" scanning. This, of course, does not mean that scans are performed non-stop on every function, but rather that it relies on [specific triggers](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html#lambda-scan-behavior) that should decide when a scan is required. There are 3 possible triggers:

- when a Lambda is discovered or created
- when a Lambda is updated
- when AWS __update their vulnerability__ database with a __relevant [CVE](https://cve.mitre.org/)__!

![virtual private cloud](//images.ctfassets.net/hqu2g0tau160/6L0qu3EBz6sc5aKoAEGzIR/9388eed69c343b2ec5ed7911517c8e8a/Amazon_Inspector.png)

## How much does it cost?

The price is calculated based solely on the __average number__ of Lambdas present in your account per month and not marked by tags to be ignored. The number of time the scan is triggered __does not matter__. This means that your deployment frequency or the number of new vulnerabilities recorded in the AWS database has __no impact__ on your final bill.

How much you end up paying  also __depends on the type of scan__ you are running. The cost per Lambda present on average per month in your environment is __$0.30 for standard__ scanning, while for the code scanning (which includes the standard scan) the cost is __$0.90__, so exactly __3 times more__.

To really understand how much you would pay by using either feature, you need an example. Let's take the following scenario in which one of you company's accounts you have:

- 100 Lambdas monitored all month (720h)
- 50 Lambdas monitored only during half the month (360h)

![Screenshot 2023-08-23 at 15.11.10](//images.ctfassets.net/hqu2g0tau160/3JdoZtnhcNKG5LU2hyAfuS/081bdad62a2aab6a27e71fa903b06e18/Screenshot_2023-08-23_at_15.11.10.png)

The final counts is $37.5 per month for the standard scan and $112.5 for standard + code scan. The price overall is pretty low, especially if you consider the potential savings earned by preventing potential security breaches. You can also see that the three-fold difference of price between the two scanning mode becomes __more and more significant__ with the increase in the number of Lambdas.

## Should you use the Inspector's code scanning feature?

The best feature of the Inspector is that __"continuous scanning"__ is triggered every time [a new vulnerability is](https://aws.amazon.com/blogs/security/perform-continuous-vulnerability-scanning-of-aws-lambda-functions-with-amazon-inspector/) added to the AWS CVE database, and is "relevant" to your function. This feature allows teams to remain informed, and react to a new dependency CVE / Vulnerability __in a matter of hours instead of days__ (or sometimes even months if the vulnerability scanning only happens when the Lambda is updated). This makes the Inspector's standard scanning type very useful and worth its price for most companies.

### What about the code scanning?

The other type of Inspector's scan, the code+standard scanning type, which is __three times more expensive__, does not rely on CVEs to identify vulnerabilities in your custom code. As mentioned earlier, it uses the [CodeGuru detector Library](https://docs.aws.amazon.com/codeguru/detector-library/) when performing the static code analysis, which defines harmful or vulnerable coding patterns. This means that if a previous code scan has not discovered any vulnerable patterns, then __a new scan__ of the exact same code __will not find anything__ new either. The only exception would be if the CodeGuru detector library has received some new patterns relevant to your Lambda, in which case a new scan could be beneficial.

Based on this definition of the code scanning type mechanism, we can say that additional scans triggered by the publication of new CVEs will usually not find anything new in our custom code. Also, since there are no triggers based on the addition of detectors in the CodeGuru detector library, the only remaining triggers still relevant for the code scanning are the ones __for the creation and update of a Lambda__. This means that only pure luck would make Inspector notice a code vulnerability immediately after a new CodeGuru pattern is added (for instance if a new CVE is published at the same time as the CodeGuru pattern, or if the Lambda is updated at the right time).

Both those triggers describe events that could be handled in the development process, prior to deployment, for instance during PRs or in the CI/CD pipeline.

This is where [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) and [CodeGuru Security](https://aws.amazon.com/codeguru/) services become valid alternatives. They are specifically designed to scan the code during the development process and would perfectly fit this use case. Also, both those services also rely on the same [CodeGuru detector Library](https://docs.aws.amazon.com/codeguru/detector-library/) to identify potential vulnerabilities.

## CodeGuru as an alternative

CodeGuru Reviewer and Security are two services designed to detect security vulnerabilities during the development process. CodeGuru Review does this mostly via PR reviews, while the newer service CodeGuru Security, also includes CLI executions and other means of running this vulnerability check, including CodePipeline and CLI commands.

![Security Review](//images.ctfassets.net/hqu2g0tau160/4z8y09vJijhHRD6SvxTdiX/b7fe83a5662bacd6ad9f5a1d24233367/Security_Review.png)

### A very different price offering

The price of CodeGuru Security is not yet known (still in preview), but CodeGuru Reviewer's costs are clear and should be very similar to what CodeGuru Security will offer, so let's try to make a simple __cost comparison__ with the Inspector's.

This will be simple, since [this article](https://kreuzwerker.de/en/post/amazon-codeguru-reviewer-already-time-for-retirement) (that I recently wrote) explains, among other things, the features and price model of CodeGuru Reviewer. Unlike Inspector, the price of CodeGuru is __based on the number of lines__, not the number of Lambdas or repositories. If we look at the calculations performed in that past blog post, we can see that the price for scanning for security and code quality __for 450k lines of code__ would be around __$120 a month__ (if no extra manual scanning occurs).

![code guru reviewer pricing](//images.ctfassets.net/hqu2g0tau160/4slblJm6xbwjawmu9LxkiP/b83a96c97c7adc281defc6553ea279a9/code_guru_reviewer_pricing.png)

Let's take our previous example (100 Lambdas monitored all month and 50 Lambdas monitored during half the month), with an assumption that a simple Lambda function has at most __500 lines of code__ (which is already a lot for your average Lambda function in my experience). That would mean that, for a price similar to the Inspector's standard+code scan ($113), we could perform static code security analysis by using CodeGuru Reviewer/Security __for 900 functions instead of only 150 analyzed via the Inspector__. 

But let's not jump to conclusions since we made an assumption on the number of lines of code your Lambdas have. What if your team deploys mostly "fat" Lambdas with a very high number of lines of code? In this case the Inspector might be the best choice, in terms of price at least.

### Which service is the cheapest?

With very similar offerings, but price models so different, it's not easy to decide which tool should be used depending on your situation, if you want to spare some cash. Let's have a look at a few examples:

- if you have 100 Lambdas which amount to 50k lines of code, then the price of CodeGuru would be around $10 cheaper than Inspector at $90
- if you have 50 large Lambdas amounting to 250k lines of code, then the Inspector is the cheapest one with $45 against the $70 for CodeGuru
- if you have 10 very large Lambdas amounting to 350k lines of code, then the Inspector is really much cheaper $ 9$ against the $100 for CodeGuru

It's obvious that the larger your Lambdas are, the more appealing Inspector price model becomes. However, if you use hundreds of small Lambdas, then opting for CodeGuru may save you a lot of money.

### Earlier is always safer

Another aspect to consider, is that the Inspector's scans happen __after__ the deployment of the Lambda. This means that any vulnerability in your custom code will only be discovered __after deployment__. And although the Inspector will generate a finding very quickly, the vulnerability is already deployed, and if no-one reacts to the finding and fixes it, then it might very well stay deployed.

By using CodeGuru we would prevent the deployment by detecting the issue __during the development cycle__, either in the PR before it gets deployed, or in the CI/CD pipeline if you practice [trunk-based development](https://kreuzwerker.de/en/post/you-should-push-to-main).

### Simpler is often better

Enabling the Inspector is just a matter of a single click in the AWS console, or a few lines of code in IaC, which makes it very simple to use. So if you only have a few Lambda, if you do not want to spend the time necessary to configure an additional service (like CodeGuru) on your CI/CD pipelines, then using the Inspector's static code analysis feature could be a good option.

## Conclusion

Inspector is a great service. It provides some very powerful features such as the continuous vulnerability scan for Lambda and ECR. It's one of the best options out there if you want to react quickly to newly publicized vulnerabilities. 

However, the optional custom code scanning it provides for an additional cost, although simple to configure, is not always the best option when it comes to static code analysis. Depending on the count and average size of your Lambdas, you might be better off using tools integrated in the development process, such as CodeGuru Reviewer/Security or even other non-AWS services like [SonarQube](https://www.sonarsource.com/products/sonarqube/), or [Snyk](https://snyk.io/product/snyk-code/). In many cases (especially if your Lambdas are small) they will be __cheaper__ than the Inspector and allow you to __detect vulnerabilities before the deployment even occurs__.