@ghostbyte/agent-docs-kit 0.0.0-stage → 4.0.2

package/skills/manage-project-quality/references/security-03-database-backend.md

@@ -0,0 +1,46 @@
+# Database & Backend
+
+# Phase 3: Database & Backend Layer
+
+**When to run this:** While building/reviewing server-side business logic and the data access layer.
+
+**Goal of this pass:** Confirm the backend enforces authorization and business rules itself, and that the data layer doesn't quietly reintroduce injection or over-fetching risk.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 12
+
+---
+
+# What to Check — Phase 3: Database & Backend Layer
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `05_Backend_Handling/01_business_logic_validation.md` | Business Logic Validation | High | Attempt to call the 'ship order' step of a checkout flow while skipping the 'payment' step and confirm the server rejects the out-of-order transition. |
+| 2 | `05_Backend_Handling/02_file_upload_handling.md` | File Upload Handling | Critical | Upload a file with a .jpg extension but executable/script magic bytes inside, and confirm the server validates content type by inspecting bytes, not just the extension. |
+| 3 | `05_Backend_Handling/03_orm_database_security.md` | ORM & Database Layer Security | High | Search the codebase for any raw-query escape hatches in the ORM and confirm every one uses parameter binding, not string concatenation. |
+| 4 | `05_Backend_Handling/04_background_job_queue_security.md` | Background Job & Queue Security | Medium | Submit a queued job payload with malformed/malicious data directly (bypassing the API layer) and confirm the worker validates it the same way the API would. |
+| 5 | `05_Backend_Handling/05_error_handling_stack_traces.md` | Error Handling & Stack Trace Exposure | Medium | Send a malformed request (bad JSON, wrong content-type) to a production endpoint and confirm the response is a generic error, not a stack trace or file path. |
+| 6 | `03_Access_Control_Session_Auth/02_backend_access_control.md` | Backend Access Control | Critical | Using User A's valid session, request User B's resource ID directly and confirm a 403, not the data. |
+| 7 | `03_Access_Control_Session_Auth/05_rbac_abac.md` | RBAC / ABAC Models (added) | Medium | Pick a long-lived test account and diff its current granted permissions against what its role should have today, looking for accumulated excess access. |
+| 8 | `06_Data_Protection_Secrets/01_encryption_at_rest.md` | Encryption at Rest | High | Confirm via cloud console/CLI that the database volume, backups, and object storage all show encryption-at-rest enabled, not just the primary disk. |
+| 9 | `06_Data_Protection_Secrets/02_encryption_in_transit.md` | Encryption in Transit | High | Attempt to connect to the database and any internal service-to-service endpoint over plaintext and confirm the connection is refused, TLS-only. |
+| 10 | `06_Data_Protection_Secrets/03_pii_data_classification.md` | PII & Data Classification | Medium | Pull a sample data export/report and check whether it exposes any field classified as higher-sensitivity than the export's intended audience. |
+| 11 | `06_Data_Protection_Secrets/04_key_management.md` | Key Management (KMS) | Critical | Confirm encryption keys live in a KMS/HSM (not a config file or env var) and walk through the documented key-revocation procedure end to end. |
+| 12 | `06_Data_Protection_Secrets/05_tls_certificate_management.md` | TLS Certificate Management | High | Run an SSL/TLS scan (e.g. against the Mozilla Observatory or testssl.sh) on each public endpoint and confirm TLS 1.2+ only, no weak ciphers, valid expiry. |

package/skills/manage-project-quality/references/security-04-api-layer.md

