Vulnerability Management Procedure

How to triage, prioritise, and remediate security vulnerabilities from dependency scanning and external reports

Public

Vulnerability Management Procedure

Implements: Information Security Policy Section 9 (Vulnerability Management) Owner: Security Lead Last Updated: 21 May 2026 Next Review: 21 November 2026


Vulnerability Sources

SourceFrequencyCoverage
Dependabot (GitHub)ContinuousAll 15 repositories. npm, Cargo, Gradle, CocoaPods, pip, Go
cargo auditCI on every PRRust repos (provii-verifier, provii-issuer, provii-crypto, provii-mobile-sdk, shared-rate-limit)
npm auditCI on every PRTypeScript repos (admin-portal, provii-management, etc.)
External reportsAd hocsecurity@maelstrom.au
Manual reviewQuarterlyArchitecture and code review

Triage and Prioritisation

CVSS-Based Priority

CVSS ScoreSeverityRemediation SLAExample
9.0-10.0Critical48 hoursRemote code execution in a direct dependency
7.0-8.9High7 daysAuthentication bypass in a dependency
4.0-6.9Medium30 daysInformation disclosure in a dev dependency
0.1-3.9Low90 days or next scheduled updateTheoretical attack requiring local access

Context Adjustments

Not all vulnerabilities have equal impact on Provii. 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.

Remediation Process

1. Assess

  1. Review the advisory: What is the vulnerability? What versions are affected?
  2. Check if the vulnerable code path is reachable in our usage
  3. Determine if an update is available

2. Update

  1. If a patched version exists: Update the dependency and run tests
  2. If no patch exists: Assess workarounds (pin to safe version, disable vulnerable feature, add mitigating controls)
  3. 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

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:

  1. Acknowledge within 2 business days
  2. Assess the reported vulnerability
  3. Remediate per the SLA above
  4. Respond to the reporter with outcome and timeline
  5. Credit the reporter (if they consent) in release notes