Architecture as a security control
Every Primanza product has its own repository, its own deployment, its own database, its own credentials, its own authentication and its own security boundary. There is no common account system, no common database and no common application secret across the portfolio.
This is a deliberate containment design, and it is worth stating what it rests on. Products are addressed as subdomains of primanza.com, which is a routing and naming arrangement — it does not put them on shared infrastructure, and it does not give one product a credential, a session or a database connection belonging to another. Cookies are scoped to each product's own host rather than to the parent domain, so a session cannot travel sideways; the Cookie Policy sets that out in detail.
What that buys is containment rather than immunity: a compromise of one product does not carry a path into another product or into this site. It is a bounded claim, not an absolute one. The layer genuinely shared across the portfolio is the domain registration and DNS, and a compromise there would be a compromise of the naming layer — which is why that configuration is in scope for disclosure below.
The corporate site is statically rendered, has no database, no authenticated surface and no user accounts. It is served over HTTPS with HTTP Strict Transport Security, a restrictive Content Security Policy and standard hardening headers. The most reliable way to secure data is to not hold it, and this site holds almost none.
Certification, testing and what this site does not claim
Primanza holds no security certification. There is no SOC 2 report, no ISO 27001 certificate and no completed third-party penetration test, and none is claimed anywhere on this site or in any document it publishes. Stating that is cheaper than being asked.
That position is a function of stage rather than of principle. Certification attests to controls operating over a period across an organisation with staff and customers; the company has neither yet, and an attestation bought before there is anything to attest to is an expense that buys a logo. The commitment is the ordering: independent testing and formal assurance belong to the first product that carries customer data, and they will be arranged before it carries any, not after.
One deliberate weakness in this site's own configuration is disclosed here rather than left to be discovered. The Content Security Policy permits inline scripts (`script-src 'unsafe-inline'`). Every route is statically prerendered, and both the framework's bootstrap payload and the structured-data block are emitted inline at build time; a nonce-based policy has to be generated per request and would force every page out of static rendering. The site accepts no user input that is reflected back into a page as HTML — the contact form's only destination is a mailbox, and its own states are fixed strings — so there is no reflected-injection sink for that directive to protect. The remaining directives are strict and do real work: no plugins, no base-tag rewriting, no off-origin form submission, no framing. If a third-party script or any surface that echoes user input into the DOM is added, this trade is revisited before it ships.
Reporting a vulnerability
Email security@primanza.com. A machine-readable pointer to this policy is published at /.well-known/security.txt in accordance with RFC 9116.
A report that lets us reproduce the issue gets fixed faster. Please include:
- The affected domain, URL or endpoint.
- A description of the issue and why you believe it is a security problem.
- Clear steps to reproduce, and a proof of concept if you have one.
- The impact you assess, and any prerequisites an attacker would need.
- How you would like to be credited, if you would.
Report in English. If you want to encrypt a report, say so and we will arrange a key — we do not publish one we would not reliably monitor. Do not include other people's personal data in a report: describe the exposure, do not send us the exposed records.
Scope
In scope:
- primanza.com and the subdomains under it operated by the company.
- The Primanza products, at the subdomains on which they run, as listed on each product's page in the portfolio.
- The company's published email and DNS configuration, including subdomain delegation and any dangling record that could be claimed by someone else.
Out of scope: any system not operated by Primanza, including our hosting, DNS, email and infrastructure providers — report those to the provider under its own policy. Also out of scope, unless you can demonstrate a concrete and realistic impact: missing security headers with no exploitable consequence, missing SPF, DKIM or DMARC records already accounted for, output of automated scanners without a working proof of concept, rate limiting on unauthenticated public pages, denial of service, social engineering or phishing of our people, physical attacks, issues requiring a rooted or compromised device or a fully man-in-the-middle position, self-XSS, clickjacking on pages with no sensitive action, and vulnerabilities in third-party software for which no patch exists.
This corporate site has no accounts, no session, no payment and no personal data store. Report classes that presuppose one do not apply here — but they do apply on the products, which are real applications.
Rules of engagement
Research within this policy is authorised. Research outside it is not, and the safe harbour below does not cover it. While testing, you must:
- Act in good faith, with the purpose of finding and reporting a vulnerability — not of exploiting one.
- Use only your own accounts and your own test data. Do not access, modify, delete or exfiltrate data that is not yours.
- Stop at proof. Once you have established that a vulnerability exists, stop — do not pivot, escalate or explore further.
- Cause no harm to service availability or integrity: no denial-of-service or volumetric testing, no destructive testing, no automated scanning at a rate that degrades the service for anyone else.
- Leave nothing behind. Delete any data you obtained as soon as you have reported it, and remove any artefact your testing created.
- Do not use social engineering, phishing or physical intrusion against our people or premises. Attacking the person is out of scope; attacking the system is the point.
- Give us reasonable time to fix the issue before disclosing it publicly — see the timelines below.
- Comply with applicable law. This authorisation is ours to give for our systems; it is not, and cannot be, permission to break the law.
Safe harbour
If you make a good-faith effort to comply with this policy during your research, we will consider your research to be authorised, and:
- We will not initiate or recommend legal action against you in connection with it, including under the Computer Fraud and Abuse Act, the Wyoming computer crimes statutes, or any other computer misuse law.
- We will not bring a claim against you under the anti-circumvention provisions of the Digital Millennium Copyright Act, and we waive any restriction in our Terms of Service or Acceptable Use Policy that would otherwise prohibit your research, to the extent needed to conduct it within this policy.
- If a third party brings legal action against you for research conducted in compliance with this policy, we will take reasonable steps to make it known that your conduct was authorised by us.
- We will treat an accidental, good-faith violation of this policy as a mistake to be discussed, not as a reason to withdraw this protection — provided you tell us promptly and stop.
The limits, stated honestly: this safe harbour is given by Primanza and binds Primanza. We cannot waive the rights of a third party, and we cannot bind a prosecutor or a court. It does not extend to systems we do not operate, and it does not apply if you act in bad faith or outside this policy.
If you are unsure whether something is authorised, ask security@primanza.com before you test it. We would rather answer the question in advance than argue about it afterwards.
What we commit to
In return for a report made under this policy:
- We acknowledge receipt within three business days.
- We give you an initial assessment — whether we can reproduce it, and how we rate the severity — within ten business days.
- We keep you informed at reasonable intervals while we work on a fix, and we tell you when it ships.
- We credit you by name or handle when the issue is resolved, if you want credit, and we omit you entirely if you do not.
- We aim to resolve issues within 90 days of the initial report, and we support coordinated disclosure at that point or earlier by agreement. If a fix genuinely needs longer, we will tell you why rather than let the clock run out in silence.
- We do not require you to sign a non-disclosure agreement as a condition of reporting, and we will not use one to keep a fixed issue quiet indefinitely.
There is no bounty, and we will not pretend otherwise
Primanza does not currently operate a paid bug bounty programme. We are not going to imply one exists to attract reports and then decline to pay.
What we do offer is a fast, honest response from the person who can actually fix the problem, public credit if you want it, and the safe harbour above. If a paid programme is introduced, it will be announced on this page with its terms.
Product security
Each Primanza product handles its own security within its own boundary — its own credentials, its own dependency updates, its own incident response — and publishes its own security contact where it differs from the address above.
In an incident affecting a product, the people affected by that product are notified through that product, and any legally required notification to a regulator or data subject is made by the entity responsible, within the deadline the applicable law sets. This site is not the notification channel for a product incident, and an incident on this site would not affect a product. If you cannot find a product's security contact, security@primanza.com reaches us and we will route it.