@@ -0,0 +1,51 @@
+# API Layer
+
+# Phase 4: API Layer
+
+**When to run this:** While building/reviewing any endpoint that's called over the network — internal or external.
+
+**Goal of this pass:** Confirm authentication, authorization, and abuse controls are enforced on every endpoint, not assumed from the caller.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 17
+
+---
+
+# What to Check — Phase 4: API Layer
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `01_API_Security/01_rate_limiting.md` | Rate Limiting | High | Fire 200 requests/sec at a login endpoint from one IP and confirm 429s with Retry-After start well before account lockout thresholds are reachable. |
+| 2 | `01_API_Security/02_api_keys.md` | API Keys | High | Grep the built client bundle and mobile binary for hardcoded key patterns, then rotate one key and confirm the old value is rejected within minutes. |
+| 3 | `01_API_Security/03_oauth2.md` | OAuth 2.0 | Critical | Attempt the authorization flow with a modified redirect_uri (e.g. attacker.com) and confirm the server rejects it rather than redirecting. |
+| 4 | `01_API_Security/04_jwt_validation.md` | JWT Validation | Critical | Submit a token with 'alg' changed to 'none' and an empty signature; confirm the API rejects it instead of trusting the claims. |
+| 5 | `01_API_Security/05_input_sanitation.md` | Input Sanitation | High | Submit oversized, wrong-type, and boundary values (e.g. negative quantity, 10k-char string) on every field and confirm consistent server-side rejection. |
+| 6 | `01_API_Security/06_cors_policy.md` | CORS Policy | High | Send a fetch with Origin: https://evil.com and credentials:'include'; confirm the Access-Control-Allow-Origin response does not reflect evil.com. |
+| 7 | `01_API_Security/07_mtls.md` | Mutual TLS (mTLS) | Medium | Present an expired or self-signed client certificate to the mTLS endpoint and confirm the connection is rejected, not silently accepted. |
+| 8 | `01_API_Security/08_request_signing.md` | Request Signing | Medium | Replay a previously captured signed request unmodified after its timestamp window; confirm it is rejected as a replay. |
+| 9 | `01_API_Security/09_ip_allowlisting.md` | IP Allowlisting | Medium | Send a request from a disallowed IP with a spoofed X-Forwarded-For header set to an allowlisted IP and confirm it is still blocked. |
+| 10 | `01_API_Security/10_security_headers.md` | Security Headers (added) | Medium | Run curl -I against each public endpoint and confirm CSP, HSTS, X-Content-Type-Options, and frame-ancestors are all present. |
+| 11 | `03_Access_Control_Session_Auth/07_session_management.md` | Session Management (added) | High | Capture the session cookie before and after login and confirm the session ID value actually changes (regenerates) rather than persisting. |
+| 12 | `03_Access_Control_Session_Auth/08_mfa.md` | Multi-Factor Authentication (added) | Critical | Attempt the password-reset flow and confirm it cannot be used to fully log in while skipping the MFA step. |
+| 13 | `03_Access_Control_Session_Auth/09_session_store_caching.md` | Session Store Security (Redis/Memcached) | High | Attempt to connect directly to the Redis/Memcached session store from outside the app network and confirm authentication is required and it isn't publicly reachable. |
+| 14 | `03_Access_Control_Session_Auth/10_remember_me_persistent_login.md` | "Remember Me" & Persistent Login Tokens | High | Use a captured remember-me token once, then reuse the same (now-rotated-out) token value again and confirm it triggers revocation/alerting rather than silent success. |
+| 15 | `03_Access_Control_Session_Auth/06_forced_reauth_sensitive_actions.md` | Forced Re-Authentication for Sensitive Actions | High | From an already-logged-in session, attempt to change the account email/password without re-entering credentials and confirm it's blocked. |
+| 16 | `03_Access_Control_Session_Auth/03_cache_invalidation_on_auth_change.md` | Cache Invalidation on Auth/Privilege Change | High | Downgrade a test user's role, then immediately retry a privileged action with their still-active session and confirm it's now denied. |
+| 17 | `03_Access_Control_Session_Auth/04_device_trust_fingerprinting.md` | Device Trust & Fingerprinting | Medium | Replay a captured device-trust identifier from a different browser/device and confirm it does not skip MFA. |

package/skills/manage-project-quality/references/security-05-frontend-ui.md

