DASA: Security Testing for Desktop and Server Apps

App Defense Alliance

The Desktop Application Security Assessment covers software that runs on a machine you do not control. Here is what that involves, who needs it, and what the laboratory does.

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.

DASA stands for Desktop Application Security Assessment. It covers software installed and run on a user's own computer, or on a customer's server, rather than in a browser or on a phone.

The specification is explicit about what falls in scope, and the list is broader than most teams expect:

• Native applications. Written in C and C++, .NET, Swift, Rust or Go.
• Electron and CEF-based applications. Desktop apps built on an embedded browser engine, which are extremely common and carry both desktop and web-style risks.
• Applications communicating with backend APIs. The client side of a client-server product.
• Installers and updaters. Explicitly named. This is the part teams most often leave out of scope and it is frequently where the most serious findings are.

It applies across Windows, macOS and Linux.

An independent laboratory works through the requirements against your software and records a verdict on each. The structure is the same as the other ADA programmes. What differs is the threat model, and that difference is the whole reason DASA exists separately.

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.

How the requirement set is organised

DASA is structured as a common baseline that applies everywhere, plus annexes for platform-specific requirements. The baseline is compact, which makes it a realistic self-assessment target.

That is roughly twenty-six common baseline requirements, with further platform-specific requirements in the Windows, macOS and Linux annexes. Requirement identifiers are hierarchical: section, then subsection, then requirement.

DASA maps onto standards you may already follow, which usually means less new work than it first appears: the AFINE Desktop Application Security Verification Standard, the NIAP Protection Profile for Application Software, the OWASP Desktop App Security Top 10, and OWASP ASVS.

Why desktop and server software is a different problem

This is worth understanding properly, because it explains why the requirements are not just the web ones renamed.

• The attacker may own the machine. With a web app you control the server. With desktop software, the user, or an attacker who has compromised the user, has full control of the environment your code runs in. You cannot assume the operating system is honest, and you cannot keep a secret in your own binary.
• Local privilege matters. Desktop applications often install services that run with high privileges. A flaw there does not just affect your app, it can hand over the whole machine to a low-privileged user.
• Updates are your responsibility. A web app is patched when you deploy. Desktop software is patched when the user updates, which makes your update mechanism security-critical. A compromised updater is a route into every customer you have, which is why this gets so much attention.
• Files are an attack surface. Desktop software opens documents, projects and configuration files. Anything parsing a file format is a place where malformed input can cause memory corruption.
• Code signing is visible. Users and operating systems check signatures. Weak signing practice is both a security problem and a usability one, because unsigned software gets blocked or warned about.

The specification puts the threat model in a single sentence worth keeping in mind while you self-assess. It observes that desktop applications execute in an environment where the application binary itself is directly accessible to attackers, where shared libraries can be subverted, and where inter-process communication channels may be exploited.

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.

The profile folder holds two documents. The DASA Specification is the requirement list: an identifier and a one-line description, and deliberately nothing more. The DASA 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. The submission artefacts that go with the profile — developer onboarding questionnaires for AL0/AL1 and AL2, and the laboratory report templates — live separately under the repository's submission forms and templates area rather than in the profile folder.

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

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 software 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 software, 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 software

The lab needs installable builds for every platform in scope, plus any licence keys required to exercise the software fully. Because desktop products are usually several things at once, an installer, an application, a background service and an updater, the lab records and hashes each component it received rather than treating the product as one artefact.

• 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 DASA 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 DASA

• Testing on a machine the tester fully controls. This is the point of desktop testing. The assessor will do things your support team would consider abusive, because a real attacker with access to the machine would too.
• Deliberate privilege escalation attempts. The lab will try to use your privileged service to do something a low-privileged user should not be able to do. This is usually where the most serious findings come from.
• Update mechanism tampering. The lab will try to serve your updater a modified or unsigned package and see whether it installs it. If it does, that is a critical finding.
• Multiple operating systems. Each platform has its own privilege model, credential store and installer behaviour, so each one in scope adds real work.

How it works from your side, step by step

How often you have to do it again

Expect annual renewal, consistent with the other ADA programmes. This is the one figure we would still confirm with your laboratory rather than assume, because DASA is a more recent addition. Desktop software has an additional consideration: if you ship a major version with significant architectural change, that is worth reassessing regardless of where you are in the annual cycle, because the report describes the version tested and nothing else.

The mistakes we see most often

• Only testing the main application. The installer, the updater and the background service are usually where the serious findings are, and they are the parts teams forget to include in scope.
• A service running as administrator for convenience. Very common, and very often the finding that matters most.
• Unsigned or weakly verified updates. If your updater will install whatever it is given, you have built a distribution channel for malware.
• Ancient bundled libraries. Nothing forces desktop dependencies to update, so they rot quietly for years.
• Storing tokens in plain text. Operating systems provide protected credential stores. Use them.
• Assuming the local user is trusted. On a shared or managed machine, a low-privilege user is a realistic attacker.

Frequently Asked Questions

Click any question to expand the answer.

Where to start

Download the DASA Test Guide from the repository and note the release version. Then do two things internally before you speak to anybody: write down everything in your product that runs with elevated privilege and justify each one, and verify that your update mechanism refuses unsigned packages. Those two exercises will tell you most of what you need to know about how a DASA assessment will go.

Desktop products with a cloud back end usually need more than one assessment. If yours talks to a web API, the companion piece on CASA covers that side, and the Cloud App and Config Profile covers the infrastructure it runs on.

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 DASA requirement set and tell you what would fail, before you pay for a formal validation. Finding out early is much cheaper than failing late. Where the requirements turn on memory safety or parsing, secure code review is usually the faster route to an answer than testing the binary.
• 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 a desktop product is usually a client talking to a service, the back end is a separate attack surface: API penetration testing covers what your installed software talks to, and threat modeling is the cheapest way to find privilege problems before they are built.

Attribution and source