Security

RoRoSafe builds detection systems for vessel cargo decks. The same engineering discipline that goes into the product applies to the platform that operates it — the way we handle data, the way our team accesses production, and the way we work with third-party security researchers. This page is the public summary of that posture.

1. Reporting a vulnerability

If you have discovered a security issue affecting RoRoSafe's website, product, or infrastructure, please report it to rorosafetech@gmail.com. Encrypted submissions are welcome — request our PGP key in your first message. We acknowledge reports within two business days and aim to triage within five.

We do not pursue legal action against researchers who report in good faith, provided you (a) do not access, modify, or exfiltrate customer data; (b) do not degrade service availability; and (c) give us reasonable time to remediate before public disclosure. Our full security.txt is published per RFC 9116.

2. Programme scope

• rorosafe.in and all subdomains we publish.
• The RoRoSafe vessel platform (segment masters, sensor cells, bridge console firmware) — bench-rig and pilot deployments only; coordinate with our team before testing.
• The customer dashboard (preview environments under *.preview.rorosafe.in).

Out of scope: third-party services we use as black boxes, social engineering of staff, denial-of-service testing, and any physical attack against a vessel or port asset.

3. Security controls

We design to a control set informed by widely recognised information-security frameworks. RoRoSafe does not currently hold ISO/IEC 27001 certification, and we do not represent that we do. If we obtain certification from a UKAS/IAF-accredited body in future, the certificate body, scope, and date of issue will be listed here.

Cloud and platform

• All production data encrypted at rest (AES-256) and in transit (TLS 1.2+).
• Production access is role-based, MFA-enforced, and audit-logged.
• Secrets are managed by a dedicated KMS — never committed to source control.
• Network controls follow least-privilege; no public ingress to data stores.

Software development

• Mandatory code review on every pull request to main.
• Automated dependency scanning and weekly patch cadence for critical CVEs.
• Static analysis on every build; secrets scanning on every commit.
• Reproducible builds; signed releases for firmware.

People

• Background checks for engineering hires with production access.
• Annual security training; on-boarding security review for all new starters.
• Documented joiner / mover / leaver process with access revocation SLAs.

Physical (bench rig + lab)

• Access-controlled lab environment in Chennai with logged entry.
• Hardware prototypes inventoried and decommissioned with documented chain of custody.

4. Incident response

We operate a documented incident response process aligned with NIST SP 800-61. Customer-affecting incidents trigger a defined notification cadence to the operator's nominated security contact, with status updates every 24 hours until closure. A post-incident report is shared under NDA on request.

5. Sub-processor security

Every sub-processor undergoes a security review before adoption and is bound by GDPR Art. 28 obligations in their processing agreement. The current list is shared on request to rorosafetech@gmail.com.

6. Customer security artefacts

Under NDA, we share with prospective customers: our control attestation, the latest external penetration-test summary, the sub-processor list, and our incident response plan. Email rorosafetech@gmail.com with your DPO/CISO details to request a packet.

7. Contact

Security reports and questions: rorosafetech@gmail.com. Postal correspondence: Daite Software Pvt Ltd, 1/734b, Padianallur, Chennai - 600052, Tamil Nadu, India.