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

package/content/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/content/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/content/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/content/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/content/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. |