Security Policy

1. Purpose of this document

This document formalizes the security policy of SIPify Labs for the SIPify Pulse product (Agent + VoiceAI Gateway). It covers:

• vulnerability reporting channels,
• the internal handling process,
• commitments to customers and security researchers,
• the disclosure policy.

2. Reporting a vulnerability

Dedicated channel: [email protected]

Information expected in a report:

• technical description of the vulnerability,
• affected Pulse version(s),
• reproduction conditions (PoC if possible),
• impact as assessed by the reporter,
• reporter contact details (for follow-up and acknowledgements).

Initial response commitment: acknowledgement of receipt within 48 business hours.

security.txt (RFC 9116): published at https://sipify.fr/.well-known/security.txt with the Contact, Expires, Preferred-Languages (fr, en), Canonical and Policy fields.

3. Scope

Covered:

• SIPify Pulse Agent (Flask backend + React frontend).
• SIPify Pulse VoiceAI Gateway (SIP/RTP, Vosk transcription).
• OFFLINE deployment bundle (installation scripts, embedded DNF repositories).
• Published OpenAPI specifications.

Not covered:

• Integrated third-party products (Oracle E-SBC, Oracle EOM) — report to the relevant vendor.
• Custom deployments at a customer site without SIPify Labs validation.
• Customer-side configuration issues (not a product defect).

4. Internal handling process

A reported vulnerability is handled through the following workflow:

1. Triage (D+0 to D+2) — Criticality assessment (CVSS 3.1 score), reproducibility confirmation, assignment of an internal owner.
2. Reproduction — Reproduction in a controlled environment (dedicated OFFLINE VM, Oracle Linux 9.6, ISO image identical to customer deployments).
3. Fix development — Dedicated branch, unit tests + non-regression tests (pytest + Vitest). The fix ships in the next minor release (weekly cadence).
4. Customer communication — Private advisory sent to impacted customers before the fix is published. The advisory includes: description, CVSS, affected versions, temporary mitigation where applicable, fixed version.
5. Publication — Integration into the OFFLINE bundle (RPM + SBOM + updated Grype report). Public advisory published 30 to 90 days after the fix is made available.
6. CVE assignment — Where applicable, CVE assignment request via MITRE or a partner CNA.

Tooling: pip-audit + npm audit + grype run on every CI build. Weekly CVE watch across all Python and Node dependencies.

5. Remediation time commitments (SLA)

The timelines below are internal objectives; they may be contractualized case by case in customer maintenance agreements.

These objectives apply from confirmation of the vulnerability (post-triage).

6. Disclosure policy

Principle: coordinated disclosure.

• The vulnerability is not publicly disclosed until a fix is available.
• Private advisory sent to impacted customers first.
• Public advisory published after a reasonable delay following availability of the fix (typically 30 to 90 days).
• Credit offered to the reporter (hall of fame or mention in the advisory), unless anonymity is requested.

7. Bug Bounty

No formal bug bounty program at this stage. An unpaid responsible disclosure program will open alongside the publication of this policy.

8. Traceability and SBOM

Each SIPify Pulse release ships with:

• SBOM in CycloneDX 1.5 and SPDX 2.3 formats (generated by Syft).
• Timestamped Grype CVE report.
• NEVRA manifest + SHA256 hashes of the RPMs in the embedded offline OS repository.
• requirements.lock file (pip-compile + SHA256 hashes).

These artifacts can be shared with any customer under NDA upon delivery.

9. Compliance with the European AI Act

9.1 System classification

SIPify Pulse is a monitoring and quality-testing tool for VoIP/SIP infrastructures. It is not a standalone AI system within the meaning of Regulation (EU) 2024/1689 (the "AI Act"), but it embeds an artificial-intelligence component:

• VoiceAI Gateway: Vosk speech-to-text transcription engine, used to transcribe pre-recorded test messages (Naegelen announcements, tones, IVR prompts) to validate correct routing of voice flows.

Retained classification: limited-risk system (Article 50).

9.2 Article 50 analysis — Transparency obligations (deadline 2 August 2026)

Article 50(1) — Chatbot interaction: Not applicable. VoiceAI Gateway is a passive, non-interactive component. It transcribes pre-recorded or passively captured audio streams (SIP/RTP mirror) — it does not interact with natural persons and generates no conversational response. No chatbot disclosure obligation.

Article 50(2) — Marking of AI-generated content: Potentially applicable. Transcriptions produced by Vosk are textual content generated by an AI system. However:

• transcriptions are intended for internal technical use (call-quality validation, audit reports),
• they are not published nor presented to the public as human content,
• they already carry their source attribution (engine: vosk field in the API's JSON metadata).

Applied compliance measure: every transcription carries a machine marker (ai_generated: true, engine: vosk, model: vosk-model-small-fr-0.22) in the API response's JSON metadata.

Article 6 — High-risk system: Not applicable. Pulse is not used in any domain listed in Annex III (health, justice, recruitment, education, essential public services, law enforcement, migration, etc.). VoIP/SIP monitoring is an industrial B2B use case with no impact on the fundamental rights of natural persons.

9.3 Technical characteristics reinforcing compliance

• 100% offline: no data transits to any third-party cloud service. Vosk models are embedded in the RPM bundle.
• No personal data processed: transcribed streams are pre-recorded test messages, not real conversations.
• Full traceability: CycloneDX/SPDX SBOM, Grype report, cross-module audit log.
• No continuous learning: the Vosk model is frozen (no fine-tuning, no feedback loop, no drift).

9.4 SIPify Labs commitments

SIPify Labs commits to:

• keeping this classification up to date if Pulse functionality evolves (addition of interactive AI components, processing of real conversations, etc.),
• tracking regulatory developments (Article 50 transparency obligations applicable on 2 August 2026, AI Act codes of practice, high-risk obligations to come),
• documenting any change to the AI component in the release notes.