Cloud App and Config: Security for Cloud-Connected Apps

App Defense Alliance

Most applications are only as secure as the cloud services behind them. This profile addresses the back end and, crucially, how it is configured.

What is this?

The App Defense Alliance, usually shortened to ADA, is an industry group that sets security standards for apps. It began at Google in 2019 and moved to the Linux Foundation in 2024, so it is no longer run by any single company. Google, Meta and Microsoft sit on its steering committee.

The Cloud App and Config Profile is a distinct profile in the App Defense Alliance requirement set, with its own specification and test guide. It addresses the security expectations for applications that connect to cloud services. The emphasis on configuration is deliberate, and it is the part most often neglected.

It covers the three major providers: Amazon Web Services, Google Cloud Platform and Microsoft Azure.

What it is built on

This profile does not invent its own checks. It builds on the Center for Internet Security benchmarks, which is genuinely good news for you: the CIS benchmarks are widely implemented, and if you already run a CIS scan you have done a real part of this profile already.

Here is the distinction that makes this worth a separate look. Application code and cloud configuration fail in different ways, and finding one kind of problem tells you nothing about the other.

Most publicly reported cloud data exposures have been configuration problems rather than code problems. A team can do everything right in the application and still lose a database because somebody opened a firewall rule to debug a problem at midnight and never closed it.

ADA does not test apps itself. It publishes the requirements, then authorises independent laboratories to do the testing. A lab has to earn that authorisation, and part of earning it is holding accreditation to ISO/IEC 17025, the international standard for testing laboratories. The point of the arrangement is that the people judging your app have no commercial interest in the answer.

Who is required to complete it

This question gets muddled because there are three different answers and people run them together. Nobody is required by law. Some organisations are required by a platform or a contract, which in practice is just as binding. Everyone else chooses.

The distinction that matters in practice: if a platform or a customer has made the assessment a condition of something you need, treat it as a hard requirement with a date attached. If nobody has asked, it is an investment decision, and you should judge it on whether the findings and the report are worth the cost to you.

The checklist is public, and free

This is the most useful thing to know before you spend any money, and most developers do not know it. The App Defense Alliance publishes its requirement sets openly on GitHub. You can read the exact bar you will be measured against, work through it yourself, and fix what fails before engaging anybody.

Each profile publishes three documents. The Cloud App and Config Specification is the requirement list: an identifier and a one-line description, and deliberately nothing more. The Cloud App and Config Test Guide is the one you actually want, because for each requirement it gives the description, the rationale, the evidence you must submit, the test procedure, the acceptance criteria and any scope limitations. There is also an Audit Summary, used mainly by laboratories for recording outcomes.

Assurance levels: how much of the work is yours

How much you do, versus how much a laboratory does, depends on the assurance level. This is the single biggest driver of what an assessment costs you, so establish it early.

AL1 is the level most developers meet, and it is worth being precise about what it asks. You are not signing a statement that you comply. You are running the test procedure and producing evidence that demonstrates it, and a reviewer then judges whether that evidence is sufficient. Thin or ambiguous evidence gets sent back, and every round trip costs you time.

What gets tested

The profile organises its requirements into six domains: compute; identity and access management; logging and monitoring; networking; storage; and database services. In plain terms:

What the laboratory actually does

Most developers have never seen inside a laboratory engagement, and the phrase independent assessment hides a lot of specific process. Here is what actually happens, and why each part is there. Knowing this makes you a much better buyer. For the whole engagement phase by phase, including the acceptance checks and the independent review, see what the laboratory actually does.

Before the lab is allowed to accept the job

An authorised lab cannot simply take your money and start. Before it accepts, it has to satisfy itself of several things, and record that it did:

• Competence. It has people qualified for your assessment type. ADA specifies which certifications the engagement team must hold, and a lapsed certification does not count.
• Capacity and tooling. It has the qualified tools and the test environment your cloud environment needs, and the time to do the work properly.
• No conflict of interest. This one matters to you. A lab that has previously assessed or advised on your application, or that helped you build it, is barred from validating it. If a firm offers to fix your app and then certify it, that is not an arrangement an authorised lab can make.
• An independent reviewer. It has someone available who took no part in the testing and who will check the work. If no independent reviewer is available, the lab should decline the engagement, because it would not be able to release your report.
• Agreed scope. Which cloud environment, which build, which requirements apply, what is excluded and why, all written down before testing begins.

Who is on the engagement

How the lab handles your cloud environment

There is no build to hand over. What the lab needs instead is read-only access to the configuration of the accounts in scope. The lab records which accounts, projects or subscriptions were examined, and the date and time the configuration was captured, because cloud configuration changes continuously and the report describes a snapshot rather than a steady state.

• A hash is recorded on receipt. The lab takes a cryptographic fingerprint of exactly what it received, so there is never an argument later about which version was tested.
• A clean environment is built for you alone. Your engagement gets its own test environment, isolated from other clients' work, and it is destroyed when the engagement closes.
• Tools are checked before use. The lab confirms each tool is at the version it has qualified and produces the expected result on a known input. A tool that fails that check is not used.
• Your data stays separated. One client's data must not be reachable from another client's engagement. This is a requirement, not a courtesy.

How evidence works, and why you should care

This is the real difference between a laboratory assessment and a consultant's report. For every requirement, the assessor has to record evidence good enough that a different competent assessor could repeat the work and reach the same conclusion. Not a summary, and not a conclusion. The actual input, the action taken and the observed result, captured at the time it happened.

Two consequences follow, and both are in your favour:

• A lab cannot fail you on a hunch. If the evidence does not demonstrate that a requirement is unmet, the assessor cannot record a Fail. Findings have to be shown, not asserted.
• A lab cannot pass you on your word. If you tell the assessor a control works and they do not verify it, that is recorded as your statement, not as a validated Pass, and the report has to disclose which requirements were self-attested rather than validated. This protects you too: it means nobody can later claim the lab checked something it did not.

