Hi everyone,
I've been seeing this question come up a few times in different contexts, so I thought it would be helpful to start a dedicated thread. For those new to cloud security tooling, understanding the scope of scanning is crucial when evaluating a platform.
Specifically, does Rapid7 InsightCloudSec actively scan and assess the security posture of serverless functions, like AWS Lambda or Google Cloud Functions? I'm particularly interested in whether it covers configuration risks (like over-permissive roles), embedded secrets in the code, and vulnerabilities within the function's dependencies/layers.
If you have hands-on experience, I'd appreciate insights into how the scanning is initiated (during deployment, on a schedule) and what the findings look like in the console. Any gotchas or limitations you've encountered would also be valuable for the community to know.
Looking forward to a constructive discussion.
~Harry
Excellent question, and a very important one for modern cloud security. Yes, InsightCloudSec does actively scan serverless functions. I've used it across several AWS Lambda-heavy environments.
Specifically for your points, it's quite good at identifying over-permissive execution roles and risky configurations. For dependencies and layers, it will inventory them and match against vulnerability databases. The secret scanning in code is there, but in my experience, it's more effective at catching secrets in environment variables rather than deeply embedded in the function package itself; you might want a dedicated SCA or secrets tool for that depth.
On process, it typically scans on discovery via its connectors, which is continuous. You'll see findings in the main inventory with resource type 'function'. A common gotcha is that for the most current code package analysis, you sometimes need to ensure the tool has the right permissions to pull the deployment package from S3 or similar, which can be a minor IAM hurdle.
null
Great question on scanning approach. From what I've seen, the continuous scanning is fantastic for catching config drift, but if you're looking for pre-deployment checks, you'll want to integrate it into your CI/CD pipeline. I've set up a webhook so it triggers a scan right after our Terraform apply, which gives devs immediate feedback.
On your point about what findings look like, the console groups Lambda issues under the specific function. It's pretty clear, showing the risk level and linking to the exact IAM policy line, for example.
One gotcha I've noticed is that for Google Cloud Functions, the scanning depth for layers (or rather, the container image) can sometimes lag a day behind AWS if a new CVE drops, so keep that in mind for critical functions.
null