@@ -0,0 +1,44 @@
+# Frontend & UI
+
+# Phase 5: Frontend / UI Layer
+
+**When to run this:** While building/reviewing client-side code — components, routing, state, build config.
+
+**Goal of this pass:** Confirm the UI never becomes the actual security boundary, and that framework-specific escape hatches don't reopen XSS.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 10
+
+---
+
+# What to Check — Phase 5: Frontend / UI Layer
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `04_UI_Framework_Security/01_framework_xss_sinks.md` | Framework-Specific XSS Sinks | High | grep -r 'dangerouslySetInnerHTML\\|v-html\\|innerHTML' across the frontend source and confirm every hit sanitizes input (e.g. via DOMPurify) first. |
+| 2 | `04_UI_Framework_Security/02_client_side_routing_auth.md` | Client-Side Routing & Route Guards | High | Call the data-fetching API endpoint behind a guarded route directly via curl/Postman without going through the SPA route guard, and confirm it's still blocked server-side. |
+| 3 | `04_UI_Framework_Security/03_state_management_leaks.md` | State Management Data Leaks | Medium | Open Redux/Vuex devtools against the production build and search global state for tokens, secrets, or full user PII objects. |
+| 4 | `04_UI_Framework_Security/04_build_config_exposure.md` | Build Config & Source Map Exposure | Medium | Fetch every .map file path from the production bundle directly and confirm 404s; grep the deployed JS bundle for API key-shaped strings. |
+| 5 | `04_UI_Framework_Security/05_csp_framework_compatibility.md` | CSP Compatibility with UI Frameworks | Medium | Check the deployed CSP header for 'unsafe-inline'; if present, test whether nonces/hashes can replace it without breaking the framework's inline scripts. |
+| 6 | `02_Web_Vulnerabilities/02_xss.md` | Cross-Site Scripting (XSS) | Critical | Submit <script>alert(document.domain)</script> and common encoded variants into every reflected, stored, and DOM-rendered field. |
+| 7 | `02_Web_Vulnerabilities/03_csrf.md` | Cross-Site Request Forgery (CSRF) | High | Build an auto-submitting HTML form on a separate origin targeting a state-changing endpoint using the victim's real session cookie, and confirm it is rejected. |
+| 8 | `02_Web_Vulnerabilities/06_clickjacking.md` | Clickjacking | Medium | Embed the target page in an <iframe> on a test page and confirm the browser refuses to render it (frame-ancestors/X-Frame-Options enforced). |
+| 9 | `02_Web_Vulnerabilities/07_open_redirect.md` | Open Redirect | Medium | Set the redirect parameter to an external domain (and bypass tricks like //evil.com or trusted.com.evil.com) and confirm the app refuses or rewrites it. |
+| 10 | `03_Access_Control_Session_Auth/01_ui_ux_access_control.md` | UI/UX-Level Access Control | Medium | Call the underlying API directly with a lower-privilege token, bypassing the UI that hides the button, and confirm the server still denies it. |

package/skills/manage-project-quality/references/security-06-application-security-testing.md

@@ -0,0 +1,48 @@
+# Application Security Testing
+
+# Phase 6: Application Security Testing (QA / Staging)
+
+**When to run this:** A dedicated security test pass in QA/staging before release — after features are functionally complete.
+
+**Goal of this pass:** Run the deeper, often-automatable vulnerability classes end to end against a real running build, and confirm coverage against recognized baselines (OWASP Top 10 / API Top 10).
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 14
+
+---
+
+# What to Check — Phase 6: Application Security Testing (QA / Staging)
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `02_Web_Vulnerabilities/01_sql_injection.md` | SQL Injection | Critical | Submit a single quote and boolean/time-based payloads (e.g. ' OR '1'='1, SLEEP(5)) in every input field and inspect responses/timing for injection signals. |
+| 2 | `02_Web_Vulnerabilities/04_ssrf.md` | Server-Side Request Forgery (SSRF) | Critical | Submit a URL-fetching parameter pointing at http://169.254.169.254/latest/meta-data/ and confirm the server does not fetch it. |
+| 3 | `02_Web_Vulnerabilities/05_idor.md` | Insecure Direct Object Reference (IDOR) | Critical | Log in as User A, capture an object ID from a request, then repeat the identical request as User B and confirm access is denied. |
+| 4 | `02_Web_Vulnerabilities/08_path_traversal.md` | Path Traversal | Critical | Submit ../../../../etc/passwd and URL-encoded/unicode variants in any file-path parameter and confirm access stays within the intended directory. |
+| 5 | `02_Web_Vulnerabilities/09_insecure_deserialization.md` | Insecure Deserialization | Critical | Tamper with a serialized object/cookie (flip a field, change a type) and submit it; confirm the server rejects it rather than deserializing blindly. |
+| 6 | `02_Web_Vulnerabilities/10_broken_authentication.md` | Broken Authentication | Critical | Run a scripted credential-stuffing pass against the login endpoint using a small known-breached credential list and confirm lockout/rate-limit triggers. |
+| 7 | `02_Web_Vulnerabilities/11_ssti.md` | Server-Side Template Injection (SSTI) (added) | Critical | Submit template syntax such as {{7*7}} or ${7*7} into user-controlled text fields and check whether the output evaluates to 49. |
+| 8 | `02_Web_Vulnerabilities/12_xxe.md` | XML External Entity (XXE) Injection (added) | Critical | Submit an XML payload with a DOCTYPE defining an external entity pointing to a local file and confirm the parser refuses to resolve it. |
+| 9 | `02_Web_Vulnerabilities/13_mass_assignment.md` | Mass Assignment (added) | High | Add an unexpected field such as "isAdmin": true to a normal profile-update request body and confirm it is ignored, not applied. |
+| 10 | `02_Web_Vulnerabilities/14_race_conditions.md` | Race Conditions (added) | High | Fire 20 identical concurrent requests at a discount/redeem endpoint and confirm only one succeeds, not all twenty. |
+| 11 | `02_Web_Vulnerabilities/15_request_smuggling.md` | HTTP Request Smuggling (added) | Critical | Send a request with conflicting Content-Length and Transfer-Encoding headers through the full proxy chain and observe whether front-end/back-end parsing disagrees. |
+| 12 | `19_Security_Checklists/01_owasp_top10_checklist.md` | OWASP Top 10 Checklist | Reference | Use this as a coverage tracker after running folders 01-18 — check off each OWASP Top 10 category once its dedicated checklist items have been executed. |
+| 13 | `19_Security_Checklists/02_api_security_checklist.md` | OWASP API Security Top 10 Checklist | Reference | Use this as a coverage tracker after running folder 01 (API_Security) and relevant items from 02/03 — confirm each OWASP API Top 10 category is addressed. |
+| 14 | `19_Security_Checklists/03_pentest_checklist.md` | Penetration Test Checklist (added) | Reference | Use this as the top-level structure for any full engagement: confirm scope/RoE are signed before folder-by-folder testing begins. |

package/skills/manage-project-quality/references/security-07-cicd-release-engineering.md

@@ -0,0 +1,41 @@
+# CI/CD & Release Engineering
+
+# Phase 7: CI/CD & Release Engineering
+
+**When to run this:** When setting up or auditing the build/release pipeline itself.
+
+**Goal of this pass:** Confirm the pipeline that ships your code is at least as trustworthy as the code it ships.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 7
+
+---
+
+# What to Check — Phase 7: CI/CD & Release Engineering
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `08_Release_Engineering_Version_Control/03_branch_protection_signed_commits.md` | Branch Protection & Signed Commits | High | Attempt to push directly to main without a PR/review and confirm the push is rejected by branch protection. |
+| 2 | `08_Release_Engineering_Version_Control/04_artifact_integrity_provenance.md` | Build Artifact Integrity & Provenance | High | Verify the checksum/signature of the last deployed artifact against the one produced by the build pipeline and confirm they match. |
+| 3 | `08_Release_Engineering_Version_Control/05_cicd_security.md` | CI/CD Pipeline Security | Critical | Check the CI/CD config for plaintext secrets and confirm all credentials are pulled from a vault/secrets manager instead. |
+| 4 | `08_Release_Engineering_Version_Control/06_code_review_checklist.md` | Security Code Review Checklist | Medium | Pull the last 5 merged PRs and confirm each one's diff was checked against input validation, authZ, and no-secrets-in-diff criteria. |
+| 5 | `08_Release_Engineering_Version_Control/07_changelog_release_notes.md` | Changelog & Release Notes | Low | Confirm the most recent release has a changelog entry, including any security-relevant fix noted without disclosing exploit specifics. |
+| 6 | `08_Release_Engineering_Version_Control/08_deprecated_version_sunset_policy.md` | Deprecated Version & Sunset Policy | Medium | Call a documented end-of-life API version and confirm it's actually disabled, not silently still functional. |
+| 7 | `14_Incident_Response_Security_Ops/05_sast_dast_tooling_integration.md` | SAST/DAST Tooling Integration | Medium | Confirm the last 10 PRs all triggered a SAST scan, and that staging received a DAST scan before its most recent production release. |

package/skills/manage-project-quality/references/security-08-cloud-infrastructure.md

@@ -0,0 +1,45 @@
+# Cloud Infrastructure
+
+# Phase 8: Cloud Infrastructure & Deployment
+
+**When to run this:** Before first deploying to a new environment, and periodically thereafter for drift.
+
+**Goal of this pass:** Confirm IAM, network, storage, and container configuration follow least privilege and don't expose more than intended.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 11
+
+---
+
+# What to Check — Phase 8: Cloud Infrastructure & Deployment
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `07_Cloud_Infra_Deployment/01_environment_separation.md` | Environment Separation | Critical | Attempt to reach the staging environment unauthenticated from the public internet and confirm it requires auth or is not publicly indexable. |
+| 2 | `07_Cloud_Infra_Deployment/02_iam_policy_review.md` | Cloud IAM Policy Review | Critical | Export all IAM policies and grep for '*:*' or overly broad wildcard actions/resources; confirm each is justified or scoped down. |
+| 3 | `07_Cloud_Infra_Deployment/03_blue_green_canary_rollback.md` | Blue-Green / Canary Deployment & Rollback | High | Trigger a rollback in staging and time how long it takes to reach the previous stable version; compare against your defined rollback-time target. |
+| 4 | `07_Cloud_Infra_Deployment/04_container_k8s_security.md` | Container Orchestration (Kubernetes) Security | High | Run 'kubectl auth can-i --list' as a low-privilege service account and confirm it cannot perform cluster-admin-level actions. |
+| 5 | `07_Cloud_Infra_Deployment/05_cloud_storage_misconfig.md` | Cloud Storage Misconfiguration | Critical | List every storage bucket/container and confirm none allow anonymous public read/write except explicitly intended public assets. |
+| 6 | `07_Cloud_Infra_Deployment/06_infra_as_code_scanning.md` | Infrastructure-as-Code Scanning | High | Run an IaC scanner (e.g. tfsec/Checkov) against the current Terraform/CloudFormation config and confirm zero unresolved high/critical findings. |
+| 7 | `07_Cloud_Infra_Deployment/07_container_image_security.md` | Container Image Security | High | Run a CVE scanner (e.g. Trivy/Grype) against the production container image and confirm no unpatched critical CVEs, and that it isn't tagged 'latest'. |
+| 8 | `07_Cloud_Infra_Deployment/08_network_segmentation_cloud.md` | Cloud Network Segmentation | High | From a low-trust workload/VPC, attempt to reach a sensitive internal service directly and confirm network policy blocks it. |
+| 9 | `07_Cloud_Infra_Deployment/09_post_deploy_monitoring.md` | Post-Deployment Monitoring | Medium | During the next deploy, confirm an on-call owner is actively watching error-rate/latency dashboards for the defined post-deploy window. |
+| 10 | `07_Cloud_Infra_Deployment/10_feature_flag_safety.md` | Feature Flags & Kill Switches | Medium | Toggle a high-risk feature flag off in staging and confirm the code path is actually disabled immediately, not just hidden in the UI. |
+| 11 | `07_Cloud_Infra_Deployment/11_deploy_pipeline_iam_scoping.md` | Least-Privilege IAM for Deployment | Critical | Inspect the CI/CD service account's IAM role and confirm a staging-deploy credential cannot touch production resources. |

package/skills/manage-project-quality/references/security-09-edge-cdn-dns.md

@@ -0,0 +1,44 @@
+# Edge, CDN & DNS
+
+# Phase 9: Edge, CDN & DNS
+
+**When to run this:** When configuring or auditing anything sitting in front of your origin — CDN, WAF, DNS, email auth.
+
+**Goal of this pass:** Confirm the edge layer actually stops what it's supposed to, and that DNS/email records can't be hijacked or spoofed.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 10
+
+---
+
+# What to Check — Phase 9: Edge, CDN & DNS
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `16_Edge_CDN_Security/01_waf_rules.md` | Cloudflare WAF Rules | High | Send a known attack pattern (e.g. a basic SQLi string) through the WAF in log mode first, confirm detection, then verify it's actually blocked once enforced. |
+| 2 | `16_Edge_CDN_Security/02_ddos_protection.md` | DDoS Protection | High | Confirm the true origin IP isn't discoverable/reachable directly, bypassing the CDN/DDoS layer entirely. |
+| 3 | `16_Edge_CDN_Security/03_bot_management.md` | Bot Management | Medium | Run a scripted login-attempt simulation against the login endpoint and confirm the bot-management layer flags/blocks it before it reaches the app. |
+| 4 | `16_Edge_CDN_Security/04_cdn_caching_authenticated_content.md` | CDN Caching of Authenticated Content | Critical | Request the same authenticated URL as two different logged-in users through the CDN and confirm User B never sees User A's cached response. |
+| 5 | `16_Edge_CDN_Security/05_cache_poisoning.md` | Web Cache Poisoning | Critical | Send a request with an unusual header (e.g. X-Forwarded-Host: evil.com) and confirm it can't influence what gets cached and served to other visitors. |
+| 6 | `16_Edge_CDN_Security/06_zero_trust_access.md` | Cloudflare Zero Trust / Access | Medium | Attempt to reach an internal app through the Zero Trust proxy without a valid per-app identity policy match and confirm access is denied. |
+| 7 | `17_DNS_Email_Domain_Security/01_dnssec.md` | DNSSEC | Medium | Run a DNSSEC validation check (e.g. via a public DNSSEC debugger) against the domain and confirm the chain resolves without validation errors. |
+| 8 | `17_DNS_Email_Domain_Security/02_spf_dkim_dmarc.md` | SPF, DKIM & DMARC | High | Send a test email through an online authentication checker and confirm SPF, DKIM, and DMARC all pass and align. |
+| 9 | `17_DNS_Email_Domain_Security/03_subdomain_takeover.md` | Subdomain Takeover (added) | Critical | Audit every CNAME record pointing at a third-party service and confirm none point to a deprovisioned/unclaimed resource that could be claimed by an attacker. |
+| 10 | `17_DNS_Email_Domain_Security/04_certificate_transparency_monitoring.md` | Certificate Transparency Monitoring | Medium | Query crt.sh for the domain and confirm every listed certificate maps to a known, authorized issuance process. |

package/skills/manage-project-quality/references/security-10-release-rollout.md

@@ -0,0 +1,41 @@
+# Release & Rollout
+
+# Phase 10: Release Rollout (Beta ? Canary ? GA)
+
+**When to run this:** During the actual release process, from closed beta through general availability.
+
+**Goal of this pass:** Confirm blast radius stays small at each stage and there's always a fast way back out.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 7
+
+---
+
+# What to Check — Phase 10: Release Rollout (Beta ? Canary ? GA)
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `09_Release_Pipeline_Stages/02_internal_qa_testing.md` | Stage 2: Internal QA Testing | Medium | Confirm the QA environment's test data is synthetic/anonymized, not a raw copy of production customer PII. |
+| 2 | `09_Release_Pipeline_Stages/03_closed_beta_group_testing.md` | Stage 3: Closed Beta / Group Testing | Medium | Confirm the beta feature flag can be disabled instantly and test that toggling it off removes it from a live beta user's session. |
+| 3 | `09_Release_Pipeline_Stages/04_staged_canary_rollout.md` | Stage 4: Staged / Canary Rollout | High | Confirm the automated rollback trigger (e.g. error-rate threshold) actually fires a rollback during the canary phase, not just logs a warning. |
+| 4 | `09_Release_Pipeline_Stages/05_general_availability_release.md` | Stage 5: General Availability (GA) Release | Medium | Confirm a rollback plan and on-call briefing exist and are actionable even after reaching 100% rollout. |
+| 5 | `09_Release_Pipeline_Stages/06_post_release_monitoring_support.md` | Stage 6: Post-Release Monitoring & Support | Medium | Confirm there is a defined SLA for triaging user-reported issues after a release and that it's actually being met on recent releases. |
+| 6 | `09_Release_Pipeline_Stages/07_maintenance_patch_management.md` | Stage 7: Maintenance & Patch Management | High | Pick a recent critical CVE affecting a used dependency and confirm it was patched within the defined SLA window. |
+| 7 | `09_Release_Pipeline_Stages/08_deprecation_end_of_life.md` | Stage 8: Deprecation & End-of-Life | Medium | Confirm a recently EOL'd endpoint/feature is fully decommissioned (404/410), not left dormant and reachable. |

package/skills/manage-project-quality/references/security-11-post-release-monitoring-ir.md

@@ -0,0 +1,43 @@
+# Post-release Monitoring & Incident Response
+
+# Phase 11: Post-Release: Monitoring, Logging & Incident Response
+
+**When to run this:** Immediately after release, and as ongoing production operations.
+
+**Goal of this pass:** Confirm you'd actually notice if something went wrong, and that the team knows what to do when it does.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 9
+
+---
+
+# What to Check — Phase 11: Post-Release: Monitoring, Logging & Incident Response
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `11_Logging_Monitoring/01_audit_logging.md` | Audit Logging | High | Perform a sensitive action (e.g. role change) and confirm the audit log captures actor, action, timestamp, source IP, and result — then try to alter that entry. |
+| 2 | `11_Logging_Monitoring/02_log_injection.md` | Log Injection (added) | Medium | Submit a username or field containing newline characters and fake log-line content, then confirm it doesn't forge a fake log entry when written. |
+| 3 | `11_Logging_Monitoring/03_siem_alerting.md` | SIEM & Alerting (added) | Medium | Trigger 10 failed logins for one account in a short window and confirm a SIEM alert fires with a linked response runbook. |
+| 4 | `14_Incident_Response_Security_Ops/01_bug_bounty_responsible_disclosure.md` | Bug Bounty & Responsible Disclosure | Medium | Fetch https://yourdomain.com/.well-known/security.txt and confirm it publishes a working contact and safe-harbor statement. |
+| 5 | `14_Incident_Response_Security_Ops/02_manmade_adversarial_scenarios.md` | Man-Made / Adversarial Scenarios | Medium | Run a phishing simulation against staff and measure the click-through and report rate against your baseline target. |
+| 6 | `14_Incident_Response_Security_Ops/03_red_team_purple_team_exercises.md` | Red Team / Purple Team Exercises | High | Run a scoped red-team exercise with written rules of engagement and measure how quickly the detection/response team noticed and reacted. |
+| 7 | `14_Incident_Response_Security_Ops/04_incident_response.md` | Incident Response Drill (added) | High | Run a tabletop IR drill for a plausible scenario (e.g. leaked API key) and confirm every role knows their escalation step without looking it up. |
+| 8 | `14_Incident_Response_Security_Ops/06_security_awareness_training.md` | Security Awareness Training | Low | Confirm every engineer completed secure-coding training within the last 12 months and that a recent incident's lessons were folded into the material. |
+| 9 | `14_Incident_Response_Security_Ops/07_vulnerability_management_sla.md` | Vulnerability Management SLA | High | Pull open vulnerabilities from the tracker and confirm none of Critical/High severity are past their defined remediation SLA. |

package/skills/manage-project-quality/references/security-12-ongoing-operations.md

@@ -0,0 +1,52 @@
+# Ongoing Operations
+
+# Phase 12: Ongoing Operations
+
+**When to run this:** On a recurring cadence for a live, already-shipped system (see UPDATE_CADENCE.md for suggested frequency).
+
+**Goal of this pass:** Confirm the things that quietly rot over time — vendor access, backups, mobile clients, compliance obligations — are still actually true.
+
+## Files in this folder
+
+| File | Purpose |
+|---|---|
+| `CHECKLIST.md` | What to check — the reference list of items, severity, and example test steps for this phase. Doesn't get filled in; copy it or use `RESULTS_TEMPLATE.md` to record a real pass. |
+| `RESULTS_TEMPLATE.md` | Fillable version of the same checklist, with Result/Notes columns and a sign-off block. Copy this file per test pass (e.g. `RESULTS_2026-08-29.md`) so history isn't overwritten. |
+
+Full background, "why it matters," and references for every item live in
+`../../SECURITY_CHECKLIST.md` (search for the source file path shown in the
+checklist below).
+
+## Sign-off criteria
+
+- All Critical/High severity items must Pass or have an approved exception
+  before this phase is considered complete.
+- Total items in this phase: 18
+
+---
+
+# What to Check — Phase 12: Ongoing Operations
+
+Reference checklist only — no result columns. Use `RESULTS_TEMPLATE.md` in
+this same folder to actually record a test pass.
+
+| # | Source file | Item | Severity | Example test |
+|---|---|---|---|---|
+| 1 | `12_Third_Party_Integration_Vendor_Risk/01_vendor_security_assessment.md` | Vendor Security Assessment | Medium | Pull the most recently onboarded critical vendor's security questionnaire/SOC 2 report and confirm it was reviewed before data sharing began. |
+| 2 | `12_Third_Party_Integration_Vendor_Risk/02_data_processing_agreements.md` | Data Processing Agreements & Contracts | Medium | Confirm a signed DPA exists for every vendor receiving personal data, and that sub-processor disclosures are on file (consult legal for interpretation). |
+| 3 | `12_Third_Party_Integration_Vendor_Risk/03_saas_integration_permission_scoping.md` | SaaS Integration Permission Scoping | Medium | Review the OAuth scopes granted to each connected third-party app and confirm none exceed what that integration actually needs. |
+| 4 | `12_Third_Party_Integration_Vendor_Risk/04_third_party_integration_handling.md` | Third-Party Integration Handling | High | Simulate a slow/failed response from a third-party API dependency and confirm your service times out gracefully instead of hanging or failing open. |
+| 5 | `12_Third_Party_Integration_Vendor_Risk/05_webhook_security.md` | Webhook Security (added) | High | Send a webhook payload with an invalid or missing signature and confirm the receiving endpoint rejects it rather than processing it. |
+| 6 | `13_Backup_DR_Resilience/01_backup_job_monitoring.md` | Backup & Error Logs | Medium | Check the last 30 days of backup job logs and confirm every failure triggered an alert, not just a silent log entry. |
+| 7 | `13_Backup_DR_Resilience/02_chaos_engineering_basics.md` | Chaos Engineering Basics | Medium | Run a small-blast-radius experiment (e.g. kill one non-critical instance) in staging and confirm monitoring/alerting actually fires. |
+| 8 | `13_Backup_DR_Resilience/03_disaster_recovery_failover_testing.md` | Disaster Recovery / Failover Testing | High | Execute a real failover to the backup region and measure actual RTO/RPO against the documented targets, then test failback too. |
+| 9 | `13_Backup_DR_Resilience/04_backup_restore_testing.md` | Backup Restore Testing | High | Restore the latest backup into an isolated environment and verify data completeness/integrity, not just that the restore job reported success. |
+| 10 | `13_Backup_DR_Resilience/05_load_stress_testing.md` | Load & Stress Testing | Medium | Load-test the system to 150% of expected peak traffic and confirm it degrades gracefully (queuing/throttling) rather than crashing outright. |
+| 11 | `13_Backup_DR_Resilience/06_natural_disaster_scenarios.md` | Natural Disaster Scenarios | Medium | Run a tabletop exercise simulating a regional outage and confirm the documented communication plan is actually followed by the team. |
+| 12 | `18_Mobile_App_Security/01_certificate_pinning.md` | Certificate Pinning (Mobile) | High | Intercept app traffic with a proxy presenting a non-pinned trusted certificate and confirm the app refuses to connect. |
+| 13 | `18_Mobile_App_Security/02_secure_local_storage_mobile.md` | Secure Local Storage (Mobile) | High | Pull app data off a rooted/jailbroken test device and confirm tokens/PII aren't sitting in plaintext files or SharedPreferences. |
+| 14 | `18_Mobile_App_Security/03_jailbreak_root_detection.md` | Jailbreak / Root Detection | Medium | Run the app on a rooted/jailbroken device with a common detection-bypass tool active and confirm the app's protection still triggers or degrades safely. |
+| 15 | `18_Mobile_App_Security/04_mobile_api_key_protection.md` | Mobile API Key / Secret Protection | High | Decompile/extract strings from the shipped app binary and confirm no high-privilege static API key or secret is embedded. |
+| 16 | `15_Architecture_Compliance/03_consent_management.md` | Consent Management | Medium | Attempt to withdraw consent for a non-essential data use as a test user and confirm the system actually stops that use promptly. |
+| 17 | `15_Architecture_Compliance/05_regulatory_compliance_mapping.md` | Regulatory Compliance Mapping | Medium | Confirm each applicable regulation (GDPR/HIPAA/PCI-DSS/etc.) has specific controls mapped to it with an owner (not legal advice — confirm interpretation with counsel). |
+| 18 | `15_Architecture_Compliance/07_data_subject_rights_handling.md` | Data Subject Rights Handling | High | Submit a test data-deletion request and confirm the data is actually removed from backups/logs within the promised timeframe, not just the primary DB. |