Cloud application security assessment for a small SaaS: what the provider secures, what is yours, and what CASA is

Search for a cloud application security assessment and the first results describe CASA, the App Defense Alliance framework Google uses for the annual security assessment of apps that request restricted Google API scopes. If your app requests none of those scopes, the assessment you need is smaller: which layers of Vercel, Supabase or AWS the provider secures, which settings are yours, and what your code must do.

What a cloud application security assessment is, in both meanings

A cloud application security assessment means one of two things. In its general sense it is a written split of every layer an app runs on into what the provider secures, what you configure and what your code must do, with a check per line. For apps requesting restricted Google API scopes, it is CASA.

The first meaning is my method, and it is the one I’d hand a customer or an investor who asks for a cloud assessment of your product. You take each layer the app runs on (the host, the database service, the cloud account behind them, and the code) and write down who secures it, the check that proves it, and the evidence you kept. The code layer has its own controls, set out in web app security for an AI-built app; this page stays on the cloud side of the line.

Most cloud assessments I’d write for a small SaaS fit on one page, because the provider runs the servers, the network and the platform underneath. For an app built entirely from managed services, cloud-native application security is almost all settings: there is no server to patch, only the configuration each service hands you. Whatever the label on the request, cloud-based application security comes down to the same three parts: the provider, your settings, your code. Any best practice for cloud application security lands in one of those three, and sorting each one there turns advice into an assessment of your app.

A cloud computing security audit of your own app, when no formal auditor’s opinion is attached, is the same split, written down and dated. Security testing in cloud computing divides the same way: the scanners that read your cloud account, covered further down, and the application tests that read your code, which the web app security page above covers.

CASA: the Google-mandated Cloud Application Security Assessment

CASA, the Cloud Application Security Assessment, is the App Defense Alliance’s framework, based entirely on the OWASP ASVS, with a risk-based, multi-tier approach that assigns each app to assurance level AL1 or AL2. Google uses it for the annual security assessment that apps requesting restricted scopes must undergo.

In the Alliance’s own words on the App Defense Alliance’s CASA page, CASA is “based 100% on the OWASP ASVS” and uses a “risk-based, multi-tier assessment approach”. Google’s Security Assessment help page says “applications requesting access to restricted scopes must undergo an annual security assessment”, that Google is “leveraging” the Alliance’s framework, and that “Applications are assigned to either the AL1 or AL2 assurance level”. An app that passes gets a “Letter of Validation” (LOV) from the security assessor, and “All applications must be revalidated every year”. Treat Google CASA certification as shorthand for that letter: it is the document Google’s page names.

The Alliance’s Assurance Levels page adds the rule that matters most: “All requirements must be satisfied for every level, the only difference between each level is the assessment method that applies.” The framework users, such as Google, and not the developer decide which level an app needs. Which scopes count as restricted is Google’s own list, in the same help center. If you were asked for a CASA Tier 2 security assessment, that is older naming the Alliance still uses on its Tier 2 Process page, explained in the FAQ below. At both assurance levels an ADA authorized lab performs the CASA assessment, and the hardening work described near the end of this page is separate from it.

Shared responsibility: IaaS, PaaS and SaaS

Shared responsibility splits security by service model: the more the provider runs, the fewer layers are yours. In NIST’s definitions, an IaaS consumer controls operating systems, storage and deployed applications; a PaaS consumer, the deployed applications and possibly the hosting environment’s settings; a SaaS consumer, possibly limited user-specific application settings.

NIST SP 800-145 is the NIST definition of cloud computing, published in September 2011, and it names five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Two of its conditions matter here. A PaaS consumer “has control over the deployed applications and possibly configuration settings for the application-hosting environment”. A SaaS consumer does not manage or control the infrastructure “or even individual application capabilities, with the possible exception of limited user-specific application configuration settings”. That is the main limitation of SaaS in relation to security, in my reading: the few settings you can reach are all you can harden.

AWS’s shared responsibility model draws the same line as security “of” the cloud versus security “in” the cloud. For abstracted services such as Amazon S3, customers “are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions”.

