HOW SCORING WORKS

How CanITrustThat scores an app's security and privacy

From the shipped binary to a 0 to 100 score, with the evidence behind every point.

CanITrustThat scores an app by decompiling the build that ships to your phone and grading how its code handles security and privacy against a fixed set of checks. Every app gets one overall trust score from 0 to 100, with separate security and privacy scores and the code evidence behind each one. The result is a free public scorecard.

How does a scan work?

1
Decompile the shipped app
We start from the exact file people install, the Android APK or the iOS build, and turn it back into readable source. We analyze the app that ships, never the store listing or the privacy policy.
2
Read the code
We go through the recovered code for how it handles secrets, cryptography, network transport, storage, permissions, and third-party trackers and SDKs. On Android we also build a call graph, so a finding ties back to exactly where it lives and how the app reaches it. iOS scans don't get a call graph yet.
3
Check what it does against what it declares
Now we look at behavior: the servers it talks to, the data it moves off the device, and how that lines up with what it claims to do. This is where the flows an app never mentions on screen show up.
4
Score across the trust pillars
Findings roll up into security and privacy scores across the trust pillars, then combine into one trust score from 0 to 100 that maps to the bands below.
5
Publish the verdict and the evidence
The scorecard goes public: the overall score, the security and privacy scores, a plain verdict, and the specific findings from the code that back it. That part is free. The detailed report goes deeper for the teams who have to act on it.

What do the scores mean?

Every app lands in one of six bands on a 0 to 100 scale. The band gives you the headline verdict. The findings underneath show how the app earned it.

Score	Verdict	What it means
90–100	Very Secure	Gets the hard parts right and keeps nothing hidden from the code.
80–89	Trustworthy	Handles your security and privacy well, with only minor findings.
70–79	Solid	Sensible practices with room to tighten up. Nothing alarming.
55–69	Use With Caution	Usable, but with weaknesses you'll want to understand before you rely on it.
35–54	Elevated Risk	Real problems that put your data at risk. Think hard before you install.
0–34	High Risk	Serious security or privacy failures. Skip it unless you truly have no other option.

How is the score calculated?

The score starts from fixed math, not judgement. Every app begins at 100, and each finding subtracts points by its severity. The same findings always produce the same starting score.

Severity weights

Each severity carries a weight. The deduction grows with the number of findings at that severity but flattens as the count climbs, so ten low findings never outweigh one critical one.

Severity	Weight
Critical	15
High	7
Medium	3
Low	1
Informational	0.2

From two scores to one

Security and privacy are scored separately, then combined into the overall score. The weaker of the two counts for 70% and the stronger for 30%, so a strong security score cannot paper over a weak privacy one, or the other way around.

The contextual adjustment

After the math baseline, a contextual adjustment can shift a score up or down where the raw counts miss context. Every such adjustment is logged against the scan alongside the baseline it started from, the reason, and the model and prompt versions in force, so the change is auditable and the baseline is never silently overwritten.

How does the scoring handle a serious finding?

A score isn't an average. One serious finding caps how high an app can land, however clean the rest of the code reads. An app that gets forty things right and one thing badly wrong — a flaw that puts your data at real risk — earns the score of that one thing.

What about findings marked Info?

Some things are worth writing down without counting against the app. We mark those Info: we saw them, recorded them, and left them on the report, but they don't move the score. They're there so you can see what we looked at.

What if a finding is wrong?

Reading decompiled code at scale produces the occasional false alarm — a flag that doesn't hold once you read what's around it. Tell us a finding is wrong and we go back to the code, check it, and correct the report and the score if it doesn't stand. The evidence sits on the page so anyone can make that case, not just us.

What does "TRUSTED" check?

The public TRUSTED mark rests on a set of plain pillars. Each one is a question you'd ask yourself before installing, and each is backed by specific checks in the code. Two of them, Truly Local and Child-Safe, are checked only when they apply.

Is my data actually protected, from the secrets and encryption down to how it's stored and who gets in?

Secure by Design

Encrypted in transit and at rest, with no keys or passwords hardcoded in the app.

Does this app take only what it needs, or does it follow me around across other apps and installs?

Data Minimization

Collects only what it needs, and keeps its tracking to the app itself.

Does it do what it declares on the screens I see, or is there something moving in the background?

Manifest Mismatch

It does what it declares on the screens you see, with nothing tracking behind them.

If I change my mind, can I get my data out and actually leave?

User Control

People can export their data and leave at any time.

If this app is meant to work offline, does my sensitive data really stay on the device? (Checked only for offline apps.)

Truly Local · conditional

Sensitive data stays on the device, checked only when an app is meant to work offline.

If this app is made for kids, is it genuinely safe for them? (Checked only for children's apps.)

Child-Safe · conditional

Safe for kids, checked only when an app is made for children.

What does a "TRUSTED" verdict mean?

A TRUSTED app clears the security and privacy checks behind every pillar and lands in the upper score bands. The code we read handles secrets, encryption, what it collects, who it shares it with, and whether you can leave, with no serious finding left hanging.

Read it as an evidence-backed snapshot of what the app does in the version we scanned. Ship a new build and things can change, which is why the scan is repeatable and the evidence sits right there on the page.

How sure are we about each finding?

Every finding carries one confidence level, and that level decides how much weight it gets.

Confirmed
The claim is backed by evidence in the code — a value, a code path, or a verified precedent. It scores and it can headline the report.
Inferred
Probable but not fully verified. It still counts toward the score and can headline, but the wording hedges to match how sure we are.
Unverified
A lead we could not stand behind yet. An unverified finding never moves the score, never fails a pillar, and never becomes a headline. It appears in the body only, labelled as unverified, so you can see what we noticed without us claiming more than we checked.

Do we notify the developer, and can they reply?

When a report raises a serious security finding, we aim to notify the developer before it goes public and give them a reply window to respond. Whatever they send back is published alongside the report, in their own words. A choice not to reply is recorded as exactly that, neither for nor against the app.

For the most sensitive findings, such as a live secret or a way past authentication, our policy allows for a coordinated-disclosure embargo: a hold on the specifics while the developer fixes the issue. That hold is not switched on by default today; when a report is under it, the page says so plainly instead of hiding that anything exists.

How long do we keep the evidence?

We retain the evidence behind every published assessment for 7 years: the SHA-256 of the exact app binary we analyzed, the analyzer's findings, the ruleset, model, and prompt versions in force at the time, the App Store privacy label exactly as it appeared when we retrieved it (with the date), our reviewer's verdict and reasoning, and any correspondence with the developer. This lets us stand behind, and if necessary substantiate, anything we say about an app.

Which version of the rules is this?

Everything on this page describes ruleset citt-ruleset-2026-08-v1. Every report is stamped with the ruleset it was scored under and links back to the matching version of this page, so you always read a report against the rules that produced it.

Do the apps we rate pay us?

No. The apps we rate don't pay us, and no one can pay to raise a score or pull one down. A score reflects the code we read and nothing else.

We also do commissioned teardowns, which are paid — but the client pays for the work, and the findings come out wherever the evidence lands, the same as every public rating.