Security and Vulnerability Disclosure Policy

Last Updated: September 24, 2026 · Version 1.0.0

This policy explains how to report a security vulnerability in SwiftQuantum services, what we ask of you while you look for one, and what you can expect from us in return. SwiftQuantum is operated by SwiftQuantum Technologies, LLC, a Delaware limited liability company. Reports are read and handled by the founder personally, so please allow for the response times below.

The machine-readable version of our contact details is published at /.well-known/security.txt (RFC 9116).

1. How to Report

Email security@swiftquantum.tech. Please include:

• the affected product, URL, API endpoint, or app and app version;
• a description of the issue and its likely impact;
• step-by-step instructions to reproduce it, and a proof of concept if you have one (screenshots, HTTP requests, a short script);
• whether you accessed, modified, or kept any data, and what;
• how you would like to be credited, if at all.

Reports may be written in English or Korean. If you need to send something sensitive, say so in a first message and we will agree on a way to exchange it. We do not currently publish a PGP key.

Please do not report vulnerabilities through app reviews, social media, public GitHub issues, or general support channels.

2. Scope

In scope

• Web applications and websites on swiftquantum.tech and its subdomains (*.swiftquantum.tech), including this site.
• APIs served from *.swiftquantum.tech, including the authentication service and the SwiftQuantum Legal API.
• iOS, iPadOS, macOS, and visionOS apps published by SwiftQuantum on the Apple App Store: SwiftQuantum, QuantumNative, Q-Bridge, QuantumCareer, Q-Alpha, Q-Shield, Q-Logos, and Q-Bio Genesis.
• Open-source packages published under the SwiftQuantum organization, where the issue affects users of those packages.

Out of scope

• Services run by third parties that we use, such as Amazon Web Services, Stripe, Apple, OpenAI, Anthropic, IBM Quantum, or our email provider. Report those to the vendor directly. If the problem is in how we configured or integrated such a service, it is in scope.
• Findings that need a rooted or jailbroken device, physical access to a victim's unlocked device, or a compromised victim browser.
• Missing security headers, cookie flags, or TLS settings without a demonstrated way to exploit them.
• Clickjacking on pages with no state-changing actions, logout CSRF, and self-XSS.
• Reports produced only by automated scanners, without a verified impact.
• Rate limiting or brute-force findings that do not show a realistic path to account takeover or data exposure.
• Email configuration findings (SPF, DKIM, DMARC policy) without a demonstrated spoofing impact.
• Vulnerabilities in outdated browsers or operating systems no longer supported by their vendors.

If you are unsure whether something is in scope, report it anyway and say so.

3. What We Ask You Not to Do

• No denial of service. Do not run load tests, flooding, or anything that degrades service for other users, and do not fill up storage or queues.
• No access to data beyond what is needed to prove the issue. If you reach personal data, stop, do not copy or keep it, and tell us in your report what you saw. Use accounts you created yourself, or accounts whose owners have agreed to take part.
• No social engineering of our users, the founder, or our vendors, and no phishing.
• No physical attacks against offices, homes, or equipment.
• Do not modify or delete data that is not yours, and do not keep a foothold (backdoors, persistent sessions, web shells) after confirming an issue.
• Do not use paid resources on another person's behalf, for example by submitting quantum hardware jobs or AI requests with credentials that are not yours.
• Do not disclose the issue publicly, or to anyone else, until we have fixed it or until the disclosure date agreed under Section 5.

4. Safe Harbor

If you make a good-faith effort to follow this policy, we will consider your research authorized. Specifically:

• we will not bring legal action against you, and will not ask a law enforcement authority to do so, for research that complies with this policy, including under laws on unauthorized access to computer systems (such as the Korean Act on Promotion of Information and Communications Network Utilization and Information Protection or the U.S. Computer Fraud and Abuse Act) and anti-circumvention laws;
• we will not treat such research as a breach of our Terms of Service to the extent it conflicts with them;
• if a third party brings a claim against you over research that complied with this policy, we will make it known that your activity was authorized by us.

This safe harbor applies only to systems and activities within the scope of this policy. It does not bind third parties, and we cannot authorize testing of systems we do not own. If you are unsure whether a planned action is consistent with this policy, ask us first at security@swiftquantum.tech.

5. What to Expect From Us

SwiftQuantum is run by one person. We aim for the following targets, which are commitments of effort and not guarantees:

We will keep you informed, tell you when the issue is fixed, and ask you before naming you in any acknowledgment. We ask that you allow up to 90 days from your report for a fix before any public disclosure. If we need longer, we will explain why and agree a date with you.

If a report shows that personal data may have been exposed, we will handle it under our Privacy Policy and applicable breach notification law, independently of the timeline above.

6. No Bug Bounty

We do not run a bug bounty program and do not pay for vulnerability reports. With your permission, we are glad to credit you publicly once the issue is fixed. A request for payment as a condition of disclosing details is not a good-faith report under this policy.

7. Related Documents

• Privacy Policy
• Subprocessors
• Data Processing Agreement
• Terms of Service

8. Changes to This Policy

We may update this policy. The version number and "Last Updated" date above change with every update, and the version in force on the day you submitted a report continues to apply to that report.

This policy is published in several languages. The English version controls in case of any inconsistency.