Electronically Signed By:
Isa Hasenko
Vulnerability Management Policy (VMT.3)
Organization: Fintable, Inc.
Owner: Security & Compliance + Engineering
Review cadence: Annual or upon material change
Approved by: Isa Hasenko
Approval Date: 2025 August 15
1) Purpose & Scope
This policy defines Fintable's vulnerability management program and the required
remediation timeframes to answer VMT.3. It applies to application code
(Laravel/PHP and Node.js assets), operating systems, third‑party packages,
containers (if used), servers, corporate endpoints (macOS), and supporting SaaS
platforms.
2) Policy Statement & SLAs (VMT.3)
Fintable remediates vulnerabilities according to the following maximum
timeframes from the date of discovery/notification:
Severity | Definition (guidance) | Max Time to Remediate
----------|---------------------------------------------------------------|------------------------
Critical | Actively exploited or CVSS ≥ 9.0; remote code execution; | ≤ 7 days
| auth bypass |
High | CVSS 7.0–8.9; significant impact/likelihood | ≤ 30 days
Medium | CVSS 4.0–6.9; moderate impact/likelihood | ≤ 90 days
Low/Info | CVSS < 4.0; hard to exploit | Best effort / next
| | window
If a fix cannot be applied within the SLA, a documented exception with
compensating controls and an expiry date is required (see §7).
3) Detection & Intake
• Automated dependency scanning in CI: `npm audit` for JS assets; `composer
audit` for PHP packages.
• Operating system updates: auto-updates enabled on all employee macOS devices
and production/staging servers; periodic manual checks validate status.
• Threat intelligence: upstream security advisories for Laravel/PHP, Node.js,
Ubuntu; alerts from WAF, logging, and monitoring systems.
• External reports: report handling through the security contact; triage within
2 business days.
4) Triage & Severity Assignment
• Triage within 2 business days for newly discovered issues; assign provisional
severity (Critical/High/Medium/Low).
• Use CVSS v3.x as guidance plus business context (exposure, data sensitivity,
exploitability, compensating controls).
• Create a ticket with affected systems/packages, versions, references, proposed
fix, and SLA due date.
5) Remediation & Patching
• Applications: upgrade or pin vulnerable packages; remove/replace affected
components; add tests to prevent regressions.
• Servers: apply security fixes via auto‑updates and scheduled maintenance;
verify kernel and critical library patches; reboot if required.
• Endpoints (macOS): auto updates enabled (OS and browsers); users prohibited
from deferring critical security updates.
• Configurations: deploy WAF/iptables rules, feature flags, or temporary
workarounds while a permanent fix is prepared (must not exceed SLA).
• Evidence of fix: attach commit hashes, package version diffs (`composer.lock`,
`package-lock.json`), apt logs, or configuration PRs to the ticket.
6) Verification & Closure
• Re-run scans (`npm audit`, `composer audit`) and relevant tests in CI/staging;
confirm vulnerabilities are resolved.
• For OS patches, confirm package versions and kernel levels; capture
`unattended-upgrades` or equivalent logs.
• Security reviewer signs off that risk is addressed; ticket transitions to
Closed with remediation evidence.
7) Exceptions & Risk Acceptance
• When remediation cannot be completed within SLA, obtain written approval from
Security & Compliance and the system owner.
• Document compensating controls (e.g., WAF block rules, service isolation,
access restrictions) and an expiry date (≤ 60 days for Critical/High, ≤ 120 days
for Medium).
• Exceptions are tracked in the risk register and reviewed weekly until closure.
8) Roles & Responsibilities
• Security & Compliance: owns the program, defines SLAs, monitors compliance,
approves exceptions.
• Engineering: fixes vulnerabilities, validates in CI/staging, provides
remediation evidence.
• IT/Operations: ensures auto‑updates and patch baselines on servers and
endpoints; performs manual checks.
• All Personnel: must not disable security updates; promptly report suspected
vulnerabilities.
9) Monitoring, Metrics & Reporting
• Weekly review of open vulnerabilities by severity and age; escalate any SLA
at‑risk items.
• KPIs: Mean‑Time‑To‑Remediate (MTTR) by severity, % closed within SLA, count of
exceptions, and backlog trend.
• Quarterly report to leadership; continuous improvement actions captured as
work items.
10) Tools & Runbook Snippets
Examples:
• JS packages: npm audit --audit-level=high
• PHP packages: composer audit
• Ubuntu servers: apt update && apt list --upgradable; unattended-upgrades logs
• macOS endpoints: softwareupdate -ia
11) Review & Maintenance
This policy is reviewed quarterly and after major incidents or changes to
tooling. SLAs may be tightened based on risk and operational maturity.
Approved By:
Isa Hasenko
Chief Executive Officer
Electronically Signed By:
Isa Hasenko