Platform as a service vs SaaS is the question for a builder app: the code runs on a PaaS host such as Vercel, Netlify or Render, the data sits in a backend service such as Supabase or Firebase, and some apps have an AWS or Azure account behind them. The table applies those IaaS, PaaS and SaaS security responsibilities to that stack. The whole table is my reading of NIST’s definitions and AWS’s model, not either source’s words, and the last column applies that reading to the builder stack.

The provider halves for the common hosts are written up separately: what Vercel secures and what stays yours, what Supabase secures for you, and where the line sits, and for Firebase, what Google secures in Firebase and what you configure. The risky defaults those platforms ship with are listed under what are insecure defaults on managed platforms. Which hosts count as PaaS, with examples, belongs to the DevOps page linked further down; this table stays on security layers.

Why it matters for your app

The cloud computing issues that matter for a small app are mostly plain settings. This is my working list of the six I look for first, with the layer each one sits on and the check that settles it.

None of these cloud computing security vulnerabilities needs a skilled attacker; each is a setting or a code choice on the owner’s side of the split. That is why a provider’s certification does not answer a reviewer’s question about your app, in my reading. For a small team, the challenges of cloud computing are less about the provider and more about knowing which of these settings someone changed, and when.

The closest figure I have comes from my own audit scoring, which rates each app on 12 pillars: across the 21 third-party apps I audited in June and July 2026, the Deployment & Operations pillar was scored on all 21 and averaged 37.0 out of 100, which ranks it third of the 12 pillars, counting from the weakest. Those 21 are a set I selected and audited, not a random sample, so read the figure as a pattern in that set rather than a rate for AI-built apps in general.

For your data, the answer to how to secure cloud data starts with the part of AWS’s model quoted above: the data, its encryption options and its permissions sit on the customer’s side. In my reading, confirming that backups exist and that they restore is yours too, whichever provider holds them, and most cloud data security best practices come down to those settings plus a restore you have actually tried.

How it works: the assessment, layer by layer

A small SaaS is assessed in six layers, in this order: the cloud account’s identity, network exposure, the managed platform’s settings, data and backups, account logging, and the application code. Each layer gets one line in the split: provider or you, the check, the evidence and the date.

The layer list is my working order. The checks under each layer come from each provider’s and each standard’s own pages, not from a report of an account I scanned.

1. 01 Identity and the account: the root or owner user, its second factor, and every long-lived access key
2. 02 Network exposure: security groups, public endpoints and public storage buckets
3. 03 The managed platform's settings: the host's environment variables and preview protection, the database service's rules and keys
4. 04 Data: encryption options, permissions and backups, all on the owner's side
5. 05 Logging on the account: CloudTrail on AWS or the activity log on Azure
6. 06 The application: authorization, input handling and the rest of the code-level controls

Layer three’s per-platform list is the managed-defaults page linked above; layer four follows the data half of AWS’s model, and layer five is a separate topic: AWS logging and monitoring for a small app. The six layers work as an AWS security checklist and as an Azure cloud security assessment checklist alike, because both providers draw the same line between their layers and yours. If a customer sends a cloud security audit checklist instead, map each question to one of the six layers before answering; a question about a server’s patches only applies if you run a server. A security audit of the cloud platform itself is the provider’s business, and your assessment starts at the settings it hands you.

Three sets of security standards for cloud computing come up when a reviewer names one:

• NIST’s guidelines on cloud security start with two publications: NIST SP 800-144, “Guidelines on Security and Privacy in Public Cloud Computing” (December 2011), which “provides an overview of the security and privacy challenges pertinent to public cloud computing”, and SP 800-210, “General Access Control Guidance for Cloud Systems” (July 2020), which gives access control guidance for IaaS, PaaS and SaaS.
• The Cloud Controls Matrix from the Cloud Security Alliance is “a cybersecurity control framework for cloud computing” of 197 control objectives in 17 domains; the version on the Alliance’s page is 4.1.
• The CIS Benchmarks are “prescriptive configuration recommendations”, with Foundations benchmarks for both Amazon Web Services and Microsoft Azure.

When a customer or investor wants a third party to do the work, cloud security assessment services exist for exactly that, from CASA labs to general security firms; this page gives you the checklist either way and does not rank them. A cloud services security audit for compliance is a different product again: an auditor tests the whole system’s controls and ends with an opinion, which a checklist is not.

