Vulnerability disclosure

Reporting a vulnerability

Write to security@porticol.app. If the report is about the licence service or the licensor rather than the product, say which one in the first line.

Include what you can of: the affected version (porticol-server --version), the request or configuration that shows the problem, and what an attacker could do with it. Do not include other people's data. If you would rather exchange an encrypted message, say so in the first mail and a key will be sent before any details travel.

What to expect

• A first reply within two working days, saying the report arrived and who is looking at it.
• A triage verdict, in principle, within ten working days: accepted with a severity, or declined with a reason.
• For accepted reports, a fix or a mitigation plan within thirty days for a high or critical finding, and an advisory published once the fix has shipped.
• Credit in the advisory unless you would rather not be named.

Please do not test for, or report, the following as vulnerabilities on their own: self-signed certificates on an administrator's own installation, missing security headers on an instance deliberately served over plain HTTP, and anything that requires a licence file the reporter was not issued.

Coordinated disclosure

Findings are published after a fix is available, or ninety days after the report, whichever comes first. An exception to the ninety days is agreed with the reporter in writing, never imposed.

Safe harbour

Research done in good faith under this policy is authorised. We will not take legal action against it, or ask anyone else to. Good faith means that you:

• test against your own installation, or your own account and organisation on Porticol Cloud;
• stop once you have shown the problem, and do not read, keep, change or delete anyone else's data;
• run no denial-of-service or load test, and no social engineering or physical attack;
• tell us first, and publish only as the section above allows.

If someone else takes action against you for research that followed this policy, we will tell them it was authorised. There is no paid bug bounty; credit in the advisory is the reward.

Supported versions

Only the newest release receives security fixes. The release notes list, for each release, the schema version it migrates to; upgrades follow release/UPGRADE.md, whose rollback step needs the release immediately before.

How this repository defends itself

• Dependency advisories are checked with cargo deny; every ignored advisory is triaged and justified in deny.toml, and a new advisory fails the build.
• The importers (Postman, Insomnia, HAR, cURL, the plain-text format), the OpenAPI, WSDL, protobuf and GraphQL parsers, the HTTP/1 and HTTP/2 response readers, the cookie and multipart parsers and the script sandbox are fuzzed every night (fuzz/), and crashes found there become regression tests.
• The release artifacts are checksummed, signed and budget-checked (release/), and the bill of materials records what links.
• The server never sends telemetry; the optional trace export is off by default and counted by an egress test.