Legal & Compliance
Identifying, Assessing, and Remediating Security Vulnerabilities
Effective: May 26, 2026 · Next review: May 26, 2027 · Pythias Technologies, LLC
1
This procedure defines how Pythias Technologies identifies, evaluates, prioritizes, and remediates security vulnerabilities in its software, infrastructure, and dependencies. The goal is to reduce the window of exposure between vulnerability disclosure and remediation.
2
This procedure applies to all Pythias production systems, including web applications, APIs, server infrastructure, third-party dependencies (npm packages, Node.js runtime, OS packages), and cloud service configurations.
3
Automated dependency scanning
npm audit is run on all application packages before every production deployment and at least weekly in the automated build process.
CVE alerts for key direct dependencies are monitored via GitHub Dependabot alerts or equivalent.
Infrastructure scanning
MongoDB Atlas security advisor recommendations are reviewed monthly.
Server OS package vulnerability lists (via apt/yum security advisories) are reviewed monthly.
Manual and external discovery
Responsible disclosure: external researchers who identify vulnerabilities may report them to [email protected]. Reports are acknowledged within 5 business days.
Security-focused code review is performed for all changes to authentication, authorization, payment-adjacent, and data export functionality.
4
Each identified vulnerability is assessed for: CVSS score (where available), exploitability in Pythias' specific environment, data or service impact if exploited, and availability of a fix or mitigation.
CVSS 9.0+, or any vulnerability with a known public exploit and direct path to Pythias production data.
CVSS 7.0–8.9, or significant risk in the Pythias context even if CVSS is lower.
CVSS 4.0–6.9, limited exploitability, or mitigating controls already in place.
CVSS < 4.0, theoretical risk, or requires extensive pre-conditions to exploit.
5
Critical — patched or mitigated within 48 hours of confirmed identification.
High — patched within 7 days.
Medium — patched within 30 days.
Low — patched within 90 days, or accepted and documented with rationale.
If a patch is not available within the required timeline, a compensating control (WAF rule, network restriction, feature disable) must be implemented and documented until the patch is available.
6
All dependency patches are tested in a non-production environment before deployment to production.
Emergency patches (Critical severity) may be deployed directly to production with post-deployment verification.
All patches are deployed via version-controlled deployments — no ad-hoc manual changes to production.
Patch deployment is logged with date, deployer, and the vulnerability addressed.
7
All identified vulnerabilities are tracked in an internal log with: discovery date, CVE or description, severity, affected component, assigned remediation owner, target date, and status.
Open vulnerabilities older than their SLA deadline are escalated to the company owner.
Vulnerability metrics (open count by severity, mean time to remediate) are reviewed quarterly.
8
This procedure is reviewed annually (next review: May 26, 2027) and updated following any significant vulnerability incident or major change to the technology stack.
© 2026 Pythias Technologies, LLC · All rights reserved
