Reporting a vulnerability.

1. How to report

Email hello@armada-solutions.com with “Security” in the subject line. Include what you found, where, and the steps to reproduce it. A proof-of-concept helps. So does telling us how you would exploit it, because that is usually the part we have not thought about.

Report it to us before disclosing it anywhere else, and give us a reasonable window to fix it. We are a two-person company; we will not treat a disclosure deadline as an attack, but we will ask you to be realistic about our size.

There is no bug bounty. We have no budget for one and we would rather say so than imply a reward that never arrives. What we can offer is a fast, human reply and public credit if you want it.

2. Safe harbour

We will not pursue legal action against anyone who reports a genuine finding in good faith and who:

• does not exploit the finding beyond the minimum needed to demonstrate it;
• does not access, modify, or retain anyone else’s data — if you encounter customer or tenant data, stop, and tell us what you saw so we can assess the exposure;
• does not degrade, disrupt, or denial-of-service the site or the platform;
• does not use social engineering, phishing, or physical intrusion against us or our vendors;
• gives us a reasonable window before public disclosure.

Work within those lines and we consider your research authorised, and will say so in writing if you need it. This commitment is ours to give for our own systems only — it cannot authorise you to test Microsoft, Cloudflare, or any other vendor.

3. In scope

• armada-solutions.com and its subdomains.
• The Armada platform API and console, once either is reachable by you. Both are pre-launch and not publicly deployed, so today this is effectively the marketing site.
• Anything that would let one customer reach another customer’s tenants, attestations, or reports.
• Anything that would let an attacker forge, alter, backdate, or replay an attestation or its signature. The hash chain is the product’s core claim, and a break in it is the most valuable report you could send us.

4. Out of scope

• Findings in Microsoft 365, Azure, or Cloudflare themselves — report those to the vendor. We will help you route it if you are unsure.
• Missing hardening on this static site that carries no exploitable consequence, such as the absence of a header on a page that holds no session and no cookie.
• Volumetric denial of service, and any automated scanning that degrades the service for others.
• Social engineering of the founders, and physical security.
• Spam or abuse of the contact form. It is a relay to an inbox; tell us if you find a way to make it do something else.
• Reports from automated scanners with no demonstrated impact.

5. What to expect from us

• Acknowledgement within 3 business days. If you do not hear back, resend — assume the mail was lost rather than ignored.
• An assessment within 10 business days, telling you whether we consider it a vulnerability and what we intend to do.
• A fix timeline that matches severity, and updates as it moves.
• Credit, if you want it, once a fix is live.
• If we disagree that it is a vulnerability, we will explain why rather than going quiet.

If a report reveals that a customer’s or an end client’s data was exposed, our breach-notification obligations in the Data Processing Agreement apply, and they run regardless of how we learned of it.

6. How this website is built

Every claim in this section is verifiable from the page you are on — view the source, or open your browser’s network panel.

• No cookies and no storage. The site sets no cookies and uses no localStorage or sessionStorage. There is no cookie banner because there is nothing to consent to.
• No analytics and no ad networks. No Google Analytics, no tag manager, no pixels. There is no tracking script to find.
• No third-party requests. Fonts, styles, scripts, and the animation library are served from this domain. Nothing calls out to a CDN, and no outside company sees your IP address by virtue of you reading this page.
• A strict Content Security Policy. Scripts may load only from this origin — script-src 'self', with no 'unsafe-inline' and no 'unsafe-eval'. The site contains no inline scripts and no inline event handlers, which is what makes that possible. An injected <script> would not execute.
• Framing is refused (frame-ancestors 'none'), MIME sniffing is off (nosniff), referrers are trimmed cross-origin, and the permissions policy denies camera, microphone, geolocation, payment, and USB — none of which this site has any reason to request.
• HTTPS is enforced with HSTS.
• No login, no accounts, no passwords, no database. These are static files. There is no server-side code on this domain to exploit and no credential store to steal.

The only outbound request the site can make is the contact form’s relay to FormSubmit, and the CSP permits that one destination and no other. Every third party is listed on the sub-processors page.

7. What we do not have yet

We hold public claims about our own security to the standard we hold the product to: a claim names the thing that implements it, or it is written in the future tense.

• No SOC 2 report. We have not begun an audit. Anyone telling you Armada is SOC 2 certified is wrong.
• No third-party penetration test of the platform.
• Signing keys are not yet in a vault. Azure Key Vault is designed and stubbed but not implemented; the attestation signing key is currently generated by the application. This is a pre-launch blocker and is tracked as one.
• No executed DPAs with our own vendors, and no Standard Contractual Clauses for EU or UK transfers. See the sub-processors page.
• No live tenant scan has ever run. The platform is pre-launch.

For the platform’s design — what a scan reads, what is discarded, and what is stored — see Method & Trust. For the rules that bind customers, see the Acceptable Use Policy.