Skip to content
Now available: Deepfake & Vishing Awareness learning module
silversight.ai
Vulnerability Disclosure Program

Program Overview

Silversight welcomes good-faith security research on the systems and services we own and operate. If you identify a vulnerability, report it privately, and give us enough detail to reproduce it. We'll review the report, coordinate remediation, and make sure you get credit.

There is currently no paid bounty program.

You can expect to hear back in about 2 days. Triage will take around 3 days.

Report a findingPlaintext

Shared Responsibility Model

Shared Commitments

Silversight

  • Review good-faith reports and acknowledge receipt.

  • Work with researchers to understand and validate credible findings.

  • Keep reported vulnerabilities non-public while remediation is underway.

  • Coordinate remediation before broader disclosure.

Security Researcher

  • Report issues privately with enough detail to reproduce the issue.

  • Stay within scope and avoid destructive, disruptive, or privacy-invasive testing.

  • Follow the exclusions and proof-of-concept guidance listed on this page.

  • Do not publicly disclose the issue until Silversight has had a reasonable opportunity to investigate and remediate it.

Disclosure Process

Security disclosure response sequenceA sequence diagram showing how a researcher reports an issue to Silversight, how Silversight verifies, triages, fixes, and confirms the issue, and how the report is ultimately resolved.YouRESEARCHERSilversightSECURITY TEAM01YOU TO SILVERSIGHTReport the issueYou share the finding privately with thedetails needed to reproduce it.SILVERSIGHT NOTESilversight verifies theissueWe confirm the behavior and validatethat the report is credible.SILVERSIGHT NOTESilversight triages theissueImpact, scope, and remediation pathare assessed internally.04SILVERSIGHT TO YOUResponds confirming the issueWe acknowledge the finding and communicatenext steps.SILVERSIGHT NOTESilversight fixes the issueEngineering implements and validatesthe remediation.06SILVERSIGHT TO YOURequests confirmation of the fixWe ask the reporter to verify the change inthe affected flow.07YOU TO SILVERSIGHTConfirms that the issue has beenfixedYou validate the remediation and confirmthat the report can close.08SILVERSIGHT TO YOUCloses report as resolvedThe issue is closed and attribution is handledseparately if requested.

Scope

Test Silversight-owned assets only

This policy applies to Silversight sites, applications, APIs, and supporting services that we own and directly operate. If an issue exists in a third-party dependency or platform we use but do not control, report it to the appropriate vendor unless the vulnerability is caused by our implementation.

If you are unsure whether a target is in scope, ask first at security@silversight.ai.

Exclusions

Excluded test types
The following test types are excluded from the scope:

  • Findings from physical testing such as office access (e.g. open doors, tailgating).

  • Findings derived primarily from social engineering (e.g. phishing, vishing).

  • Findings from applications or systems not listed in the "Scope" section. I do accept high-severity issues on out of scope assets if they directly affect me.

  • Vulnerability reports with video only PoCs.

  • Reports that state that software is out of date or vulnerable without a proof of concept.

  • Highly speculative reports about theoretical damage. Be concrete.

  • Vulnerabilities as reported by automated tools without additional analysis as to how they're an issue.

  • Issues in third-party services should be reported to the respective team.

Exclusions

Excluded issue types
The following issue types are excluded from scope:
DescriptionReason
Network-level Denial of Service (DoS/DDoS) vulnerabilities.I do not want you to disrupt any of my services and to be honest with you if I want to take down a service I will always find a way.
Low severity issues that can be detected with tools such as Hardenize and Security Headers.I run regular scans with these services and try to improve my score gradually.
Content injection issues.The severity of this issue is so low that it does not warrant a report.
Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.).In order for CSRF to be a valid issue it must affect some important action such as deleting one's account.
Missing cookie flags.These type of issues do not present a major risk and are usually picked up by scanners.
UI and UX bugs (including spelling mistakes).No comment.
401 injection.This is usually an accepted risk.
Stack traces that disclose information.Most of my projects are open-source therefore this information is usually public knowledge. That said, if you discover a stack trace that discloses information which is not located in my GitHub repositories, please do submit a report.
Host header issues without an accompanying proof-of-concept demonstrating vulnerability.PoC or GTFO.
Open ports without an accompanying proof-of-concept demonstrating vulnerability.Same as above.
Banner grabbing issues (figuring out what web server I use, etc.).I will happily share what web servers I am running.
Missing X-Frame-Options header (Clickjacking)The lack of X-Frame-Options does not always indicate that a security vulnerability is present. This is an optional header that is only necessary on endpoints where the UI is rendered to invoke state changing actions.
Cross-site tracingIn order for Cross-Site Tracing (XST) to really be a significant issue you would need to find an endpoint vulnerable to Cross-site Scripting (XSS).
CSP uses unsafe-inlineThe fact that a CSP includes unsafe-inline is not an issue in itself. In order for you to demonstrate the actual impact of this value, I highly recommend you look for an XSS vulnerability. Try to trigger alert(document.domain).
Disclosure of robots.txt fileI am aware that in some cases robots.txt files have been known to disclose sensitive information. In my case I have determined that my robots.txt files do not contain any information that poses a potential security risk.
Email spoofing (SPF misconfigurations)I have accepted the risk that this issue poses and do not believe that it warrants an immediate fix.
Open redirect using Host headerOpen redirects in the Host header are not exploitable.
Proving me wrong on Twitter. 

Proof of concepts

When to report the issue
Issue typeWhen to report the issue
XSSFor XSS, a simple alert(document.domain) should suffice. Bonus points for alert('🐸').
RCEPlease only execute harmless code. Simply printing something or evaluating an expression should be enough to demonstrate the issue.
SQLiReport it as soon as you have a SQL error that indicates SQL injection or you are able to disclose the SQL server's version number.
Unvalidated redirectSet the redirect endpoint to http://example.com.
Information disclosureIf your report contains sensitive data, please use my PGP key to encrypt it.
CSRFEither attach a file to demonstrate the issue or paste the code in a code block in your report.
SSRFDo not go playing around on any internal networks. Leave the fun bit to me. If you feel the necessity to retrieve an internal file, please only request the internal security.txt file.
LFIThe same applies here -- please do not go against the guideline listed in the Disclosure policy section. There should be a security.txt file located in the root directory. Being able to retrieve that file should be enough to demonstrate the issue.