What cloud security covers, and where the provider’s job ends

Cloud security is the set of controls that protect the data, applications and infrastructure you run in the cloud. For one app it is those six layers, not a vendor’s list of pillars. The provider’s job ends at the configuration surface it hands you; its SOC 2 or ISO 27001 report covers its controls, not your settings.

Take any list of cloud security tips and each tip lands on one of the six layers: turning on MFA is identity, closing a port is network, encrypting a bucket is data. You don’t secure the cloud itself; you secure your part of it, the part AWS’s model calls security “in” the cloud. Infrastructure security in cloud computing, meaning the hardware, software, networking and facilities that run the provider’s services, is the provider’s side of that line; the infrastructure you configure on top, such as a security group, is yours. Security management in the cloud, for one app, is keeping those configured settings right after launch.

Application security vs cloud security is the same split again: cloud settings protect the account your app lives in, application security is what your code does with each request, and securing cloud applications needs both. A secure cloud architecture for a small app is mostly permissive defaults switched off. This cloud security guide stops at one app and its owner, and leaves multi-account programs to the teams that run them.

Cloud-native security, as the Kubernetes docs on cloud native security describe it, follows the CNCF white paper’s “security controls and practices that are appropriate to different lifecycle phases”: develop, distribute, deploy and runtime. Hybrid and multi-cloud security, with its own architecture, challenges and solutions, concerns companies running workloads across several providers or their own data centers, not one app on one host. Your own SOC 2, if a customer asks for one, is a separate project: SOC 2 compliance consultants for a small SaaS. Hardening servers you run yourself, and how to secure cloud infrastructure you own, is covered in DevOps for startups: environments, CI/CD and deployment.

Cloud vulnerability scanning: what the scanners check and what they miss

A cloud vulnerability scanner inspects workloads for software vulnerabilities and unintended network exposure: Amazon Inspector scans EC2 instances, container images and Lambda functions, and the Defender for Servers plan scans machines on Azure. Posture tools, the other kind, check account settings against a standard: AWS Security Hub CSPM, Defender for Cloud’s secure score and the open-source Prowler.

For AWS vulnerability scanning, the scanner is Amazon Inspector, which AWS calls “a vulnerability management service”. Accounts new to it are eligible for a 15-day free trial, and “CIS Benchmark assessments are not included in the 15-day free trial”. For Azure vulnerability scanning, vulnerability scanning in Defender for Servers uses Microsoft Defender Vulnerability Management in agentless and agent-based modes. Agentless scanning “is on by default when Defender for Servers Plan 2 or the Defender for Servers Cloud Security Posture Management (CSPM) plan is enabled”, and agent-based scanning needs Plan 1 or Plan 2. Those are plans you enable on top of Defender for Cloud’s free Foundational CSPM capabilities.

The posture half reads settings. Security Hub CSPM helps you “assess your AWS environment against security industry standards and best practices”, receives Amazon Inspector’s findings, and supports the CIS AWS Foundations Benchmark in versions 5.0.0, 3.0.0, 1.4.0 and 1.2.0, as AWS Security Hub CSPM’s CIS standard page lists them. One condition matters: “You must enable AWS Config and record resources in AWS Config for Security Hub CSPM to generate most control findings”. An account that enables it for the first time gets a 30-day free trial, during which you are still charged for the other services it works with, such as AWS Config items, though not for AWS Config rules that only its security standards activate. Defender for Cloud’s secure score “can help you improve your cloud security posture” and is part of the free Foundational CSPM capabilities. Prowler describes itself as an “open-source cloud security platform that automates security and compliance across any cloud environment”, under the Apache License 2.0.

A small app on a PaaS host runs no servers of its own, so in my reading the workload scan only applies where the app runs its own machines, containers or functions; the posture check applies to every cloud account. CSPM (cloud security posture management) is the name AWS and Microsoft both give the posture products, and CNAPP (Cloud Native Application Protection Platform) is the wider cloud-native security platform category Microsoft says Defender for Cloud belongs to. I don’t rank the cloud-native security tools sold under either name. Among cloud computing security tools, the AWS and Azure security tools in the table are the providers’ own, switched on inside the same cloud account.

