Skip to content

STD-SECURITY-050: Vulnerability Management Lifecycle

STD-SECURITY-050: Vulnerability Management Lifecycle

Field Value
Owner Security Team
Approved By CDO
Date 2026-04-03
Review Date 2026-10-03
Domain SECURITY

Purpose

This standard defines Simpaisa's vulnerability management lifecycle — covering scanning, triage, severity-based remediation SLAs, exception/waiver processes, and verified closure. It applies to all Simpaisa systems (containers, dependencies, application code, infrastructure) across PK, BD, NP, and IQ.

Current State

  • Container image scanning is performed manually before major releases but not continuously.

  • Dependency vulnerability scanning (Dependabot equivalent) is enabled on some repositories but not all.

  • No static application security testing (SAST) in the CI pipeline.

  • Remediation is ad hoc — no SLAs by severity, no tracking of remediation timelines.

  • No formal exception/waiver process — some known vulnerabilities are silently ignored.

  • No verified closure process — vulnerabilities are marked "resolved" without confirmation.

Gaps

  • No continuous scanning across all repositories and container images.

  • No SAST integration in CI/CD pipelines.

  • No severity-based remediation SLAs.

  • No formal exception process for vulnerabilities that cannot be immediately remediated.

  • No verified closure (re-scan to confirm fix).

  • No single dashboard for vulnerability posture across the platform.

Target State

Continuous, automated vulnerability scanning at multiple layers (containers, dependencies, source code) with severity-based SLAs, a formal exception process, and mandatory verified closure before findings are marked resolved.

Scanning Architecture

Layer 1 — Container Image Scanning (Trivy)

Tool : Trivy (open-source, integrated into CI/CD).

Scope : All container images built by Simpaisa's CI/CD pipeline. Includes base images, Go binaries, and any bundled dependencies.

When scanned :

  • On every container image build in CI (blocking — critical/high findings fail the build).

  • Nightly scan of all images currently deployed in production (catch newly disclosed CVEs).

  • On base image update (e.g., new Alpine or Distroless release).

Configuration :

  • Severity filter: Critical and High block the build. Medium and Low produce warnings.

  • Ignore file (.trivyignore) for acknowledged exceptions only — requires Security team approval.

  • Output format: SARIF, integrated into vulnerability dashboard.

Layer 2 — Dependency Scanning (Dependabot / Renovate)

Tool : Dependabot (or Renovate, depending on Git hosting) for all repositories.

Scope : All Go modules (go.mod), Node.js packages (package.json), Python requirements, and any other dependency manifests.

When scanned :

  • Continuously — Dependabot monitors dependency advisories and raises pull requests automatically.

  • Weekly full-dependency audit (go mod audit, npm audit) run in CI.

Configuration :

  • Security updates: auto-generated PRs for critical and high vulnerabilities. Assigned to the service owner.

  • Version updates: weekly PRs for minor/patch updates to keep dependencies current and reduce vulnerability surface.

  • Grouping: related dependency updates grouped into a single PR where possible to reduce review burden.

Layer 3 — Static Application Security Testing (SAST)

Tool : Semgrep (open-source, with Simpaisa-specific custom rules).

Scope : All Go, TypeScript, and Python source code in Simpaisa repositories.

When scanned :

  • On every pull request (blocking — findings with severity High or above block merge).

  • Nightly full-repository scan to catch issues in code not recently changed.

Custom rules (Simpaisa-specific):

  • Detection of hardcoded secrets, API keys, or PAN patterns in source code.

  • Detection of SQL injection patterns in SurrealDB query construction.

  • Detection of insecure cryptographic usage (e.g., MD5, SHA1 for signing).

  • Detection of missing authentication checks on payment-related handlers.

  • Detection of PII logging (customer name, phone number, PAN logged without masking).

Configuration :

  • Rules repository: simpaisa/semgrep-rules — maintained by Security team.

  • Output format: SARIF, integrated into vulnerability dashboard.

Layer 4 — Infrastructure Scanning

Tool : Checkov for infrastructure-as-code (Terraform), kube-bench for Kubernetes configuration.

Scope : All Terraform modules, Kubernetes manifests, Cloudflare configuration.

