Hartmut/CapaKraken
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

CDP 35948473: Implement Patching Process (app/AI) #6

New Issue
Open
opened 2026-04-16 08:16:45 +02:00 by Hartmut · 3 comments
Hartmut commented 2026-04-16 08:16:45 +02:00
Owner
Copy Link
Copy Source

CDP Control ID: 35948473
Category: Patching
Frequency: Biannually
Owner: h.noerenberg
Parent: #1

Requirement & Guidance

Patching Requirement: Patch vulnerabilities. Develop, document and implement a patching schedule and timeframe in accordance with your terms and conditions of your contract, and seek written client sign off of schedules. Documenting Engagement Level Procedures is requiredAttachment(s) RequiredGuidance: Install security patches as per the agreed patching schedule. If you have specific timeframes in your contract, you must follow them and you may use the signed contract as client sign-off, otherwise you must obtain written client approval for your current patching schedule, timeframe and process that takes into account the specific client circumstances and SANS patching standards, including but not limited to: the current state of client infrastructure, technology platforms involved, availability of automated tools, number of infrastructure devices being managed, regular vendor patching release timelines, etcAttach to this control the patching schedule and timeframe and the process that has been formally signed off by the client. Additional information regarding the patching process can be set in the engagement level procedure.For application development work: Seek contractual requirements to determine who is responsible for patching the backend, comply with this requirement when it's in scope for Accenture (e.g: Applications coded over pre-packed software)Patch ManagementSecurity Remediation and Patch Management Standard

**CDP Control ID:** `35948473` **Category:** Patching **Frequency:** Biannually **Owner:** h.noerenberg **Parent:** #1 ## Requirement & Guidance Patching Requirement: Patch vulnerabilities. Develop, document and implement a patching schedule and timeframe in accordance with your terms and conditions of your contract, and seek written client sign off of schedules. Documenting Engagement Level Procedures is requiredAttachment(s) RequiredGuidance: Install security patches as per the agreed patching schedule. If you have specific timeframes in your contract, you must follow them and you may use the signed contract as client sign-off, otherwise you must obtain written client approval for your current patching schedule, timeframe and process that takes into account the specific client circumstances and SANS patching standards, including but not limited to: the current state of client infrastructure, technology platforms involved, availability of automated tools, number of infrastructure devices being managed, regular vendor patching release timelines, etcAttach to this control the patching schedule and timeframe and the process that has been formally signed off by the client. Additional information regarding the patching process can be set in the engagement level procedure.For application development work: Seek contractual requirements to determine who is responsible for patching the backend, comply with this requirement when it's in scope for Accenture (e.g: Applications coded over pre-packed software)Patch ManagementSecurity Remediation and Patch Management Standard
Hartmut added the cdpsecurity labels 2026-04-16 08:16:45 +02:00
Hartmut commented 2026-04-16 08:32:37 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Action Plan — 35948473 Patching Process

Scope: Security-Patches für alle Dependencies + OS / Container / Node / Postgres.

Aktueller Stand:

  • docs/acn-security-compliance-status.md 3.2.2.7.01 PARTIAL — Dependabot + npm audit in CI
  • Weekly /api/cron/security-audit
  • Container: node:20-bookworm-slim (Dockerfile.prod)

Todos:

  • Patching-Schedule formalisieren (z.B. Critical ≤ 7 Tage, High ≤ 30 Tage, Medium ≤ 90 Tage)
  • Prozess dokumentieren: docs/patching-policy.md (neu) mit SLA + Renovate/Dependabot-Konfig
  • Postgres/Redis Docker-Image regelmäßig prüfen (aktuell postgres:16 / redis:7)
  • CI-Gate: pnpm audit --audit-level=high fails the build
  • Evidence: Signiertes Dokument des Schedules (Client-Sign-off)

Dateien:

  • Dockerfile.prod, .github/workflows/ci.yml, packages/api/src/router/cron.ts (security-audit)
### CapaKraken Action Plan — 35948473 Patching Process **Scope:** Security-Patches für alle Dependencies + OS / Container / Node / Postgres. **Aktueller Stand:** - `docs/acn-security-compliance-status.md` 3.2.2.7.01 **PARTIAL** — Dependabot + npm audit in CI - Weekly `/api/cron/security-audit` - Container: `node:20-bookworm-slim` (Dockerfile.prod) **Todos:** - [ ] Patching-Schedule formalisieren (z.B. Critical ≤ 7 Tage, High ≤ 30 Tage, Medium ≤ 90 Tage) - [ ] Prozess dokumentieren: `docs/patching-policy.md` (neu) mit SLA + Renovate/Dependabot-Konfig - [ ] Postgres/Redis Docker-Image regelmäßig prüfen (aktuell `postgres:16` / `redis:7`) - [ ] CI-Gate: `pnpm audit --audit-level=high` fails the build - [ ] Evidence: Signiertes Dokument des Schedules (Client-Sign-off) **Dateien:** - `Dockerfile.prod`, `.github/workflows/ci.yml`, `packages/api/src/router/cron.ts` (security-audit)
Hartmut commented 2026-04-16 10:02:28 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Compliance-Status

