Skip to content

vulnerability-management.md

Latest commit

 

History

History
112 lines (71 loc) · 7.39 KB

vulnerability-management.md

File metadata and controls

112 lines (71 loc) · 7.39 KB
Raw

Vulnerability Management Procedure

Policy Owner: Security Engineering Effective Date: April 2026 (updated June 2026) Aligned with: Kernel Operations Security Policy (SOC 2), ISO 27001:2022 A.5.7, A.8.8

Scope

This procedure applies to all repositories and infrastructure under the Kernel GitHub organization. In-scope repositories include the core monorepo, all customer-facing SDKs, infrastructure CLIs, and supporting services.

Vulnerability Identification

Kernel uses automated scanning tools deployed across all in-scope repositories via reusable GitHub Actions workflows defined in kernel/security-workflows:

  • Semgrep (SAST): runs on every pull request. Scans application code for security flaws using rulesets tailored to the repository's codebase. An AI agent triages findings and posts results to the PR. The kernel/security team is automatically assigned as reviewer on remediation PRs.

  • Socket (SCA): runs weekly. Scans dependency manifests for known vulnerabilities, supply chain threats, and license risks. Findings are automatically triaged, remediated where possible, and submitted as pull requests for review.

  • Trivy (Container Scanning): runs on every image build and weekly for remediation. Scans production container images for OS package and compiled application dependency CVEs. Covers the layer that SAST and SCA cannot reach — vulnerabilities in the built artifact that actually runs in production.

Additionally, public-facing systems in the production environment undergo quarterly vulnerability scans and annual penetration testing by independent assessors.

Container Vulnerability Scanning

Production workloads run on AWS Fargate (serverless containers). There is no user-managed host OS. Vulnerability scanning for container workloads covers:

Scanning (every build)

Every container image build triggers a Trivy scan that produces:

  • Human-readable table in workflow logs
  • Machine-readable JSON artifact (audit evidence, timestamped per build)
  • Step summary with severity counts visible on the PR

This exceeds the SOC 2 quarterly scanning bar with every-build cadence.

Triage (weekly, exploitability-prioritized)

Raw scan findings are triaged by an AI agent using an exploitability-first framework:

Priority Criteria SLA
P0 CISA KEV-listed, OR RCE/auth bypass in a network-exposed package in our binary 7 days
P1 Critical/High in our binary, network-exposed, fix available 30 days (Critical), 60 days (High)
P2 High in our binary, not network-exposed, or DoS-only 120 days
Deferred Vendor-managed binaries, wrong platform, no fix available, local-access-only Out of remediation scope

Triage evaluates: CISA Known Exploited Vulnerabilities catalog, EPSS score (exploit prediction), reachability (is it in our binary or a third-party tool?), network exposure (does it handle HTTP/gRPC/TLS input?), and impact type (RCE > auth bypass > data exposure > DoS).

Remediation (weekly, automated)

A weekly workflow (aligned to Patch Tuesday) scans all production ECR images, triages findings, and applies safe dependency bumps automatically:

  • Scans: kernel/api, kernel/managed-auth-flow-simulator, kernel/cloudwatch-exporter, kernel/nvidia-license-server-exporter, kernel/otel-collector
  • Applies Go module bumps and base image patches
  • Validates each fix compiles before committing
  • Creates/updates an evergreen PR (security/container-remediation) for human review

Why Not AWS-Native Scanning?

AWS ECR/Inspector scanning remains enabled in AWS as a passive safety net but is not used as the primary vulnerability management control because:

  • No prioritization: Inspector reports 19,761 findings (411 unique CVEs inflated 48x by per-image-tag duplication) with no distinction between exploitable and theoretical risk
  • No ownership context: mixes our code, vendor binaries, and wrong-platform CVEs equally
  • 83% negligible risk: EPSS scoring shows 83% of unique CVEs have <0.1% probability of exploitation
  • No remediation: requires manual triage of thousands of findings; our workflow automates fix PRs

The Trivy + triage workflow surfaces the ~15 findings that actually matter (reachable, severe, known-exploited) and remediates them automatically within SLA.

Severity Classification and Remediation Timelines

Vulnerabilities are identified from four sources:

  1. Source code findings via Semgrep (SAST)
  2. Dependency findings via Socket (SCA)
  3. Container image findings via Trivy (OS packages + compiled dependencies)
  4. Infrastructure-level CVEs from providers (AWS, Leaseweb, Unikraft)

All findings are evaluated for severity. The following remediation timelines apply:

Severity Remediation Timeline
Critical 30 days
High 60 days
Medium 120 days
Low As needed
Informational As needed

Vulnerabilities that cannot be remediated within the standard timeline require a documented risk acceptance plan or planned remediation timeline.

Remediation Tracking

Source code vulnerabilities (Semgrep) are surfaced directly on the pull request as inline review comments with vulnerability explanations, CWE references, and recommended fixes. Developers are expected to resolve findings before merging as part of Kernel's Secure Code Training Program, which delivers continuous security training through automated tooling at the point of code authorship rather than periodic classroom-style sessions.

Dependency vulnerabilities (Socket) are tracked through the CI/CD pipeline rather than a separate manual register. Each weekly Socket scan produces structured JSON artifacts (scan report, triage decision, fix result) that are attached to the corresponding remediation PR. The PR history in version control serves as the audit trail — the scan identifies the vulnerability, the triage documents the rationale, and the merged PR evidences closure. For vulnerabilities that require manual intervention or cannot be auto-remediated, the triage agent classifies them as "defer" with documented justification. These are reviewed in the next scan cycle.

Container image vulnerabilities (Trivy) follow the same CI/CD-based tracking pattern. Weekly scans produce trivy-results.json (raw findings) and triage-result.json (prioritized actionable items). The remediation PR history evidences closure. Deferred findings (vendor-managed binaries, unfixed CVEs) are documented in the triage output with justification.

Infrastructure-level CVEs from providers are evaluated by the security team and remediated through patching or configuration changes following the timelines above.

External Threat Intelligence

External vulnerability sources monitored include:

  • CISA Known Exploited Vulnerabilities (KEV) catalog (prioritized in container triage)
  • EPSS (Exploit Prediction Scoring System) for probability-of-exploitation ranking
  • Socket's real-time supply chain threat feed
  • CVE databases via Socket's vulnerability matching and Trivy's advisory databases (NVD, Alpine SecDB, Go VulnDB)
  • Vendor security bulletins for infrastructure dependencies

Continuous Improvement

Vulnerability management scope and tooling are reviewed following security incidents and as part of the regular ISMS management review cycle. Scope expansions and tooling changes are tracked through the standard change management process.