Riverse Vulnerability Disclosure

generated: '2026-08-17'
method: searched
probe: true
source: https://docs.rainbowstandard.io/rainbow-standard-documents/procedures-manual/registry-requirements
note: >-
  Rainbow (formerly Riverse) serves NO /.well-known/security.txt on any host (all 404 — see
  well-known/riverse-well-known.yml). It does, however, publish a real written vulnerability
  and incident reporting procedure inside the Procedures Manual's Registry IT security
  section, including an explicit invitation to the general public, a named contact address,
  and a committed 24-hour acknowledgement. That is a genuine disclosure programme and is why
  the Security pointer is emitted; it is documentation-published rather than
  well-known-published, which is the honest distinction.
policy:
- https://docs.rainbowstandard.io/rainbow-standard-documents/procedures-manual/registry-requirements#incident-procedures
contact:
- support@rainbowstandard.io
bug_bounty: null
security_txt: false
acknowledgement_sla: >-
  Within one working day (24 hours) the on-call engineer confirms receipt of the incident
  report and begins an investigation to verify and assess scope.
scope:
  reporters: >-
    "The general public is encouraged to report suspected incidents or vulnerabilities to
    support@rainbowstandard.io"
  incident_definition:
  - Theft or loss of data
  - Transfer of data to those unauthorized to receive it
  - Attempts to gain unauthorized access to Rainbow data or systems
  - Unintended disruption of the availability of Rainbow systems
  - Other significant events or bugs that compromise Rainbow's position as a trusted actor in the VCM ecosystem
response_process:
- On-call engineer confirms receipt and opens an investigation within 24 hours
- A dedicated coordination channel is opened with the relevant teams if it qualifies as an incident
- Response team contains, eliminates and recovers as highest-priority task
- Affected parties (clients, certifying bodies, employees) are communicated to during and after recovery
- Post-mortem meeting held; findings shared internally or externally as appropriate
security_standards:
  source: https://docs.rainbowstandard.io/rainbow-standard-documents/procedures-manual/registry-requirements#security-standards
  minimum_requirements:
  - Data transfers shall always use industry-standard encryption (SSL/TLS/HTTPS)
  - Application authentication verified by a third-party provider that is ISO 27001 certified
  - Backend service and database hosting by a provider that enables encryption
  - 2FA required for administrative tool authentication and sign-in
evidence:
- {source: 'https://docs.rainbowstandard.io/rainbow-standard-documents/procedures-manual/registry-requirements.md', kind: docs-incident-procedure, status: 200}
- {source: 'https://rainbowstandard.io/.well-known/security.txt', kind: security.txt, status: 404}
- {source: 'https://registry.rainbowstandard.io/.well-known/security.txt', kind: security.txt, status: 404}
- {source: 'https://arc.rainbowstandard.io/.well-known/security.txt', kind: security.txt, status: 404}
recommendation: >-
  Publishing the same contact at /.well-known/security.txt (RFC 9116) on rainbowstandard.io,
  registry.rainbowstandard.io and arc.rainbowstandard.io would make an already-real programme
  machine-discoverable. The policy text already exists; only the file is missing.