Vulnerability Management Procedure
Implements: Information Security Policy Section 9 (Vulnerability Management) Owner: Security Lead Last Updated: 19 June 2026 Next Review: 21 November 2026
This procedure applies across both Maelstrom AI platforms — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). Dependency scanning, triage and remediation cover the repositories of both products. For downpipes, the same process governs the in-tenant engine and console (source-available, Elastic License v2), the vendor-side control-plane, and the MIT offline reader; engine updates are additionally delivered through a signature-pinned update channel (see Engine Update Channel).
Vulnerability Sources
| Source | Frequency | Coverage |
|---|---|---|
| Dependabot (GitHub) | Continuous | All Provii and downpipes repositories. npm, Cargo, Gradle, CocoaPods, pip, Go |
| cargo audit | CI on every PR | Rust repos (provii-verifier, provii-issuer, provii-crypto, provii-mobile-sdk, shared-rate-limit) |
| npm audit | CI on every PR | TypeScript repos (admin-portal, provii-management, etc.; downpipes engine, console, control-plane) |
| go vuln scan | CI on every PR | Go modules (downpipes offline reader) |
| External reports | Ad hoc | security@maelstrom.au |
| Manual review | Quarterly | Architecture and code review |
Triage and Prioritisation
CVSS-Based Priority
| CVSS Score | Severity | Remediation SLA | Example |
|---|---|---|---|
| 9.0-10.0 | Critical | 48 hours | Remote code execution in a direct dependency |
| 7.0-8.9 | High | 7 days | Authentication bypass in a dependency |
| 4.0-6.9 | Medium | 30 days | Information disclosure in a dev dependency |
| 0.1-3.9 | Low | 90 days or next scheduled update | Theoretical attack requiring local access |
Context Adjustments
Not all vulnerabilities have equal impact across the two platforms. Consider:
- Is the vulnerable code path reachable? A vulnerability in an unused feature of a dependency may be low priority regardless of CVSS.
- Is it a dev dependency only? Dev-only dependencies don’t run in production. Downgrade by one severity level.
- Is it in a WASM-compiled crate? Some OS-level vulnerabilities don’t apply to the WASM sandbox.
- Does Cloudflare’s infrastructure mitigate it? Network-level vulnerabilities may be mitigated by Cloudflare’s WAF/DDoS protection.
- Which platform ships the dependency, and where does that code run? For downpipes, the engine and console run in the customer’s own Cloudflare account, under the customer’s keys, with no standing inbound path (“runs dark”); a flaw reachable only from a vendor-facing surface has no path into a customer tenant, while a flaw in the in-tenant engine or console is assessed for its effect on customer-operated instances and on the no-custody boundary (Maelstrom holds no customer keys, data or Cloudflare tokens).
Remediation Process
1. Assess
- Review the advisory: What is the vulnerability? What versions are affected?
- Check if the vulnerable code path is reachable in our usage
- Determine if an update is available
2. Update
- If a patched version exists: Update the dependency and run tests
- If no patch exists: Assess workarounds (pin to safe version, disable vulnerable feature, add mitigating controls)
- If the dependency is unused: Remove it
3. Test
- Run full CI suite (lint, test, build)
- For critical/high: Manual testing of affected flows
4. Deploy
- Follow the Change Management Procedure
- For critical vulnerabilities: Emergency change process is acceptable
5. Verify
- Confirm the vulnerability scanner no longer reports the issue
- Close the Dependabot alert or GitHub Issue
Engine Update Channel (downpipes)
Because the downpipes engine runs in the customer’s own Cloudflare account, a remediated engine build does not reach customers via a Maelstrom-controlled deploy. It is published to the static, signature-pinned update channel (updates.downpipes.io, Cloudflare R2) and pulled by the engine — never pushed, with no phone-home and no standing inbound path:
- The fixed engine artefact is signed by the downpipes Update Signer, held offline by the operator and never deployed to any Worker
- The engine verifies each update’s signature against a pinned public key before applying it
- Roll-out is canary-gated with automatic rollback if the canary fails
The console and the vendor-side control-plane are remediated and released by Maelstrom through the standard Change Management Procedure. The MIT offline reader is built from the frozen public format spec; a fixed reader is published as a normal release. Operating the in-account engine and console — including applying available updates promptly — is a customer-operated responsibility (a complementary user-entity control). The control-plane is fail-open and never gates backup or restore, so a vulnerability there cannot block a customer’s recovery.
Dependabot Configuration
Each repository has .github/dependabot.yml configuring:
- Frequency. Weekly for most ecosystems, daily for security-only updates
- Reviewers. Auto-assigned based on platform
- Labels.
dependencies,security(for security advisories) - Grouping. Minor/patch updates grouped to reduce PR noise
External Vulnerability Reports
Reports received at security@maelstrom.au:
- Acknowledge within 2 business days
- Assess the reported vulnerability
- Remediate per the SLA above
- Respond to the reporter with outcome and timeline
- Credit the reporter (if they consent) in release notes