Vulnerability Management Policy

Continuous npm audit, Dependabot, CVSS-based SLAs, honest risk acceptance.

Ajeris , Vulnerability Management Policy

Document Owner: Sarah Mitchell, Founder Contact: hi@ajeris.com Effective Date: April 15, 2026 Last Reviewed: April 15, 2026 Review Frequency: Annually, or upon significant infrastructure changes

1. Purpose

This policy defines how Ajeris identifies, triages, and remediates security vulnerabilities in the code it ships, the dependencies it relies on, and the infrastructure it runs on. The goal is simple: vulnerabilities are detected fast, triaged honestly, and patched inside clear SLAs.

2. Scope

Covers:

All application source code in the Ajeris repositories (packages/*, web/, alexa-skill/)
Every npm dependency (direct and transitive) reachable from package.json in any of those workspaces
GitHub Actions workflows (a supply-chain surface of its own)
Hosting infrastructure (Railway managed PostgreSQL, Railway containers)
Third-party platforms we integrate with, where a vulnerability in them creates risk for us (Twilio, Plaid, Anthropic, OAuth providers)

3. Detection

3.1 Continuous dependency scanning

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 (root monorepo, web/, alexa-skill/). A PR cannot merge to main if any high- or critical-severity advisory is surfaced by npm audit. No exceptions without a documented risk acceptance (see §5.3).
Weekly scheduled scan against main catches vulnerabilities disclosed between merges. GitHub's Advisory Database receives new CVEs daily; our weekly cron (Monday 08:00 UTC) picks them up within one week at worst.

The workflow also emits an informational npm outdated report on each scheduled run so that non-security updates are visible even when they are not advisory-tagged.

3.2 Automated dependency updates

.github/dependabot.yml configures Dependabot to:

Open weekly PRs for minor and patch npm updates across the three workspaces, grouped to keep review load low.
Open individual PRs for any security-severity advisory, immediately, regardless of the weekly cadence.
Keep GitHub Actions versions current (actions themselves have their own advisories).

3.3 Code-level review

Every code change goes through review before merge.
The silent-failure-hunter and code-reviewer review agents are invoked proactively on security-sensitive changes (auth, token handling, encryption, webhook validation).

3.4 Upstream advisories

We monitor security advisories from:

GitHub Advisory Database (via Dependabot + npm audit)
Anthropic (model-side risks, policy changes)
Plaid (platform-side advisories for connected apps)
Twilio (platform-side advisories)
Node.js LTS security releases
Railway (platform-side advisories)

4. Severity and remediation SLAs

We use the standard Common Vulnerability Scoring System (CVSS) severity tiers.

Severity	CVSS score	Time to patch / mitigate
Critical	9.0 and above	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

SLAs are measured from the earliest of: advisory publication date, Dependabot PR opening, or internal discovery.

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

5. Triage and response

5.1 Dependabot PR triage

Dependabot PRs are triaged at least weekly. For each PR:

Review the advisory link to confirm severity and impact on our code paths.
Run the CI suite (tests + audit) on the bump.
Merge if green and within SLA. Defer (with a dated comment) only if a compensating control is in place.

5.2 npm audit failures on pull requests

When npm audit fails a PR:

Identify the offending package and advisory.
If a non-vulnerable version is available, bump and re-run.
If not, decide inline: accept the risk with documentation (§5.3) or block merge until upstream patches.

5.3 Risk acceptance

A vulnerability may be accepted without immediate patch only when:

The vulnerable code path is not reachable in our deployment, AND
A patch is not yet available upstream, AND
The acceptance is documented in the PR description with the CVE, reasoning, and a review date no later than the SLA for the severity tier.

Risk acceptances are revisited on every subsequent scan run.

5.4 Zero-day response

When a zero-day vulnerability is disclosed against a dependency Ajeris uses:

Detect: advisory surfaces via Dependabot or manual monitoring.
Contain: disable affected functionality if exploitation is plausible; rotate any credentials that could have been exposed.
Eradicate: apply the upstream patch as soon as it is published, or a documented mitigation if not.
Notify: if consumer data was or could have been compromised, users are notified within 72 hours per the information security policy §8.
Review: the incident is documented and the policy is updated if the incident revealed a gap.

6. Supply-chain controls

6.1 Lockfiles

Every workspace commits its package-lock.json. No unlocked installs in CI or production.

6.2 Pinned actions

GitHub Actions are pinned to specific major versions (for example, actions/checkout@v4). Dependabot keeps them current and surfaces breaking changes in advance.

6.3 Source-repo protections

The main branch is protected: required reviews, required status checks (including the audit workflow), no direct pushes.
Deploy credentials live as GitHub Secrets scoped to the deployment workflow only.

6.4 Runtime isolation

Per-user agent containers (see the Access Controls Policy §5.3) limit the blast radius of a compromised dependency. A vulnerability that affects one user's container does not reach another user's data.

7. Infrastructure vulnerability management

7.1 Operating system and runtime

Container base images (Node.js LTS) are rebuilt on each deploy; updates to the base image are picked up automatically.
Railway applies host-OS patches; we track Railway's changelog for infrastructure-level advisories.

7.2 Managed services

We rely on SOC 2 Type II certified providers for managed PostgreSQL (Railway), SMS gateway (Twilio), and LLM inference (Anthropic, OpenAI). Their compliance and patching posture is evaluated during provider selection and re-evaluated annually.

7.3 Production database

Database software updates are applied by the hosting provider (Railway).
Major version upgrades are coordinated to avoid windows of unpatched versions.

8. Reporting a vulnerability

We welcome responsible disclosure from security researchers and users.

Contact: hi@ajeris.com

Please include:

A description of the vulnerability
Steps to reproduce
Impact assessment if known
Your preferred credit attribution (or anonymity, if preferred)

Response targets:

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.

9. Metrics

The following metrics are 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.

10. Policy 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.

11. Contact

Security concerns, advisory reports, and policy questions:

hi@ajeris.com , Sarah Mitchell, Founder