Vulnerability and Patch Management Policy

Organization: Strategic Habits Consulting, LLC, doing business as Gevell and TheAccessible.Org Owner: Larry Anglin, CTO Effective date: 2026-09-23 Parent policy: Information Security Policy

1. Purpose and scope

This policy sets how the Company finds, ranks, fixes and verifies security vulnerabilities. It also sets how risk is reduced while a fix is not yet available or cannot yet be applied.

It covers:

application code and its dependencies, including npm packages, Python packages and container base images;
staff laptops;
cloud configuration on AWS, Cloudflare and Supabase.

2. Where vulnerabilities come from

Source	How it runs today
Dependabot version updates	Weekly. Covers all application, infrastructure-as-code and documentation package manifests, plus GitHub Actions. Opens pull requests that must pass the same CI `gate` as any other change.
`npm audit`	Nightly scheduled job on the CTO’s workstation. It emails a report of critical and high findings.
Vendor security advisories	AWS, Cloudflare, Supabase, Node.js, GitHub and major framework advisories, as the CTO receives them.
Internal review	Security reviews and red-team exercises, such as the attack-surface review, the September 2026 AI security assessment, and the prompt-injection red-team.
External reports	Reports sent to security@gevell.com.

Every confirmed vulnerability is logged as a GitHub issue labeled security, with its severity.

3. Severity and remediation targets

Severity starts from the CVSS base score, and the CTO adjusts it for real exposure in our environment. Questions that affect the rating:

Is the vulnerable code actually reachable?
Is it exposed to the internet?
Can it touch customer data?

Severity	Examples	Mitigate by	Fully fix by
Critical	Actively exploited, or remotely exploitable without login, on an internet-facing path that touches customer data	48 hours	7 days
High	Remotely exploitable with limited conditions, or data exposure that needs a login	7 days	30 days
Medium	Needs unusual conditions or local access, or has limited impact	n/a	90 days
Low	Defense in depth, or not reachable in our deployment	n/a	Next routine update, or accept the risk (§6)

The clock starts when the CTO confirms the vulnerability applies to us.

These targets are set for a team with one engineer. They are commitments for the future: the Company has not yet measured its past performance against them.

If a vulnerability has no vendor fix yet, the “mitigate by” deadline still applies. The item stays open until the fix is released and applied.

4. Reducing risk until a fix is applied

When a fix cannot be applied within the target, the CTO puts one or more of the following in place and records it on the issue.

AI kill switch (no deploy needed).
- Bedrock PDF conversion can be stopped from the admin AI Controls page. If the API is down, it can be stopped with a Supabase SQL update.
- Queued jobs are held, not lost.
- A separate Lambda environment variable, PDF_BEDROCK_ENABLED=false, turns off the Bedrock path entirely even if the database is unreachable.
- Procedure: the AI kill-switch runbook.
Feature gates set by environment variables. Several features are controlled by Lambda environment variables that can be changed without a code deploy. Turning one off takes the affected path out of service.
Cloudflare edge controls. All customer traffic passes through Cloudflare. From the Cloudflare dashboard, a WAF custom rule, IP or country block, or rate-limiting rule can be added in minutes without a deploy. A Cloudflare Access policy can put a path behind login.
Turning off an endpoint or feature. A route can be taken out of service through a small reverted or feature-flagged change that goes through the normal CI gate.
Rotating credentials. Any credential that may have been exposed is rotated using the secrets inventory and rotation runbook (§6, emergency rotation).
Per-customer AI opt-out. A tenant or user can turn off AI processing for their account. The server enforces this.

5. Patching infrastructure and devices

Cloud services (AWS Lambda runtimes, Cloudflare, Supabase): the providers patch the platform. The Company updates runtime versions before they reach end of support.
Container images: rebuilt from updated base images when a security fix is released. Critical fixes follow the timeline in §3.
Laptops: automatic operating system and browser updates stay turned on. Critical updates are installed within 7 days.

6. Exceptions and accepting risk

If a vulnerability will not be fixed within its target, the CTO records a risk acceptance. This could be because no fix exists, the fix would break the product, or the risk is judged negligible. It is a GitHub issue labeled security-exception that states:

the vulnerability and its severity;
why it is not being fixed yet;
the interim mitigations from §4 that are in place;
an expiry or next review date of no more than 90 days for Critical or High, and 12 months for other severities.

Accepted risks are reviewed when they expire, and at the annual policy review.

7. Verification

A vulnerability is closed only after:

the fix has been deployed to production from main; and
the fix has been verified, by a clean npm audit or Dependabot result for that package, a test that reproduces the issue and now passes, or a manual check against production, whichever fits.

Interim mitigations are removed only after the fix is verified. Each removal is noted on the issue.

Actions required to make this policy true

~~Turn on Dependabot alerts and Dependabot security updates.~~ Done 2026-09-23. Both are enabled for theaccessible-platform.
~~Add a dependency audit to CI.~~ Done 2026-09-23 (#3506, #3530). Every PR audits all committed lockfiles for high/critical advisories inside the required gate check; accepted advisories are listed in .github/npm-audit-allowlist.json with expiry dates (fixes tracked in #3505).
Extend Dependabot to the other ecosystems:
- pip for services/flyer-tagger and the other Python services;
- docker for the Dockerfiles. Today, neither Python dependencies nor container base images are scanned.
Clear the Dependabot pull-request backlog. There are 13 open, some from 2026-09-01. Then keep to the weekly triage.
Confirm laptops have automatic updates on, and record it in the device inventory.
~~Move the nightly npm audit off the CTO’s workstation.~~ Done 2026-09-23. A daily scheduled GitHub Actions audit (dependency-audit.yml) now runs it.
Create the security-exception label. The security label already exists. Log any known open critical or high findings as security issues with a severity, so the targets in §3 have a starting point.
Commission the external penetration test tracked in #3096. It is not required by this policy, but reviewers commonly ask for one.