Silverflow Vulnerability Disclosure

generated: '2026-08-27'
method: searched
source: https://www.silverflow.com/.well-known/security-policy.txt
name: Silverflow vulnerability disclosure
program:
  type: coordinated-disclosure
  bug_bounty: false
  bug_bounty_note: >-
    Silverflow states plainly: "Whilst we don't yet have a bug bounty program for any of our
    products, we do of course take security seriously, and are committed to and believe in
    friendly, coordinated disclosure of security vulnerabilities and issues." No HackerOne,
    Bugcrowd or Intigriti program was found.
  safe_harbour: not stated
  scope_statement: '"something we own" — no formal in-scope/out-of-scope asset list is published.'
policy:
- url: https://www.silverflow.com/.well-known/security-policy.txt
  status: 200
  content_type: text/plain
contact:
- mailto:security@silverflow.com
encryption:
  pgp_key: https://www.silverflow.com/.well-known/pgp-key.txt
  status: 200
  note: Full PGP public key block published; the security.txt itself is PGP clear-signed with
    the same key (key id fingerprint ends B9B5B8DE85F7D68FE19AFEC15892B6958C37E171).
security_txt:
  url: https://www.silverflow.com/.well-known/security.txt
  status: 200
  file: well-known/silverflow-security.txt
  rfc: RFC 9116
  signed: true
  fields: [Contact, Expires, Encryption, Preferred-Languages, Canonical, Policy]
  expires: '2026-03-01T00:00:00.000Z'
  expired: true
  expiry_note: >-
    DEFECT WORTH REPORTING BACK - the served security.txt carries Expires 2026-03-01, which is
    almost six months in the past as of this probe (2026-08-27). RFC 9116 s2.5.5 says a file
    past its Expires date should not be relied upon by researchers. The file is otherwise
    complete, correctly signed and correctly canonicalised; it simply needs re-signing with a
    forward date. This is a one-line fix that restores a genuinely well-built disclosure
    surface.
disclosure_expectations: >-
  Researchers are directed to use the contact details in security.txt and to encrypt sensitive
  reports with the published GPG key. No response-time commitment, disclosure timeline, or
  reward is published.
evidence:
- url: https://www.silverflow.com/.well-known/security.txt
  status: 200
- url: https://www.silverflow.com/.well-known/security-policy.txt
  status: 200
- url: https://www.silverflow.com/.well-known/pgp-key.txt
  status: 200
- url: https://trust.silverflow.com/
  status: 0
  note: DNS does not resolve — no trust center subdomain.
- url: https://www.silverflow.com/trust
  status: 404
- url: https://www.silverflow.com/security
  status: 404
trust_center:
  found: false
  note: >-
    No trust center and no public certifications page. Silverflow's public site names no SOC 2,
    ISO 27001 or PCI DSS certification anywhere, which is notable for a card processor — PCI
    DSS compliance is a hard requirement to touch PANs and Silverflow demonstrably does (it
    operates processor and network tokenization and stores card data). The compliance evidence
    is presumably shared under NDA through the sales/TAM channel. No security/silverflow-trust-center.yml
    was written and no Compliance pointer was emitted, because asserting one from inference
    rather than a published document is exactly the fabrication this pipeline forbids.