BORINGSEC PUBLIC TRUST PACKET Version: 1.2.1 Last reviewed: 2026-08-01 Next review target: 2026-11-01 CANONICAL PUBLIC REFERENCES Trust center: https://www.boringsec.com/en/trust Privacy policy: https://www.boringsec.com/en/privacy Terms: https://www.boringsec.com/en/terms Responsible disclosure: https://www.boringsec.com/security RFC 9116 security.txt: https://www.boringsec.com/.well-known/security.txt Live status: https://www.boringsec.com/status CONTACTS Security: security@boringsec.com — Vulnerability reports and coordinated disclosure Privacy: privacy@boringsec.com — Privacy questions and data-subject requests Support: support@boringsec.com — Product, account, and billing support RESPONSIBLE DISCLOSURE SUMMARY Contact: security@boringsec.com In scope: The production BoringSec web application and same-origin public APIs at https://www.boringsec.com. In scope: BoringSec accounts, domains, reports, and test data that you own or are explicitly authorized to use. Out of scope: Customer scan targets, customer reports, third-party systems, and provider infrastructure that you do not own or have explicit authorization to test. Out of scope: Social engineering, phishing, physical security, employee or customer targeting, and attacks against support channels. Out of scope: Denial of service, resource exhaustion, high-volume automation, spam, credential stuffing, and tests that degrade service for other users. Out of scope: Accessing, modifying, deleting, downloading, or retaining another person’s data beyond the minimum unavoidable evidence needed to report accidental access. Out of scope: Persistence, malware, backdoors, lateral movement, supply-chain compromise, or continued access-control bypass after you have enough evidence to report the issue. Stop on access: If you encounter credentials, personal data, non-public customer data, another user’s report, or unexpected system access, stop immediately. Do not continue exploring, copy more data than the minimum evidence, retain the data longer than needed to report it, or share it with anyone other than BoringSec through the reporting channel. Sensitive evidence: Do not send secrets, credentials, personal data, full data exports, or destructive exploit payloads in the initial email. Redact the minimum evidence needed to explain the issue. BoringSec does not currently publish a PGP key or a general secure-upload endpoint. If additional sensitive evidence is necessary, wait for case-specific instructions before transferring it. Good-faith safe harbor: For research carried out in good faith and in accordance with this policy, BoringSec considers the activity authorized against the BoringSec systems listed as in scope and does not intend to initiate legal action based solely on that compliant research. Accidental boundary crossing: If you accidentally cross a boundary, stop immediately, tell us what happened, do not retain or use accessed data, and cooperate with reasonable steps to prevent harm. We will assess the conduct by its intent, proportionality, and your response rather than treating an accidental good-faith mistake as malicious by default. Safe-harbor condition: Stay within the listed scope and use only accounts, assets, repositories, and data that you own or are explicitly authorized to test. Safe-harbor condition: Follow the prohibited-testing and stop-on-access rules, minimize requests and data, and stop if BoringSec asks you to stop. Safe-harbor condition: Report privately and promptly, do not exploit the issue beyond the minimum proof, and do not use the issue for extortion or commercial pressure. Safe-harbor condition: Comply with applicable law and do not infringe the rights of customers, service providers, or other third parties. Safe-harbor boundary: This safe harbor states BoringSec’s position only. It is not legal advice or blanket immunity, cannot authorize testing of third-party systems, and cannot bind customers, service providers, regulators, law enforcement, or other third parties. It does not cover deliberate policy violations, threats, deception, privacy violations, destructive conduct, data use or retention, testing outside scope, or conduct continued after a stop request. Coordination: Please keep the report private while we investigate. Publish technical details only after we confirm remediation or we agree on a disclosure date in writing. Bounty and immunity boundary: BoringSec does not currently operate a public bug-bounty program and does not promise payment. The good-faith safe harbor is limited to the BoringSec systems and conduct described above. It is not blanket legal immunity, does not waive third-party rights, and does not authorize testing outside scope. SCANNER AUTHORIZATION AND RESULT BOUNDARY Public URL: A submitted public URL authorizes only the bounded public-surface modules listed in the Methodology. It does not authorize verified-owner background engines. Verified owner: Verified-owner background engines require a signed-in, non-anonymous scan owned by the account or team and a currently verified domain. Repository: Repository analysis requires an explicit connected-repository or source-archive grant. A URL scan never implies repository access. Result semantics: Target-dependent, incomplete, inapplicable, or unavailable capability stays explicit and is never converted into a verified clean result. PUBLIC CONTROL STATEMENTS Server-side authorization and ownership boundaries [implemented] Protection: Server-managed sessions, role checks, ownership checks, and focused authorization tests are used on protected access and mutation paths. Boundary: This control covers the protected paths listed in its scope and is maintained through focused authorization tests. Server-side secret protection [implemented] Protection: Sensitive values remain server-side, and release checks help prevent accidental exposure in public application assets. Boundary: The public packet protects secret names, values, internal paths, and deployment credentials. Authorized and bounded scanning [implemented] Protection: Public scans are limited to the submitted public surface. Deeper or source-based checks require verified ownership or an explicit connection. Boundary: Coverage is target-dependent. An unavailable or incomplete scanner is reported as such and is not converted into a clean result. Protected billing state [implemented] Protection: Pricing and billing status are validated server-side. Payment-card details are processed by the payment provider. Boundary: Stripe independently processes payment details; BoringSec validates trusted pricing and billing state server-side. Data minimization and retention [implemented] Protection: The Privacy Policy explains data categories, retention windows, and deletion rights. Boundary: Narrow billing, fraud, incident, legal, or security obligations can require limited retention beyond the normal product path. Privacy-safe service status [conditional] Protection: The public status view reports the current privacy-safe application health signal. Boundary: The snapshot covers application health at the time of the request; scanner applicability remains target-dependent. DATA RETENTION Anonymous URL scan report and request network metadata Default: Public report access expires after 30 days. Deletion/minimization: Request metadata is minimized when public access expires, and the anonymous scan is deleted shortly afterward under the retention schedule. Exceptions: A scan retained for an active Care relationship or a required outreach/disclosure audit trail is protected from that automatic deletion path. Signed-in domains, scans, findings, monitoring history, and paid reports Default: Retained while needed to provide the account, purchase, report history, or monitoring relationship. No shorter fixed automatic window is promised. Deletion/minimization: The owner can delete a domain/account or request erasure. Related product data is deleted or anonymized unless a legal or security obligation requires limited retention. Exceptions: Billing, fraud, incident, and legally required records may be retained separately for the applicable obligation. Optional authenticated-scan credentials Default: The owner selects 7, 30, or 90 days. The profile expires automatically. Deletion/minimization: Credentials remain encrypted and server-side, are used only for the authorized scan, and can be revoked or deleted earlier. Exceptions: Reports store scan status and minimized evidence, not credential values. Connected repository content and repository access credentials Default: Source is fetched for the authorized scan. Findings and scan metadata remain with the report history. Deletion/minimization: Repository credentials stay server-side and can be revoked. Full source content is not intentionally copied into public reports. Evidence is minimized and secrets are masked. Exceptions: Provider-side logs and repository retention remain governed by the connected provider and customer repository. Repository archive and redacted static-analysis findings Default: The raw archive is deleted after processing. The minimized manifest and findings expire after 30 days. Deletion/minimization: The owner can delete the scan sooner. Raw source is kept private during processing and is never returned through public report surfaces. Secret-bearing evidence is redacted before result storage. Exceptions: Minimal audit metadata may be retained for abuse prevention and does not contain source content. Raw product analytics sessions Default: 90 days. Deletion/minimization: Raw analytics sessions older than the window are deleted automatically. Exceptions: Aggregated, non-identifying operational metrics may remain after raw sessions are removed. Audit-log IP addresses and user agents Default: Direct network and routine client detail are minimized after 90 days. Deletion/minimization: Network identifiers are reduced and routine client details are removed when they are no longer needed. Exceptions: Security-relevant audit events may retain limited user-agent context for abuse, access, and incident review. Closed support and inbound-reply conversations Default: 24 months after the last message. Deletion/minimization: Closed conversations older than the window are deleted automatically. Exceptions: Open conversations and records under a legal/security hold are not part of the normal closed-conversation cleanup. Billing and transaction records Default: For the tax, accounting, dispute, and fraud-prevention period required by applicable law and payment operations. Deletion/minimization: BoringSec stores provider identifiers and purchase state, not full payment-card data. Exceptions: Stripe independently processes payment data under its own retention and legal obligations. SERVICE-PROVIDER AND SUBPROCESSOR INVENTORY This operational inventory describes each provider’s purpose, activation boundary, data boundary, and current privacy reference. Hetzner [core] Purpose: Infrastructure hosting. Data boundary: Service and customer data needed to operate BoringSec. When used: Core production service. Provider reference: https://www.hetzner.com/legal/privacy-policy/ Stripe [feature dependent] Purpose: Payments, subscriptions, invoices, refunds, and fraud prevention. Data boundary: Billing identity, transaction metadata, and payment details submitted directly to Stripe. BoringSec stores provider identifiers and billing state, not full card details. When used: When a user starts or manages a paid purchase or subscription. Provider reference: https://stripe.com/privacy Resend [feature dependent] Purpose: Transactional and requested email delivery. Data boundary: Recipient address, message content, and delivery metadata needed to send the email. When used: When BoringSec sends email through the configured Resend transport. Provider reference: https://resend.com/legal/privacy-policy Google [feature dependent] Purpose: Optional Google sign-in and consent-gated advertising or conversion measurement. Data boundary: OAuth identity data when Google sign-in is chosen. Measurement data is sent only after the relevant cookie consent. When used: Only when the user selects Google sign-in or grants the relevant optional consent. Provider reference: https://policies.google.com/privacy GitHub [feature dependent] Purpose: Optional GitHub sign-in and user-authorized repository connection. Data boundary: OAuth identity and repository data authorized by the user for the selected feature. When used: Only when the user selects GitHub sign-in or connects a repository. Provider reference: https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement VirusTotal [feature dependent] Purpose: Optional external threat-intelligence lookups for website origins and hostnames. Data boundary: Only the website origin or hostname needed for the optional lookup is shared. Credentials, URL paths, queries, and fragments are excluded. When used: Only when the optional threat-intelligence feature is available and applicable. Provider reference: https://docs.virustotal.com/docs/privacy-policy DPA AND PRIVACY REVIEW REQUEST Privacy and DPA review requests are handled case by case through the privacy contact below. Contact: privacy@boringsec.com Subject: DPA and privacy review request Include: Your legal entity and business contact. Include: The BoringSec feature and intended use. Include: Expected data categories and data-subject groups. Include: Relevant jurisdictions and requested review deadline. Request boundary: We will confirm the materials, processing details, and expected review timing available for the stated context. PUBLIC STATUS BOUNDARY The public status page reports the current privacy-safe application health signal as a scoped snapshot of application availability and target-dependent scanner applicability. This packet is a dated public summary. The canonical live version is https://www.boringsec.com/en/trust.