EAPPS-Mapping: Patch Management Standard
Status: 🟡 PARTIAL / TODO — konkrete Schritte unten

Zusammenfassung

Dependabot + pnpm audit in CI sind aktiv. Formaler Patch-SLA fehlt noch.

Aktuelle Evidenz

Offene Aufgaben

  • Patch-SLA definieren: Critical 48h / High 7d / Medium 30d (siehe docs/acn-standards-applicability.md #8).
  • Dokumentation ergänzen: docs/patch-management.md mit Rolle, Trigger, Eskalationspfad.
  • nginx-/Docker-Base-Image Updates monatlich einplanen (Infra-TODO).

Ticket bleibt offen bis alle Aufgaben abgehakt sind.

## CapaKraken Compliance-Status **EAPPS-Mapping:** `Patch Management Standard` **Status:** 🟡 **PARTIAL / TODO** — konkrete Schritte unten ### Zusammenfassung Dependabot + `pnpm audit` in CI sind aktiv. Formaler **Patch-SLA** fehlt noch. ### Aktuelle Evidenz - Nightly Security Audit Workflow — [`.github/workflows/nightly-security.yml`](../blob/main/.github/workflows/nightly-security.yml) - `pnpm audit --audit-level=high` in CI (blockiert bei High/Critical) - Dependabot-Config — [`.github/dependabot.yml`](../blob/main/.github/dependabot.yml) - Compliance-Doc: Patch Management Standard = **TEILWEISE** ### Offene Aufgaben - [ ] Patch-SLA definieren: Critical 48h / High 7d / Medium 30d (siehe `docs/acn-standards-applicability.md` #8). - [ ] Dokumentation ergänzen: `docs/patch-management.md` mit Rolle, Trigger, Eskalationspfad. - [ ] nginx-/Docker-Base-Image Updates monatlich einplanen (Infra-TODO). --- *Ticket bleibt offen bis alle Aufgaben abgehakt sind.*
Hartmut commented 2026-04-16 10:20:06 +02:00
Author
Owner
Copy Link
Copy Source

Action Plan

CDP-Requirement: Patching-Schedule dokumentieren + durchsetzen, mit Client-Sign-off (hier: intern).

Status

  • Dependency Audit läuft nightly: .github/workflows/nightly-security.yml (pnpm audit --audit-level=high, Cron 17 2 * * *).
  • Dependabot konfiguriert: .github/dependabot.yml.
  • Base-Image-Updates erfolgen über Alpine/Node-Upstream, aber kein dokumentierter SLA.

TODOs — Patching-Policy dokumentieren

Neu anlegen: docs/patching-policy.md mit:

Severity Remediation-SLA
Critical (CVSS ≥ 9.0) 48 h
High (CVSS 7.0–8.9) 7 Tage
Medium (CVSS 4.0–6.9) 30 Tage
Low (CVSS < 4.0) nächster Release-Cycle

Coverage:

  • npm-Dependencies (Dependabot + pnpm audit)
  • Docker-Base-Images (monatlich via Renovate oder manuell docker build --pull)
  • PostgreSQL + Redis (QNAP-Host, via docker compose pull)
  • OS-Level (QNAP, Accenture-Owner)

Client-Sign-off: Intern — Hartmut als Projekt-Owner dokumentiert in Policy-File.

Frequency: Biannual review.

## Action Plan **CDP-Requirement:** Patching-Schedule dokumentieren + durchsetzen, mit Client-Sign-off (hier: intern). ### Status - **Dependency Audit** läuft nightly: `.github/workflows/nightly-security.yml` (`pnpm audit --audit-level=high`, Cron `17 2 * * *`). - **Dependabot** konfiguriert: `.github/dependabot.yml`. - **Base-Image-Updates** erfolgen über Alpine/Node-Upstream, aber kein dokumentierter SLA. ### TODOs — Patching-Policy dokumentieren Neu anlegen: `docs/patching-policy.md` mit: | Severity | Remediation-SLA | |----------|-----------------| | Critical (CVSS ≥ 9.0) | 48 h | | High (CVSS 7.0–8.9) | 7 Tage | | Medium (CVSS 4.0–6.9) | 30 Tage | | Low (CVSS < 4.0) | nächster Release-Cycle | **Coverage:** - npm-Dependencies (Dependabot + pnpm audit) - Docker-Base-Images (monatlich via Renovate oder manuell `docker build --pull`) - PostgreSQL + Redis (QNAP-Host, via `docker compose pull`) - OS-Level (QNAP, Accenture-Owner) **Client-Sign-off:** Intern — Hartmut als Projekt-Owner dokumentiert in Policy-File. **Frequency:** Biannual review.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
cdp
CDP (Client Data Protection) compliance
 epic
Parent/umbrella ticket
 not-applicable
Control does not apply to CapaKraken scope
 security
Security / compliance work
No Label cdp security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Hartmut
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Hartmut/CapaKraken#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?