Security & Responsible Disclosure

Email us at security at sichgate dot com. Include enough detail to reproduce the issue: affected URL or endpoint, steps, and impact. A proof-of-concept helps. A PGP key can be added on request.

• —sichgate.com
• —app.sichgate.com
• —Our API endpoints

Third-party services we build on are governed by their own disclosure programs; please report issues in those systems to the respective vendor.

We will close these without a detailed response. That is not a judgment on your skill — it's that a report in one of these categories doesn't tell us anything we can act on.

• —Denial of service, volumetric testing, resource exhaustion, and brute-force or credential-stuffing runs.
• —Social engineering of our staff, customers, or vendors, including phishing and pretexting; physical attacks.
• —Email configuration findings reported on their own — SPF, DKIM, DMARC, DNSSEC, and similar DNS records.
• —Self-XSS, and issues that require a fully compromised or physically accessible device, or a victim running attacker-supplied code in their own console.
• —Missing security headers, missing cookie flags, weak TLS ciphers, and similar configuration observations with no demonstrated impact.
• —Raw output from an automated scanner, pasted without a working proof-of-concept and an explanation of the impact.
• —Absent rate limiting, where you have not shown a concrete abuse case it enables.
• —Software version disclosure, banner grabbing, and CVEs reported against a version number without a demonstrated exploit path on our systems.
• —Clickjacking on pages with no state-changing action, and open redirects with no demonstrated escalation.
• —Vulnerabilities that only affect end-of-life browsers, or that require an unlikely degree of user interaction.
• —A model producing harmful, biased, or incorrect output. That is the subject of the product, not a vulnerability in it — if a model we tested behaves badly, that is a finding the platform is designed to report, not a security issue in SichGate.

The assessment pipeline runs real GPUs and costs real money per run. These limits exist so that testing us doesn't bill us, and so that no research touches a customer who did not sign up for it.

• —Use your own account and your own models. Register an account for research, and point Assessments only at models and endpoints you own or are authorized to test.
• —Don't run automated scanners against the assessment pipeline. Automated tooling against the marketing site or unauthenticated endpoints is fine within reason. Pointing a scanner or fuzzer at assessment execution, job submission, or anything that schedules GPU work is not.
• —Don't consume credits at volume. A handful of runs to demonstrate a finding is expected. Scripted or repeated runs to see what happens are not, and we may suspend the account and treat the activity as outside this policy.
• —Stay inside your own tenant. No attempts to reach another customer's Assessments, Results, credentials, or billing data. If you find a path that crosses tenants, stop at the minimum proof needed to show it exists, don't retrieve the data, and tell us.
• —Don't degrade the service. No testing that takes the platform down, exhausts capacity, or affects other users' runs.
• —Use test data, and don't exfiltrate what you find. Don't access, modify, delete, or retain data that isn't yours. Delete anything you obtain incidentally once you've reported it.

If a finding genuinely cannot be demonstrated inside these limits, email us first and we'll arrange a window and a test account. We would much rather scope it with you than have you guess.