NorForgeStart a conversation
Vulnerability disclosure

Found something?
Tell us directly.

We build and break software for a living, so we know what a good report costs to write. Send one and it reaches an engineer, not a ticket queue.

security@norforge.comOpenPGP key

Encryption is welcome but not required. Verify the key against the fingerprint published in security.txt.

Safe harbour

If you research in good faith and within the scope below, we will not pursue or support legal action against you, and we will not report you to law enforcement. We will say so in writing if a third party questions your conduct on our behalf.

Good faith means: you stop at the point of proof, you access only the minimum data needed to demonstrate the issue, you do not modify or destroy anything, you do not degrade service for others, and you give us a reasonable chance to fix the issue before publishing.

This is a commitment from NorForge about NorForge’s systems. It cannot and does not authorise you to test anyone else’s.

Scope

What we want reported.

  • norforge.com and its subdomains.
  • Our public-facing infrastructure - DNS, mail, and TLS configuration for those domains.
  • Anything published under github.com/norforgeinc.

Out of scope.

Client systems and client data.
We work inside our clients’ environments under their authorisation, which does not extend to us or to you. Testing them is neither covered by this policy nor ours to permit. If you believe you have found an issue in a system NorForge operates for a client, report it to us and stop - do not probe further.
Third-party services we consume.
Our forms, fonts, and hosting run on third parties. Report issues in those to the vendor under their own disclosure programme.
Denial of service, load testing, and automated scanning at volume.
Findings that amount to "the site can be flooded" are not actionable, and the traffic is indistinguishable from an attack.
Social engineering, phishing, and physical access.
Our people are not a test target.
Best-practice findings with no demonstrated impact.
Missing headers, cipher-suite preferences, and scanner output on a static marketing site: we will read these, but they are unlikely to be treated as vulnerabilities.
Writing the report

What to include.

  1. 01The affected host, URL, or endpoint, and the date and time you tested.
  2. 02Reproduction steps precise enough for us to follow without guessing - a request/response pair or a short proof-of-concept is ideal.
  3. 03What an attacker gets out of it. Impact decides priority far more than severity labels do.
  4. 04Any accounts, IP addresses, or user agents you tested from, so we can separate your traffic from real attacks in our logs.
In return

What you get from us.

Acknowledgement within 3 business days
A human confirms we have the report and have started looking. Not an autoresponder.
Assessment within 10 business days
Our reading of the issue, whether we consider it valid, and what we intend to do about it.
A disclosure timeline agreed with you
We do not impose one. Tell us your intended publication date and we will tell you plainly whether we can meet it.
Credit, if you want it
Named in any advisory we publish, or left out entirely - your call.

We do not run a bug bounty and do not pay for reports. We would rather be straight about that up front than have you discover it after the work is done.