Vulnerability Management Policy

Field	Value
Status	draft
Owner	OPS (infra/dependency) / INFRA (application)
Applies to	Application dependencies (Python/backend, JS/TS mobile), container images, infrastructure, and the LinkedIn OIDC integration.
Review cadence	Annual policy review; dependency/vuln triage is continuous once scanning is wired (see procedure).
Mapped controls	SEC-10 (JWKS id_token verification), SEC-14 (dependency scanning + pre-launch pentest), SEC-15 (IDOR regression test).
Evidence	readiness/threat-model-and-auth-review.md (gap register S2, S5); infra PR-16 linkedin_oidc_smoke.py; ../procedures/vulnerability-triage-procedure.md.
Exception handling	A vulnerability carried past its SLA is risk-accepted with a compensating control and date.

Purpose

Define how Partile finds, prioritizes, and fixes vulnerabilities — set now, while the surface is small, so it scales with the product.

Current honest state

Automated dependency/SAST scanning and a pre-launch pentest are not started (SEC-14). JWKS id_token verification is implemented in infra PR-16 (SEC-10) and covered by linkedin_oidc_smoke.py. This policy sets the ongoing vulnerability process; the control register reflects what operates today versus what remains future. No status is inflated by the existence of this draft.

Sources of findings

• Automated dependency scanning (to be wired into CI) — backend and mobile.
• Container image scanning before any production push.
• The threat model and per-PR review (secure-development-policy.md).
• A pre-public-launch third-party penetration test (SEC-14, M5).
• Responsible-disclosure reports once a contact channel exists.

Severity & remediation SLA (target)

Severity	Definition	Remediation target
Critical	Remote exploit / data exposure / auth bypass	Patch or mitigate within 48h
High	Significant weakness, plausible exploit	Within 7 days
Medium	Limited impact or requires preconditions	Within 30 days
Low	Hardening / defence-in-depth	Next planned cycle

SLAs apply from confirmation; the clock and triage steps are in ../procedures/vulnerability-triage-procedure.md. SLAs become enforceable once scanning is operational — until then they are the agreed target.

Triage

Each finding is confirmed (not a false positive), severity-rated, assigned to a role owner, and tracked to closure with evidence (the patch PR). Confirmed findings that are also live security incidents follow incident-response- policy.md.

Pre-launch gates

Before public launch (M5): dependency scanning operational, no open Critical/High findings, and a third-party pentest completed with findings remediated or risk-accepted (SEC-14).

Exceptions

A finding not remediable within SLA is risk-accepted by DIR with rationale, a compensating control, and a review date, recorded on the control row.