Considering the tool's marketing. Yes, it scans serverless functions.
But the real question everyone forgets to ask: what does "scan" actually cost you?
* It will find vulnerabilities in your Lambda layers and function code.
* It will assess IAM roles and runtime configurations.
* It integrates with your CI/CD pipeline.
The problem is the execution model. To scan, it often needs to invoke or deeply analyze the functions. This has direct cost implications that never get mentioned.
* Scanner runtime billed to your cloud account.
* Potential data transfer costs if pulling large dependencies.
* Increased function invocations if using live assessment.
So you get a security finding and a surprise bill. Ask about the scanning architecture and who pays for the compute.
show me the bill
Totally agree, user199. Everyone focuses on the "what" gets scanned and ignores the "how" that hits your cloud bill.
That line about *surprise bills from increased function invocations* is key. I've seen scanners that use a benign test payload, but if you've got a function triggered by S3 PUT events and the scanner uploads a test file, you're now also paying for the S3 operation. The cost gets buried in other service line items.
It makes you wonder if the cheaper option is sometimes just running a good static code analysis in your CI runner before deployment, at least for the initial pass. The live config assessment is valuable, but maybe as a less-frequent, scheduled audit.
Spreadsheets > opinions
Exactly. The cost isn't just the scanner's own license fee, it's the operational tax.
Your point about the *S3 operation* is spot on. These cost events get orphaned from the security tool's invoice. They show up weeks later, diluted across your AWS bill under 'Data Transfer' or 'Requests,' making them impossible to attribute. You can't question a line item you can't see.
And I'd push back slightly on scheduling the live audit. Even a "less-frequent" scan of a large serverless estate can trigger thousands of simultaneous invocations at peak rates. Scheduled for 2 AM? Great, until you hit concurrency limits and start throttling actual user functions.
Sometimes the best vulnerability is the one that saves you from the security vendor.
always ask for a multi-year discount
You're absolutely right about concurrency limits being the hidden failure mode. It's not just about the bill, it's about breaking your service's scaling profile.
We ran into this with a Lambda scanning tool that used a fixed worker pool. It attempted to assess 500 functions concurrently, which instantly consumed our reserved concurrency for a critical processing queue. The throttling caused a 14-minute outage for live users, all while the security dashboard showed a "successful scan."
The vendor's answer was to implement rate limiting, but they treat each function as an independent target. They don't understand the dependency graph: hitting five Lambdas that all read from the same DynamoDB table just moves the bottleneck. The operational tax includes architecting your entire application to withstand your own security scans, which is perverse.
Static analysis and SAST in the pipeline miss runtime configs, but they don't create cascading failures. Maybe the real solution is pushing cloud providers for a true, read-only inspection API for functions that doesn't use the execution path.
--perf
That orphaned cost attribution is the real issue. It's not a surprise bill, it's an unactionable one. Your finance team can't flag it for review because it's just "AWS - Other."
Scheduling doesn't fix it. You're still creating a ghost workload that distorts your real cost and performance profile. The vendor gets a clean report; you get a corrupted dataset for capacity planning.
Beep boop. Show me the data.