How the verdict is reached

Each requirement in scope gets one of three verdicts. There is no partial credit and no overall score that hides the detail.

Watch the Inconclusive count on your report. Inconclusive is the easy place to park a difficult judgement, and a well-run lab monitors its own rate for exactly that reason. If a large share of your requirements came back Inconclusive, ask why: usually it means the scoping was wrong or something the lab needed was never provided. It is worth knowing when a laboratory is allowed to record Inconclusive, because it may not be used where the evidence would support a Fail.

The independent review

Before anything is released, the reviewer works through the engagement and checks, among other things:

• that the build tested is the build received, by reference to the recorded hash;
• that the approved environment and qualified tools were actually used;
• that every verdict is supported by contemporaneous evidence;
• that no Inconclusive verdict is standing in for a Fail the evidence would support;
• that requirements you self-attested, and requirements excluded from scope, are disclosed;
• that remediation guidance is specific to your application rather than generic advice;
• that nobody who was barred or recused took part.

If any of that fails, the reviewer sends it back or withholds the report. That review is itself a record, kept whether or not it changed anything, because a review that found nothing is evidence the control was operating.

What the report has to contain

A cloud configuration profile report is not a free-form document. Certain elements are mandatory, and the reason each one is there is worth understanding:

What happens to the records afterwards

The lab keeps the whole record set, not just the report: the evidence, the verdicts, the environment configuration, the review record, every version of the report and every retest. Retention is typically at least two years after the certificate expires. That exists so that if a question arises later about how a verdict was reached, the answer can actually be produced.

It also means a lab cannot quietly revise history. Every attempt at your assessment, including one that failed, is a retained record with its own report. If a lab suggests it can make a failed attempt disappear, that is a serious problem with that lab.

What you are entitled to ask for

• the scope agreement in writing before testing starts;
• the name of your Quality Control Reviewer and the basis on which they are independent of the testing team;
• the dispute process, in writing, before you need it;
• written confirmation that no part of the fee depends on the verdict;
• a clear statement of what will be published, what will be sent to ADA, and what consent you need to give;
• the lab's retention period for your data, and what is destroyed at the end of the engagement.

A lab that is reluctant to answer any of those in writing is telling you something useful.

Specific to the cloud configuration profile

• Read-only access is normally sufficient. There is rarely a good reason to give an assessor permission to change anything. If a lab asks for write access, ask why and expect a specific answer.
• Configuration review does not disturb running services. It reads settings. If any active testing is proposed, that should be agreed separately, in a defined window, with your team available.
• Your cloud provider's own rules apply. Providers have policies about testing in their environments. Configuration review is generally unproblematic; active testing may need notification. The lab should know this, but confirm it.
• Every account in scope has to be named. Forgotten accounts and old projects are exactly where the problems are, so a scope that covers only the accounts you remember is of limited use.

How it works from your side, step by step

How often you have to do it again

Annually as a formal matter, but configuration differs from code in one important way: it drifts continuously. Somebody opens a port to debug a problem and does not close it. Somebody grants broad permissions to make a deployment work and never narrows them again. None of that involves a code change or a release, so none of your normal review gates catch it.

So the honest answer is that the formal assessment is annual, but configuration monitoring should be continuous and automated. Teams that put automated configuration checks into their deployment pipeline find that the annual assessment becomes a formality instead of a fire drill.

The mistakes we see most often

• An incomplete inventory. Resources in forgotten regions and old projects, created for a trial two years ago and never deleted.
• Long-lived credentials. Access keys created years ago, still valid, sitting in a script somewhere.
• Development able to reach production. Convenient, and one mistake away from a real incident.
• Secrets in source control. Still extremely common. Remember that deleting a file does not remove it from git history.
• Logging switched off to save money. Then no way to investigate when something happens.
• Backups never restored. An untested backup is a hope, not a control.
• Fixing findings without fixing the cause. Closing the port without asking why it was opened means it will be opened again next month.

Frequently Asked Questions

Click any question to expand the answer.

Where to start

Run a CIS benchmark scan and your cloud provider's own security assessment tool this week. Because the profile is built on the CIS benchmarks, that scan maps directly onto the requirements, which makes it the fastest useful thing available to you. Then close anything publicly exposed that should not be, and search your source control history for secrets. Those three actions will remove more real risk than anything else on this page.

If you are also being assessed on the application itself rather than only its back end, the companion piece on CASA, the Cloud Application Security Assessment, covers the web and API side of the same family. This profile rarely travels alone.

About Adayptus

Adayptus Consulting Private Limited is an application security testing firm based in Noida, India. We have been doing web, mobile and cloud security testing since 2018.

We are currently building our laboratory management system to ISO/IEC 17025:2017 and working towards authorisation as an App Defense Alliance Security Test Laboratory. We are not an ADA-authorised laboratory today. We will say so plainly on this page until that changes, because you should be able to trust what a security firm tells you about itself.

What we can do for you right now:

• Readiness testing. We test your app against the cloud configuration requirement set and tell you what would fail, before you pay for a formal validation. Finding out early is much cheaper than failing late. In practice this is a cloud security assessment aimed at a specific published bar, with identity and permissions review where the estate warrants it.
• Fixing what we find. We give you guidance specific to your application, pointing at the actual component and the actual change needed, not a link to a general guideline.
• Evidence preparation. We help you assemble the documentation, architecture information and test accounts an authorised lab will ask for, so your validation does not stall on paperwork.

Because configuration drifts rather than sitting still, the follow-on that actually keeps an account clean is continuous validation and knowing what you expose through attack surface management, rather than waiting for next year's assessment.

Attribution and source