# PortfolioPlane — security contact and disclosure policy
# https://portfolioplane.com/.well-known/security.txt
# Format: RFC 9116.
#
# THE MAILBOX IS REAL, AND IT WAS PROVEN BEFORE IT WAS PRINTED. This file was
# first published with a page as its only Contact, because portfolioplane.com
# published no MX record then and an address that bounces silently converts a
# researcher who was trying to help into one who concludes nobody is
# listening. On 2026-08-15 the mailbox was stood up — inbound MX published at
# the apex and verified, and delivery to security@portfolioplane.com proven
# end-to-end with a real message before this line changed. RFC 9116 §2.5.3
# lists Contact fields in order of preference: the mailbox first, the page as
# the fallback route.

Contact: mailto:security@portfolioplane.com
Contact: https://portfolioplane.com/contact
Expires: 2027-08-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://portfolioplane.com/.well-known/security.txt
Policy: https://portfolioplane.com/security

# WHAT THE POLICY LINK LEADS TO. Not a bug-bounty page — there is no bounty, and
# saying so plainly is the point. /security is the third-party risk page, and it
# opens with the attestations this product does NOT hold rather than closing
# with them. A researcher reading it will find the standing gaps already
# written down, which should save both sides a report.
#
# NOT IN SCOPE, and stated here so nobody spends an afternoon on one: a missing
# header on a marketing page, a version banner, TLS configuration owned by the
# managed host, and any finding that requires an already-compromised operator
# credential. Tenant isolation IS in scope and is the finding we most want.