Security
Reporting a vulnerability
Send it to [email protected] and it reaches one person, me. Everything below is what happens after that: what I will look at, how quickly you hear back, and my position if you find something by poking at the software in good faith.
How to report
Email [email protected]. Do not use the contact form on the home page for this: it stores what you write in a database, and a working exploit does not belong there.
Start the subject with [TRIDENT SECURITY] if you can. One person reads that address, and the prefix is what pulls your mail out of everything else that arrives that day. A report without it still gets read.
Write in English, Portuguese or Dutch. Include enough to reproduce it:
- The Trident version from Extension Management, or the URL if it is this website.
- The base application version, and whether the environment is a sandbox or production.
- The steps, in order, with the page or API endpoint named.
- What you saw that should not have been possible.
- The permission set the account was assigned, if the finding is about access.
A screenshot helps. A proof-of-concept helps more. If you would rather encrypt the mail, say so in a first message with no detail in it and I will send you a key.
What you get back, and when
This is one maintainer, not a security team, so the commitments are ones I can actually keep:
| 3 working days | An acknowledgement from a human, saying I have it and I have read it. |
|---|---|
| 10 working days | Whether I reproduced it, what I think the severity is, and what I intend to do. |
| While it is open | An update whenever the state changes, and no silence longer than a fortnight. |
| On the fix | The build number that carries it, and a note of whether it is already published. |
Anything that reads data across companies, defeats a permission check, or lets an unauthenticated caller reach a Trident API page becomes the only thing I work on until it is closed. Everything else queues behind the current release.
If I disagree that a finding is a vulnerability, you get the reasoning, not a form letter. You are free to publish that disagreement.
Scope
| In scope | The Trident extension, any 0.1.0.x build. The two API pages and the service account model behind them. The permission sets. This website, marverafinance.com, including the contact endpoint at /api/contact. |
|---|---|
| Out of scope | Business Central itself, and everything Microsoft ships. Those go to the Microsoft Security Response Centre, not to me. So does anything in the Azure or Entra layer underneath a tenant. |
| Not a finding | Gaps I have already written down. The known limitations page lists what Trident does not enforce, on purpose or because it is unfinished. A report that one of those is missing tells me something I published myself. |
| Also not a finding | Missing headers with no exploit attached, mail configuration scored by an online grader, version numbers being visible, or output from a scanner pasted in with no analysis. Show me what an attacker gets. |
Rules for testing
Test against your own tenant, or against a sandbox you control. Ask me and I will give you a build and the seed script that fills a demo company with charters, so you have realistic data that belongs to nobody.
- Do not touch a tenant you were not given.
- Stop at the point where you have proved the finding. Reading one record you should not see proves it; enumerating the table does not.
- Leave the data alone. No deletion, no encryption, no modification you cannot undo.
- No denial of service, no load testing, no spam through the contact form.
- No social engineering of me or anyone else, and no physical access attempts.
- Give me the window in the table above before you publish. If it runs out and nothing has happened, publish.
Safe harbour
If your research stays inside those rules, I will not report you, sue you, or ask anyone else to, and I will treat what you did as authorised. If a third party comes after you for it, tell me and I will confirm in writing that you were working with my permission.
I can only speak for Marvera. Microsoft's terms cover the platform your test tenant runs on, and a customer's terms cover their environment. Nothing here waives their rights, so read theirs too.
There is no bounty
Be clear-eyed about this before you spend a weekend on it
Marvera has no revenue and no customers. There is no money to pay you, and pretending otherwise would waste your time.
What you get instead: credit by name on the release notes and on the status page if you want it, silence if you do not, and a straight answer either way.
Disclosure
There are no customers today, so coordinating a disclosure date is a conversation between the two of us. If a pilot is running when a report lands, those customers hear about it before any public page does, and you are told what date that is.
Fixed security issues are named on the status page once a build carrying the fix is published. The finding gets described in enough detail to be useful and not enough to be a recipe.
What the software already does about this
So you know where to start. Trident holds no credentials of its own and issues no tokens; authentication is Business Central's, and every permission decision is enforced by the platform against permission sets the extension declares. The API pages sit behind a dedicated service account with its own restricted set, described in the API guide. Business data never leaves the tenant, and the only outbound signal is telemetry classified as system metadata, itemised in the privacy page.
The soft spot is authorisation, not authentication. A permission set that grants more than it should is the failure mode I would look for first, and it is where a live non-SUPER account has already found defects that no unit test caught.