Security contact
Report product vulnerabilities privately to security@boringsec.com. Customer scan targets and third-party systems are outside the disclosure scope unless you own them or have explicit authorization.
Version 1.2.1Reviewed August 1, 2026
Public trust center
Security claims you can read, scope, and verify.
A dated public reference for BoringSec controls, data handling, retention, providers, service health, and vulnerability disclosure. Every statement includes its boundary.
Review target: once per quarter and after a material change to data handling, providers, disclosure scope, or public controls. Next review target: November 1, 2026.
What this packet covers
This packet summarizes public product controls and evidence while keeping secret material and private topology protected.
Data handling
BoringSec stores the account, target, result, billing, integration, and operational data needed to deliver scans, reports, monitoring, alerts, and support. The matrix below distinguishes fixed windows from relationship-based retention.
Secrets boundary
Sensitive values remain server-side. Public reports minimize evidence and never intentionally display full credentials, private configuration, or secret values.
Responsible scanning
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 background engines require a signed-in, non-anonymous scan owned by the account or team and a currently verified domain. Repository analysis requires an explicit connected-repository or source-archive grant. A URL scan never implies repository access. Target-dependent, incomplete, inapplicable, or unavailable capability stays explicit and is never converted into a verified clean result.
Public control statements
Implemented describes an active product or release control. Conditional means the statement applies only to the listed surface or has a stated public-evidence limit.
Server-side authorization and ownership boundaries
implementedServer-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
implementedSensitive 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
implementedPublic 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
implementedPricing 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
implementedThe 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
conditionalThe 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.
Service 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.
Open live statusOne address for each request
- Vulnerability reports and coordinated disclosure
- security@boringsec.com
- Privacy questions and data-subject requests
- privacy@boringsec.com
- Product, account, and billing support
- support@boringsec.com
Data handling and retention
We collect only the account, scan, report, billing, and support data needed to provide the service. Public report access is time-limited, optional scan credentials expire automatically, and account owners can request deletion subject to narrow legal and security obligations.
Service-provider and subprocessor inventory
This operational inventory describes each provider's purpose, activation boundary, data boundary, and current privacy reference. Feature-dependent providers receive data only when their listed feature is used.
Hetzner
coreInfrastructure hosting.
Data boundary: Service and customer data needed to operate BoringSec.
Provider privacy referenceStripe
feature dependentPayments, 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.
Provider privacy referenceResend
feature dependentTransactional and requested email delivery.
Data boundary: Recipient address, message content, and delivery metadata needed to send the email.
Provider privacy referenceOptional 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.
Provider privacy referenceGitHub
feature dependentOptional GitHub sign-in and user-authorized repository connection.
Data boundary: OAuth identity and repository data authorized by the user for the selected feature.
Provider privacy referenceVirusTotal
feature dependentOptional 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.
Provider privacy referenceDPA and privacy review request
Privacy and DPA review requests are handled case by case through the privacy contact below.
- Your legal entity and business contact.
- The BoringSec feature and intended use.
- Expected data categories and data-subject groups.
- Relevant jurisdictions and requested review deadline.
We will confirm the materials, processing details, and expected review timing available for the stated context.
Request privacy reviewAI data boundary
AI-assisted features are optional. Core scanning, scoring, and reports continue without external model processing.
AI generation runs only when an AI analysis or guidance feature is explicitly requested and available. It is not required to calculate the Security Score.
Only the limited report context and relevant findings needed to produce the requested analysis are sent. Data is minimized before any external transfer.
The analysis payload does not intentionally include account passwords, scan credentials, cookie values, full page bodies, raw source archives, payment-card data, or full secret values.
Need a precise answer?
Use the security address only for vulnerabilities. Privacy requests and product support have separate channels, so each request reaches the right workflow without exposing it publicly.