Trust & Safety

How Authobek secures applications

Authobek distributes software directly, so the checks below describe what actually happens to a package between upload and installation. They are platform mechanisms, not certifications: Authobek does not hold third-party security accreditation and does not claim any.

Package inspection

When a developer uploads a build, Authobek reads the package itself rather than trusting the submission form. The file type, declared version, package size and the version already published are recorded as a security record attached to that release.

Signing verification

Android packages must be signed by the developer before Authobek will accept them. The signing block is checked during inspection, and an unsigned or malformed package cannot progress to review.

Signing certificate & fingerprint

The certificate fingerprint captured at upload is stored with the release. Later versions of the same application are expected to carry the same fingerprint, so a sudden change in signing identity is visible to reviewers instead of silently shipping to installed devices.

SHA-256 package integrity

Authobek computes a SHA-256 digest of every accepted package and stores it with the version. An application cannot be published without one. Anyone can confirm a download independently at /api/public/verify/<app>/<version>, which returns the digest, file name and size Authobek holds for that release.

Security scanning

Each release moves through a scan pipeline with a recorded status — pending, scanning, integrity verified, passed, flagged or failed — and a security score. Every state change is written to the release's security event history, so the outcome is auditable rather than a one-off verdict.

Publication readiness

Before an application can become publicly visible it must clear a blocking checklist: a real publisher account with a working public profile, an icon, at least two screenshots, complete metadata, an installable package, a recorded SHA-256 digest, a passing scan status and moderation approval. Any failed blocking check makes publication impossible — this is enforced in the database, not only in the interface.

Human security review

Automated checks decide what reviewers see, not what gets published. A moderator reviews the submission, its scan result and its readiness report, and records the decision with a note. Publication is an explicit human action.

What happens when an application fails security review

It is not published. A flagged or failed scan is a blocking readiness failure, so the application stays out of the marketplace. Nothing partially published is left reachable.

The developer is told what failed. The scan status, the security score and the reviewer's note are written to the release record and shown in the developer's dashboard, alongside the specific readiness checks that did not pass.

A fix means a new build. The developer uploads a corrected package, which is inspected, digested and scanned again from the start. Previous attempts remain in the security history of that application.

An already-published app can be pulled. If a problem is found after release — through a scan, a moderator, or a public report — the application can be suspended or unpublished. Every lifecycle change is written to an audit log with the account that made it.

Developers can appeal. A rejection, suspension or removal can be appealed from the developer dashboard. Appeals are reviewed by platform staff and the outcome is recorded.

Security is one part of the trust decision Authobek publishes on every listing.

Verification explained Data Safety Report an application Trust Center

What happens when an application fails security review

Related