When scanned :

  • On every infrastructure pull request (blocking for critical findings).

  • Weekly full scan of deployed infrastructure state.

Severity-Based Remediation SLAs

Severity CVSS v4.0 Range Remediation SLA Escalation if Overdue Example
Critical 9.0–10.0 24 hours CDO + CTO after 12 hours RCE in payment processing service
High 7.0–8.9 7 calendar days CTO after 3 days SQL injection in merchant portal
Medium 4.0–6.9 30 calendar days Security Lead after 14 days XSS in documentation portal
Low 0.1–3.9 90 calendar days Security Lead after 60 days Information disclosure in error message

SLA start : Clock starts when the vulnerability is triaged and assigned to a remediation owner.

SLA measurement : Tracked in the vulnerability dashboard. Weekly SLA compliance report sent to Security Lead. Monthly summary to CTO and CDO.

CDE-Specific SLAs

Vulnerabilities in CDE components (Token Vault, Card Capture Service, Processor Gateway, CDE Database) follow accelerated SLAs:

Severity CDE SLA Standard SLA
Critical 12 hours 24 hours
High 3 calendar days 7 calendar days
Medium 14 calendar days 30 calendar days
Low 30 calendar days 90 calendar days

Exception and Waiver Process

When a vulnerability cannot be remediated within the SLA:

  1. Service owner submits an exception request including: vulnerability details, reason remediation is not possible within SLA, proposed compensating controls, and requested extension period.

  2. Approval authority :

    • Low/Medium: Security Lead.

    • High: CTO.

    • Critical: CDO (critical vulnerabilities should almost never be waived).

  3. Compensating controls : The exception must include compensating controls that reduce the risk. Examples: WAF rule to block the attack vector, network segmentation to limit exposure, enhanced monitoring to detect exploitation.

  4. Maximum waiver period : 90 days. After 90 days, the waiver must be re-evaluated. No permanent waivers.

  5. Documentation : All exceptions logged in the vulnerability dashboard with: approval, compensating controls, expiry date, and re-evaluation owner.

  6. Audit trail : Exception history is available for PCI DSS QSA review during annual assessment.

Verified Closure

Vulnerabilities are NOT closed until verified:

  1. Developer implements the fix and submits a pull request.

  2. CI/CD pipeline runs the relevant scanner (Trivy, Dependabot, Semgrep) on the PR. The specific finding must no longer appear.

  3. Post-deployment scan : After deployment to production, the nightly scan confirms the vulnerability is no longer present in the running environment.

  4. Closure : Only after the post-deployment scan confirms remediation is the vulnerability marked as "Resolved" in the dashboard.

For findings from the annual penetration test (STD-SECURITY-042), re-testing by the original assessor is required for Critical and High findings before closure.

Vulnerability Dashboard

A single dashboard (built on Grafana, fed by OpenTelemetry and scanner SARIF outputs) provides:

  • Total open vulnerabilities by severity, by service, by market.

  • SLA compliance rate (percentage remediated within SLA).

  • Ageing report (vulnerabilities approaching or past SLA).

  • Trend analysis (new vs. resolved per week/month).

  • Exception/waiver summary.

Access : Security team (full access), CTO and CDO (executive summary view), service owners (their services only).

Actions

  1. Deploy Trivy in all CI/CD pipelines with build-blocking for Critical/High findings. Configure nightly production image scanning.

  2. Enable Dependabot/Renovate on all repositories. Ensure security update PRs are assigned to service owners with SLA-linked due dates.

  3. Integrate Semgrep into all PR pipelines. Deploy Simpaisa-specific custom rules from simpaisa/semgrep-rules.

  4. Build vulnerability dashboard on Grafana with SARIF ingestion from all scanners.

  5. Publish SLA policy to all engineering teams. Include in new-joiner onboarding.

  6. Establish exception review cadence — weekly review of open exceptions by Security Lead.

  7. Report to CDO — monthly vulnerability posture report including SLA compliance, open critical/high count, exception summary, and trend.

References

  • STD-SECURITY-042: Penetration Testing Programme

  • PCI DSS v4.0 Requirements 6.3, 11.3

  • OWASP Vulnerability Management Guide

  • SECURITY-ARCHITECTURE.md