Vulnerability Management Policy

This policy defines the ongoing process Ouva uses to detect, assess, remediate, and validate security vulnerabilities across the application, supporting services, and managed deployment footprint.

Scope

This policy applies to:

• Ouva-managed application code, APIs, and edge functions
• Open-source dependencies used in production systems
• Managed kiosk deployments and supporting operational tooling
• Security findings reported internally, by automated tooling, by customers, or by third parties

Detection Sources

Ouva uses multiple sources to identify potential vulnerabilities:

• GitHub Dependabot alerts and automatic security update pull requests for known dependency vulnerabilities
• CI-based production dependency audits on pull requests and pushes to the main branch
• GitHub CodeQL code scanning for automated semantic vulnerability detection across application code
• GitHub CodeQL code quality analysis for identifying maintainability and correctness issues that may have security implications
• Semgrep static application security testing in CI for frontend and edge-function codepaths
• GitHub secret scanning with push protection, AI-based detection, non-provider pattern matching, and validity checks for credential exposure risks
• Internal engineering review, incident follow-up, and customer-reported findings
• Periodic external web application scanning and independent application-layer assessments based on risk and contractual requirements

Triage and Ownership

• New vulnerability findings are reviewed within 1 business day of receipt or detection.
• Findings are assessed for severity, exploitability, affected scope, customer impact, and whether compensating controls already exist.
• A remediation owner is assigned for each actionable High Risk or Critical finding.
• Findings determined to have no realistic exploit path in Ouva’s environment are documented with the rationale for deferral or acceptance.

Remediation Targets

• Critical vulnerabilities: remediate and deploy within 72 business hours of identification.
• High severity vulnerabilities: remediate and deploy within 7 business days of identification.
• Moderate and low severity vulnerabilities: remediate on a risk-based schedule aligned to product roadmap, maintenance windows, and exploitability.
• Emergency remediation may bypass normal release scheduling when active exploitation or material customer risk exists.

Dependency and Code Scanning

• Dependabot remains enabled for alerting and security update pull requests.
• Dependency audits run automatically in CI on pull requests and on pushes to the main branch.
• GitHub CodeQL runs automatically to perform semantic code analysis, identifying vulnerabilities such as injection flaws, authentication issues, and insecure data handling patterns. CodeQL code quality analysis is also enabled to detect correctness and maintainability issues.
• Semgrep runs automatically in CI to detect common security anti-patterns, injection risks, and hardcoded secrets.
• GitHub secret scanning is enabled with push protection, AI-based secret detection, non-provider pattern matching, and automatic validity checks to verify whether detected credentials are active.
• Findings from automated scanners are triaged by engineering and either fixed, suppressed with documented rationale, or tracked for follow-up.

Validation and Ongoing Testing

• After remediation, the affected control or code path is re-tested through CI, targeted manual validation, or both.
• Automated web application vulnerability scanning is performed at least quarterly or after material changes to externally exposed functionality.
• Independent application-layer penetration testing is performed at least annually, after major architectural changes, or when required by customer contract or risk review.

Exceptions and Risk Acceptance

• Any exception to the remediation targets in this policy requires documented approval from the system owner.
• Exceptions must include business justification, compensating controls, residual risk, and an expiration or review date.

Incident Escalation

• Vulnerabilities that indicate active compromise, attempted exploitation, or significant customer impact are handled under the Incident Response Plan.
• Security events should be reported to security@ouva.co.
• Operational issues requiring urgent support should be reported to help@ouva.co.

Shared Responsibility

• Ouva relies on managed providers including Netlify and Supabase for infrastructure-layer controls such as CDN delivery, TLS termination, managed backups, and provider-operated platform security.
• Provider-managed controls do not replace Ouva’s responsibility to secure application code, dependencies, configuration, and access controls.

For release controls and patch execution, see Change and Patch Management. For secure engineering requirements, see Secure Software Development Lifecycle. For provider security posture, see Third-party Services.