Security isn't a certificate. It's how we build.
SecurityTrackr is built by security professionals who have spent long enough on the wrong side of audit reports to know which practices actually reduce risk and which ones just look good on paper. This page is what we do and what we ask of you.
The product is the proof. Not the paperwork.
We do not currently pursue SOC 2 reports or similar paper-only attestations. In our experience, those frameworks measure whether you have a policy document, not whether your application resists a real attacker. We'd rather spend that effort on architecture decisions, code review, and continuous adversarial testing of the product itself.
That review is structured, not ad hoc: every release cycle runs multi-agent deep-dives against four named lenses (the OWASP Top 10, multi-tenant isolation, cryptographic correctness, and fail-secure behaviour), and every finding is tracked to closure with a dated fix or a written, identified acceptance rationale (an A-NN a future auditor can reason about). The concrete controls that come out of that work are below.
Our own product, assessed in public.
We use AI agents for source review against recognised standards and for authorized live testing of a non-production deployment. We publish the methods, verdicts, failures, and limitations, with sensitive fixture and credential details removed.
Live application security assessment
We authorized GPT-5.6 Sol to probe a non-production deployment through browser sessions, the REST API, and MCP/OAuth. Here is what it tested, how it tested it, what it did not test, and the result.
ISO/IEC 25010:2023
An AI agent graded our whole codebase against the ISO/IEC 25010 product-quality model: architecture, reliability, security, maintainability, and the rest. Here are the grades, the reasoning, and what happened when a verification pass threw out two of the three findings.
OWASP ASVS 5.0.0
An AI agent checked the app against the OWASP Application Security Verification Standard and the API Security Top 10, requirement by requirement. Per-chapter pass/fail, the API Top 10 verdicts, a broken-object-access probe on both ways in, and the gaps we still have open.
SOC 2 Trust Services Criteria
We don't pursue a SOC 2 report, so we had an AI agent run the gap analysis honestly: every Trust Services Criterion, what the code already does, and the governance work a real attestation would still need. The technical controls are strong; the paperwork is a deliberate gap.
A public check of the perimeter.
Our architecture and review process are documented here. An independent external report gives you a separate view of what the public domain exposes.
Hardenize — securitytrackr.com
Review the latest public report covering the domain's DNS, email, TLS, certificates, HTTP security headers, and other exposed configuration. It reflects the fixed Content Security Policy.
Domain Security Check — securitytrackr.com
Run a second independent check of the public domain configuration and security headers.
This is an external configuration report, not a certification or an assessment of the application's private code.
Multi-tenant boundaries that don't rely on remembering.
Tenancy is enforced cryptographically and at compile time, not just by a WHERE organizationId = ? clause.
Per-organisation encryption keys
A two-tier key hierarchy: every organisation has its own random AES-256 data-encryption key, and that key is itself wrapped at rest by a platform master key held outside the database. SecurityTrackr staff have no interface for browsing or decrypting customer content, and raw database or object-storage access reveals ciphertext only. The only operator-assisted path is the GDPR data export that SecurityTrackr is legally required to facilitate; it releases data only after the customer supplies a one-time authorisation code sent to their registered email address.
Bound to tenant and field, not just encrypted
We don't just encrypt. We use authenticated encryption (AEAD). Every AES-256-GCM operation also binds the data to its context as additional authenticated data: your organisation ID and the specific field it lives in. The authentication tag then proves more than encryption under a key; it proves the value belongs to this organisation, in this field. A ciphertext copied to another tenant, or relocated from one column to another, fails authentication and refuses to decrypt rather than silently returning data. Tenant isolation does not rest on the key alone.
Observation data is encrypted at rest
Every sensitive field on an observation (title, user-supplied detail, AI-generated summary and recommendations, mitigating controls, affected systems) is encrypted with AES-256-GCM under your organisation's key before it touches the database, and so is the discussion thread your team writes underneath it. The plaintext exists only in memory, decrypted per request and never written to disk.
Organisation data is encrypted too
Your organisation profile (including the corporate logo you upload) is encrypted under the same per-org key. Even the branding we render for you is unreadable to anyone but you.
Evidence files: encrypted, checked, never exfiltrated
Uploaded screenshots, PDFs, and documents are MIME-validated against their magic bytes, encrypted with your per-org key before they reach object storage, and submitted by SHA-256 hash to VirusTotal for malware reputation lookup. The filename is encrypted alongside the bytes, under its own context label — a name like acme-prod-vpn-creds.pdf gives away the finding on its own. The file bytes themselves never leave our infrastructure; only the hash does. Files flagged as malicious are blocked from re-download.
Search without decryption (a blind index)
Because observation fields are encrypted at rest, we store nothing readable to search against. Each finding's words are normalised and one-way hashed with a per-organisation key (derived from your org key via HKDF, kept cryptographically separate from the encryption key) into a blind index. Your query is hashed the same way and matched by equality, so a search never decrypts a row to filter it. Anyone with raw database access but no keys sees only irreversible per-org hashes, and the same word hashes differently in every organisation.
EU data residency, no third-party tracking
All customer data stored by SecurityTrackr — including database records and uploaded evidence files — lives in EU-jurisdiction data centres. Evidence files are encrypted before entering object storage under per-organisation keys. AI processing location and retention depend on the provider selected by the customer and are disclosed separately. We also keep the surfaces clean of surveillance: no third-party analytics, user-profiling trackers, or session replay in the application or on the marketing site.
Compile-time multi-tenant boundary
Every kind of identifier (organisation, user, observation, and the rest) is its own distinct type, not an interchangeable string. The compiler rejects code that mixes them up or passes them in the wrong order, and that check is enforced in our build pipeline on every change. Multi-tenant isolation is guaranteed by the type system before code can ship, not left to whoever remembers to scope each query.
Mandatory MFA, no per-stage oracle
MFA is not optional. Signing in requires email, password, and a TOTP code together, in a single step; nothing confirms one factor before the others, so the flow can't be used to probe whether a password is correct or whether an account exists. Backup codes are stored only as hashes and used once. SSO accounts inherit MFA from your corporate identity provider.
Bounded sessions, revoked server-side
Sessions run on a two-tier clock: an 8-hour idle window that slides forward while you're active, and a hard 48-hour cap anchored at sign-in that no amount of activity can extend. Revocation is enforced on the server, not just by clearing a cookie. Changing your password, resetting it, signing out, deleting your account, or being removed from an organisation invalidates every live session through a store checked on each request. If that store is unreachable, the session is rejected, not trusted.
Containing prompt-injection risk
Prompt injection remains an unsolved industry problem. We defend against it, but never treat a model following instructions as a security boundary. AI providers have no persistent memory between requests; where a conversation needs context, SecurityTrackr supplies a bounded transcript for that request only. Models receive only tenant-scoped context selected by the application and cannot independently browse customer records, invoke product tools, or change application state.
Choose your managed AI provider
Our managed Advanced AI tier defaults to Anthropic (Claude), chosen for markedly richer, more accurate output, processed in the US under our DPA and Zero Data Retention agreement, with no training on your data and nothing retained beyond generating the response. Need your findings to stay in Europe too? Switch to Mistral, a European (EU-based) AI provider with EU data centres, also under a DPA and ZDR. Prefer GPT? Switch to OpenAI (GPT-5.6), processed in the US under a DPA with no training, but without ZDR. Each is a one-click choice in Account settings.
Or bring your own provider key
Prefer that your findings never run under our AI contract at all? Bring your own provider key (OpenAI, Anthropic, or Mistral) and every generative AI call runs against your account, under the data-processing terms you have agreed directly with that provider: their retention, their training opt-outs, their residency. Semantic-matching embeddings remain on a separate platform-managed Mistral path when enabled. The key is stored encrypted under your per-org key like any other secret. It is a sovereignty option for organisations that need the AI path to sit inside their own vendor agreements.
Fail-secure by default
If a security control the request depends on can't be reached, the request is refused rather than waved through; every such path is fail-closed by design, and each one is reviewed on that basis. Security-relevant actions (sign-ins, MFA changes, finding edits, billing events) are written to an audit trail keyed by a one-way correlation value, so activity can be traced for support without keeping personal data in operational logs.
Report a vulnerability, end up on this page.
If you believe you have found a security issue in SecurityTrackr, please report it to security@securitytrackr.com. Our machine-readable contact is published at /.well-known/security.txt per RFC 9116.
We are in the process of standing up engagements with established bug-bounty programmes so researchers can submit through the channel they already use. Until that lands, please email us directly. We read every report and respond.
We will not pursue legal action against good-faith researchers who follow the rules of engagement below.
Test us hard. Just not the wallet.
Testing SecurityTrackr is welcomed; we'd rather you find a bug than someone else does. A few practical limits keep the platform available for paying customers and the costs sustainable.
- Authenticated and unauthenticated probing against accounts you control.
- Source-code review (we are not currently open source, but front-end bundles are fair game).
- Reasoning about cryptographic and access-control assumptions.
- Reporting issues with reproduction steps.
- Denial-of-service or volumetric tests against any environment.
- Automated scanners that hammer AI endpoints; they cost us real money per call.
- Prompt-injection and jailbreak testing of the AI features; the section below explains why it is out of scope.
- Mass account creation, mass-invite, or mass-evidence-upload abuse.
- Social engineering of staff or customers.
- Accessing data belonging to organisations you do not own.
- Publishing details of an unfixed issue before we have had time to respond.
Why prompt injection is out of scope
Prompt injection remains an unsolved industry problem. Our containment model does not depend on the model always obeying instructions: cross-tenant authorisation is enforced before any AI context is assembled, and the model receives only tenant-scoped context selected by the application. AI providers have no persistent memory between requests. Most features send one bounded request; where the Security Advisor needs conversational context, SecurityTrackr supplies a bounded transcript for that request only. The model cannot independently browse customer records, invoke product tools, or change application state.
A jailbreak that changes only the prose returned to the requesting user is an output-quality issue, not a crossing of a security boundary. We describe our broader approach in How we build with AI.
What we do want to hear about: AI output containing data from an organisation the caller does not belong to, an AI response that causes a state change nobody authorised, or a way to make an AI feature act on a prompt the requesting user never supplied. Those are access-control findings that happen to travel through the AI, and they are firmly in scope.