CDP Control ID:35948520 Category: Secure Application Development Frequency: Biannually Owner: h.noerenberg Parent:#1
Requirement & Guidance
Secure Application Development Requirement: Complete ADM and CDP requirements for Web Application Security. Guidance: Confirm compliance through control validation questions. Additional information can be found on CDP website Secure Application Development
Sub-Validation Questions (Compliance-Status pro Frage markieren)
1. Segregate application servers and databases that contain confidential data from the web-DMZ by placing them in an internal network zone. Deny direct Internet access to databases. ✅PostgreSQL nur im Docker-Netz, keine Internet-Exposition (Compliance EAPPS 3.2.1.02/03).
2. For Accenture hosted applications, web-based applications must use federated authentication (ADFS) using WS -PRP or SAML 2.0 protocol. ⚪Interne App, nicht Accenture-hosted — Credentials + TOTP MFA statt ADFS/SAML.
3. Webservice and webservice definition language (wsdl) must enforce authentication via alternate endpoints using transport layer authentication mechanisms like windows authentication or basic authentication over TLS. ⚪Kein SOAP/WSDL — ausschließlich tRPC/REST.
4. To enable the web application front-end to connect to the database, create an active directory account (AD) for the application and configure this account to the database server using window integrated authentication. ⚪Keine Windows Active Directory-Integration — PostgreSQL-User mit ENV-Passwort.
Where use of AD account is not possible, the database connection credentials must be encrypted within a configuration file using 3DES or stronger encryption algorithms. The configuration file should be accessible only by authorized system administrators. ✅DB-Credentials in ENV (DATABASE_URL), nicht in Config-Files; .env in .gitignore.
5. Implement efficient input validation object into coding. ✅Zod-Schemas auf allen tRPC-Input-Pfaden.
Validate all inputs by the server-side code. Reject these characters:|, &, ; , $ , % , @ , ' , "" , ' , "" , <> , (), +, CR, LF, \ ✅Server-Validation via Zod; Prisma parameterized SQL verhindert Injection ohne Character-Rejection; DOMPurify sanitized Rich-Text.
For all input fields, forms, URLs and cookies in the application, only accept data from the end user or process that is expected. ✅Typed I/O via Zod auf tRPC + Cookies als HttpOnly (kein Client-Write).
Perform validation against session variables and parameters (e.g. URL variables, hidden fields etc.) ✅Session-State server-only (Auth.js), URL-Params via Next.js typed routes + Zod.
Ensure proper length limit on application parameters and URLs. Validate strings length, expected characters and pattern. Use regular expressions for validation as necessary. ✅Zod .min()/.max() auf relevanten Feldern (Compliance EAPPS 3.2.2.3.03).
Reject inputs with potentially malicious characters. Sanitize input to exclude context-changing symbols such as apostrophe, quotes, etc.; as well as script characters such as < > "" ' % ; ) ( & + JavaScript: img ✅DOMPurify auf Rich-Text; React escapt automatisch; Prisma parameterized SQL.
6. Encode HTML input to prevent the client’s web browser from interpreting every users supplied input as executable code. Do not store sensitive data in cookies. ✅React auto-escape in JSX; Sensitive Daten nicht in Cookies (HttpOnly Session-only).
7. Use libraries (e.g., anti-cross site scripting library such as .Net AntiXSS Library) to protect against security bugs during web application development. ✅DOMPurify auf User-Markdown/Rich-Text; React escapt alle String-Werte.
8. Webdav should be left disabled, by default, if there is no business functionality that requires it. ✅nginx Reverse Proxy, keine WebDAV-Konfiguration aktiviert.
9. Apply pre-requisites before using http methods DELETE, PUT, OPTIONS, PATCH HEAD. Refer to the Application Security Standard. Disable Trace method ✅tRPC nutzt nur GET/POST; andere Methoden nicht exposed (Compliance EAPPS 3.3.1.5.01).
10. Use cookies securely: ✅Parent — siehe Sub-Items.
Set the 'Secure' and 'Httponly' attributes in the cookie. ✅auth.config.ts setzt httpOnly: true + secure: production + sameSite: strict auf allen Cookies.
Do not use the domain parameter unless you need to scope the cookie to other applications outside the current application. ✅Kein domain Parameter gesetzt (Default = current host only).
Set the proper scope of the ‘path’ attribute. ✅path: '/' — passend für Single-App-Deployment.
*For example, if the application resides at /myapp/, then set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. ✅Informational — nicht anwendbar bei Root-Deployment.
Establish Hard limits to the lifetime of authentication cookies. Do not set cookie expiration time unless a persistent cookie is required. Setting the expiration time changes a cookie from session to persistent and should be avoided where possible. In cases were a persistent cookie is a business requirement, limit the lifespan of the cookie to the shortest duration that meets the required business benefit. ✅maxAge: 28800 (8h absolute), Session-basiert (kein persistent Cookie).
The cookie must be input validated; ✅HttpOnly verhindert Client-Write; Server-Side liest nur getypte JWT-Claims.
If the cookie must not be modified by the user then it must be made tamper resistant with an HMAC or similar mechanism to protect integrity of cookie content. ✅Auth.js JWT-Signature (HMAC-SHA256 mit AUTH_SECRET); Mismatch → Session ungültig.
If the user must not see the data in the cookie then it must also be encrypted. 🟡Session-Cookie ist signed (JWT), nicht encrypted. HttpOnly verhindert Einsicht via JS. Follow-up: Auth.js Encrypted-JWE evaluieren, falls sensitive Claims hinzukommen.
12. Do not use sensitive parameters in the URL such as user id, sessionid and other sensitive parameters. ✅Keine User-IDs/Session-IDs in URLs; tRPC nutzt POST-Body + Cookie-Session.
13. For Silverlight or Flash components, specify trusted domains in the client access policy or crossdomain policy configuration file. Do not leave domain = *. ⚪Kein Silverlight / Flash im Einsatz.
14. Pages containing static sensitive data must not be cached. ✅Cache-Control: no-store global + auf Auth-Seiten (Compliance EAPPS 3.3.1.7.01).
15. Avoid using URL redirects and forwards. If this cannot be avoided, verify that the parameter(s) are validated to contain only an allowed destination. ✅Auth.js callbackUrl wird gegen konfigurierte Base-URL validiert; keine Open-Redirects.
16. Use HTTP POST-requests instead of HTTP GET-requests since all parameters will be found in the URL for a GET-request. In general, avoid transmitting passwords in URL. Use secure mechanisms instead, such as digital certificates for example for sending passwords. ✅Login und Mutations über POST (tRPC + Auth.js); keine Credentials in Query-Strings.
17. Create an inventory of all input fields, including Get parameters/hidden fields, and have these included in test scripts for input validation tests. 🟡Zod-Schemas sind im Code (einheitliche Quelle), aber kein aggregiertes Test-Input-Inventory-Dokument. Follow-up: Skript, das alle Zod-Schemas extrahiert und als Security-Test-Matrix ausgibt.
18. Conduct a critical evaluation to the level of scrutiny over approval process of when/how applications are opened to the internet and confirm that the following are in place: 🟡Parent — siehe Sub-Items zu Change-Control-Prozess.
A structured change control review procedure to define two layers of review in advance of ports being opened to the internet. 🟡PR-Review + CI-Checks vorhanden (1 Layer). TODO: 2. Review-Layer für sicherheitskritische Änderungen (z. B. Auth, RBAC) dokumentieren.
Review procedure is documented in this control and communicated. 🟡docs/sdlc.md dokumentiert PR-Prozess. TODO: Explizite Security-Change-Review-Sektion ergänzen.
A ""final approver"" is identified. 🟡Repo-Owner ist de-facto Final-Approver (CODEOWNERS). TODO: Formal dokumentieren.
Changes and connections must be approved by qualified security teams. 🟡Kleines Team ohne dediziertes Security-Team. TODO: Bei Security-relevanten PRs externen Review einplanen (z. B. Accenture Security-Kontakt).
**CDP Control ID:** `35948520`
**Category:** Secure Application Development
**Frequency:** Biannually
**Owner:** h.noerenberg
**Parent:** #1
## Requirement & Guidance
Secure Application Development Requirement: Complete ADM and CDP requirements for Web Application Security. Guidance: Confirm compliance through control validation questions. Additional information can be found on CDP website Secure Application Development
## Sub-Validation Questions (Compliance-Status pro Frage markieren)
- [x] 1. Segregate application servers and databases that contain confidential data from the web-DMZ by placing them in an internal network zone. Deny direct Internet access to databases.
✅ *PostgreSQL nur im Docker-Netz, keine Internet-Exposition (Compliance EAPPS 3.2.1.02/03).*
- [x] 2. For Accenture hosted applications, web-based applications must use federated authentication (ADFS) using WS -PRP or SAML 2.0 protocol.
⚪ *Interne App, nicht Accenture-hosted — Credentials + TOTP MFA statt ADFS/SAML.*
- [x] 3. Webservice and webservice definition language (wsdl) must enforce authentication via alternate endpoints using transport layer authentication mechanisms like windows authentication or basic authentication over TLS.
⚪ *Kein SOAP/WSDL — ausschließlich tRPC/REST.*
- [x] 4. To enable the web application front-end to connect to the database, create an active directory account (AD) for the application and configure this account to the database server using window integrated authentication.
⚪ *Keine Windows Active Directory-Integration — PostgreSQL-User mit ENV-Passwort.*
- [x] Where use of AD account is not possible, the database connection credentials must be encrypted within a configuration file using 3DES or stronger encryption algorithms. The configuration file should be accessible only by authorized system administrators.
✅ *DB-Credentials in ENV (`DATABASE_URL`), nicht in Config-Files; `.env` in `.gitignore`.*
- [x] 5. Implement efficient input validation object into coding.
✅ *Zod-Schemas auf allen tRPC-Input-Pfaden.*
- [x] Validate all inputs by the server-side code. Reject these characters:|, &, ; , $ , % , @ , ' , "" , \' , \"" , <> , (), +, CR, LF, \
✅ *Server-Validation via Zod; Prisma parameterized SQL verhindert Injection ohne Character-Rejection; DOMPurify sanitized Rich-Text.*
- [x] For all input fields, forms, URLs and cookies in the application, only accept data from the end user or process that is expected.
✅ *Typed I/O via Zod auf tRPC + Cookies als HttpOnly (kein Client-Write).*
- [x] Perform validation against session variables and parameters (e.g. URL variables, hidden fields etc.)
✅ *Session-State server-only (Auth.js), URL-Params via Next.js typed routes + Zod.*
- [x] Ensure proper length limit on application parameters and URLs. Validate strings length, expected characters and pattern. Use regular expressions for validation as necessary.
✅ *Zod `.min()`/`.max()` auf relevanten Feldern (Compliance EAPPS 3.2.2.3.03).*
- [x] Reject inputs with potentially malicious characters. Sanitize input to exclude context-changing symbols such as apostrophe, quotes, etc.; as well as script characters such as < > "" ' % ; ) ( & + JavaScript: img
✅ *DOMPurify auf Rich-Text; React escapt automatisch; Prisma parameterized SQL.*
- [x] 6. Encode HTML input to prevent the client’s web browser from interpreting every users supplied input as executable code. Do not store sensitive data in cookies.
✅ *React auto-escape in JSX; Sensitive Daten nicht in Cookies (HttpOnly Session-only).*
- [x] 7. Use libraries (e.g., anti-cross site scripting library such as .Net AntiXSS Library) to protect against security bugs during web application development.
✅ *DOMPurify auf User-Markdown/Rich-Text; React escapt alle String-Werte.*
- [x] 8. Webdav should be left disabled, by default, if there is no business functionality that requires it.
✅ *nginx Reverse Proxy, keine WebDAV-Konfiguration aktiviert.*
- [x] 9. Apply pre-requisites before using http methods DELETE, PUT, OPTIONS, PATCH HEAD. Refer to the Application Security Standard. Disable Trace method
✅ *tRPC nutzt nur GET/POST; andere Methoden nicht exposed (Compliance EAPPS 3.3.1.5.01).*
- [x] 10. Use cookies securely:
✅ *Parent — siehe Sub-Items.*
- [x] Set the 'Secure' and 'Httponly' attributes in the cookie.
✅ *`auth.config.ts` setzt `httpOnly: true` + `secure: production` + `sameSite: strict` auf allen Cookies.*
- [x] Do not use the domain parameter unless you need to scope the cookie to other applications outside the current application.
✅ *Kein `domain` Parameter gesetzt (Default = current host only).*
- [x] Set the proper scope of the ‘path’ attribute.
✅ *`path: '/'` — passend für Single-App-Deployment.*
- [x] *For example, if the application resides at /myapp/, then set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp.
✅ *Informational — nicht anwendbar bei Root-Deployment.*
- [x] Establish Hard limits to the lifetime of authentication cookies. Do not set cookie expiration time unless a persistent cookie is required. Setting the expiration time changes a cookie from session to persistent and should be avoided where possible. In cases were a persistent cookie is a business requirement, limit the lifespan of the cookie to the shortest duration that meets the required business benefit.
✅ *`maxAge: 28800` (8h absolute), Session-basiert (kein persistent Cookie).*
- [x] 11. Secure Cookie Content:
✅ *Parent — siehe Sub-Items.*
- [x] The cookie must be input validated;
✅ *HttpOnly verhindert Client-Write; Server-Side liest nur getypte JWT-Claims.*
- [x] If the cookie must not be modified by the user then it must be made tamper resistant with an HMAC or similar mechanism to protect integrity of cookie content.
✅ *Auth.js JWT-Signature (HMAC-SHA256 mit `AUTH_SECRET`); Mismatch → Session ungültig.*
- [ ] If the user must not see the data in the cookie then it must also be encrypted.
🟡 *Session-Cookie ist signed (JWT), nicht encrypted. HttpOnly verhindert Einsicht via JS. **Follow-up:** Auth.js Encrypted-JWE evaluieren, falls sensitive Claims hinzukommen.*
- [x] 12. Do not use sensitive parameters in the URL such as user id, sessionid and other sensitive parameters.
✅ *Keine User-IDs/Session-IDs in URLs; tRPC nutzt POST-Body + Cookie-Session.*
- [x] 13. For Silverlight or Flash components, specify trusted domains in the client access policy or crossdomain policy configuration file. Do not leave domain = *.
⚪ *Kein Silverlight / Flash im Einsatz.*
- [x] 14. Pages containing static sensitive data must not be cached.
✅ *`Cache-Control: no-store` global + auf Auth-Seiten (Compliance EAPPS 3.3.1.7.01).*
- [x] 15. Avoid using URL redirects and forwards. If this cannot be avoided, verify that the parameter(s) are validated to contain only an allowed destination.
✅ *Auth.js `callbackUrl` wird gegen konfigurierte Base-URL validiert; keine Open-Redirects.*
- [x] 16. Use HTTP POST-requests instead of HTTP GET-requests since all parameters will be found in the URL for a GET-request. In general, avoid transmitting passwords in URL. Use secure mechanisms instead, such as digital certificates for example for sending passwords.
✅ *Login und Mutations über POST (tRPC + Auth.js); keine Credentials in Query-Strings.*
- [ ] 17. Create an inventory of all input fields, including Get parameters/hidden fields, and have these included in test scripts for input validation tests.
🟡 *Zod-Schemas sind im Code (einheitliche Quelle), aber **kein aggregiertes Test-Input-Inventory-Dokument**. Follow-up: Skript, das alle Zod-Schemas extrahiert und als Security-Test-Matrix ausgibt.*
- [ ] 18. Conduct a critical evaluation to the level of scrutiny over approval process of when/how applications are opened to the internet and confirm that the following are in place:
🟡 *Parent — siehe Sub-Items zu Change-Control-Prozess.*
- [ ] A structured change control review procedure to define two layers of review in advance of ports being opened to the internet.
🟡 *PR-Review + CI-Checks vorhanden (1 Layer). **TODO:** 2. Review-Layer für sicherheitskritische Änderungen (z. B. Auth, RBAC) dokumentieren.*
- [ ] Review procedure is documented in this control and communicated.
🟡 *`docs/sdlc.md` dokumentiert PR-Prozess. **TODO:** Explizite Security-Change-Review-Sektion ergänzen.*
- [ ] A ""final approver"" is identified.
🟡 *Repo-Owner ist de-facto Final-Approver (CODEOWNERS). **TODO:** Formal dokumentieren.*
- [ ] Changes and connections must be approved by qualified security teams.
🟡 *Kleines Team ohne dediziertes Security-Team. **TODO:** Bei Security-relevanten PRs externen Review einplanen (z. B. Accenture Security-Kontakt).*
Die 4 Partials in Q18.x hängen am Change-Management-Prozess — das läuft als Doku-TODO in Parent-Ticket #1 (Epic). Die 2 anderen Partials (Q11.3 Cookie-JWE, Q17 Input-Inventory) sind kleine Follow-ups.
Keine echten Gaps in den 36 Fragen. Ticket kann nach Abarbeitung von #31 (enthält die 4 Gaps für Password-Handling) geschlossen werden.
## Review-Ergebnis: 36 Sub-Validation-Questions
| Status | Anzahl |
|--------|--------|
| ✅ OK | 25 |
| 🟡 PARTIAL | 7 |
| 🔴 GAP | 0 |
| ⚪ N/A | 4 |
| **Total** | **36** |
Detail-Evidenz inline in jedem Check-Item vermerkt.
### 🟡 Partial-Items (Follow-ups)
1. **Cookie-Encryption** (Q11.3) — aktuell signed JWT. Bei sensitiver Claim-Erweiterung auf Encrypted-JWE (Auth.js option) evaluieren.
2. **Input-Inventory-Dokument** (Q17) — Zod-Schemas aggregieren als Test-Matrix.
3. **Security-Change-Review-Prozess** (Q18.x — 4 Sub-Items) — 2-Layer-Review + dokumentierten Final-Approver für sicherheitskritische PRs formalisieren.
### ⚪ N/A-Items
Q2 (ADFS/SAML), Q3 (WSDL), Q4 (AD account), Q13 (Silverlight/Flash) — Technologien werden in CapaKraken nicht verwendet.
### Verwandte Tickets
- Detail-Checkliste #31 (35 General Web-App Checks) — 4 Gaps + 4 Partials offen
- Detail-Checkliste #33 HTML5, #34 Node.js, #35 ReactJs → **alle geschlossen** ✅
- Detail-Checkliste #32 Cloud → geschlossen als N/A
### Empfehlung
Die 4 Partials in Q18.x hängen am Change-Management-Prozess — das läuft als Doku-TODO in Parent-Ticket #1 (Epic). Die 2 anderen Partials (Q11.3 Cookie-JWE, Q17 Input-Inventory) sind kleine Follow-ups.
Keine echten Gaps in den 36 Fragen. Ticket kann nach Abarbeitung von #31 (enthält die 4 Gaps für Password-Handling) geschlossen werden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
CDP Control ID:
35948520Category: Secure Application Development
Frequency: Biannually
Owner: h.noerenberg
Parent: #1
Requirement & Guidance
Secure Application Development Requirement: Complete ADM and CDP requirements for Web Application Security. Guidance: Confirm compliance through control validation questions. Additional information can be found on CDP website Secure Application Development
Sub-Validation Questions (Compliance-Status pro Frage markieren)
✅ PostgreSQL nur im Docker-Netz, keine Internet-Exposition (Compliance EAPPS 3.2.1.02/03).
⚪ Interne App, nicht Accenture-hosted — Credentials + TOTP MFA statt ADFS/SAML.
⚪ Kein SOAP/WSDL — ausschließlich tRPC/REST.
⚪ Keine Windows Active Directory-Integration — PostgreSQL-User mit ENV-Passwort.
✅ DB-Credentials in ENV (
DATABASE_URL), nicht in Config-Files;.envin.gitignore.✅ Zod-Schemas auf allen tRPC-Input-Pfaden.
✅ Server-Validation via Zod; Prisma parameterized SQL verhindert Injection ohne Character-Rejection; DOMPurify sanitized Rich-Text.
✅ Typed I/O via Zod auf tRPC + Cookies als HttpOnly (kein Client-Write).
✅ Session-State server-only (Auth.js), URL-Params via Next.js typed routes + Zod.
✅ Zod
.min()/.max()auf relevanten Feldern (Compliance EAPPS 3.2.2.3.03).✅ DOMPurify auf Rich-Text; React escapt automatisch; Prisma parameterized SQL.
✅ React auto-escape in JSX; Sensitive Daten nicht in Cookies (HttpOnly Session-only).
✅ DOMPurify auf User-Markdown/Rich-Text; React escapt alle String-Werte.
✅ nginx Reverse Proxy, keine WebDAV-Konfiguration aktiviert.
✅ tRPC nutzt nur GET/POST; andere Methoden nicht exposed (Compliance EAPPS 3.3.1.5.01).
✅ Parent — siehe Sub-Items.
✅
auth.config.tssetzthttpOnly: true+secure: production+sameSite: strictauf allen Cookies.✅ Kein
domainParameter gesetzt (Default = current host only).✅
path: '/'— passend für Single-App-Deployment.✅ Informational — nicht anwendbar bei Root-Deployment.
✅
maxAge: 28800(8h absolute), Session-basiert (kein persistent Cookie).✅ Parent — siehe Sub-Items.
✅ HttpOnly verhindert Client-Write; Server-Side liest nur getypte JWT-Claims.
✅ Auth.js JWT-Signature (HMAC-SHA256 mit
AUTH_SECRET); Mismatch → Session ungültig.🟡 Session-Cookie ist signed (JWT), nicht encrypted. HttpOnly verhindert Einsicht via JS. Follow-up: Auth.js Encrypted-JWE evaluieren, falls sensitive Claims hinzukommen.
✅ Keine User-IDs/Session-IDs in URLs; tRPC nutzt POST-Body + Cookie-Session.
⚪ Kein Silverlight / Flash im Einsatz.
✅
Cache-Control: no-storeglobal + auf Auth-Seiten (Compliance EAPPS 3.3.1.7.01).✅ Auth.js
callbackUrlwird gegen konfigurierte Base-URL validiert; keine Open-Redirects.✅ Login und Mutations über POST (tRPC + Auth.js); keine Credentials in Query-Strings.
🟡 Zod-Schemas sind im Code (einheitliche Quelle), aber kein aggregiertes Test-Input-Inventory-Dokument. Follow-up: Skript, das alle Zod-Schemas extrahiert und als Security-Test-Matrix ausgibt.
🟡 Parent — siehe Sub-Items zu Change-Control-Prozess.
🟡 PR-Review + CI-Checks vorhanden (1 Layer). TODO: 2. Review-Layer für sicherheitskritische Änderungen (z. B. Auth, RBAC) dokumentieren.
🟡
docs/sdlc.mddokumentiert PR-Prozess. TODO: Explizite Security-Change-Review-Sektion ergänzen.🟡 Repo-Owner ist de-facto Final-Approver (CODEOWNERS). TODO: Formal dokumentieren.
🟡 Kleines Team ohne dediziertes Security-Team. TODO: Bei Security-relevanten PRs externen Review einplanen (z. B. Accenture Security-Kontakt).
CapaKraken Action Plan — 35948520 Web Application Security
Scope: Kompletter ADM/CDP-Katalog für Web-Apps (36 Sub-Validation-Fragen siehe Checkbox-Liste unten).
Aktueller Stand (Auszug aus
docs/acn-security-compliance-status.md, 3.3.1 Web Standards — 20+ Controls OK):Mapping der 36 Sub-Validation-Fragen auf vorhandene Nachweise:
docker-compose.prod.yml(3.2.4.01 OK)Todos:
samples/CDP/attestations/webapp.pdfCapaKraken Compliance-Status
EAPPS-Mapping:
3.3.1.x (Web Application Standard)Status: 🟡 PARTIAL / TODO — konkrete Schritte unten
Zusammenfassung
Web-App-Sicherheit ist überwiegend umgesetzt. Die 36 Sub-Validation-Questions in diesem Ticket + 5 Detail-Checklisten decken den vollen Scope ab.
Aktuelle Evidenz
apps/web/next.config.tspackages/api/src/middleware/rate-limit.tsOffene Aufgaben
Ticket bleibt offen bis alle Aufgaben abgehakt sind.
Review-Ergebnis: 36 Sub-Validation-Questions
Detail-Evidenz inline in jedem Check-Item vermerkt.
🟡 Partial-Items (Follow-ups)
⚪ N/A-Items
Q2 (ADFS/SAML), Q3 (WSDL), Q4 (AD account), Q13 (Silverlight/Flash) — Technologien werden in CapaKraken nicht verwendet.
Verwandte Tickets
Empfehlung
Die 4 Partials in Q18.x hängen am Change-Management-Prozess — das läuft als Doku-TODO in Parent-Ticket #1 (Epic). Die 2 anderen Partials (Q11.3 Cookie-JWE, Q17 Input-Inventory) sind kleine Follow-ups.
Keine echten Gaps in den 36 Fragen. Ticket kann nach Abarbeitung von #31 (enthält die 4 Gaps für Password-Handling) geschlossen werden.