In my reading, any cloud security assessment tool you are offered is one of these two kinds, or both in one product. A cloud scan of either kind reads the account and its workloads, not the logic of your code, which is why a cloud scanner cannot tell you that one customer can read another’s records. Cloud-based vulnerability management, for one app, is these reports read on a schedule and the findings fixed. For how a scan differs from a test, see pen test vs vulnerability assessment; scanners that read the code itself are covered in where automated scanners lose the application’s intent.

The cloud account itself: the AWS and Azure settings worth checking

The AWS account settings I check first are five: MFA and no access keys on the root user, IAM roles instead of long-term user access keys, a multi-Region CloudTrail trail, S3 Block Public Access on for the account, and security groups that open each port only to the sources that need it, never SSH or RDP to the whole internet.

AWS’s root user best practices say to secure root sign-in with MFA and “Don’t create access keys for the root user”; for a standalone account, IAM roles provide “temporary security credentials”, while IAM users carry long-term credentials such as passwords and access keys. AWS recommends a multi-Region CloudTrail trail “because it captures activity in all enabled Regions”, and Security Hub CSPM’s control CloudTrail.1 checks for at least one. For S3, AWS recommends that you “turn on all four settings for block public access for your account”. For EC2 on AWS, AWS’s security group best practices say that for ports 22 (SSH) and 3389 (RDP) you should “authorize only specific IP address ranges”. The same page adds: “Do not open large port ranges. Ensure that access through each port is restricted to the sources or destinations that require it.” Keeping database ports closed to the internet is my rule, not AWS’s wording; AWS’s own example has the database servers’ security group allow database requests from the web servers, with the web servers’ security group as the source.

Azure cloud security for one web app comes down to five checks, each taken from Microsoft’s own best practices and product pages. Read Defender for Cloud’s secure score first. For Azure App Service security, turn on HTTPS-only mode, which Microsoft notes “isn’t on by default”, use a managed identity instead of stored credentials and connection strings, and keep secrets in Key Vault, reached through Key Vault references. Microsoft’s network advice is to “Disable direct RDP and SSH access to your Azure virtual machines from the internet”. Azure keeps activity log events for 90 days, so a longer record needs a diagnostic setting that sends them elsewhere.

1. 01 AWS: MFA on the root user, and no access keys for it
2. 02 AWS: IAM roles with temporary credentials instead of IAM users with long-term access keys
3. 03 AWS: a multi-Region CloudTrail trail
4. 04 AWS: all four S3 Block Public Access settings on for the account
5. 05 AWS: security groups with no SSH or RDP open to the whole internet and each port limited to the sources that need it
6. 06 Azure: Defender for Cloud's secure score read and its recommendations worked through
7. 07 Azure: App Service with HTTPS-only mode on
8. 08 Azure: a managed identity instead of stored credentials and connection strings
9. 09 Azure: secrets in Key Vault, reached through Key Vault references
10. 10 Azure: no direct RDP or SSH from the internet, and the activity log sent to longer storage if you need more than its default retention

These five AWS security controls, with their Azure counterparts, are also the values to have in hand before you answer an AWS security questionnaire or the AWS part of a cloud security assessment questionnaire. Auditing AWS after that is a habit: I’d read Security Hub CSPM findings and CloudTrail about once a week, as my working rule.

One of my own apps shows why the settings list is not enough on its own. Its deploy script copied the whole local .env, including the secret vault’s bootstrap credential, into the cloud function’s configuration as plain variables. Any account role allowed to read function configuration, which ordinary read-only roles often are, could read every secret the service uses. The lesson I take from it: the provider stored that configuration exactly as it should, and who could read it was a setting on my side of the split.

Whose name the cloud accounts are in is its own question, covered in developer owns our hosting account. A second factor belongs on every provider dashboard, not only the AWS root user: how to implement two factor authentication.

How to check your own app

A cloud assessment of your own app is six checks: list each provider and its layer, mark your lines on each provider’s shared-responsibility page, run the cloud account’s scanners, record each setting’s value and date, test the application layer, and write the one-page split a reviewer can read.

