Google Cloud Artifacts Vulnerability scanning: Pricing, features and competitiveness

Headline

Few months ago a post on X/Twitter highlighted the pricing of Google Cloud Artifacts Vulnerability scanning. The author of the post expressed concern over how expensive Artifacts Vulnerability scanning is and compared it to a self-managed solution from Aqua Security. Subsequent responses also highlighted the low pricing of other cloud providers offering.

This article attempts to address these concerns. I’m not trying to downplay the concern voiced by the original author of the post but rather provide some clarification into why the pricing of Artifacts Vulnerability scanning makes sense and how to properly compare it to similar offerings.

Artifacts Vulnerability Scanning VS self-run self-managed alternatives

One of the main concerns from the post is how running a self-managed version of Trivy from AquaSecurity costs substantially less.

On the surface this is a valid point. Running Trivy (or to this extent any other Open Source alternatives like Docker Scout) as part of CI pipelines will almost certainly be cheaper for most users. But there are some caveats:

• Artifacts Vulnerability scanning is a fully managed solution. Users just need to enable the API and forget about it. It just works!
• Artifacts Vulnerability scanning will continuously scan images whenever a new vulnerability is added to Google Cloud databases within the smart-scan window of 30 days. With OSS tools (like Trivy) assuming they are used as part of the CI pipeline the user has to trigger rescans manually to catch new vulnerabilities.
• When a new OS, Programming language, Package or any new target is added to Artifacts Vulnerability scanning coverage customers benefit from this out of the box. With OSS tools users will have to upgrade the version of the tool to get new features.

One thing I need to acknowledge is that Trivy particularly has substantial scanning coverage. Beside OS packages, languages, it can also scan IaC files and Kubernetes. Artifacts Vulnerability scanning is limited to OS packages and popular programming languages.

Artifacts Analysis Scanning VS Other Cloud offerings.

Some of the responses to the original thread highlighted how other cloud providers offer the same features for cheaper. But as usual the answer is not as straightforward as you might want it to be.

AWS

Let’s take an example of AWS Container scanning on ECR (Elastic Container Registry). Looking at AWS documentation and a relatively recent updates blog. We can see that:

• Basic scanning is free. Container images are re-scanned every 24h.
• Enhanced scanning pricing has two tiers:
  - On-Push to ECR scanning costs 0.09$ per image.
  - Each re-scan costs 0.01$ per image. If A new vulnerability is added to the database, automatic re-scanning is triggered. I could not find any way in the doc to disable this behavior and only ask ECR to scan on-push.

Azure

As for Azure and Azure Container Registry(ACR). The benchmark is slightly more difficult to make. First Vulnerability scanning in ACR requires Defender for Cloud and I could not find any information about the pricing of scans per image/digest. The only figure we found is this pricing for Microsoft Defender for Containers at $0.0095/vCore/hour. And this note in the docs:

Pricing is performed based on vCores in your Kubernetes worker nodes supported by Defender for Containers. This price includes 20 free monthly vulnerability assessments performed in your container registry per charged vCore, whereby the count will be based on the previous month’s consumption. Every subsequent scan will be charged at $0.29 per image digest. The majority of customers are not expected to incur any additional image scan charges.

Conclusion

To conclude the answer to which tool/software/service is cheaper or more expensive is relative to many parameters. And the answer is usually more nuanced and cannot be captured in 280 characters.

The purpose of this article was to apply some critical thinking to answer these complex questions and learn from each other ;)

I’d like to credit Patrick Faucher, Greg Mucci, Rishi Mukhopadhyay from Google for putting together the material that helped write this article.