Vulnerability & Patch Management Procedure

This documents closing an open gap, not an existing process

This procedure exists ahead of the tooling that would make it operate. No dependency/SCA scanning exists anywhere in Stratify's pipeline today — confirmed absent, not merely undocumented: neither dos-ci.yml nor the vestigial Jenkinsfile runs pnpm audit, Dependabot, or Renovate (register/facts.md). This is tracked as RISK-003 in register/risks.yaml (inherent score 9, treatment: mitigate, status: open) and as objective 1 in GOV-08 ("Close the dependency/SCA scanning gap in CI," target 2026-11-01). Writing the procedure before the tooling exists is intentional and expected at this stage — it defines what "closing this gap" means concretely, so the eventual CI job has a target to satisfy rather than being wired up ad hoc.

Current state

• Dependency vulnerabilities: no automated detection. A known-vulnerable npm/pnpm package can

ship to production today and nothing in CI or elsewhere would flag it.

• Infrastructure/platform vulnerabilities: no dedicated scanning of the Hetzner host, Docker

images, or the self-hosted Supabase stack beyond what a future pentest (PRO-14) would surface.

• Application vulnerabilities: only what the CI gate's lint/typecheck/test jobs happen

to catch, plus whatever a code-review pass notices — no dedicated SAST tooling.

This procedure's scope for now is the dependency/SCA gap specifically, since that's the concretely scoped, closeable gap identified in facts.md and risks.yaml. Infrastructure and application vulnerability scanning are named as out-of-scope-for-now, not silently ignored — they should be picked up as separate objectives once this one lands.

Target procedure

1. Automated dependency scanning

• On every PR: add a sca job to .github/workflows/dos-ci.yml running

pnpm audit --audit-level high, added to verify's needs: [...] list so a high/critical finding blocks merge the same way a failing test does (concrete wiring detailed in PRO-04).

• On a weekly cron, independent of PR activity, since a dependency can become newly

vulnerable (a CVE published against an already-merged version) without any code change triggering a scan: a scheduled GitHub Actions workflow (schedule: trigger, weekly) running the same pnpm audit command against main, or — preferably, once set up — Dependabot's own scheduled security-update PRs, which cover this case natively without a hand-rolled cron.

• Both are proposed, not yet implemented. Until they exist, this procedure's "detection" step is

manual: an occasional pnpm audit run by the ISMS Owner, with no guarantee of regularity.

2. Triage SLA by severity

Proposed pending ISMS Owner confirmation — these are reasonable defaults, not yet ratified as policy:

For a single-engineer team, "triage" in practice means: the ISMS Owner reads the finding, judges severity against Stratify's actual exposure (is the vulnerable code path reachable from untrusted input, e.g. the public B2B API or subscriber-facing forms — this is a judgment call until a formal severity-scoring rubric exists) and picks one of: patch now, patch in the SLA window, or risk-accept with a documented reason and review date.

3. Finding tracking

Each finding, once scanning exists, is tracked as either:

• An entry in `register/risks.yaml`, following the existing RISK-nnn schema, if the finding

represents an ongoing risk decision (e.g. a vulnerable dependency with no available patch, being risk-accepted for now) — this reuses the register that already exists rather than inventing a parallel tracker.

• A GitHub issue, for a finding that simply needs a version bump or straightforward fix and

doesn't warrant a standing risk-register entry — closed once the patch merges and passes the CI gate.

Which path a given finding takes is a judgment call for the ISMS Owner at triage time; the rule of thumb is: if it's fixed within the SLA window with a normal PR, a GitHub issue is enough — if it lingers past the SLA window or has no available fix, promote it to risks.yaml so it doesn't silently drop off tracking.

Evidence

Once the scanning job exists: its CI run history (pass/fail, findings list per run) becomes the primary evidence trail, same pattern as PRO-04. Until then, any manual pnpm audit runs should be logged as a dated entry under docs/compliance/isms/evidence/ (finding list, triage decision per finding, action taken) — this is the interim evidence record while the automated path doesn't exist yet.

Relationship to GOV-08

This procedure operationalizes GOV-08 objective 1 directly. Once the sca job lands in dos-ci.yml and the SLA table above is confirmed rather than proposed, this document's status should move from draft toward approved, and RISK-003 in register/risks.yaml should be updated with a treatment date and, once meaningfully mitigated, a residual score.

Review

Reviewed at every GOV-12 management-review cycle until the scanning gap is closed, then annually. The SLA table should be explicitly confirmed (not just re-read) by the ISMS Owner at the first review after this procedure is approved.