Skip to content
FINTERY

FINTERY AUDIT · TAKO CRM

TAKO CRM: the full audit report

Bound to version 1.0.0, not to the product name.

AUDIT · 2026-07-19CONDITIONS
  • Audited2026-07-19
  • Version auditedv1.0.0
  • Current versionv1.0.0

published in full

Summary

What the audit found

First-party flagship suite operating in production at tako.software. Deployed tier available now; the full Auditor run (including AI-surface and GDPR data-map checks) is pending.

An audit describes one exact archive on one exact date. It is not a warranty, and it is not a promise about the code you write on top of it once it is yours.

The checks

Every check, its method and its limit

Two checks run by machine on the packaged archive in a public CI workflow, on a clean runner that has never seen the code: the boot check and the secret scan. The other five are carried out by hand and signed off by a human before the listing changes. The catalog is never edited by the workflow.

Boots from compose

PASS

Machine verified in CI

The packaged archive is unzipped on a clean runner, the quickstart step its own README documents is replicated (copy .env.example to .env), the compose file has to validate, and the System has to answer an HTTP request on the port its compose file publishes, with a non empty body, within 90 seconds of starting.

What this does not prove: This proves the archive you download starts and serves a page on a machine that has never seen it before. It is not a functional test of every feature, a load test, or a penetration test.

Result here: The check ran and found nothing to hold against the System.

Secret scan, including history

CONDITIONS

Machine verified in CI

Every file in the unpacked archive is scanned for known credential formats: AWS access keys, private keys, live Stripe keys, GitHub and GitLab tokens, Slack tokens and Google API keys. The source repository's full git history is scanned separately, because a key deleted in the last commit still sits in the history.

What this does not prove: Pattern matching finds credentials that look like credentials. A password that reads like an ordinary word is not detectable this way, so this is a floor and not a guarantee.

Result here: The check ran and the result is qualified. The condition is stated in the summary rather than rounded up to a pass.

Licences and SBOM

CONDITIONS

Carried out by hand

The dependency tree is installed from the lockfile that ships inside the archive, and every package in it is inventoried into a THIRD-PARTY-LICENSES.md file that travels with the System. Copyleft and weak copyleft obligations are named explicitly instead of being averaged into a count.

What this does not prove: This is an inventory of declared licences, regenerated from the installed tree at the audit date. It is not legal advice, and it does not adjudicate a disputed licence.

Result here: The check ran and the result is qualified. The condition is stated in the summary rather than rounded up to a pass.

SAST and CVE scan

CONDITIONS

Carried out by hand

The shipped lockfile is audited for published advisories at every severity, and the findings are read rather than auto fixed: an automatic fix here proposes downgrading the framework by six major versions, so advisories are cleared by moving forward to patched releases instead. The source is reviewed by hand for the predictable classes: untrusted input rendered as HTML, authentication and session handling, and file paths built from user input.

What this does not prove: A clean advisory report describes the day it was run. New advisories are published continuously, so the audit date on this page is the honest scope of the claim, and kits are re audited and repackaged when that gap opens.

Result here: The check ran and the result is qualified. The condition is stated in the summary rather than rounded up to a pass.

GDPR data map

CONDITIONS

Carried out by hand

The personal data the System actually stores is read out of its schema and compared against the data map it declares in its fintery.json manifest. A field the code writes but the manifest does not declare counts as a finding, not as a detail.

What this does not prove: This describes the software as it ships. How you configure it, which processors you point it at and what you then do with the data is your controllership, and no audit of an archive can settle that for you.

Result here: The check ran and the result is qualified. The condition is stated in the summary rather than rounded up to a pass.

AI surface and egress

CONDITIONS

Carried out by hand

Where a System calls a model, the audit records which surfaces send data outward, whether an API key is required to run the System at all, and whether it degrades gracefully without one. Model identifiers have to be aliases rather than dated snapshot ids, so a System does not silently pin itself to a model that gets retired.

What this does not prove: Marked as not applicable where a System contains no AI surface at all, which is the case for most of this catalog.

Result here: The check ran and the result is qualified. The condition is stated in the summary rather than rounded up to a pass.

Provenance and realness

PASS

Carried out by hand

Whether the System was produced with AI assistance, which tools were involved and whether a human reviewed the result are declared rather than implied. The demo content inside the archive is checked for real customer data, real names and real balances carried over from the source system.

What this does not prove: This is a declaration backed by a review of the shipped files. It is not an attestation about every line's authorship.

Result here: The check ran and found nothing to hold against the System.

Provenance

How this System was produced

DECLARATIONREVIEWED
  • AI assistedYes
  • Toolsclaude-code
  • Human reviewedYes

No System in this catalog has been rated or reviewed by a customer, so no star ratings appear here or in the structured data these pages publish. When that changes it will be shown as what it is.