1. 01 List every provider the app runs on and the layer each one is, filling in the builder-stack column of the responsibility table. Evidence: the list.
2. 02 Open each provider's shared-responsibility page and mark the lines that are yours. Evidence: the marked lines, with the date you read the page.
3. 03 Run the cloud account's posture check (Security Hub CSPM once AWS Config is recording resources, or Defender for Cloud's secure score) and, where the app runs its own machines, containers or functions, its vulnerability scan (Amazon Inspector, paid after its free trial, or a Defender for Servers plan). Evidence: each report, with its date.
4. 04 Walk the settings list and record each setting's current value and the date. Evidence: the settings table.
5. 05 Run the application checklist and the API checks linked below. Evidence: their results.
6. 06 Write the one-page split: layer, provider or you, check, evidence, date. Evidence: the page itself.

For check five, use the SaaS security checklist for the product you built and API security assessment for an AI-built app. Check six produces what a security questionnaire’s cloud section asks for; the rest of such a questionnaire is a separate topic: security questionnaire examples and templates.

For the managed services in the stack, the Production Hardening Sprint verifies deliverable 2.9 this way: record the before-and-after settings for each managed service, naming each risky default and its new value.

Where the sprint does this

Deliverable 2.9 of the Production Hardening Sprint reviews and hardens the settings of every managed service in the stack: auth policies, storage access rules, privileged keys kept server-side, and a plan tier adequate for backups and recovery, checked as the previous section describes. Deliverable 1.11 enforces a second factor on every owner and admin account, in the application and on every provider dashboard behind it. The results go in the production readiness report, which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Formal third-party certifications and independent audit opinions are separate from the sprint deliverables. Every deliverable is listed under the 13 areas of the sprint scope.

Common questions about cloud application security

What are the four types of cloud security?

The four-type answer Google shows for this question comes from Check Point’s page, which says cloud security “requires a combination of deterrent, preventive, detective, and corrective controls”: deterrent controls discourage attackers, preventive controls stop attacks before they succeed, detective controls identify threats that get past prevention, and corrective controls contain incidents and recover operations. For one app, the six layers on this page are the more useful split, in my reading, because each layer names who has to act.

What are the top 3 cloud security risks?

My working list for a small SaaS has three: public storage, a database or admin port reachable from the internet, and a root or owner account with no second factor. Each sits on the owner’s side of the split, and each has a check in the risk table above.

What is the CASA Tier 2 assessment and what does it include?

“Tier 2” is older CASA naming. The Alliance’s Tier 2 Process page, last updated in November 2024, describes an assessment started by a notification from a partner such as Google: the developer scans their own app and gives the scan results and other evidence to an authorized assessor, who issues a Letter of Validation. That page now warns that “The CASA self scanning process is deprecated” and says to follow the instructions in your notification. The Self-Initiated Assessment page, last updated in October 2022, says “only a Tier 3 assessment is validated by the authorized labs” and that a developer checking readiness “without validation and cost” can “follow the Tier 2 scanning procedures without submitting for validation”. Google’s help page assigns apps to AL1 or AL2 instead, the levels on the Alliance’s current Assurance Levels page; how the tiers map to the levels is not stated in the App Defense Alliance’s pages.

How much does a CASA security assessment cost?

Google’s Security Assessment help page states no cost; the lab you hire sets the price. On September 27, 2026, TAC Security’s CASA page, which calls TAC an approved ADA lab, listed its Basic plan, a one-time AL1 assessment with a Letter of Validation, at $675, and its Enterprise AL2 plan, a one-time AL2 assessment, at $5,400. The two plans also differ on revalidation: two cycles on Basic, unlimited on Enterprise AL2.

What is a cloud security audit and what does it involve?

For a small SaaS, a cloud security audit is the six-layer split set out in the layer-by-layer section above, with a piece of evidence and a date for every line. The owner can do it, or a third party can. A formal audit that ends in an auditor’s opinion is a separate engagement with its own criteria.

Is cloud security different from cybersecurity?

Cloud security is cybersecurity applied to layers you rent. The difference is that the provider owns part of the job: AWS calls its part security “of” the cloud and the customer’s part security “in” the cloud. The skills are the same; the first task is finding where the line sits for each service you use.