AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Serverless functions' ephemeral nature makes traditional endpoint-agent monitoring impractical; ask specifically how runtime visibility is achieved (e.g., a lightweight extension/layer, or provider-native telemetry) since this is a genuinely different technical problem than securing a persistent VM or container.
Over-permissioned serverless functions are a very common real-world finding (broad default roles copy-pasted across many functions); ask for a concrete before/after permission-reduction figure from a named customer.
Pre-deployment (CI/CD-integrated) scanning is materially stronger than post-deployment-only detection, since it prevents vulnerable functions from ever reaching production rather than just flagging them after the fact.
Ask for an explicit per-provider coverage breakdown, since serverless security tooling maturity often varies significantly by cloud provider and this gap is not always disclosed upfront.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Serverless functions are invoked by diverse event sources (queues, storage triggers, API gateways) each with different injection risk profiles; ask specifically how the platform addresses event-source-specific injection risks, not just generic input validation.
Invocation-volume-based pricing interacts awkwardly with serverless's inherently elastic, spiky usage patterns — ask explicitly how the vendor handles pricing for genuinely variable workloads rather than assuming a static baseline.
Serverless forensics is genuinely harder than persistent-server forensics given function ephemerality — ask for a specific evidence-preservation mechanism and a real customer example of investigating a confirmed compromise.
Native compliance-evidence generation is materially more valuable than raw findings requiring manual compilation for every audit cycle.
This is a real, common buyer question given the functional overlap with CNAPP's own serverless coverage — a vendor should give an honest answer about the boundary and complementarity, not imply a standalone purchase is always necessary.
Function-level IAM and architecture findings are sensitive reconnaissance information — role-based access control over the tool's own findings is an often-overlooked consideration.
Cold-start latency is a particularly sensitive performance metric for serverless workloads — ask for a specific, measured overhead figure rather than a general 'minimal impact' claim.
Trend-over-time reporting is a distinct capability from a per-function security check — confirm this exists as a maintained, exportable report.
Strong answers give a concrete, customer-validated timeline for a realistic existing-footprint scenario (not a small greenfield deployment), and are honest about the customer-side configuration effort required.