Vulnerability Management Policy

This Vulnerability Management Policy ("Policy") defines how Persoon.ai Inc. ("ShipReady Metrics", "we", or "us") identifies, assesses, prioritizes, and remediates security vulnerabilities in the ShipReady Metrics service ("Service") — its application code, dependencies, database, and configuration.

This Policy is distinct from, and complementary to, our Vulnerability Disclosure Policy. The Vulnerability Disclosure Policy governs how EXTERNAL security researchers report vulnerabilities to us in good faith (scope, safe harbor, and coordinated disclosure); this Policy governs the INTERNAL lifecycle — what happens to a vulnerability once we know about it, however it was found. Reports received under the Vulnerability Disclosure Policy enter the remediation process described here.

Vulnerabilities in the platforms of our subprocessors (e.g., our hosting, database, or email providers) are managed by those providers under their own programs; our responsibility is to track their advisories and apply any customer-side action they require.

ShipReady Metrics is an early-stage company with a small team; vulnerability management responsibilities are held by the company's leadership and engineering function rather than a dedicated security department. [Owner to confirm: the named accountable role for vulnerability management decisions and risk acceptance.]

Regardless of headcount, the responsibilities remain distinct: identifying and triaging vulnerabilities, deciding remediation priority, applying and verifying fixes, and accepting any residual risk are each deliberate steps, and material decisions are traceable through source control history and the platform audit trail.

We identify vulnerabilities in the Service through the following channels:

• Continuous integration checks that run on every pull request and every push to the main branch (see Section 5).
• External reports from security researchers under our Vulnerability Disclosure Policy (security@persooninc.com).
• Security advisories published for the open-source dependencies and platforms we build on.
• Notifications from our subprocessors about incidents or vulnerabilities on their platforms.
• [Owner to confirm: which GitHub-native scanning features (Dependabot alerts, code scanning, secret scanning) are enabled on the company's own repository — these are repository settings not visible in the codebase itself.]

The Service's dependencies are pinned through a package-manager lockfile, and continuous integration installs with a frozen lockfile — a build can never silently pick up a different dependency version than the one reviewed and committed.

Dependency updates are currently performed manually by the engineering owner and reviewed through the normal pull-request gates; an automated dependency-update service (such as Dependabot version updates or Renovate) is not currently configured in the repository. [Owner to confirm: the intended cadence for routine dependency review, and whether to adopt an automated update bot.]

Security-relevant dependency updates (a published vulnerability in a dependency we ship) are prioritized ahead of routine version maintenance, using the severity and exploitation criteria in Section 6.

Every pull request and every push to the main branch must pass the following automated gates before it reaches production (pushes to main deploy automatically):

• Type checking, linting, formatting checks, unit tests, and a full production build.
• A function-grant audit that guards against privilege leaks through database functions (a SECURITY DEFINER leak guard).
• A database test suite that applies every migration from scratch and runs a row-level-security isolation suite proving tenant isolation — a failure blocks the merge.
• Both the verify job and the database test job are required status checks on the main branch under branch protection.

In addition, a scheduled daily drift alarm runs a read-only check that every committed database migration has actually been applied to production; a mismatch fails the scheduled run and raises an alert, so schema drift cannot accumulate silently.

ShipReady Metrics builds vulnerability intelligence into its own product: the Service ingests security findings (dependency alerts, code-scanning alerts, and detected secrets) from the sources a customer connects, normalizes them, and enriches them with public exploitation data — the CISA Known Exploited Vulnerabilities (KEV) catalog, EPSS exploitation probabilities, and CVSS severity. The KEV catalog is refreshed on a schedule before connector re-syncs so prioritization reflects current exploited-in-the-wild status.

We apply the same prioritization philosophy to our own vulnerabilities that the product applies for customers: a vulnerability known to be actively exploited (on the KEV catalog) is treated as top priority, ahead of a higher-severity finding that is not being exploited; within a severity band, exploitation likelihood (EPSS) and then CVSS break ties. Raw severity labels alone do not set the queue.

[Owner to confirm: whether the company runs the Service's own connectors against its own repositories, so that ShipReady Metrics' internal posture is tracked in the same findings pipeline it offers customers.]

Confirmed vulnerabilities are remediated according to their priority. The target timelines below are draft goals for this Policy — not contractual commitments — and must be confirmed by the owner before publication.

• Fixes ship through the same gated pipeline as all other changes (Section 5) — a security fix is never exempt from tests or review gates.
• A vulnerability that indicates possible active compromise or customer-data exposure is escalated immediately under the Incident Response Policy rather than queued here.
• Where a vulnerability was reported externally, we coordinate remediation and disclosure timing with the reporter as described in the Vulnerability Disclosure Policy.

A vulnerability may be deliberately deferred only by an explicit, recorded decision — for example, when a fix depends on an upstream release, when the affected code path is not reachable in production, or when remediation risk exceeds the vulnerability's realistic impact. Deferral requires a documented rationale and an owner. [Owner to confirm: who may accept risk, and where acceptances are recorded.]

Deferred items are not forgotten items: they are revisited when new exploitation intelligence appears (for example, a deferred CVE later appearing on the KEV catalog re-enters the queue at top priority).

This Policy is reviewed at least [Owner to confirm: cadence, e.g., annually] and after any significant incident or material change to our architecture or tooling. Related documents: the Vulnerability Disclosure Policy (inbound researcher reports), the Incident Response Policy (active incidents), and the Security Overview.

ShipReady Metrics has not obtained SOC 2, ISO 27001, or an independent audit of its vulnerability management program; the current status of any such effort is reflected in our Trust Center. Questions and reports: security@persooninc.com. Postal contact: Persoon.ai Inc., 525 Randall Ave Ste 100 PMB 228, Cheyenne, WY 82001. This document is an AI-generated draft pending legal and owner review and is not legally binding.