Archknot

What is protected, and what is not

A security page is the easiest place on a website to over-claim, because almost nobody can check it. Every control below was verified against the implementation first, and the gaps are listed on the same page rather than left out.

What is in place

  • Encryption in transit

    Everything is served over HTTPS, and browsers are told to refuse plain HTTP for this domain from now on.

    How it is implemented
    HTTP Strict Transport Security is served with max-age 63072000, includeSubDomains and preload, alongside upgrade-insecure-requests in the content security policy.

  • Encryption at rest

    Application data is stored in a managed PostgreSQL database whose storage is encrypted at rest.

    How it is implemented
    This is a capability of the managed platform the database runs on, not something we built. We rely on it and say so rather than implying we implemented it.

  • Tenant isolation

    Every table is protected by row level security, so a signed-in user can only reach their own rows and the organisations they belong to.

    How it is implemented
    Row level security is enabled on every table, including projects, project versions, profiles, organisations and memberships. Policies are scoped with auth.uid(). A dedicated isolation script runs sixteen cross-tenant probes and is expected to pass all of them.

  • Secret handling

    Privileged keys are only ever used on the server. Nothing that can bypass tenant isolation is sent to a browser.

    How it is implemented
    Environment variables are validated at startup against a schema. Only the two NEXT_PUBLIC_ values - the project URL and the anon key - are permitted into the client bundle; the service_role key is read server-side only. The content security policy restricts connections to this origin and our own Supabase project.

  • Browser hardening

    The site ships a restrictive content security policy and the other headers that stop the common browser-side attacks.

    How it is implemented
    frame-ancestors none and X-Frame-Options DENY (no embedding), object-src none, base-uri and form-action locked to this origin, X-Content-Type-Options nosniff, a strict referrer policy, and camera, microphone, geolocation and payment permissions denied outright.

  • No access to your infrastructure

    Archknot never changes your production systems. There is no automatic apply, at any tier.

    How it is implemented
    We hold no credentials to any cloud provider account. The product generates Terraform for you to review and run through your own process. This is a design constraint rather than a setting.

What is not in place yet

Listed at the same weight as the controls above. A buyer who discovers a missing control after signing is a customer who stops believing the rest of the list.

  • No security certification

    We hold no SOC 2 report, no ISO 27001 certificate and no other attestation. Compliance output in the product describes your architecture against technical considerations; it says nothing about our own compliance, and we do not imply otherwise.

  • No independent penetration test

    The application has not been tested by an external offensive security firm. Dependency auditing runs on a schedule, but that is not the same thing and we will not present it as though it were.

  • Hardware security keys (FIDO2/WebAuthn) not yet supported

    Multi-factor authentication currently supports standard RFC 6238 TOTP authenticator apps. Hardware tokens (e.g. YubiKeys) and passkeys are planned but not yet supported.

  • No customer-managed KMS encryption keys (BYOK)

    Data encryption at rest uses platform-managed KMS encryption keys. Storing and rotating customer-supplied encryption keys in your own AWS/GCP account is not yet available.

  • No automated SCIM directory provisioning

    Enterprise SSO relies on manual collaborator invitations or email domain access levels; automated SCIM directory synchronization with Okta or Azure AD is on the roadmap.

Reporting a vulnerability

If you have found something, we would rather hear it from you than read about it somewhere else. Tell us what you found and we will tell you what we are doing about it.

Report tosecurity@archknot.com

In scope

  • This application and its server routes - anything served from archknot.com
  • Authentication and account handling, including session and token behaviour
  • Tenant isolation: any way one account can reach another account’s projects, requirements or reports
  • Handling of uploaded or generated content, including anything injected into a generated report or Terraform file

Out of scope

  • The platforms we run on. Supabase, Vercel and our mail host have their own programmes - report to them, though we will happily pass a report on if you tell us
  • Denial of service, volumetric attacks and resource exhaustion
  • Social engineering, phishing of our team, or physical access
  • Automated scanner output with no demonstrated impact attached to it
  • Best-practice suggestions with no exploitable consequence - missing headers on a static page, SPF or DMARC tuning, clickjacking on a page with no sensitive action behind it
  • Anything requiring a compromised device, a malicious extension, or hands on someone else’s keyboard

What to include

  • What you did, step by step, so we can reproduce it
  • What you believe the impact is, and who it affects
  • A proof of concept, if you have one - it saves a great deal of guessing
  • Whether you want to be credited, and under what name

What we commit to

  • We will acknowledge your report and tell you whether we are treating it as a security issue
  • We will explain what we are doing about it, and tell you when it is fixed
  • We will not take legal action against researchers acting in good faith within this scope
  • We will credit you when the fix ships, unless you would rather we did not

Two honest limits on the above. We aim to respond quickly but we are not yet able to offer a response-time guarantee, because we do not have a staffed security function. And the safe-harbour intention is an intention: turning it into a legally binding commitment needs a lawyer, and that wording is still being written.

This assessment covers technical architecture considerations only and does not constitute legal advice, certification, or confirmation of regulatory compliance.

Read how the decisions are made

The methodology page explains the rest of the process, including the parts that are not built yet.