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 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) or to 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. 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, AWS added the capability to scan Lambda dependencies to find vulnerabilities, and even more recently, to scan the code of the Lambda itself.
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 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 (NVD), which contains all the known Common Vulnerabilities and Exposures (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 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 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!
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)
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 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 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 and CodeGuru Security 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 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.
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 (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).
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.
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, or Snyk. 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.