Vulnerability
Management
Policy

This policy defines how Ajeris identifies, triages, and remediates security vulnerabilities in the code we ship, the dependencies we rely on, and the infrastructure we run on. Detect fast, triage honestly, patch inside clear SLAs.

• ◆All application source code (packages/*, web/, alexa-skill/)
• ◆Every npm dependency reachable from package.json in any workspace
• ◆GitHub Actions workflows (a supply-chain surface of its own)
• ◆Hosting infrastructure (Railway managed PostgreSQL, Railway containers)
• ◆Third-party platforms where a vulnerability creates risk for us (Twilio, Plaid, Anthropic, OAuth providers)

Two automated mechanisms run continuously:

• ◆npm audit on every pull request: the .github/workflows/audit.yml workflow runs npm audit --audit-level=high against each of the three workspaces. A PR cannot merge to main if any high- or critical-severity advisory is surfaced.
• ◆Weekly scheduled scan against main (Monday 08:00 UTC) catches vulnerabilities disclosed between merges.
• ◆Dependabot opens grouped weekly PRs for minor and patch npm updates, and immediate individual PRs for any security-severity advisory.
• ◆GitHub Actions versions are tracked by Dependabot (actions have their own advisories).

Every code change is reviewed before merge. Security-sensitive changes (auth, token handling, encryption, webhook validation) get focused review.

We use the standard CVSS tiers. Measured from the earliest of: advisory publication date, Dependabot PR opening, or internal discovery.

• ◆Critical (CVSS 9.0+): within 24 hours of disclosure
• ◆High (7.0 to 8.9): within 7 days of disclosure
• ◆Medium (4.0 to 6.9): within 30 days of disclosure
• ◆Low (below 4.0): within the next regular update cycle

When a patch is not yet available, we apply compensating controls (pin to non-vulnerable version, code-level mitigation, feature disablement) inside the severity SLA and track the underlying vulnerability until a permanent fix lands.

Dependabot PR triage runs at least weekly. For each PR: review the advisory, run the CI suite, merge if green and within SLA, defer (with a dated comment) only if a compensating control is in place.

• ◆npm audit failures on pull requests: identify the package, bump to a non-vulnerable version, re-run. If no patch exists, accept the risk with documentation or block merge.
• ◆Risk acceptance is allowed only when the vulnerable code path is unreachable, no patch is available upstream, and acceptance is documented in the PR with CVE, reasoning, and a review date inside the severity SLA.
• ◆Zero-day: detect, contain (disable functionality, rotate credentials), eradicate (patch or document mitigation), notify users within 72 hours if data was compromised, review and update policy if a gap was revealed.

• ◆Lockfiles: every workspace commits package-lock.json. No unlocked installs in CI or production.
• ◆Pinned actions: GitHub Actions pinned to major versions (e.g. actions/checkout@v4). Dependabot surfaces breaking changes in advance.
• ◆Branch protection: main branch requires reviews and passing status checks (including the audit workflow). No direct pushes.
• ◆Deploy credentials live as GitHub Secrets scoped to the deployment workflow only.
• ◆Runtime isolation: per-user agent containers limit the blast radius of a compromised dependency.

• ◆Container base images (Node.js LTS) are rebuilt on every deploy; base-image updates are picked up automatically.
• ◆Railway applies host-OS patches; we track Railway's changelog for infrastructure-level advisories.
• ◆Managed services (Railway, Twilio, Anthropic, OpenAI) are SOC 2 Type II. Their compliance and patching posture is evaluated at provider selection and re-evaluated annually.
• ◆Database major version upgrades are coordinated to avoid windows of unpatched versions.

We welcome responsible disclosure from researchers and users. Please include a description, steps to reproduce, impact assessment if known, and your preferred credit attribution (or anonymity).

• ◆Acknowledgement within 24 hours
• ◆Initial assessment within 4 business days
• ◆Patch and public disclosure coordinated with the reporter

We do not operate a formal bug bounty program at this time. We may recognize reporters in release notes or a public security acknowledgements page when a fix ships.

Tracked privately and reviewed quarterly:

• ◆Mean time from disclosure to patch, by severity tier
• ◆Count of open high/critical advisories at any given week
• ◆Dependabot PR turnaround time
• ◆Count of risk acceptances older than their SLA

Metrics that cross the SLA threshold trigger an immediate review.

This policy is reviewed:

• ◆Annually
• ◆Upon any significant change to the dependency or infrastructure model
• ◆Upon any security incident
• ◆Before onboarding any new third-party data provider

Next scheduled review: April 2027.

Security concerns, advisory reports, and policy questions: hi@ajeris.com.