From 27576cdd656309b3a311f9a0b316dd3c813a48fc Mon Sep 17 00:00:00 2001
From: O M <om@omLaptop.local>
Date: Fri, 2 Oct 2026 10:25:21 -0400
Subject: [PATCH] Remove the templated noindex posts so those URLs 404.

The lastmod check skips files that no longer exist, so a deletion is not treated as an indexed edit.

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 scripts/check-blog-dates.mjs                  |   4 +-
 src/content/blog/ai-ml-security-cloud.md      | 106 -----------------
 .../apra-cps-234-cloud-security-compliance.md | 107 ------------------
 src/content/blog/aws-acm-security-guide.md    | 107 ------------------
 .../blog/aws-amplify-security-guide.md        | 107 ------------------
 .../blog/aws-api-gateway-security-guide.md    | 107 ------------------
 .../blog/aws-app-runner-security-guide.md     | 107 ------------------
 .../blog/aws-appsync-security-guide.md        | 107 ------------------
 src/content/blog/aws-athena-security-guide.md | 107 ------------------
 src/content/blog/aws-aurora-security-guide.md | 107 ------------------
 src/content/blog/aws-backup-security-guide.md | 107 ------------------
 .../blog/aws-bedrock-security-guide.md        | 107 ------------------
 .../aws-cloudtrail-monitoring-security.md     | 107 ------------------
 .../blog/aws-codebuild-security-guide.md      | 107 ------------------
 .../blog/aws-codedeploy-security-guide.md     | 107 ------------------
 .../blog/aws-codepipeline-security-guide.md   | 107 ------------------
 .../blog/aws-cognito-security-guide.md        | 107 ------------------
 src/content/blog/aws-config-security-guide.md | 107 ------------------
 .../blog/aws-direct-connect-security-guide.md | 107 ------------------
 .../blog/aws-dynamodb-security-guide.md       | 107 ------------------
 .../blog/aws-ec2-hardening-checklist.md       | 107 ------------------
 src/content/blog/aws-ecs-security-guide.md    | 107 ------------------
 src/content/blog/aws-eks-security-guide.md    | 107 ------------------
 .../blog/aws-elasticache-security-guide.md    | 107 ------------------
 .../blog/aws-fargate-security-guide.md        | 107 ------------------
 .../blog/aws-guardduty-threat-detection.md    | 107 ------------------
 .../blog/aws-inspector-security-guide.md      | 107 ------------------
 .../blog/aws-kinesis-security-guide.md        | 107 ------------------
 .../blog/aws-kms-encryption-key-management.md | 107 ------------------
 .../blog/aws-lightsail-security-guide.md      | 107 ------------------
 src/content/blog/aws-macie-security-guide.md  | 107 ------------------
 src/content/blog/aws-msk-security-guide.md    | 107 ------------------
 .../aws-network-firewall-security-guide.md    | 107 ------------------
 .../blog/aws-opensearch-security-guide.md     | 107 ------------------
 .../blog/aws-organizations-scp-security.md    | 107 ------------------
 .../blog/aws-privatelink-security-guide.md    | 107 ------------------
 .../blog/aws-rds-database-security-guide.md   |  14 ---
 .../blog/aws-redshift-security-guide.md       | 107 ------------------
 .../blog/aws-route-53-security-guide.md       | 107 ------------------
 .../aws-secrets-manager-security-guide.md     | 107 ------------------
 .../aws-security-groups-best-practices.md     | 107 ------------------
 .../blog/aws-security-hub-security-guide.md   | 107 ------------------
 .../aws-site-to-site-vpn-security-guide.md    | 107 ------------------
 src/content/blog/aws-sns-security-guide.md    | 107 ------------------
 src/content/blog/aws-sqs-security-guide.md    | 107 ------------------
 .../aws-sso-iam-identity-center-hardening.md  | 107 ------------------
 .../blog/aws-step-functions-security-guide.md | 107 ------------------
 .../aws-systems-manager-security-guide.md     | 107 ------------------
 .../aws-transit-gateway-security-guide.md     | 107 ------------------
 .../aws-waf-web-application-firewall-guide.md | 107 ------------------
 src/content/blog/azure-acr-security-guide.md  | 107 ------------------
 ...azure-ad-privileged-identity-management.md | 107 ------------------
 src/content/blog/azure-aks-security-guide.md  | 107 ------------------
 .../azure-api-management-security-guide.md    | 107 ------------------
 .../blog/azure-app-service-security-guide.md  | 107 ------------------
 src/content/blog/azure-arc-security-guide.md  | 107 ------------------
 .../blog/azure-automation-security-guide.md   | 107 ------------------
 .../blog/azure-backup-security-guide.md       | 107 ------------------
 .../blog/azure-bastion-security-guide.md      | 107 ------------------
 .../blog/azure-batch-security-guide.md        | 107 ------------------
 .../blog/azure-blob-storage-security-guide.md | 107 ------------------
 src/content/blog/azure-cdn-security-guide.md  | 107 ------------------
 ...e-communication-services-security-guide.md | 107 ------------------
 ...zure-container-instances-security-guide.md | 107 ------------------
 .../blog/azure-cosmos-db-security-guide.md    | 107 ------------------
 .../blog/azure-data-lake-security-guide.md    | 107 ------------------
 .../azure-ddos-protection-security-guide.md   | 107 ------------------
 .../blog/azure-defender-cloud-security.md     | 107 ------------------
 .../blog/azure-devops-security-guide.md       | 107 ------------------
 .../azure-digital-twins-security-guide.md     | 107 ------------------
 .../blog/azure-event-hubs-security-guide.md   | 107 ------------------
 .../blog/azure-expressroute-security-guide.md | 107 ------------------
 .../blog/azure-firewall-security-guide.md     | 107 ------------------
 .../blog/azure-front-door-security-guide.md   | 107 ------------------
 .../blog/azure-functions-security-guide.md    | 107 ------------------
 ...e-information-protection-security-guide.md | 107 ------------------
 .../blog/azure-iot-hub-security-guide.md      | 107 ------------------
 .../azure-key-vault-security-hardening.md     | 107 ------------------
 .../azure-load-balancer-security-guide.md     | 107 ------------------
 .../blog/azure-logic-apps-security-guide.md   | 107 ------------------
 .../azure-machine-learning-security-guide.md  | 107 ------------------
 .../blog/azure-management-groups-policy.md    | 107 ------------------
 .../blog/azure-monitor-security-guide.md      | 107 ------------------
 .../blog/azure-mysql-security-guide.md        | 107 ------------------
 .../azure-network-security-groups-guide.md    | 107 ------------------
 .../azure-openai-service-security-guide.md    | 107 ------------------
 .../blog/azure-postgresql-security-guide.md   | 107 ------------------
 .../blog/azure-purview-security-guide.md      | 107 ------------------
 .../blog/azure-redis-security-guide.md        | 107 ------------------
 src/content/blog/azure-sentinel-cloud-siem.md | 107 ------------------
 .../blog/azure-service-bus-security-guide.md  | 107 ------------------
 .../blog/azure-signalr-security-guide.md      | 107 ------------------
 .../azure-site-recovery-security-guide.md     | 107 ------------------
 .../azure-sql-database-security-hardening.md  | 107 ------------------
 ...ure-sql-managed-instance-security-guide.md | 107 ------------------
 .../azure-static-web-apps-security-guide.md   | 107 ------------------
 .../blog/azure-synapse-security-guide.md      | 107 ------------------
 .../blog/azure-vm-security-baseline.md        | 107 ------------------
 .../blog/azure-vpn-gateway-security-guide.md  | 107 ------------------
 src/content/blog/bug-bounty-cloud-scope.md    | 106 -----------------
 .../blog/ccpa-cloud-security-compliance.md    | 107 ------------------
 src/content/blog/ciso-cloud-strategy.md       | 106 -----------------
 .../blog/cloud-api-security-rate-limiting.md  | 107 ------------------
 .../blog/cloud-compliance-cis-benchmarks.md   | 107 ------------------
 .../blog/cloud-drift-detection-remediation.md | 107 ------------------
 src/content/blog/cloud-forensics.md           | 106 -----------------
 .../cloud-identity-federation-sso-security.md | 107 ------------------
 .../blog/cloud-incident-response-playbook.md  | 107 ------------------
 src/content/blog/cloud-penetration-testing.md | 106 -----------------
 src/content/blog/cloud-red-team.md            | 106 -----------------
 ...cloud-secrets-management-best-practices.md | 107 ------------------
 .../cloud-security-automation-remediation.md  | 107 ------------------
 .../blog/cloud-security-maturity-model.md     | 106 -----------------
 ...ud-tagging-strategy-security-governance.md | 107 ------------------
 src/content/blog/cloud-vendor-risk.md         | 106 -----------------
 .../cloud-vulnerability-management-program.md | 107 ------------------
 .../cloud-workload-protection-cwpp-guide.md   | 107 ------------------
 .../cmmc-level-2-cloud-security-compliance.md | 107 ------------------
 src/content/blog/cnapp-buyers-guide.md        | 106 -----------------
 src/content/blog/confidential-computing.md    | 106 -----------------
 .../blog/container-image-scanning-cicd.md     | 107 ------------------
 src/content/blog/cryptomining-detection.md    | 106 -----------------
 ...sentials-plus-cloud-security-compliance.md | 107 ------------------
 .../blog/dora-cloud-security-compliance.md    | 107 ------------------
 .../dspm-data-security-posture-management.md  | 107 ------------------
 src/content/blog/edge-cloud-security.md       | 106 -----------------
 ...sential-eight-cloud-security-compliance.md | 107 ------------------
 .../exposure-management-cloud-security.md     | 107 ------------------
 .../external-attack-surface-management.md     | 106 -----------------
 ...ramp-moderate-cloud-security-compliance.md | 107 ------------------
 src/content/blog/finops-security.md           | 106 -----------------
 ...isma-moderate-cloud-security-compliance.md | 107 ------------------
 .../blog/gcp-alloydb-security-guide.md        | 107 ------------------
 src/content/blog/gcp-apigee-security-guide.md | 107 ------------------
 .../blog/gcp-app-engine-security-guide.md     | 107 ------------------
 .../gcp-artifact-registry-security-guide.md   | 107 ------------------
 .../blog/gcp-bigquery-security-guide.md       | 107 ------------------
 .../blog/gcp-bigtable-security-guide.md       | 107 ------------------
 ...gcp-binary-authorization-security-guide.md | 107 ------------------
 .../gcp-certificate-manager-security-guide.md | 107 ------------------
 .../blog/gcp-chronicle-security-operations.md | 107 ------------------
 .../blog/gcp-cloud-build-security-guide.md    | 107 ------------------
 .../blog/gcp-cloud-cdn-security-guide.md      | 107 ------------------
 .../blog/gcp-cloud-deploy-security-guide.md   | 107 ------------------
 .../blog/gcp-cloud-dns-security-guide.md      | 107 ------------------
 .../gcp-cloud-functions-security-guide.md     | 107 ------------------
 .../gcp-cloud-interconnect-security-guide.md  | 107 ------------------
 ...gcp-cloud-load-balancing-security-guide.md | 107 ------------------
 .../blog/gcp-cloud-logging-security-guide.md  | 107 ------------------
 .../blog/gcp-cloud-nat-security-guide.md      | 107 ------------------
 .../blog/gcp-cloud-run-security-guide.md      | 107 ------------------
 .../gcp-cloud-scheduler-security-guide.md     | 107 ------------------
 .../gcp-cloud-sql-security-best-practices.md  | 107 ------------------
 .../blog/gcp-cloud-storage-access-control.md  | 107 ------------------
 .../blog/gcp-cloud-tasks-security-guide.md    | 107 ------------------
 .../blog/gcp-cloud-trace-security-guide.md    | 107 ------------------
 .../blog/gcp-cloud-vpn-security-guide.md      | 107 ------------------
 .../gcp-compute-engine-security-hardening.md  | 107 ------------------
 .../blog/gcp-dataflow-security-guide.md       | 107 ------------------
 .../blog/gcp-dataproc-security-guide.md       | 107 ------------------
 .../gcp-error-reporting-security-guide.md     | 107 ------------------
 .../blog/gcp-filestore-security-guide.md      | 107 ------------------
 .../blog/gcp-firestore-security-guide.md      | 107 ------------------
 src/content/blog/gcp-gke-security-guide.md    | 107 ------------------
 ...gcp-identity-aware-proxy-security-guide.md | 107 ------------------
 .../blog/gcp-memorystore-security-guide.md    | 107 ------------------
 .../gcp-organization-policy-constraints.md    | 107 ------------------
 .../blog/gcp-pub-sub-security-guide.md        | 107 ------------------
 .../blog/gcp-secret-manager-security-guide.md | 107 ------------------
 .../blog/gcp-security-command-center-guide.md | 107 ------------------
 .../blog/gcp-spanner-security-guide.md        | 107 ------------------
 .../blog/gcp-vertex-ai-security-guide.md      | 107 ------------------
 .../gcp-vpc-service-controls-explained.md     | 107 ------------------
 .../blog/gcp-workload-identity-federation.md  | 107 ------------------
 .../blog/gdpr-cloud-security-compliance.md    | 107 ------------------
 src/content/blog/graphql-api-security.md      | 106 -----------------
 .../blog/hipaa-cloud-security-compliance.md   | 107 ------------------
 .../blog/hitrust-cloud-security-compliance.md | 107 ------------------
 src/content/blog/hybrid-cloud-security.md     | 106 -----------------
 src/content/blog/insider-threat-cloud.md      | 106 -----------------
 .../blog/irap-cloud-security-compliance.md    | 107 ------------------
 .../iso-27001-cloud-security-compliance.md    | 107 ------------------
 ...bernetes-admission-controllers-security.md | 107 ------------------
 .../kubernetes-argo-cd-hardening-guide.md     | 106 -----------------
 .../blog/kubernetes-calico-policies-guide.md  | 106 -----------------
 .../blog/kubernetes-cert-manager-tls-guide.md | 106 -----------------
 .../blog/kubernetes-cilium-network-guide.md   | 106 -----------------
 .../kubernetes-cis-benchmark-k8s-guide.md     | 106 -----------------
 ...netes-cluster-autoscaler-security-guide.md | 106 -----------------
 ...ubernetes-control-plane-hardening-guide.md | 106 -----------------
 .../blog/kubernetes-cronjob-security-guide.md | 106 -----------------
 .../kubernetes-csi-driver-security-guide.md   | 106 -----------------
 .../blog/kubernetes-egress-control-guide.md   | 106 -----------------
 .../blog/kubernetes-etcd-encryption-guide.md  | 106 -----------------
 .../blog/kubernetes-external-secrets-guide.md | 106 -----------------
 .../blog/kubernetes-falco-runtime-guide.md    | 106 -----------------
 .../blog/kubernetes-gatekeeper-opa-guide.md   | 106 -----------------
 .../blog/kubernetes-gitops-security-guide.md  | 106 -----------------
 .../kubernetes-helm-chart-security-guide.md   | 106 -----------------
 .../blog/kubernetes-ingress-security-guide.md | 106 -----------------
 .../blog/kubernetes-kyverno-policies-guide.md | 106 -----------------
 .../blog/kubernetes-multi-tenancy-guide.md    | 106 -----------------
 ...rnetes-network-policies-practical-guide.md | 107 ------------------
 .../blog/kubernetes-node-hardening-guide.md   | 106 -----------------
 ...rnetes-persistent-volume-security-guide.md | 106 -----------------
 .../blog/kubernetes-pod-security-standards.md | 107 ------------------
 ...bernetes-runtime-threat-detection-guide.md | 106 -----------------
 .../blog/kubernetes-sealed-secrets-guide.md   | 106 -----------------
 .../kubernetes-service-mesh-mtls-guide.md     | 106 -----------------
 .../blog/kubernetes-trivy-scanning-guide.md   | 106 -----------------
 .../blog/lateral-movement-aws-mitigation.md   | 107 ------------------
 src/content/blog/llm-cloud-security.md        | 106 -----------------
 .../blog/mas-trm-cloud-security-compliance.md | 107 ------------------
 src/content/blog/microservices-security.md    | 106 -----------------
 src/content/blog/mitre-att-ck-cloud.md        | 106 -----------------
 src/content/blog/mssp-cloud-security.md       | 106 -----------------
 .../blog/multi-cloud-security-governance.md   | 107 ------------------
 ...is2-directive-cloud-security-compliance.md | 107 ------------------
 .../nist-800-53-cloud-security-compliance.md  | 107 ------------------
 src/content/blog/oauth-cloud-attacks.md       | 106 -----------------
 src/content/blog/opa-cloud-governance.md      | 106 -----------------
 .../pci-dss-4-0-cloud-security-compliance.md  | 107 ------------------
 src/content/blog/policy-as-code-cloud.md      | 106 -----------------
 src/content/blog/purple-team-cloud.md         | 106 -----------------
 src/content/blog/ransomware-cloud-recovery.md | 106 -----------------
 .../blog/sbom-supply-chain-cloud-security.md  | 107 ------------------
 src/content/blog/security-architect-cloud.md  | 106 -----------------
 .../blog/security-chaos-engineering.md        | 106 -----------------
 ...verless-security-lambda-azure-functions.md | 107 ------------------
 ...soc-2-type-ii-cloud-security-compliance.md | 107 ------------------
 .../sox-itgc-cloud-security-compliance.md     | 107 ------------------
 .../terraform-security-scanning-iac-drift.md  | 107 ------------------
 src/content/blog/third-party-cloud-access.md  | 106 -----------------
 src/content/blog/threat-modeling-cloud.md     | 106 -----------------
 234 files changed, 3 insertions(+), 24784 deletions(-)
 delete mode 100644 src/content/blog/ai-ml-security-cloud.md
 delete mode 100644 src/content/blog/apra-cps-234-cloud-security-compliance.md
 delete mode 100644 src/content/blog/aws-acm-security-guide.md
 delete mode 100644 src/content/blog/aws-amplify-security-guide.md
 delete mode 100644 src/content/blog/aws-api-gateway-security-guide.md
 delete mode 100644 src/content/blog/aws-app-runner-security-guide.md
 delete mode 100644 src/content/blog/aws-appsync-security-guide.md
 delete mode 100644 src/content/blog/aws-athena-security-guide.md
 delete mode 100644 src/content/blog/aws-aurora-security-guide.md
 delete mode 100644 src/content/blog/aws-backup-security-guide.md
 delete mode 100644 src/content/blog/aws-bedrock-security-guide.md
 delete mode 100644 src/content/blog/aws-cloudtrail-monitoring-security.md
 delete mode 100644 src/content/blog/aws-codebuild-security-guide.md
 delete mode 100644 src/content/blog/aws-codedeploy-security-guide.md
 delete mode 100644 src/content/blog/aws-codepipeline-security-guide.md
 delete mode 100644 src/content/blog/aws-cognito-security-guide.md
 delete mode 100644 src/content/blog/aws-config-security-guide.md
 delete mode 100644 src/content/blog/aws-direct-connect-security-guide.md
 delete mode 100644 src/content/blog/aws-dynamodb-security-guide.md
 delete mode 100644 src/content/blog/aws-ec2-hardening-checklist.md
 delete mode 100644 src/content/blog/aws-ecs-security-guide.md
 delete mode 100644 src/content/blog/aws-eks-security-guide.md
 delete mode 100644 src/content/blog/aws-elasticache-security-guide.md
 delete mode 100644 src/content/blog/aws-fargate-security-guide.md
 delete mode 100644 src/content/blog/aws-guardduty-threat-detection.md
 delete mode 100644 src/content/blog/aws-inspector-security-guide.md
 delete mode 100644 src/content/blog/aws-kinesis-security-guide.md
 delete mode 100644 src/content/blog/aws-kms-encryption-key-management.md
 delete mode 100644 src/content/blog/aws-lightsail-security-guide.md
 delete mode 100644 src/content/blog/aws-macie-security-guide.md
 delete mode 100644 src/content/blog/aws-msk-security-guide.md
 delete mode 100644 src/content/blog/aws-network-firewall-security-guide.md
 delete mode 100644 src/content/blog/aws-opensearch-security-guide.md
 delete mode 100644 src/content/blog/aws-organizations-scp-security.md
 delete mode 100644 src/content/blog/aws-privatelink-security-guide.md
 delete mode 100644 src/content/blog/aws-rds-database-security-guide.md
 delete mode 100644 src/content/blog/aws-redshift-security-guide.md
 delete mode 100644 src/content/blog/aws-route-53-security-guide.md
 delete mode 100644 src/content/blog/aws-secrets-manager-security-guide.md
 delete mode 100644 src/content/blog/aws-security-groups-best-practices.md
 delete mode 100644 src/content/blog/aws-security-hub-security-guide.md
 delete mode 100644 src/content/blog/aws-site-to-site-vpn-security-guide.md
 delete mode 100644 src/content/blog/aws-sns-security-guide.md
 delete mode 100644 src/content/blog/aws-sqs-security-guide.md
 delete mode 100644 src/content/blog/aws-sso-iam-identity-center-hardening.md
 delete mode 100644 src/content/blog/aws-step-functions-security-guide.md
 delete mode 100644 src/content/blog/aws-systems-manager-security-guide.md
 delete mode 100644 src/content/blog/aws-transit-gateway-security-guide.md
 delete mode 100644 src/content/blog/aws-waf-web-application-firewall-guide.md
 delete mode 100644 src/content/blog/azure-acr-security-guide.md
 delete mode 100644 src/content/blog/azure-ad-privileged-identity-management.md
 delete mode 100644 src/content/blog/azure-aks-security-guide.md
 delete mode 100644 src/content/blog/azure-api-management-security-guide.md
 delete mode 100644 src/content/blog/azure-app-service-security-guide.md
 delete mode 100644 src/content/blog/azure-arc-security-guide.md
 delete mode 100644 src/content/blog/azure-automation-security-guide.md
 delete mode 100644 src/content/blog/azure-backup-security-guide.md
 delete mode 100644 src/content/blog/azure-bastion-security-guide.md
 delete mode 100644 src/content/blog/azure-batch-security-guide.md
 delete mode 100644 src/content/blog/azure-blob-storage-security-guide.md
 delete mode 100644 src/content/blog/azure-cdn-security-guide.md
 delete mode 100644 src/content/blog/azure-communication-services-security-guide.md
 delete mode 100644 src/content/blog/azure-container-instances-security-guide.md
 delete mode 100644 src/content/blog/azure-cosmos-db-security-guide.md
 delete mode 100644 src/content/blog/azure-data-lake-security-guide.md
 delete mode 100644 src/content/blog/azure-ddos-protection-security-guide.md
 delete mode 100644 src/content/blog/azure-defender-cloud-security.md
 delete mode 100644 src/content/blog/azure-devops-security-guide.md
 delete mode 100644 src/content/blog/azure-digital-twins-security-guide.md
 delete mode 100644 src/content/blog/azure-event-hubs-security-guide.md
 delete mode 100644 src/content/blog/azure-expressroute-security-guide.md
 delete mode 100644 src/content/blog/azure-firewall-security-guide.md
 delete mode 100644 src/content/blog/azure-front-door-security-guide.md
 delete mode 100644 src/content/blog/azure-functions-security-guide.md
 delete mode 100644 src/content/blog/azure-information-protection-security-guide.md
 delete mode 100644 src/content/blog/azure-iot-hub-security-guide.md
 delete mode 100644 src/content/blog/azure-key-vault-security-hardening.md
 delete mode 100644 src/content/blog/azure-load-balancer-security-guide.md
 delete mode 100644 src/content/blog/azure-logic-apps-security-guide.md
 delete mode 100644 src/content/blog/azure-machine-learning-security-guide.md
 delete mode 100644 src/content/blog/azure-management-groups-policy.md
 delete mode 100644 src/content/blog/azure-monitor-security-guide.md
 delete mode 100644 src/content/blog/azure-mysql-security-guide.md
 delete mode 100644 src/content/blog/azure-network-security-groups-guide.md
 delete mode 100644 src/content/blog/azure-openai-service-security-guide.md
 delete mode 100644 src/content/blog/azure-postgresql-security-guide.md
 delete mode 100644 src/content/blog/azure-purview-security-guide.md
 delete mode 100644 src/content/blog/azure-redis-security-guide.md
 delete mode 100644 src/content/blog/azure-sentinel-cloud-siem.md
 delete mode 100644 src/content/blog/azure-service-bus-security-guide.md
 delete mode 100644 src/content/blog/azure-signalr-security-guide.md
 delete mode 100644 src/content/blog/azure-site-recovery-security-guide.md
 delete mode 100644 src/content/blog/azure-sql-database-security-hardening.md
 delete mode 100644 src/content/blog/azure-sql-managed-instance-security-guide.md
 delete mode 100644 src/content/blog/azure-static-web-apps-security-guide.md
 delete mode 100644 src/content/blog/azure-synapse-security-guide.md
 delete mode 100644 src/content/blog/azure-vm-security-baseline.md
 delete mode 100644 src/content/blog/azure-vpn-gateway-security-guide.md
 delete mode 100644 src/content/blog/bug-bounty-cloud-scope.md
 delete mode 100644 src/content/blog/ccpa-cloud-security-compliance.md
 delete mode 100644 src/content/blog/ciso-cloud-strategy.md
 delete mode 100644 src/content/blog/cloud-api-security-rate-limiting.md
 delete mode 100644 src/content/blog/cloud-compliance-cis-benchmarks.md
 delete mode 100644 src/content/blog/cloud-drift-detection-remediation.md
 delete mode 100644 src/content/blog/cloud-forensics.md
 delete mode 100644 src/content/blog/cloud-identity-federation-sso-security.md
 delete mode 100644 src/content/blog/cloud-incident-response-playbook.md
 delete mode 100644 src/content/blog/cloud-penetration-testing.md
 delete mode 100644 src/content/blog/cloud-red-team.md
 delete mode 100644 src/content/blog/cloud-secrets-management-best-practices.md
 delete mode 100644 src/content/blog/cloud-security-automation-remediation.md
 delete mode 100644 src/content/blog/cloud-security-maturity-model.md
 delete mode 100644 src/content/blog/cloud-tagging-strategy-security-governance.md
 delete mode 100644 src/content/blog/cloud-vendor-risk.md
 delete mode 100644 src/content/blog/cloud-vulnerability-management-program.md
 delete mode 100644 src/content/blog/cloud-workload-protection-cwpp-guide.md
 delete mode 100644 src/content/blog/cmmc-level-2-cloud-security-compliance.md
 delete mode 100644 src/content/blog/cnapp-buyers-guide.md
 delete mode 100644 src/content/blog/confidential-computing.md
 delete mode 100644 src/content/blog/container-image-scanning-cicd.md
 delete mode 100644 src/content/blog/cryptomining-detection.md
 delete mode 100644 src/content/blog/cyber-essentials-plus-cloud-security-compliance.md
 delete mode 100644 src/content/blog/dora-cloud-security-compliance.md
 delete mode 100644 src/content/blog/dspm-data-security-posture-management.md
 delete mode 100644 src/content/blog/edge-cloud-security.md
 delete mode 100644 src/content/blog/essential-eight-cloud-security-compliance.md
 delete mode 100644 src/content/blog/exposure-management-cloud-security.md
 delete mode 100644 src/content/blog/external-attack-surface-management.md
 delete mode 100644 src/content/blog/fedramp-moderate-cloud-security-compliance.md
 delete mode 100644 src/content/blog/finops-security.md
 delete mode 100644 src/content/blog/fisma-moderate-cloud-security-compliance.md
 delete mode 100644 src/content/blog/gcp-alloydb-security-guide.md
 delete mode 100644 src/content/blog/gcp-apigee-security-guide.md
 delete mode 100644 src/content/blog/gcp-app-engine-security-guide.md
 delete mode 100644 src/content/blog/gcp-artifact-registry-security-guide.md
 delete mode 100644 src/content/blog/gcp-bigquery-security-guide.md
 delete mode 100644 src/content/blog/gcp-bigtable-security-guide.md
 delete mode 100644 src/content/blog/gcp-binary-authorization-security-guide.md
 delete mode 100644 src/content/blog/gcp-certificate-manager-security-guide.md
 delete mode 100644 src/content/blog/gcp-chronicle-security-operations.md
 delete mode 100644 src/content/blog/gcp-cloud-build-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-cdn-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-deploy-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-dns-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-functions-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-interconnect-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-load-balancing-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-logging-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-nat-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-run-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-scheduler-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-sql-security-best-practices.md
 delete mode 100644 src/content/blog/gcp-cloud-storage-access-control.md
 delete mode 100644 src/content/blog/gcp-cloud-tasks-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-trace-security-guide.md
 delete mode 100644 src/content/blog/gcp-cloud-vpn-security-guide.md
 delete mode 100644 src/content/blog/gcp-compute-engine-security-hardening.md
 delete mode 100644 src/content/blog/gcp-dataflow-security-guide.md
 delete mode 100644 src/content/blog/gcp-dataproc-security-guide.md
 delete mode 100644 src/content/blog/gcp-error-reporting-security-guide.md
 delete mode 100644 src/content/blog/gcp-filestore-security-guide.md
 delete mode 100644 src/content/blog/gcp-firestore-security-guide.md
 delete mode 100644 src/content/blog/gcp-gke-security-guide.md
 delete mode 100644 src/content/blog/gcp-identity-aware-proxy-security-guide.md
 delete mode 100644 src/content/blog/gcp-memorystore-security-guide.md
 delete mode 100644 src/content/blog/gcp-organization-policy-constraints.md
 delete mode 100644 src/content/blog/gcp-pub-sub-security-guide.md
 delete mode 100644 src/content/blog/gcp-secret-manager-security-guide.md
 delete mode 100644 src/content/blog/gcp-security-command-center-guide.md
 delete mode 100644 src/content/blog/gcp-spanner-security-guide.md
 delete mode 100644 src/content/blog/gcp-vertex-ai-security-guide.md
 delete mode 100644 src/content/blog/gcp-vpc-service-controls-explained.md
 delete mode 100644 src/content/blog/gcp-workload-identity-federation.md
 delete mode 100644 src/content/blog/gdpr-cloud-security-compliance.md
 delete mode 100644 src/content/blog/graphql-api-security.md
 delete mode 100644 src/content/blog/hipaa-cloud-security-compliance.md
 delete mode 100644 src/content/blog/hitrust-cloud-security-compliance.md
 delete mode 100644 src/content/blog/hybrid-cloud-security.md
 delete mode 100644 src/content/blog/insider-threat-cloud.md
 delete mode 100644 src/content/blog/irap-cloud-security-compliance.md
 delete mode 100644 src/content/blog/iso-27001-cloud-security-compliance.md
 delete mode 100644 src/content/blog/kubernetes-admission-controllers-security.md
 delete mode 100644 src/content/blog/kubernetes-argo-cd-hardening-guide.md
 delete mode 100644 src/content/blog/kubernetes-calico-policies-guide.md
 delete mode 100644 src/content/blog/kubernetes-cert-manager-tls-guide.md
 delete mode 100644 src/content/blog/kubernetes-cilium-network-guide.md
 delete mode 100644 src/content/blog/kubernetes-cis-benchmark-k8s-guide.md
 delete mode 100644 src/content/blog/kubernetes-cluster-autoscaler-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-control-plane-hardening-guide.md
 delete mode 100644 src/content/blog/kubernetes-cronjob-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-csi-driver-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-egress-control-guide.md
 delete mode 100644 src/content/blog/kubernetes-etcd-encryption-guide.md
 delete mode 100644 src/content/blog/kubernetes-external-secrets-guide.md
 delete mode 100644 src/content/blog/kubernetes-falco-runtime-guide.md
 delete mode 100644 src/content/blog/kubernetes-gatekeeper-opa-guide.md
 delete mode 100644 src/content/blog/kubernetes-gitops-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-helm-chart-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-ingress-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-kyverno-policies-guide.md
 delete mode 100644 src/content/blog/kubernetes-multi-tenancy-guide.md
 delete mode 100644 src/content/blog/kubernetes-network-policies-practical-guide.md
 delete mode 100644 src/content/blog/kubernetes-node-hardening-guide.md
 delete mode 100644 src/content/blog/kubernetes-persistent-volume-security-guide.md
 delete mode 100644 src/content/blog/kubernetes-pod-security-standards.md
 delete mode 100644 src/content/blog/kubernetes-runtime-threat-detection-guide.md
 delete mode 100644 src/content/blog/kubernetes-sealed-secrets-guide.md
 delete mode 100644 src/content/blog/kubernetes-service-mesh-mtls-guide.md
 delete mode 100644 src/content/blog/kubernetes-trivy-scanning-guide.md
 delete mode 100644 src/content/blog/lateral-movement-aws-mitigation.md
 delete mode 100644 src/content/blog/llm-cloud-security.md
 delete mode 100644 src/content/blog/mas-trm-cloud-security-compliance.md
 delete mode 100644 src/content/blog/microservices-security.md
 delete mode 100644 src/content/blog/mitre-att-ck-cloud.md
 delete mode 100644 src/content/blog/mssp-cloud-security.md
 delete mode 100644 src/content/blog/multi-cloud-security-governance.md
 delete mode 100644 src/content/blog/nis2-directive-cloud-security-compliance.md
 delete mode 100644 src/content/blog/nist-800-53-cloud-security-compliance.md
 delete mode 100644 src/content/blog/oauth-cloud-attacks.md
 delete mode 100644 src/content/blog/opa-cloud-governance.md
 delete mode 100644 src/content/blog/pci-dss-4-0-cloud-security-compliance.md
 delete mode 100644 src/content/blog/policy-as-code-cloud.md
 delete mode 100644 src/content/blog/purple-team-cloud.md
 delete mode 100644 src/content/blog/ransomware-cloud-recovery.md
 delete mode 100644 src/content/blog/sbom-supply-chain-cloud-security.md
 delete mode 100644 src/content/blog/security-architect-cloud.md
 delete mode 100644 src/content/blog/security-chaos-engineering.md
 delete mode 100644 src/content/blog/serverless-security-lambda-azure-functions.md
 delete mode 100644 src/content/blog/soc-2-type-ii-cloud-security-compliance.md
 delete mode 100644 src/content/blog/sox-itgc-cloud-security-compliance.md
 delete mode 100644 src/content/blog/terraform-security-scanning-iac-drift.md
 delete mode 100644 src/content/blog/third-party-cloud-access.md
 delete mode 100644 src/content/blog/threat-modeling-cloud.md

diff --git a/scripts/check-blog-dates.mjs b/scripts/check-blog-dates.mjs
index 9402ee2..215ed8d 100644
--- a/scripts/check-blog-dates.mjs
+++ b/scripts/check-blog-dates.mjs
@@ -6,7 +6,7 @@
  * pubDate on new posts). Sitemap lastmod is derived from those fields.
  */
 import { execFileSync } from 'node:child_process';
-import { readFileSync } from 'node:fs';
+import { existsSync, readFileSync } from 'node:fs';
 import { frontmatterDate, frontmatterFlag } from './content-dates.mjs';
 
 const base = process.env.BLOG_DATE_BASE_SHA ?? '';
@@ -58,6 +58,8 @@ if (!base) {
 const problems = [];
 
 for (const path of changedBlogFiles()) {
+  // Deletions are not indexed edits. A missing file has no lastmod to bump.
+  if (!existsSync(path)) continue;
   const nextFm = readFileSync(path, 'utf8').split('---')[1] ?? '';
   if (frontmatterFlag(nextFm, 'noindex') || frontmatterFlag(nextFm, 'draft')) continue;
 
diff --git a/src/content/blog/ai-ml-security-cloud.md b/src/content/blog/ai-ml-security-cloud.md
deleted file mode 100644
index 0c8c244..0000000
--- a/src/content/blog/ai-ml-security-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "AI and ML Security Risks in Cloud Workloads"
-description: "AI and ML Security Risks in Cloud Workloads — expert guide to ai ml security cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: ai ml security cloud
-faq:
-  - question: Why does ai ml security cloud matter for cloud teams?
-    answer: ai ml security cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does ai ml security cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether ai ml security cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support ai ml security cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize ai ml security cloud without proprietary black boxes.
----
-
-**ai ml security cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why ai ml security cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without ai ml security cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp compute engine security hardening](/blog/gcp-compute-engine-security-hardening/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align ai ml security cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce ai ml security cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature ai ml security cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **ai ml security cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-compute-engine-security-hardening](/blog/gcp-compute-engine-security-hardening/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/apra-cps-234-cloud-security-compliance.md b/src/content/blog/apra-cps-234-cloud-security-compliance.md
deleted file mode 100644
index d40ed69..0000000
--- a/src/content/blog/apra-cps-234-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "APRA CPS 234 Cloud Security for Australian Finance"
-description: "APRA CPS 234 Cloud Security for Australian Finance — expert guide to APRA CPS 234 cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - APRA CPS 234
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: APRA CPS 234 cloud security
-faq:
-  - question: Why does APRA CPS 234 cloud security matter for cloud teams?
-    answer: APRA CPS 234 cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does APRA CPS 234 cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether APRA CPS 234 cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support APRA CPS 234 cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize APRA CPS 234 cloud security without proprietary black boxes.
----
-
-**APRA CPS 234 cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why APRA CPS 234 cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without APRA CPS 234 cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align APRA CPS 234 cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce APRA CPS 234 cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature APRA CPS 234 cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **APRA CPS 234 cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/aws-acm-security-guide.md b/src/content/blog/aws-acm-security-guide.md
deleted file mode 100644
index 5fc1c03..0000000
--- a/src/content/blog/aws-acm-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Certificate Manager Security and TLS Best Practices"
-description: "AWS Certificate Manager Security and TLS Best Practices — expert guide to AWS ACM security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - ACM
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS ACM security
-faq:
-  - question: Why does AWS ACM security matter for cloud teams?
-    answer: AWS ACM security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS ACM security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS ACM security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS ACM security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS ACM security without proprietary black boxes.
----
-
-**AWS ACM security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS ACM security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS ACM security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) and [gcp workload identity federation](/blog/gcp-workload-identity-federation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS ACM security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS ACM security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS ACM security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS ACM security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/) · [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/)
diff --git a/src/content/blog/aws-amplify-security-guide.md b/src/content/blog/aws-amplify-security-guide.md
deleted file mode 100644
index 9244f3b..0000000
--- a/src/content/blog/aws-amplify-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Amplify Security for Full-Stack Web Applications"
-description: "AWS Amplify Security for Full-Stack Web Applications — expert guide to AWS Amplify security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Amplify
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Amplify security
-faq:
-  - question: Why does AWS Amplify security matter for cloud teams?
-    answer: AWS Amplify security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Amplify security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Amplify security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Amplify security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Amplify security without proprietary black boxes.
----
-
-**AWS Amplify security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Amplify security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Amplify security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) and [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Amplify security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Amplify security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Amplify security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Amplify security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/) · [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/)
diff --git a/src/content/blog/aws-api-gateway-security-guide.md b/src/content/blog/aws-api-gateway-security-guide.md
deleted file mode 100644
index 6c7749c..0000000
--- a/src/content/blog/aws-api-gateway-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon API Gateway Security: Auth, Throttling, and WAF"
-description: "Amazon API Gateway Security — expert guide to AWS API Gateway security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization f..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - API Gateway
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS API Gateway security
-faq:
-  - question: Why does AWS API Gateway security matter for cloud teams?
-    answer: AWS API Gateway security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS API Gateway security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS API Gateway security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS API Gateway security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS API Gateway security without proprietary black boxes.
----
-
-**AWS API Gateway security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS API Gateway security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS API Gateway security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS API Gateway security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS API Gateway security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS API Gateway security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS API Gateway security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/aws-app-runner-security-guide.md b/src/content/blog/aws-app-runner-security-guide.md
deleted file mode 100644
index cb4317e..0000000
--- a/src/content/blog/aws-app-runner-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS App Runner Security for Containerized Web Services"
-description: "AWS App Runner Security for Containerized Web Services — expert guide to AWS App Runner security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - App Runner
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS App Runner security
-faq:
-  - question: Why does AWS App Runner security matter for cloud teams?
-    answer: AWS App Runner security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS App Runner security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS App Runner security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS App Runner security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS App Runner security without proprietary black boxes.
----
-
-**AWS App Runner security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS App Runner security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS App Runner security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security groups best practices](/blog/aws-security-groups-best-practices/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS App Runner security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS App Runner security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS App Runner security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS App Runner security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/aws-appsync-security-guide.md b/src/content/blog/aws-appsync-security-guide.md
deleted file mode 100644
index 4052889..0000000
--- a/src/content/blog/aws-appsync-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS AppSync Security for GraphQL APIs in the Cloud"
-description: "AWS AppSync Security for GraphQL APIs in the Cloud — expert guide to AWS AppSync security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - AppSync
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS AppSync security
-faq:
-  - question: Why does AWS AppSync security matter for cloud teams?
-    answer: AWS AppSync security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS AppSync security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS AppSync security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS AppSync security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS AppSync security without proprietary black boxes.
----
-
-**AWS AppSync security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS AppSync security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS AppSync security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes pod security standards](/blog/kubernetes-pod-security-standards/) and [exposure management cloud security](/blog/exposure-management-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS AppSync security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS AppSync security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS AppSync security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS AppSync security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-pod-security-standards](/blog/kubernetes-pod-security-standards/) · [exposure-management-cloud-security](/blog/exposure-management-cloud-security/)
diff --git a/src/content/blog/aws-athena-security-guide.md b/src/content/blog/aws-athena-security-guide.md
deleted file mode 100644
index 5333b9b..0000000
--- a/src/content/blog/aws-athena-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Athena Security: Query Access and S3 Data Controls"
-description: "Amazon Athena Security — expert guide to AWS Athena security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practit..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Athena
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Athena security
-faq:
-  - question: Why does AWS Athena security matter for cloud teams?
-    answer: AWS Athena security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Athena security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Athena security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Athena security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Athena security without proprietary black boxes.
----
-
-**AWS Athena security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Athena security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Athena security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Athena security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Athena security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Athena security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Athena security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/)
diff --git a/src/content/blog/aws-aurora-security-guide.md b/src/content/blog/aws-aurora-security-guide.md
deleted file mode 100644
index 02803c9..0000000
--- a/src/content/blog/aws-aurora-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Aurora Security Guide for Production Databases"
-description: "Amazon Aurora Security Guide for Production Databases — expert guide to AWS Aurora security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Aurora
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Aurora security
-faq:
-  - question: Why does AWS Aurora security matter for cloud teams?
-    answer: AWS Aurora security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Aurora security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Aurora security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Aurora security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Aurora security without proprietary black boxes.
----
-
-**AWS Aurora security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Aurora security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Aurora security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Aurora security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Aurora security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Aurora security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Aurora security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/)
diff --git a/src/content/blog/aws-backup-security-guide.md b/src/content/blog/aws-backup-security-guide.md
deleted file mode 100644
index 8f1571a..0000000
--- a/src/content/blog/aws-backup-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Backup Security: Vaults, Encryption, and Cross-Account"
-description: "AWS Backup Security — expert guide to AWS Backup security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practition..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Backup
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Backup security
-faq:
-  - question: Why does AWS Backup security matter for cloud teams?
-    answer: AWS Backup security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Backup security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Backup security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Backup security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Backup security without proprietary black boxes.
----
-
-**AWS Backup security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Backup security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Backup security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Backup security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Backup security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Backup security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Backup security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/aws-bedrock-security-guide.md b/src/content/blog/aws-bedrock-security-guide.md
deleted file mode 100644
index afd8585..0000000
--- a/src/content/blog/aws-bedrock-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Bedrock Security: Guardrails, IAM, and Data Privacy"
-description: "Amazon Bedrock Security — expert guide to AWS Bedrock security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pract..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Bedrock
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Bedrock security
-faq:
-  - question: Why does AWS Bedrock security matter for cloud teams?
-    answer: AWS Bedrock security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Bedrock security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Bedrock security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Bedrock security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Bedrock security without proprietary black boxes.
----
-
-**AWS Bedrock security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Bedrock security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Bedrock security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [aws security groups best practices](/blog/aws-security-groups-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Bedrock security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Bedrock security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Bedrock security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Bedrock security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/)
diff --git a/src/content/blog/aws-cloudtrail-monitoring-security.md b/src/content/blog/aws-cloudtrail-monitoring-security.md
deleted file mode 100644
index 386b05f..0000000
--- a/src/content/blog/aws-cloudtrail-monitoring-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS CloudTrail for Security Monitoring: Organization-Wide Logging"
-description: "AWS CloudTrail for Security Monitoring—practical guidance on AWS CloudTrail security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - CloudTrail
-  - SIEM
-  - cloud security
-  - logging
-focusKeyword: AWS CloudTrail security
-faq:
-  - question: Why does AWS CloudTrail security matter for cloud teams?
-    answer: AWS CloudTrail security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS CloudTrail security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS CloudTrail security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS CloudTrail security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS CloudTrail security without proprietary black boxes.
----
-
-**AWS CloudTrail security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS CloudTrail security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS CloudTrail security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [aws security groups best practices](/blog/aws-security-groups-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS CloudTrail security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS CloudTrail security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS CloudTrail security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS CloudTrail security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/)
diff --git a/src/content/blog/aws-codebuild-security-guide.md b/src/content/blog/aws-codebuild-security-guide.md
deleted file mode 100644
index 7ee94ab..0000000
--- a/src/content/blog/aws-codebuild-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS CodeBuild Security: Isolation, IAM, and Secrets"
-description: "AWS CodeBuild Security — expert guide to AWS CodeBuild security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for prac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - CodeBuild
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS CodeBuild security
-faq:
-  - question: Why does AWS CodeBuild security matter for cloud teams?
-    answer: AWS CodeBuild security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS CodeBuild security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS CodeBuild security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS CodeBuild security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS CodeBuild security without proprietary black boxes.
----
-
-**AWS CodeBuild security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS CodeBuild security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS CodeBuild security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure defender cloud security](/blog/azure-defender-cloud-security/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS CodeBuild security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS CodeBuild security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS CodeBuild security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS CodeBuild security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-defender-cloud-security](/blog/azure-defender-cloud-security/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/aws-codedeploy-security-guide.md b/src/content/blog/aws-codedeploy-security-guide.md
deleted file mode 100644
index 0bb2e1f..0000000
--- a/src/content/blog/aws-codedeploy-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS CodeDeploy Security for Blue-Green Deployments"
-description: "AWS CodeDeploy Security for Blue-Green Deployments — expert guide to AWS CodeDeploy security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - CodeDeploy
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS CodeDeploy security
-faq:
-  - question: Why does AWS CodeDeploy security matter for cloud teams?
-    answer: AWS CodeDeploy security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS CodeDeploy security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS CodeDeploy security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS CodeDeploy security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS CodeDeploy security without proprietary black boxes.
----
-
-**AWS CodeDeploy security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS CodeDeploy security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS CodeDeploy security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS CodeDeploy security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS CodeDeploy security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS CodeDeploy security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS CodeDeploy security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/aws-codepipeline-security-guide.md b/src/content/blog/aws-codepipeline-security-guide.md
deleted file mode 100644
index f847452..0000000
--- a/src/content/blog/aws-codepipeline-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS CodePipeline Security for Secure CI/CD Delivery"
-description: "AWS CodePipeline Security for Secure CI/CD Delivery — expert guide to AWS CodePipeline security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - CodePipeline
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS CodePipeline security
-faq:
-  - question: Why does AWS CodePipeline security matter for cloud teams?
-    answer: AWS CodePipeline security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS CodePipeline security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS CodePipeline security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS CodePipeline security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS CodePipeline security without proprietary black boxes.
----
-
-**AWS CodePipeline security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS CodePipeline security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS CodePipeline security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure key vault security hardening](/blog/azure-key-vault-security-hardening/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS CodePipeline security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS CodePipeline security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS CodePipeline security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS CodePipeline security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-key-vault-security-hardening](/blog/azure-key-vault-security-hardening/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/aws-cognito-security-guide.md b/src/content/blog/aws-cognito-security-guide.md
deleted file mode 100644
index b403bb2..0000000
--- a/src/content/blog/aws-cognito-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Cognito Security: User Pools, Identity Pools, and OAuth"
-description: "Amazon Cognito Security — expert guide to AWS Cognito security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pract..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Cognito
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Cognito security
-faq:
-  - question: Why does AWS Cognito security matter for cloud teams?
-    answer: AWS Cognito security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Cognito security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Cognito security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Cognito security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Cognito security without proprietary black boxes.
----
-
-**AWS Cognito security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Cognito security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Cognito security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) and [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Cognito security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Cognito security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Cognito security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Cognito security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/) · [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/)
diff --git a/src/content/blog/aws-config-security-guide.md b/src/content/blog/aws-config-security-guide.md
deleted file mode 100644
index ebeda07..0000000
--- a/src/content/blog/aws-config-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Config Rules for Continuous Compliance Monitoring"
-description: "AWS Config Rules for Continuous Compliance Monitoring — expert guide to AWS Config security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Config
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Config security
-faq:
-  - question: Why does AWS Config security matter for cloud teams?
-    answer: AWS Config security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Config security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Config security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Config security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Config security without proprietary black boxes.
----
-
-**AWS Config security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Config security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Config security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Config security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Config security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Config security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Config security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/)
diff --git a/src/content/blog/aws-direct-connect-security-guide.md b/src/content/blog/aws-direct-connect-security-guide.md
deleted file mode 100644
index d5a3694..0000000
--- a/src/content/blog/aws-direct-connect-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Direct Connect Security and Encryption Options"
-description: "AWS Direct Connect Security and Encryption Options — expert guide to AWS Direct Connect security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Direct Connect
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Direct Connect security
-faq:
-  - question: Why does AWS Direct Connect security matter for cloud teams?
-    answer: AWS Direct Connect security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Direct Connect security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Direct Connect security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Direct Connect security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Direct Connect security without proprietary black boxes.
----
-
-**AWS Direct Connect security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Direct Connect security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Direct Connect security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Direct Connect security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Direct Connect security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Direct Connect security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Direct Connect security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/)
diff --git a/src/content/blog/aws-dynamodb-security-guide.md b/src/content/blog/aws-dynamodb-security-guide.md
deleted file mode 100644
index f8fbb3d..0000000
--- a/src/content/blog/aws-dynamodb-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon DynamoDB Security: IAM, Encryption, and Access Patterns"
-description: "Amazon DynamoDB Security — expert guide to AWS DynamoDB security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pra..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - DynamoDB
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS DynamoDB security
-faq:
-  - question: Why does AWS DynamoDB security matter for cloud teams?
-    answer: AWS DynamoDB security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS DynamoDB security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS DynamoDB security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS DynamoDB security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS DynamoDB security without proprietary black boxes.
----
-
-**AWS DynamoDB security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS DynamoDB security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS DynamoDB security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS DynamoDB security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS DynamoDB security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS DynamoDB security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS DynamoDB security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/)
diff --git a/src/content/blog/aws-ec2-hardening-checklist.md b/src/content/blog/aws-ec2-hardening-checklist.md
deleted file mode 100644
index dfc1eec..0000000
--- a/src/content/blog/aws-ec2-hardening-checklist.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS EC2 Hardening Checklist: AMIs, IMDS, and Patch Management"
-description: "AWS EC2 Hardening Checklist—practical guidance on AWS EC2 hardening for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - EC2
-  - CWPP
-  - cloud security
-  - hardening
-focusKeyword: AWS EC2 hardening
-faq:
-  - question: Why does AWS EC2 hardening matter for cloud teams?
-    answer: AWS EC2 hardening reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS EC2 hardening relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS EC2 hardening gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS EC2 hardening?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS EC2 hardening without proprietary black boxes.
----
-
-**AWS EC2 hardening** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS EC2 hardening matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS EC2 hardening | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) and [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS EC2 hardening with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS EC2 hardening at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS EC2 hardening program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS EC2 hardening** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/) · [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/)
diff --git a/src/content/blog/aws-ecs-security-guide.md b/src/content/blog/aws-ecs-security-guide.md
deleted file mode 100644
index abfeb0d..0000000
--- a/src/content/blog/aws-ecs-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon ECS Security: Task Roles, Networking, and Fargate Hardening"
-description: "Amazon ECS Security — expert guide to AWS ECS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - ECS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS ECS security
-faq:
-  - question: Why does AWS ECS security matter for cloud teams?
-    answer: AWS ECS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS ECS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS ECS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS ECS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS ECS security without proprietary black boxes.
----
-
-**AWS ECS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS ECS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS ECS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS ECS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS ECS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS ECS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS ECS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/aws-eks-security-guide.md b/src/content/blog/aws-eks-security-guide.md
deleted file mode 100644
index 0d02165..0000000
--- a/src/content/blog/aws-eks-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon EKS Security Hardening: Control Plane, Nodes, and IRSA"
-description: "Amazon EKS Security Hardening — expert guide to AWS EKS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pra..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - EKS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS EKS security
-faq:
-  - question: Why does AWS EKS security matter for cloud teams?
-    answer: AWS EKS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS EKS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS EKS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS EKS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS EKS security without proprietary black boxes.
----
-
-**AWS EKS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS EKS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS EKS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS EKS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS EKS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS EKS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS EKS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/)
diff --git a/src/content/blog/aws-elasticache-security-guide.md b/src/content/blog/aws-elasticache-security-guide.md
deleted file mode 100644
index 70cc764..0000000
--- a/src/content/blog/aws-elasticache-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon ElastiCache Security for Redis and Memcached"
-description: "Amazon ElastiCache Security for Redis and Memcached — expert guide to AWS ElastiCache security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - ElastiCache
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS ElastiCache security
-faq:
-  - question: Why does AWS ElastiCache security matter for cloud teams?
-    answer: AWS ElastiCache security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS ElastiCache security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS ElastiCache security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS ElastiCache security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS ElastiCache security without proprietary black boxes.
----
-
-**AWS ElastiCache security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS ElastiCache security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS ElastiCache security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [container image scanning cicd](/blog/container-image-scanning-cicd/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS ElastiCache security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS ElastiCache security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS ElastiCache security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS ElastiCache security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [container-image-scanning-cicd](/blog/container-image-scanning-cicd/)
diff --git a/src/content/blog/aws-fargate-security-guide.md b/src/content/blog/aws-fargate-security-guide.md
deleted file mode 100644
index be52502..0000000
--- a/src/content/blog/aws-fargate-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Fargate Security Best Practices for Container Workloads"
-description: "AWS Fargate Security Best Practices for Container Workloads — expert guide to AWS Fargate security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Fargate
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Fargate security
-faq:
-  - question: Why does AWS Fargate security matter for cloud teams?
-    answer: AWS Fargate security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Fargate security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Fargate security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Fargate security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Fargate security without proprietary black boxes.
----
-
-**AWS Fargate security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Fargate security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Fargate security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Fargate security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Fargate security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Fargate security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Fargate security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/)
diff --git a/src/content/blog/aws-guardduty-threat-detection.md b/src/content/blog/aws-guardduty-threat-detection.md
deleted file mode 100644
index 3a63365..0000000
--- a/src/content/blog/aws-guardduty-threat-detection.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS GuardDuty Threat Detection: Tuning Alerts for Real Incidents"
-description: "AWS GuardDuty Threat Detection—practical guidance on AWS GuardDuty for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - GuardDuty
-  - threat detection
-  - cloud security
-  - SIEM
-focusKeyword: AWS GuardDuty
-faq:
-  - question: Why does AWS GuardDuty matter for cloud teams?
-    answer: AWS GuardDuty reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS GuardDuty relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS GuardDuty gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS GuardDuty?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS GuardDuty without proprietary black boxes.
----
-
-**AWS GuardDuty** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS GuardDuty matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS GuardDuty | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [cloud incident response playbook](/blog/cloud-incident-response-playbook/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS GuardDuty with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS GuardDuty at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS GuardDuty program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS GuardDuty** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/)
diff --git a/src/content/blog/aws-inspector-security-guide.md b/src/content/blog/aws-inspector-security-guide.md
deleted file mode 100644
index 4cb9fb6..0000000
--- a/src/content/blog/aws-inspector-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Inspector for Vulnerability Management in AWS"
-description: "Amazon Inspector for Vulnerability Management in AWS — expert guide to AWS Inspector security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Inspector
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Inspector security
-faq:
-  - question: Why does AWS Inspector security matter for cloud teams?
-    answer: AWS Inspector security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Inspector security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Inspector security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Inspector security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Inspector security without proprietary black boxes.
----
-
-**AWS Inspector security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Inspector security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Inspector security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Inspector security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Inspector security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Inspector security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Inspector security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/aws-kinesis-security-guide.md b/src/content/blog/aws-kinesis-security-guide.md
deleted file mode 100644
index 4e68385..0000000
--- a/src/content/blog/aws-kinesis-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Kinesis Data Streams Security and IAM Policies"
-description: "Amazon Kinesis Data Streams Security and IAM Policies — expert guide to AWS Kinesis security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Kinesis
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Kinesis security
-faq:
-  - question: Why does AWS Kinesis security matter for cloud teams?
-    answer: AWS Kinesis security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Kinesis security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Kinesis security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Kinesis security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Kinesis security without proprietary black boxes.
----
-
-**AWS Kinesis security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Kinesis security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Kinesis security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure management groups policy](/blog/azure-management-groups-policy/) and [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Kinesis security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Kinesis security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Kinesis security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Kinesis security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-management-groups-policy](/blog/azure-management-groups-policy/) · [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/)
diff --git a/src/content/blog/aws-kms-encryption-key-management.md b/src/content/blog/aws-kms-encryption-key-management.md
deleted file mode 100644
index 2c16528..0000000
--- a/src/content/blog/aws-kms-encryption-key-management.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS KMS Key Management: Encryption Policies Teams Actually Use"
-description: "AWS KMS Key Management—practical guidance on AWS KMS security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - KMS
-  - encryption
-  - cloud security
-  - data protection
-focusKeyword: AWS KMS security
-faq:
-  - question: Why does AWS KMS security matter for cloud teams?
-    answer: AWS KMS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS KMS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS KMS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS KMS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS KMS security without proprietary black boxes.
----
-
-**AWS KMS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS KMS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS KMS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS KMS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS KMS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS KMS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS KMS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/)
diff --git a/src/content/blog/aws-lightsail-security-guide.md b/src/content/blog/aws-lightsail-security-guide.md
deleted file mode 100644
index 691ca9c..0000000
--- a/src/content/blog/aws-lightsail-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Lightsail Security Basics for Small Cloud Workloads"
-description: "Amazon Lightsail Security Basics for Small Cloud Workloads — expert guide to AWS Lightsail security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Lightsail
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Lightsail security
-faq:
-  - question: Why does AWS Lightsail security matter for cloud teams?
-    answer: AWS Lightsail security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Lightsail security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Lightsail security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Lightsail security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Lightsail security without proprietary black boxes.
----
-
-**AWS Lightsail security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Lightsail security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Lightsail security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp security command center guide](/blog/gcp-security-command-center-guide/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Lightsail security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Lightsail security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Lightsail security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Lightsail security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-security-command-center-guide](/blog/gcp-security-command-center-guide/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/aws-macie-security-guide.md b/src/content/blog/aws-macie-security-guide.md
deleted file mode 100644
index df3ee8c..0000000
--- a/src/content/blog/aws-macie-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Macie for Sensitive Data Discovery in S3"
-description: "Amazon Macie for Sensitive Data Discovery in S3 — expert guide to AWS Macie security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Macie
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Macie security
-faq:
-  - question: Why does AWS Macie security matter for cloud teams?
-    answer: AWS Macie security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Macie security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Macie security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Macie security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Macie security without proprietary black boxes.
----
-
-**AWS Macie security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Macie security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Macie security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Macie security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Macie security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Macie security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Macie security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/aws-msk-security-guide.md b/src/content/blog/aws-msk-security-guide.md
deleted file mode 100644
index a80162d..0000000
--- a/src/content/blog/aws-msk-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon MSK Security: Kafka Encryption and ACL Best Practices"
-description: "Amazon MSK Security — expert guide to AWS MSK security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - MSK
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS MSK security
-faq:
-  - question: Why does AWS MSK security matter for cloud teams?
-    answer: AWS MSK security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS MSK security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS MSK security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS MSK security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS MSK security without proprietary black boxes.
----
-
-**AWS MSK security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS MSK security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS MSK security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [multi cloud security governance](/blog/multi-cloud-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS MSK security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS MSK security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS MSK security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS MSK security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [multi-cloud-security-governance](/blog/multi-cloud-security-governance/)
diff --git a/src/content/blog/aws-network-firewall-security-guide.md b/src/content/blog/aws-network-firewall-security-guide.md
deleted file mode 100644
index 3f12dde..0000000
--- a/src/content/blog/aws-network-firewall-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Network Firewall Rules and Inspection Design"
-description: "AWS Network Firewall Rules and Inspection Design — expert guide to AWS Network Firewall security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Network Firewall
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Network Firewall security
-faq:
-  - question: Why does AWS Network Firewall security matter for cloud teams?
-    answer: AWS Network Firewall security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Network Firewall security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Network Firewall security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Network Firewall security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Network Firewall security without proprietary black boxes.
----
-
-**AWS Network Firewall security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Network Firewall security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Network Firewall security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Network Firewall security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Network Firewall security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Network Firewall security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Network Firewall security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/aws-opensearch-security-guide.md b/src/content/blog/aws-opensearch-security-guide.md
deleted file mode 100644
index 2085943..0000000
--- a/src/content/blog/aws-opensearch-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon OpenSearch Service Security and Access Policies"
-description: "Amazon OpenSearch Service Security and Access Policies — expert guide to AWS OpenSearch security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - OpenSearch
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS OpenSearch security
-faq:
-  - question: Why does AWS OpenSearch security matter for cloud teams?
-    answer: AWS OpenSearch security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS OpenSearch security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS OpenSearch security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS OpenSearch security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS OpenSearch security without proprietary black boxes.
----
-
-**AWS OpenSearch security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS OpenSearch security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS OpenSearch security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security groups best practices](/blog/aws-security-groups-best-practices/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS OpenSearch security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS OpenSearch security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS OpenSearch security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS OpenSearch security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/aws-organizations-scp-security.md b/src/content/blog/aws-organizations-scp-security.md
deleted file mode 100644
index ae90b8d..0000000
--- a/src/content/blog/aws-organizations-scp-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Organizations SCPs: Guardrails for Multi-Account Security"
-description: "AWS Organizations SCPs—practical guidance on AWS Organizations SCP for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - SCP
-  - governance
-  - cloud security
-  - IAM
-focusKeyword: AWS Organizations SCP
-faq:
-  - question: Why does AWS Organizations SCP matter for cloud teams?
-    answer: AWS Organizations SCP reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Organizations SCP relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Organizations SCP gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Organizations SCP?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Organizations SCP without proprietary black boxes.
----
-
-**AWS Organizations SCP** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Organizations SCP matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Organizations SCP | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Organizations SCP with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Organizations SCP at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Organizations SCP program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Organizations SCP** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/)
diff --git a/src/content/blog/aws-privatelink-security-guide.md b/src/content/blog/aws-privatelink-security-guide.md
deleted file mode 100644
index 3d742e6..0000000
--- a/src/content/blog/aws-privatelink-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS PrivateLink Security for Private Service Access"
-description: "AWS PrivateLink Security for Private Service Access — expert guide to AWS PrivateLink security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - PrivateLink
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS PrivateLink security
-faq:
-  - question: Why does AWS PrivateLink security matter for cloud teams?
-    answer: AWS PrivateLink security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS PrivateLink security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS PrivateLink security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS PrivateLink security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS PrivateLink security without proprietary black boxes.
----
-
-**AWS PrivateLink security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS PrivateLink security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS PrivateLink security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS PrivateLink security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS PrivateLink security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS PrivateLink security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS PrivateLink security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/aws-rds-database-security-guide.md b/src/content/blog/aws-rds-database-security-guide.md
deleted file mode 100644
index 7a6eb93..0000000
--- a/src/content/blog/aws-rds-database-security-guide.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: "AWS RDS Security Guide (moved)"
-description: "This duplicate URL is not indexed. Amazon RDS security now lives at /blog/aws-rds-security-guide/."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - RDS
-focusKeyword: Amazon RDS security
----
-
-This page is a leftover URL. The unique **Amazon RDS security** guide is:
-
-[Amazon RDS Security: Encryption, IAM Auth, and Public Access](/blog/aws-rds-security-guide/)
diff --git a/src/content/blog/aws-redshift-security-guide.md b/src/content/blog/aws-redshift-security-guide.md
deleted file mode 100644
index 265a72f..0000000
--- a/src/content/blog/aws-redshift-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Redshift Security: Data Warehouse Access Controls"
-description: "Amazon Redshift Security — expert guide to AWS Redshift security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pra..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Redshift
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Redshift security
-faq:
-  - question: Why does AWS Redshift security matter for cloud teams?
-    answer: AWS Redshift security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Redshift security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Redshift security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Redshift security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Redshift security without proprietary black boxes.
----
-
-**AWS Redshift security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Redshift security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Redshift security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) and [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Redshift security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Redshift security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Redshift security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Redshift security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/) · [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/)
diff --git a/src/content/blog/aws-route-53-security-guide.md b/src/content/blog/aws-route-53-security-guide.md
deleted file mode 100644
index 320b2f2..0000000
--- a/src/content/blog/aws-route-53-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon Route 53 Security: DNS Hijacking Prevention"
-description: "Amazon Route 53 Security — expert guide to AWS Route 53 security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pra..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Route 53
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Route 53 security
-faq:
-  - question: Why does AWS Route 53 security matter for cloud teams?
-    answer: AWS Route 53 security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Route 53 security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Route 53 security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Route 53 security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Route 53 security without proprietary black boxes.
----
-
-**AWS Route 53 security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Route 53 security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Route 53 security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) and [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Route 53 security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Route 53 security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Route 53 security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Route 53 security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/) · [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/)
diff --git a/src/content/blog/aws-secrets-manager-security-guide.md b/src/content/blog/aws-secrets-manager-security-guide.md
deleted file mode 100644
index 23ac10b..0000000
--- a/src/content/blog/aws-secrets-manager-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Secrets Manager vs Parameter Store Security Patterns"
-description: "AWS Secrets Manager vs Parameter Store Security Patterns — expert guide to AWS Secrets Manager security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP,..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Secrets Manager
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Secrets Manager security
-faq:
-  - question: Why does AWS Secrets Manager security matter for cloud teams?
-    answer: AWS Secrets Manager security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Secrets Manager security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Secrets Manager security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Secrets Manager security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Secrets Manager security without proprietary black boxes.
----
-
-**AWS Secrets Manager security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Secrets Manager security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Secrets Manager security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [kubernetes pod security standards](/blog/kubernetes-pod-security-standards/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Secrets Manager security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Secrets Manager security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Secrets Manager security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Secrets Manager security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [kubernetes-pod-security-standards](/blog/kubernetes-pod-security-standards/)
diff --git a/src/content/blog/aws-security-groups-best-practices.md b/src/content/blog/aws-security-groups-best-practices.md
deleted file mode 100644
index b4d15af..0000000
--- a/src/content/blog/aws-security-groups-best-practices.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Security Groups Best Practices: Least-Privilege Network Access"
-description: "AWS Security Groups Best Practices—practical guidance on AWS security groups for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path pri..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - security groups
-  - network security
-  - CSPM
-  - cloud security
-focusKeyword: AWS security groups
-faq:
-  - question: Why does AWS security groups matter for cloud teams?
-    answer: AWS security groups reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS security groups relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS security groups gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS security groups?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS security groups without proprietary black boxes.
----
-
-**AWS security groups** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS security groups matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS security groups | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp workload identity federation](/blog/gcp-workload-identity-federation/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS security groups with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS security groups at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS security groups program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS security groups** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/aws-security-hub-security-guide.md b/src/content/blog/aws-security-hub-security-guide.md
deleted file mode 100644
index 359e2f7..0000000
--- a/src/content/blog/aws-security-hub-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Security Hub: Centralizing Findings and Compliance"
-description: "AWS Security Hub — expert guide to AWS Security Hub security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practit..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Security Hub
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Security Hub security
-faq:
-  - question: Why does AWS Security Hub security matter for cloud teams?
-    answer: AWS Security Hub security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Security Hub security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Security Hub security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Security Hub security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Security Hub security without proprietary black boxes.
----
-
-**AWS Security Hub security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Security Hub security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Security Hub security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [gcp iam security hardening](/blog/gcp-iam-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Security Hub security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Security Hub security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Security Hub security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Security Hub security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/)
diff --git a/src/content/blog/aws-site-to-site-vpn-security-guide.md b/src/content/blog/aws-site-to-site-vpn-security-guide.md
deleted file mode 100644
index d1d0e90..0000000
--- a/src/content/blog/aws-site-to-site-vpn-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Site-to-Site VPN Security Configuration Guide"
-description: "AWS Site-to-Site VPN Security Configuration Guide — expert guide to AWS Site-to-Site VPN security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Site-to-Site VPN
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Site-to-Site VPN security
-faq:
-  - question: Why does AWS Site-to-Site VPN security matter for cloud teams?
-    answer: AWS Site-to-Site VPN security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Site-to-Site VPN security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Site-to-Site VPN security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Site-to-Site VPN security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Site-to-Site VPN security without proprietary black boxes.
----
-
-**AWS Site-to-Site VPN security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Site-to-Site VPN security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Site-to-Site VPN security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Site-to-Site VPN security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Site-to-Site VPN security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Site-to-Site VPN security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Site-to-Site VPN security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/aws-sns-security-guide.md b/src/content/blog/aws-sns-security-guide.md
deleted file mode 100644
index 1947bd3..0000000
--- a/src/content/blog/aws-sns-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon SNS Security: Topics, Policies, and Encryption"
-description: "Amazon SNS Security — expert guide to AWS SNS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - SNS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS SNS security
-faq:
-  - question: Why does AWS SNS security matter for cloud teams?
-    answer: AWS SNS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS SNS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS SNS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS SNS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS SNS security without proprietary black boxes.
----
-
-**AWS SNS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS SNS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS SNS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS SNS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS SNS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS SNS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS SNS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/aws-sqs-security-guide.md b/src/content/blog/aws-sqs-security-guide.md
deleted file mode 100644
index c56b9fd..0000000
--- a/src/content/blog/aws-sqs-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Amazon SQS Security: Queues, Policies, and Dead-Letter Handling"
-description: "Amazon SQS Security — expert guide to AWS SQS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - SQS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS SQS security
-faq:
-  - question: Why does AWS SQS security matter for cloud teams?
-    answer: AWS SQS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS SQS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS SQS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS SQS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS SQS security without proprietary black boxes.
----
-
-**AWS SQS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS SQS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS SQS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS SQS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS SQS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS SQS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS SQS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/aws-sso-iam-identity-center-hardening.md b/src/content/blog/aws-sso-iam-identity-center-hardening.md
deleted file mode 100644
index 5e9cf4f..0000000
--- a/src/content/blog/aws-sso-iam-identity-center-hardening.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS IAM Identity Center Hardening: SSO Permission Sets Done Right"
-description: "AWS IAM Identity Center Hardening—practical guidance on AWS IAM Identity Center for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - IAM Identity Center
-  - CIEM
-  - cloud security
-  - SSO
-focusKeyword: AWS IAM Identity Center
-faq:
-  - question: Why does AWS IAM Identity Center matter for cloud teams?
-    answer: AWS IAM Identity Center reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS IAM Identity Center relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS IAM Identity Center gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS IAM Identity Center?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS IAM Identity Center without proprietary black boxes.
----
-
-**AWS IAM Identity Center** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS IAM Identity Center matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS IAM Identity Center | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [serverless security lambda azure functions](/blog/serverless-security-lambda-azure-functions/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS IAM Identity Center with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS IAM Identity Center at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS IAM Identity Center program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS IAM Identity Center** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [serverless-security-lambda-azure-functions](/blog/serverless-security-lambda-azure-functions/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/aws-step-functions-security-guide.md b/src/content/blog/aws-step-functions-security-guide.md
deleted file mode 100644
index 39348d7..0000000
--- a/src/content/blog/aws-step-functions-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Step Functions Security and State Machine IAM"
-description: "AWS Step Functions Security and State Machine IAM — expert guide to AWS Step Functions security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Step Functions
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Step Functions security
-faq:
-  - question: Why does AWS Step Functions security matter for cloud teams?
-    answer: AWS Step Functions security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Step Functions security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Step Functions security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Step Functions security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Step Functions security without proprietary black boxes.
----
-
-**AWS Step Functions security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Step Functions security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Step Functions security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Step Functions security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Step Functions security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Step Functions security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Step Functions security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/aws-systems-manager-security-guide.md b/src/content/blog/aws-systems-manager-security-guide.md
deleted file mode 100644
index 45bc076..0000000
--- a/src/content/blog/aws-systems-manager-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Systems Manager Security for Patch and Session Manager"
-description: "AWS Systems Manager Security for Patch and Session Manager — expert guide to AWS Systems Manager security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAP..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Systems Manager
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Systems Manager security
-faq:
-  - question: Why does AWS Systems Manager security matter for cloud teams?
-    answer: AWS Systems Manager security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Systems Manager security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Systems Manager security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Systems Manager security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Systems Manager security without proprietary black boxes.
----
-
-**AWS Systems Manager security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Systems Manager security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Systems Manager security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [azure defender cloud security](/blog/azure-defender-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Systems Manager security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Systems Manager security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Systems Manager security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Systems Manager security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [azure-defender-cloud-security](/blog/azure-defender-cloud-security/)
diff --git a/src/content/blog/aws-transit-gateway-security-guide.md b/src/content/blog/aws-transit-gateway-security-guide.md
deleted file mode 100644
index 209aa06..0000000
--- a/src/content/blog/aws-transit-gateway-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS Transit Gateway Security and Segmentation Patterns"
-description: "AWS Transit Gateway Security and Segmentation Patterns — expert guide to AWS Transit Gateway security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - Transit Gateway
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: AWS Transit Gateway security
-faq:
-  - question: Why does AWS Transit Gateway security matter for cloud teams?
-    answer: AWS Transit Gateway security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS Transit Gateway security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS Transit Gateway security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS Transit Gateway security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS Transit Gateway security without proprietary black boxes.
----
-
-**AWS Transit Gateway security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS Transit Gateway security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS Transit Gateway security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS Transit Gateway security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS Transit Gateway security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS Transit Gateway security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS Transit Gateway security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/aws-waf-web-application-firewall-guide.md b/src/content/blog/aws-waf-web-application-firewall-guide.md
deleted file mode 100644
index 216b4fd..0000000
--- a/src/content/blog/aws-waf-web-application-firewall-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "AWS WAF Guide: Rules, Managed Groups, and Logging"
-description: "AWS WAF Guide—practical guidance on AWS WAF for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - WAF
-  - application security
-  - cloud security
-  - DDoS
-focusKeyword: AWS WAF
-faq:
-  - question: Why does AWS WAF matter for cloud teams?
-    answer: AWS WAF reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does AWS WAF relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether AWS WAF gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support AWS WAF?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize AWS WAF without proprietary black boxes.
----
-
-**AWS WAF** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why AWS WAF matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without AWS WAF | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure application gateway waf](/blog/azure-application-gateway-waf/) and [gcp iam security hardening](/blog/gcp-iam-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align AWS WAF with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce AWS WAF at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature AWS WAF program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **AWS WAF** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-application-gateway-waf](/blog/azure-application-gateway-waf/) · [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/)
diff --git a/src/content/blog/azure-acr-security-guide.md b/src/content/blog/azure-acr-security-guide.md
deleted file mode 100644
index e75836d..0000000
--- a/src/content/blog/azure-acr-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Container Registry Security and Image Scanning"
-description: "Azure Container Registry Security and Image Scanning — expert guide to Azure ACR security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - ACR
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure ACR security
-faq:
-  - question: Why does Azure ACR security matter for cloud teams?
-    answer: Azure ACR security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure ACR security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure ACR security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure ACR security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure ACR security without proprietary black boxes.
----
-
-**Azure ACR security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure ACR security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure ACR security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) and [cspm vs cnapp whats the difference](/blog/cspm-vs-cnapp-whats-the-difference/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure ACR security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure ACR security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure ACR security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure ACR security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/) · [CSPM vs CNAPP](/blog/cspm-vs-cnapp-whats-the-difference/)
diff --git a/src/content/blog/azure-ad-privileged-identity-management.md b/src/content/blog/azure-ad-privileged-identity-management.md
deleted file mode 100644
index 5dcbc48..0000000
--- a/src/content/blog/azure-ad-privileged-identity-management.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Privileged Identity Management for Cloud Administrators"
-description: "Azure Privileged Identity Management for Cloud Administrators—practical guidance on Azure Privileged Identity Management for AWS, Azure, GCP, and Kubernetes ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - PIM
-  - CIEM
-  - cloud security
-  - identity
-focusKeyword: Azure Privileged Identity Management
-faq:
-  - question: Why does Azure Privileged Identity Management matter for cloud teams?
-    answer: Azure Privileged Identity Management reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Privileged Identity Management relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Privileged Identity Management gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Privileged Identity Management?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Privileged Identity Management without proprietary black boxes.
----
-
-**Azure Privileged Identity Management** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Privileged Identity Management matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Privileged Identity Management | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Privileged Identity Management with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Privileged Identity Management at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Privileged Identity Management program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Privileged Identity Management** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/azure-aks-security-guide.md b/src/content/blog/azure-aks-security-guide.md
deleted file mode 100644
index 3752a77..0000000
--- a/src/content/blog/azure-aks-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Kubernetes Service Security Hardening Guide"
-description: "Azure Kubernetes Service Security Hardening Guide — expert guide to Azure AKS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - AKS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure AKS security
-faq:
-  - question: Why does Azure AKS security matter for cloud teams?
-    answer: Azure AKS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure AKS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure AKS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure AKS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure AKS security without proprietary black boxes.
----
-
-**Azure AKS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure AKS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure AKS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure AKS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure AKS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure AKS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure AKS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/azure-api-management-security-guide.md b/src/content/blog/azure-api-management-security-guide.md
deleted file mode 100644
index 6d20359..0000000
--- a/src/content/blog/azure-api-management-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure API Management Security: OAuth and Rate Limits"
-description: "Azure API Management Security — expert guide to Azure API Management security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritiz..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - API Management
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure API Management security
-faq:
-  - question: Why does Azure API Management security matter for cloud teams?
-    answer: Azure API Management security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure API Management security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure API Management security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure API Management security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure API Management security without proprietary black boxes.
----
-
-**Azure API Management security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure API Management security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure API Management security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure API Management security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure API Management security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure API Management security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure API Management security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/)
diff --git a/src/content/blog/azure-app-service-security-guide.md b/src/content/blog/azure-app-service-security-guide.md
deleted file mode 100644
index ca28dbe..0000000
--- a/src/content/blog/azure-app-service-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure App Service Security for Web Applications"
-description: "Azure App Service Security for Web Applications — expert guide to Azure App Service security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - App Service
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure App Service security
-faq:
-  - question: Why does Azure App Service security matter for cloud teams?
-    answer: Azure App Service security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure App Service security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure App Service security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure App Service security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure App Service security without proprietary black boxes.
----
-
-**Azure App Service security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure App Service security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure App Service security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) and [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure App Service security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure App Service security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure App Service security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure App Service security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/) · [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/)
diff --git a/src/content/blog/azure-arc-security-guide.md b/src/content/blog/azure-arc-security-guide.md
deleted file mode 100644
index 2359e86..0000000
--- a/src/content/blog/azure-arc-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Arc Security for Hybrid and Multi-Cloud Servers"
-description: "Azure Arc Security for Hybrid and Multi-Cloud Servers — expert guide to Azure Arc security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Arc
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Arc security
-faq:
-  - question: Why does Azure Arc security matter for cloud teams?
-    answer: Azure Arc security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Arc security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Arc security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Arc security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Arc security without proprietary black boxes.
----
-
-**Azure Arc security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Arc security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Arc security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [serverless security lambda azure functions](/blog/serverless-security-lambda-azure-functions/) and [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Arc security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Arc security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Arc security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Arc security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [serverless-security-lambda-azure-functions](/blog/serverless-security-lambda-azure-functions/) · [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/)
diff --git a/src/content/blog/azure-automation-security-guide.md b/src/content/blog/azure-automation-security-guide.md
deleted file mode 100644
index 6ddf6e3..0000000
--- a/src/content/blog/azure-automation-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Automation Security for Runbooks and Updates"
-description: "Azure Automation Security for Runbooks and Updates — expert guide to Azure Automation security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Automation
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Automation security
-faq:
-  - question: Why does Azure Automation security matter for cloud teams?
-    answer: Azure Automation security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Automation security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Automation security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Automation security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Automation security without proprietary black boxes.
----
-
-**Azure Automation security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Automation security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Automation security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [serverless security lambda azure functions](/blog/serverless-security-lambda-azure-functions/) and [azure application gateway waf](/blog/azure-application-gateway-waf/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Automation security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Automation security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Automation security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Automation security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [serverless-security-lambda-azure-functions](/blog/serverless-security-lambda-azure-functions/) · [azure-application-gateway-waf](/blog/azure-application-gateway-waf/)
diff --git a/src/content/blog/azure-backup-security-guide.md b/src/content/blog/azure-backup-security-guide.md
deleted file mode 100644
index 4d3efee..0000000
--- a/src/content/blog/azure-backup-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Backup Security: Vaults, Encryption, and RBAC"
-description: "Azure Backup Security — expert guide to Azure Backup security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practi..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Backup
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Backup security
-faq:
-  - question: Why does Azure Backup security matter for cloud teams?
-    answer: Azure Backup security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Backup security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Backup security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Backup security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Backup security without proprietary black boxes.
----
-
-**Azure Backup security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Backup security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Backup security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [serverless security lambda azure functions](/blog/serverless-security-lambda-azure-functions/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Backup security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Backup security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Backup security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Backup security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [serverless-security-lambda-azure-functions](/blog/serverless-security-lambda-azure-functions/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/azure-bastion-security-guide.md b/src/content/blog/azure-bastion-security-guide.md
deleted file mode 100644
index 685ed69..0000000
--- a/src/content/blog/azure-bastion-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Bastion Security for Secure RDP and SSH Access"
-description: "Azure Bastion Security for Secure RDP and SSH Access — expert guide to Azure Bastion security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Bastion
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Bastion security
-faq:
-  - question: Why does Azure Bastion security matter for cloud teams?
-    answer: Azure Bastion security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Bastion security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Bastion security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Bastion security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Bastion security without proprietary black boxes.
----
-
-**Azure Bastion security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Bastion security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Bastion security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Bastion security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Bastion security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Bastion security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Bastion security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/azure-batch-security-guide.md b/src/content/blog/azure-batch-security-guide.md
deleted file mode 100644
index f9ca526..0000000
--- a/src/content/blog/azure-batch-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Batch Security for High-Performance Computing"
-description: "Azure Batch Security for High-Performance Computing — expert guide to Azure Batch security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Batch
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Batch security
-faq:
-  - question: Why does Azure Batch security matter for cloud teams?
-    answer: Azure Batch security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Batch security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Batch security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Batch security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Batch security without proprietary black boxes.
----
-
-**Azure Batch security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Batch security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Batch security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [aws security groups best practices](/blog/aws-security-groups-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Batch security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Batch security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Batch security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Batch security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/)
diff --git a/src/content/blog/azure-blob-storage-security-guide.md b/src/content/blog/azure-blob-storage-security-guide.md
deleted file mode 100644
index 9fd81ed..0000000
--- a/src/content/blog/azure-blob-storage-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Blob Storage Security: Access Tiers, SAS, and Private Link"
-description: "Azure Blob Storage Security—practical guidance on Azure blob storage security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - blob storage
-  - data security
-  - CSPM
-  - cloud security
-focusKeyword: Azure blob storage security
-faq:
-  - question: Why does Azure blob storage security matter for cloud teams?
-    answer: Azure blob storage security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure blob storage security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure blob storage security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure blob storage security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure blob storage security without proprietary black boxes.
----
-
-**Azure blob storage security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure blob storage security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure blob storage security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [azure network security groups guide](/blog/azure-network-security-groups-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure blob storage security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure blob storage security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure blob storage security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure blob storage security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/)
diff --git a/src/content/blog/azure-cdn-security-guide.md b/src/content/blog/azure-cdn-security-guide.md
deleted file mode 100644
index d4e5c0f..0000000
--- a/src/content/blog/azure-cdn-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure CDN Security: TLS, Origin Protection, and Rules"
-description: "Azure CDN Security — expert guide to Azure CDN security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - CDN
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure CDN security
-faq:
-  - question: Why does Azure CDN security matter for cloud teams?
-    answer: Azure CDN security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure CDN security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure CDN security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure CDN security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure CDN security without proprietary black boxes.
----
-
-**Azure CDN security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure CDN security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure CDN security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure vm security baseline](/blog/azure-vm-security-baseline/) and [azure management groups policy](/blog/azure-management-groups-policy/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure CDN security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure CDN security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure CDN security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure CDN security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-vm-security-baseline](/blog/azure-vm-security-baseline/) · [azure-management-groups-policy](/blog/azure-management-groups-policy/)
diff --git a/src/content/blog/azure-communication-services-security-guide.md b/src/content/blog/azure-communication-services-security-guide.md
deleted file mode 100644
index 37a8356..0000000
--- a/src/content/blog/azure-communication-services-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Communication Services Security Guide"
-description: "Azure Communication Services Security Guide — expert guide to Azure Communication Services security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Communication Services
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Communication Services security
-faq:
-  - question: Why does Azure Communication Services security matter for cloud teams?
-    answer: Azure Communication Services security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Communication Services security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Communication Services security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Communication Services security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Communication Services security without proprietary black boxes.
----
-
-**Azure Communication Services security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Communication Services security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Communication Services security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Communication Services security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Communication Services security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Communication Services security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Communication Services security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/azure-container-instances-security-guide.md b/src/content/blog/azure-container-instances-security-guide.md
deleted file mode 100644
index eaff58d..0000000
--- a/src/content/blog/azure-container-instances-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Container Instances Security Patterns"
-description: "Azure Container Instances Security Patterns — expert guide to Azure Container Instances security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Container Instances
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Container Instances security
-faq:
-  - question: Why does Azure Container Instances security matter for cloud teams?
-    answer: Azure Container Instances security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Container Instances security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Container Instances security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Container Instances security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Container Instances security without proprietary black boxes.
----
-
-**Azure Container Instances security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Container Instances security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Container Instances security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Container Instances security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Container Instances security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Container Instances security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Container Instances security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/azure-cosmos-db-security-guide.md b/src/content/blog/azure-cosmos-db-security-guide.md
deleted file mode 100644
index c8b55ce..0000000
--- a/src/content/blog/azure-cosmos-db-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Cosmos DB Security: RBAC, Firewall, and Encryption"
-description: "Azure Cosmos DB Security — expert guide to Azure Cosmos DB security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Cosmos DB
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Cosmos DB security
-faq:
-  - question: Why does Azure Cosmos DB security matter for cloud teams?
-    answer: Azure Cosmos DB security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Cosmos DB security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Cosmos DB security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Cosmos DB security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Cosmos DB security without proprietary black boxes.
----
-
-**Azure Cosmos DB security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Cosmos DB security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Cosmos DB security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) and [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Cosmos DB security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Cosmos DB security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Cosmos DB security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Cosmos DB security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/) · [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/)
diff --git a/src/content/blog/azure-data-lake-security-guide.md b/src/content/blog/azure-data-lake-security-guide.md
deleted file mode 100644
index b34341b..0000000
--- a/src/content/blog/azure-data-lake-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Data Lake Storage Security and Access Control"
-description: "Azure Data Lake Storage Security and Access Control — expert guide to Azure Data Lake security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Data Lake
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Data Lake security
-faq:
-  - question: Why does Azure Data Lake security matter for cloud teams?
-    answer: Azure Data Lake security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Data Lake security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Data Lake security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Data Lake security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Data Lake security without proprietary black boxes.
----
-
-**Azure Data Lake security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Data Lake security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Data Lake security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) and [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Data Lake security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Data Lake security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Data Lake security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Data Lake security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/) · [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/)
diff --git a/src/content/blog/azure-ddos-protection-security-guide.md b/src/content/blog/azure-ddos-protection-security-guide.md
deleted file mode 100644
index d1ca297..0000000
--- a/src/content/blog/azure-ddos-protection-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure DDoS Protection Standard Configuration Guide"
-description: "Azure DDoS Protection Standard Configuration Guide — expert guide to Azure DDoS Protection security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - DDoS Protection
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure DDoS Protection security
-faq:
-  - question: Why does Azure DDoS Protection security matter for cloud teams?
-    answer: Azure DDoS Protection security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure DDoS Protection security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure DDoS Protection security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure DDoS Protection security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure DDoS Protection security without proprietary black boxes.
----
-
-**Azure DDoS Protection security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure DDoS Protection security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure DDoS Protection security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure DDoS Protection security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure DDoS Protection security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure DDoS Protection security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure DDoS Protection security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/azure-defender-cloud-security.md b/src/content/blog/azure-defender-cloud-security.md
deleted file mode 100644
index ce6ab03..0000000
--- a/src/content/blog/azure-defender-cloud-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Microsoft Defender for Cloud: Plans, Alerts, and Integration"
-description: "Microsoft Defender for Cloud—practical guidance on Azure Defender for Cloud for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Defender for Cloud
-  - CSPM
-  - cloud security
-  - threat detection
-focusKeyword: Azure Defender for Cloud
-faq:
-  - question: Why does Azure Defender for Cloud matter for cloud teams?
-    answer: Azure Defender for Cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Defender for Cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Defender for Cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Defender for Cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Defender for Cloud without proprietary black boxes.
----
-
-**Azure Defender for Cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Defender for Cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Defender for Cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Defender for Cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Defender for Cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Defender for Cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Defender for Cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/)
diff --git a/src/content/blog/azure-devops-security-guide.md b/src/content/blog/azure-devops-security-guide.md
deleted file mode 100644
index 6b40798..0000000
--- a/src/content/blog/azure-devops-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure DevOps Security: Pipelines, Repos, and Secrets"
-description: "Azure DevOps Security — expert guide to Azure DevOps security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practi..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - DevOps
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure DevOps security
-faq:
-  - question: Why does Azure DevOps security matter for cloud teams?
-    answer: Azure DevOps security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure DevOps security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure DevOps security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure DevOps security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure DevOps security without proprietary black boxes.
----
-
-**Azure DevOps security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure DevOps security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure DevOps security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure DevOps security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure DevOps security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure DevOps security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure DevOps security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/azure-digital-twins-security-guide.md b/src/content/blog/azure-digital-twins-security-guide.md
deleted file mode 100644
index cefe09f..0000000
--- a/src/content/blog/azure-digital-twins-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Digital Twins Security for IoT Platforms"
-description: "Azure Digital Twins Security for IoT Platforms — expert guide to Azure Digital Twins security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Digital Twins
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Digital Twins security
-faq:
-  - question: Why does Azure Digital Twins security matter for cloud teams?
-    answer: Azure Digital Twins security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Digital Twins security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Digital Twins security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Digital Twins security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Digital Twins security without proprietary black boxes.
----
-
-**Azure Digital Twins security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Digital Twins security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Digital Twins security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) and [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Digital Twins security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Digital Twins security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Digital Twins security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Digital Twins security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) · [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/)
diff --git a/src/content/blog/azure-event-hubs-security-guide.md b/src/content/blog/azure-event-hubs-security-guide.md
deleted file mode 100644
index 3aee3f9..0000000
--- a/src/content/blog/azure-event-hubs-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Event Hubs Security for Streaming Data"
-description: "Azure Event Hubs Security for Streaming Data — expert guide to Azure Event Hubs security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Event Hubs
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Event Hubs security
-faq:
-  - question: Why does Azure Event Hubs security matter for cloud teams?
-    answer: Azure Event Hubs security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Event Hubs security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Event Hubs security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Event Hubs security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Event Hubs security without proprietary black boxes.
----
-
-**Azure Event Hubs security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Event Hubs security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Event Hubs security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp security command center guide](/blog/gcp-security-command-center-guide/) and [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Event Hubs security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Event Hubs security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Event Hubs security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Event Hubs security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-security-command-center-guide](/blog/gcp-security-command-center-guide/) · [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/)
diff --git a/src/content/blog/azure-expressroute-security-guide.md b/src/content/blog/azure-expressroute-security-guide.md
deleted file mode 100644
index f6db786..0000000
--- a/src/content/blog/azure-expressroute-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure ExpressRoute Security and Private Connectivity"
-description: "Azure ExpressRoute Security and Private Connectivity — expert guide to Azure ExpressRoute security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - ExpressRoute
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure ExpressRoute security
-faq:
-  - question: Why does Azure ExpressRoute security matter for cloud teams?
-    answer: Azure ExpressRoute security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure ExpressRoute security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure ExpressRoute security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure ExpressRoute security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure ExpressRoute security without proprietary black boxes.
----
-
-**Azure ExpressRoute security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure ExpressRoute security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure ExpressRoute security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security groups best practices](/blog/aws-security-groups-best-practices/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure ExpressRoute security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure ExpressRoute security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure ExpressRoute security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure ExpressRoute security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/azure-firewall-security-guide.md b/src/content/blog/azure-firewall-security-guide.md
deleted file mode 100644
index 0ab551f..0000000
--- a/src/content/blog/azure-firewall-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Firewall Policy Design for Cloud Networks"
-description: "Azure Firewall Policy Design for Cloud Networks — expert guide to Azure Firewall security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Firewall
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Firewall security
-faq:
-  - question: Why does Azure Firewall security matter for cloud teams?
-    answer: Azure Firewall security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Firewall security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Firewall security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Firewall security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Firewall security without proprietary black boxes.
----
-
-**Azure Firewall security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Firewall security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Firewall security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [ciem explained for cloud teams](/blog/ciem-explained-for-cloud-teams/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Firewall security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Firewall security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Firewall security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Firewall security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [CIEM explained](/blog/ciem-explained-for-cloud-teams/)
diff --git a/src/content/blog/azure-front-door-security-guide.md b/src/content/blog/azure-front-door-security-guide.md
deleted file mode 100644
index b9b99b9..0000000
--- a/src/content/blog/azure-front-door-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Front Door Security with WAF and Private Link"
-description: "Azure Front Door Security with WAF and Private Link — expert guide to Azure Front Door security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Front Door
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Front Door security
-faq:
-  - question: Why does Azure Front Door security matter for cloud teams?
-    answer: Azure Front Door security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Front Door security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Front Door security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Front Door security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Front Door security without proprietary black boxes.
----
-
-**Azure Front Door security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Front Door security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Front Door security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) and [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Front Door security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Front Door security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Front Door security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Front Door security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/) · [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/)
diff --git a/src/content/blog/azure-functions-security-guide.md b/src/content/blog/azure-functions-security-guide.md
deleted file mode 100644
index 6ebc554..0000000
--- a/src/content/blog/azure-functions-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Functions Security: Managed Identity and Networking"
-description: "Azure Functions Security — expert guide to Azure Functions security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Functions
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Functions security
-faq:
-  - question: Why does Azure Functions security matter for cloud teams?
-    answer: Azure Functions security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Functions security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Functions security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Functions security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Functions security without proprietary black boxes.
----
-
-**Azure Functions security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Functions security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Functions security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) and [gcp security command center guide](/blog/gcp-security-command-center-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Functions security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Functions security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Functions security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Functions security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/) · [gcp-security-command-center-guide](/blog/gcp-security-command-center-guide/)
diff --git a/src/content/blog/azure-information-protection-security-guide.md b/src/content/blog/azure-information-protection-security-guide.md
deleted file mode 100644
index d6ed931..0000000
--- a/src/content/blog/azure-information-protection-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Microsoft Information Protection in Azure Workloads"
-description: "Microsoft Information Protection in Azure Workloads — expert guide to Azure Information Protection security for AWS, Azure, GCP, and Kubernetes with CSPM, CN..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Information Protection
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Information Protection security
-faq:
-  - question: Why does Azure Information Protection security matter for cloud teams?
-    answer: Azure Information Protection security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Information Protection security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Information Protection security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Information Protection security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Information Protection security without proprietary black boxes.
----
-
-**Azure Information Protection security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Information Protection security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Information Protection security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Information Protection security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Information Protection security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Information Protection security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Information Protection security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/azure-iot-hub-security-guide.md b/src/content/blog/azure-iot-hub-security-guide.md
deleted file mode 100644
index 8d8f3ae..0000000
--- a/src/content/blog/azure-iot-hub-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure IoT Hub Security: Device Identity and Monitoring"
-description: "Azure IoT Hub Security — expert guide to Azure IoT Hub security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for prac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - IoT Hub
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure IoT Hub security
-faq:
-  - question: Why does Azure IoT Hub security matter for cloud teams?
-    answer: Azure IoT Hub security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure IoT Hub security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure IoT Hub security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure IoT Hub security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure IoT Hub security without proprietary black boxes.
----
-
-**Azure IoT Hub security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure IoT Hub security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure IoT Hub security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure application gateway waf](/blog/azure-application-gateway-waf/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure IoT Hub security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure IoT Hub security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure IoT Hub security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure IoT Hub security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-application-gateway-waf](/blog/azure-application-gateway-waf/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/azure-key-vault-security-hardening.md b/src/content/blog/azure-key-vault-security-hardening.md
deleted file mode 100644
index 11d2397..0000000
--- a/src/content/blog/azure-key-vault-security-hardening.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Key Vault Security Hardening for Production Workloads"
-description: "Azure Key Vault Security Hardening for Production Workloads—practical guidance on Azure Key Vault security for AWS, Azure, GCP, and Kubernetes teams using CS..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Key Vault
-  - encryption
-  - cloud security
-  - secrets management
-focusKeyword: Azure Key Vault security
-faq:
-  - question: Why does Azure Key Vault security matter for cloud teams?
-    answer: Azure Key Vault security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Key Vault security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Key Vault security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Key Vault security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Key Vault security without proprietary black boxes.
----
-
-**Azure Key Vault security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Key Vault security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Key Vault security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Key Vault security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Key Vault security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Key Vault security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Key Vault security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/azure-load-balancer-security-guide.md b/src/content/blog/azure-load-balancer-security-guide.md
deleted file mode 100644
index 23a076d..0000000
--- a/src/content/blog/azure-load-balancer-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Load Balancer Security and NSG Integration"
-description: "Azure Load Balancer Security and NSG Integration — expert guide to Azure Load Balancer security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Load Balancer
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Load Balancer security
-faq:
-  - question: Why does Azure Load Balancer security matter for cloud teams?
-    answer: Azure Load Balancer security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Load Balancer security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Load Balancer security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Load Balancer security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Load Balancer security without proprietary black boxes.
----
-
-**Azure Load Balancer security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Load Balancer security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Load Balancer security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [exposure management cloud security](/blog/exposure-management-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Load Balancer security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Load Balancer security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Load Balancer security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Load Balancer security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [exposure-management-cloud-security](/blog/exposure-management-cloud-security/)
diff --git a/src/content/blog/azure-logic-apps-security-guide.md b/src/content/blog/azure-logic-apps-security-guide.md
deleted file mode 100644
index 2d998c7..0000000
--- a/src/content/blog/azure-logic-apps-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Logic Apps Security for Workflow Automation"
-description: "Azure Logic Apps Security for Workflow Automation — expert guide to Azure Logic Apps security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Logic Apps
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Logic Apps security
-faq:
-  - question: Why does Azure Logic Apps security matter for cloud teams?
-    answer: Azure Logic Apps security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Logic Apps security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Logic Apps security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Logic Apps security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Logic Apps security without proprietary black boxes.
----
-
-**Azure Logic Apps security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Logic Apps security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Logic Apps security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp compute engine security hardening](/blog/gcp-compute-engine-security-hardening/) and [ciem explained for cloud teams](/blog/ciem-explained-for-cloud-teams/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Logic Apps security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Logic Apps security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Logic Apps security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Logic Apps security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-compute-engine-security-hardening](/blog/gcp-compute-engine-security-hardening/) · [CIEM explained](/blog/ciem-explained-for-cloud-teams/)
diff --git a/src/content/blog/azure-machine-learning-security-guide.md b/src/content/blog/azure-machine-learning-security-guide.md
deleted file mode 100644
index 8ed7784..0000000
--- a/src/content/blog/azure-machine-learning-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Machine Learning Security for MLOps Teams"
-description: "Azure Machine Learning Security for MLOps Teams — expert guide to Azure Machine Learning security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Machine Learning
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Machine Learning security
-faq:
-  - question: Why does Azure Machine Learning security matter for cloud teams?
-    answer: Azure Machine Learning security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Machine Learning security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Machine Learning security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Machine Learning security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Machine Learning security without proprietary black boxes.
----
-
-**Azure Machine Learning security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Machine Learning security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Machine Learning security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security groups best practices](/blog/aws-security-groups-best-practices/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Machine Learning security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Machine Learning security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Machine Learning security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Machine Learning security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/azure-management-groups-policy.md b/src/content/blog/azure-management-groups-policy.md
deleted file mode 100644
index dc2fb7c..0000000
--- a/src/content/blog/azure-management-groups-policy.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Management Groups and Policy: Enterprise Guardrails"
-description: "Azure Management Groups and Policy—practical guidance on Azure management groups policy for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Azure Policy
-  - governance
-  - CSPM
-  - cloud security
-focusKeyword: Azure management groups policy
-faq:
-  - question: Why does Azure management groups policy matter for cloud teams?
-    answer: Azure management groups policy reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure management groups policy relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure management groups policy gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure management groups policy?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure management groups policy without proprietary black boxes.
----
-
-**Azure management groups policy** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure management groups policy matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure management groups policy | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure management groups policy with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure management groups policy at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure management groups policy program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure management groups policy** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/)
diff --git a/src/content/blog/azure-monitor-security-guide.md b/src/content/blog/azure-monitor-security-guide.md
deleted file mode 100644
index 8cd1187..0000000
--- a/src/content/blog/azure-monitor-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Monitor Security Logging and Alert Rules"
-description: "Azure Monitor Security Logging and Alert Rules — expert guide to Azure Monitor security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Monitor
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Monitor security
-faq:
-  - question: Why does Azure Monitor security matter for cloud teams?
-    answer: Azure Monitor security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Monitor security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Monitor security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Monitor security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Monitor security without proprietary black boxes.
----
-
-**Azure Monitor security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Monitor security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Monitor security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Monitor security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Monitor security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Monitor security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Monitor security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/azure-mysql-security-guide.md b/src/content/blog/azure-mysql-security-guide.md
deleted file mode 100644
index 2b9a6e9..0000000
--- a/src/content/blog/azure-mysql-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Database for MySQL Security Best Practices"
-description: "Azure Database for MySQL Security Best Practices — expert guide to Azure MySQL security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - MySQL
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure MySQL security
-faq:
-  - question: Why does Azure MySQL security matter for cloud teams?
-    answer: Azure MySQL security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure MySQL security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure MySQL security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure MySQL security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure MySQL security without proprietary black boxes.
----
-
-**Azure MySQL security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure MySQL security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure MySQL security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) and [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure MySQL security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure MySQL security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure MySQL security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure MySQL security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/) · [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/)
diff --git a/src/content/blog/azure-network-security-groups-guide.md b/src/content/blog/azure-network-security-groups-guide.md
deleted file mode 100644
index f0254c3..0000000
--- a/src/content/blog/azure-network-security-groups-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure NSG Rules: A Practical Security Guide for Cloud Teams"
-description: "Azure NSG Rules—practical guidance on Azure NSG security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - NSG
-  - network security
-  - CSPM
-  - cloud security
-focusKeyword: Azure NSG security
-faq:
-  - question: Why does Azure NSG security matter for cloud teams?
-    answer: Azure NSG security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure NSG security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure NSG security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure NSG security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure NSG security without proprietary black boxes.
----
-
-**Azure NSG security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure NSG security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure NSG security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [gcp workload identity federation](/blog/gcp-workload-identity-federation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure NSG security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure NSG security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure NSG security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure NSG security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/)
diff --git a/src/content/blog/azure-openai-service-security-guide.md b/src/content/blog/azure-openai-service-security-guide.md
deleted file mode 100644
index 6f4c2a4..0000000
--- a/src/content/blog/azure-openai-service-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure OpenAI Service Security and Data Residency"
-description: "Azure OpenAI Service Security and Data Residency — expert guide to Azure OpenAI Service security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - OpenAI Service
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure OpenAI Service security
-faq:
-  - question: Why does Azure OpenAI Service security matter for cloud teams?
-    answer: Azure OpenAI Service security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure OpenAI Service security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure OpenAI Service security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure OpenAI Service security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure OpenAI Service security without proprietary black boxes.
----
-
-**Azure OpenAI Service security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure OpenAI Service security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure OpenAI Service security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure OpenAI Service security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure OpenAI Service security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure OpenAI Service security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure OpenAI Service security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/azure-postgresql-security-guide.md b/src/content/blog/azure-postgresql-security-guide.md
deleted file mode 100644
index 3635cb2..0000000
--- a/src/content/blog/azure-postgresql-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Database for PostgreSQL Security Hardening"
-description: "Azure Database for PostgreSQL Security Hardening — expert guide to Azure PostgreSQL security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - PostgreSQL
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure PostgreSQL security
-faq:
-  - question: Why does Azure PostgreSQL security matter for cloud teams?
-    answer: Azure PostgreSQL security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure PostgreSQL security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure PostgreSQL security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure PostgreSQL security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure PostgreSQL security without proprietary black boxes.
----
-
-**Azure PostgreSQL security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure PostgreSQL security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure PostgreSQL security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [ciem explained for cloud teams](/blog/ciem-explained-for-cloud-teams/) and [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure PostgreSQL security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure PostgreSQL security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure PostgreSQL security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure PostgreSQL security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [CIEM explained](/blog/ciem-explained-for-cloud-teams/) · [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/)
diff --git a/src/content/blog/azure-purview-security-guide.md b/src/content/blog/azure-purview-security-guide.md
deleted file mode 100644
index b0d06c5..0000000
--- a/src/content/blog/azure-purview-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Microsoft Purview for Cloud Data Governance and DSPM"
-description: "Microsoft Purview for Cloud Data Governance and DSPM — expert guide to Azure Purview security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Purview
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Purview security
-faq:
-  - question: Why does Azure Purview security matter for cloud teams?
-    answer: Azure Purview security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Purview security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Purview security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Purview security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Purview security without proprietary black boxes.
----
-
-**Azure Purview security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Purview security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Purview security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Purview security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Purview security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Purview security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Purview security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/azure-redis-security-guide.md b/src/content/blog/azure-redis-security-guide.md
deleted file mode 100644
index 605a84b..0000000
--- a/src/content/blog/azure-redis-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Cache for Redis Security and Network Isolation"
-description: "Azure Cache for Redis Security and Network Isolation — expert guide to Azure Redis security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Redis
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Redis security
-faq:
-  - question: Why does Azure Redis security matter for cloud teams?
-    answer: Azure Redis security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Redis security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Redis security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Redis security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Redis security without proprietary black boxes.
----
-
-**Azure Redis security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Redis security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Redis security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Redis security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Redis security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Redis security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Redis security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/azure-sentinel-cloud-siem.md b/src/content/blog/azure-sentinel-cloud-siem.md
deleted file mode 100644
index 991c4a9..0000000
--- a/src/content/blog/azure-sentinel-cloud-siem.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Microsoft Sentinel for Cloud Security Operations"
-description: "Microsoft Sentinel for Cloud Security Operations—practical guidance on Azure Sentinel cloud security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CN..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Sentinel
-  - SIEM
-  - cloud security
-  - SOC
-focusKeyword: Azure Sentinel cloud security
-faq:
-  - question: Why does Azure Sentinel cloud security matter for cloud teams?
-    answer: Azure Sentinel cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Sentinel cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Sentinel cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Sentinel cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Sentinel cloud security without proprietary black boxes.
----
-
-**Azure Sentinel cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Sentinel cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Sentinel cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) and [multi cloud security governance](/blog/multi-cloud-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Sentinel cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Sentinel cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Sentinel cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Sentinel cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/) · [multi-cloud-security-governance](/blog/multi-cloud-security-governance/)
diff --git a/src/content/blog/azure-service-bus-security-guide.md b/src/content/blog/azure-service-bus-security-guide.md
deleted file mode 100644
index be62a9a..0000000
--- a/src/content/blog/azure-service-bus-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Service Bus Security: Auth and Network Rules"
-description: "Azure Service Bus Security — expert guide to Azure Service Bus security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Service Bus
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Service Bus security
-faq:
-  - question: Why does Azure Service Bus security matter for cloud teams?
-    answer: Azure Service Bus security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Service Bus security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Service Bus security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Service Bus security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Service Bus security without proprietary black boxes.
----
-
-**Azure Service Bus security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Service Bus security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Service Bus security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Service Bus security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Service Bus security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Service Bus security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Service Bus security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/azure-signalr-security-guide.md b/src/content/blog/azure-signalr-security-guide.md
deleted file mode 100644
index ebf7c97..0000000
--- a/src/content/blog/azure-signalr-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure SignalR Service Security and Access Keys"
-description: "Azure SignalR Service Security and Access Keys — expert guide to Azure SignalR security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - SignalR
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure SignalR security
-faq:
-  - question: Why does Azure SignalR security matter for cloud teams?
-    answer: Azure SignalR security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure SignalR security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure SignalR security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure SignalR security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure SignalR security without proprietary black boxes.
----
-
-**Azure SignalR security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure SignalR security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure SignalR security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [container image scanning cicd](/blog/container-image-scanning-cicd/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure SignalR security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure SignalR security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure SignalR security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure SignalR security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [container-image-scanning-cicd](/blog/container-image-scanning-cicd/)
diff --git a/src/content/blog/azure-site-recovery-security-guide.md b/src/content/blog/azure-site-recovery-security-guide.md
deleted file mode 100644
index 32d129c..0000000
--- a/src/content/blog/azure-site-recovery-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Site Recovery Security for DR Workloads"
-description: "Azure Site Recovery Security for DR Workloads — expert guide to Azure Site Recovery security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Site Recovery
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Site Recovery security
-faq:
-  - question: Why does Azure Site Recovery security matter for cloud teams?
-    answer: Azure Site Recovery security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Site Recovery security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Site Recovery security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Site Recovery security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Site Recovery security without proprietary black boxes.
----
-
-**Azure Site Recovery security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Site Recovery security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Site Recovery security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Site Recovery security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Site Recovery security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Site Recovery security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Site Recovery security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/azure-sql-database-security-hardening.md b/src/content/blog/azure-sql-database-security-hardening.md
deleted file mode 100644
index dc205a8..0000000
--- a/src/content/blog/azure-sql-database-security-hardening.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure SQL Database Security Hardening for Regulated Workloads"
-description: "Azure SQL Database Security Hardening for Regulated Workloads—practical guidance on Azure SQL security for AWS, Azure, GCP, and Kubernetes teams using CSPM, ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - SQL Database
-  - database security
-  - cloud security
-  - encryption
-focusKeyword: Azure SQL security
-faq:
-  - question: Why does Azure SQL security matter for cloud teams?
-    answer: Azure SQL security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure SQL security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure SQL security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure SQL security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure SQL security without proprietary black boxes.
----
-
-**Azure SQL security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure SQL security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure SQL security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) and [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure SQL security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure SQL security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure SQL security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure SQL security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) · [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/)
diff --git a/src/content/blog/azure-sql-managed-instance-security-guide.md b/src/content/blog/azure-sql-managed-instance-security-guide.md
deleted file mode 100644
index 8a51ed8..0000000
--- a/src/content/blog/azure-sql-managed-instance-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure SQL Managed Instance Security Baseline"
-description: "Azure SQL Managed Instance Security Baseline — expert guide to Azure SQL Managed Instance security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - SQL Managed Instance
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure SQL Managed Instance security
-faq:
-  - question: Why does Azure SQL Managed Instance security matter for cloud teams?
-    answer: Azure SQL Managed Instance security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure SQL Managed Instance security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure SQL Managed Instance security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure SQL Managed Instance security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure SQL Managed Instance security without proprietary black boxes.
----
-
-**Azure SQL Managed Instance security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure SQL Managed Instance security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure SQL Managed Instance security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure SQL Managed Instance security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure SQL Managed Instance security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure SQL Managed Instance security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure SQL Managed Instance security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/)
diff --git a/src/content/blog/azure-static-web-apps-security-guide.md b/src/content/blog/azure-static-web-apps-security-guide.md
deleted file mode 100644
index caa81de..0000000
--- a/src/content/blog/azure-static-web-apps-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Static Web Apps Security and Auth Integration"
-description: "Azure Static Web Apps Security and Auth Integration — expert guide to Azure Static Web Apps security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, an..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Static Web Apps
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Static Web Apps security
-faq:
-  - question: Why does Azure Static Web Apps security matter for cloud teams?
-    answer: Azure Static Web Apps security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Static Web Apps security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Static Web Apps security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Static Web Apps security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Static Web Apps security without proprietary black boxes.
----
-
-**Azure Static Web Apps security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Static Web Apps security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Static Web Apps security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Static Web Apps security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Static Web Apps security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Static Web Apps security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Static Web Apps security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/azure-synapse-security-guide.md b/src/content/blog/azure-synapse-security-guide.md
deleted file mode 100644
index c08f2d3..0000000
--- a/src/content/blog/azure-synapse-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure Synapse Analytics Security for Data Warehouses"
-description: "Azure Synapse Analytics Security for Data Warehouses — expert guide to Azure Synapse security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - Synapse
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure Synapse security
-faq:
-  - question: Why does Azure Synapse security matter for cloud teams?
-    answer: Azure Synapse security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure Synapse security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure Synapse security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure Synapse security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure Synapse security without proprietary black boxes.
----
-
-**Azure Synapse security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure Synapse security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure Synapse security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure Synapse security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure Synapse security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure Synapse security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure Synapse security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/azure-vm-security-baseline.md b/src/content/blog/azure-vm-security-baseline.md
deleted file mode 100644
index f52dfec..0000000
--- a/src/content/blog/azure-vm-security-baseline.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure VM Security Baseline: Disk Encryption, NSGs, and Monitoring"
-description: "Azure VM Security Baseline—practical guidance on Azure VM security baseline for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - virtual machines
-  - CWPP
-  - cloud security
-  - hardening
-focusKeyword: Azure VM security baseline
-faq:
-  - question: Why does Azure VM security baseline matter for cloud teams?
-    answer: Azure VM security baseline reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure VM security baseline relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure VM security baseline gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure VM security baseline?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure VM security baseline without proprietary black boxes.
----
-
-**Azure VM security baseline** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure VM security baseline matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure VM security baseline | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure VM security baseline with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure VM security baseline at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure VM security baseline program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure VM security baseline** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/azure-vpn-gateway-security-guide.md b/src/content/blog/azure-vpn-gateway-security-guide.md
deleted file mode 100644
index e93e947..0000000
--- a/src/content/blog/azure-vpn-gateway-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Azure VPN Gateway Security and Site-to-Site Setup"
-description: "Azure VPN Gateway Security and Site-to-Site Setup — expert guide to Azure VPN Gateway security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Azure
-  - VPN Gateway
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: Azure VPN Gateway security
-faq:
-  - question: Why does Azure VPN Gateway security matter for cloud teams?
-    answer: Azure VPN Gateway security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Azure VPN Gateway security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Azure VPN Gateway security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Azure VPN Gateway security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Azure VPN Gateway security without proprietary black boxes.
----
-
-**Azure VPN Gateway security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Azure VPN Gateway security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Azure VPN Gateway security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp iam security hardening](/blog/gcp-iam-security-hardening/) and [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Azure VPN Gateway security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Azure VPN Gateway security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Azure VPN Gateway security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Azure VPN Gateway security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/) · [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/)
diff --git a/src/content/blog/bug-bounty-cloud-scope.md b/src/content/blog/bug-bounty-cloud-scope.md
deleted file mode 100644
index f01c39c..0000000
--- a/src/content/blog/bug-bounty-cloud-scope.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Bug Bounty Program Scope for Cloud Infrastructure"
-description: "Bug Bounty Program Scope for Cloud Infrastructure — expert guide to bug bounty cloud scope for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: bug bounty cloud scope
-faq:
-  - question: Why does bug bounty cloud scope matter for cloud teams?
-    answer: bug bounty cloud scope reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does bug bounty cloud scope relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether bug bounty cloud scope gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support bug bounty cloud scope?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize bug bounty cloud scope without proprietary black boxes.
----
-
-**bug bounty cloud scope** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why bug bounty cloud scope matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without bug bounty cloud scope | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align bug bounty cloud scope with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce bug bounty cloud scope at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature bug bounty cloud scope program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **bug bounty cloud scope** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/)
diff --git a/src/content/blog/ccpa-cloud-security-compliance.md b/src/content/blog/ccpa-cloud-security-compliance.md
deleted file mode 100644
index 5754689..0000000
--- a/src/content/blog/ccpa-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "CCPA Cloud Privacy and Security for California Data"
-description: "CCPA Cloud Privacy and Security for California Data — expert guide to CCPA cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - CCPA
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: CCPA cloud security
-faq:
-  - question: Why does CCPA cloud security matter for cloud teams?
-    answer: CCPA cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does CCPA cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether CCPA cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support CCPA cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize CCPA cloud security without proprietary black boxes.
----
-
-**CCPA cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why CCPA cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without CCPA cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align CCPA cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce CCPA cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature CCPA cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **CCPA cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/ciso-cloud-strategy.md b/src/content/blog/ciso-cloud-strategy.md
deleted file mode 100644
index fd1b0fa..0000000
--- a/src/content/blog/ciso-cloud-strategy.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "CISO Cloud Security Strategy for Growing Startups"
-description: "CISO Cloud Security Strategy for Growing Startups — expert guide to ciso cloud strategy for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: ciso cloud strategy
-faq:
-  - question: Why does ciso cloud strategy matter for cloud teams?
-    answer: ciso cloud strategy reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does ciso cloud strategy relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether ciso cloud strategy gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support ciso cloud strategy?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize ciso cloud strategy without proprietary black boxes.
----
-
-**ciso cloud strategy** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why ciso cloud strategy matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without ciso cloud strategy | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align ciso cloud strategy with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce ciso cloud strategy at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature ciso cloud strategy program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **ciso cloud strategy** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/cloud-api-security-rate-limiting.md b/src/content/blog/cloud-api-security-rate-limiting.md
deleted file mode 100644
index 31b265a..0000000
--- a/src/content/blog/cloud-api-security-rate-limiting.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud API Security: Rate Limiting, Auth, and Abuse Prevention"
-description: "Cloud API Security—practical guidance on cloud API security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - API security
-  - cloud security
-  - WAF
-  - devsecops
-  - zero trust
-focusKeyword: cloud API security
-faq:
-  - question: Why does cloud API security matter for cloud teams?
-    answer: cloud API security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud API security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud API security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud API security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud API security without proprietary black boxes.
----
-
-**cloud API security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud API security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud API security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud API security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud API security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud API security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud API security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/cloud-compliance-cis-benchmarks.md b/src/content/blog/cloud-compliance-cis-benchmarks.md
deleted file mode 100644
index 88f4810..0000000
--- a/src/content/blog/cloud-compliance-cis-benchmarks.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Compliance: CIS Benchmarks Across AWS, Azure, and GCP"
-description: "Cloud Compliance—practical guidance on CIS cloud benchmarks for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - CIS
-  - CSPM
-  - cloud security
-  - audit
-focusKeyword: CIS cloud benchmarks
-faq:
-  - question: Why does CIS cloud benchmarks matter for cloud teams?
-    answer: CIS cloud benchmarks reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does CIS cloud benchmarks relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether CIS cloud benchmarks gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support CIS cloud benchmarks?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize CIS cloud benchmarks without proprietary black boxes.
----
-
-**CIS cloud benchmarks** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why CIS cloud benchmarks matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without CIS cloud benchmarks | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [container image scanning cicd](/blog/container-image-scanning-cicd/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align CIS cloud benchmarks with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce CIS cloud benchmarks at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature CIS cloud benchmarks program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **CIS cloud benchmarks** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [container-image-scanning-cicd](/blog/container-image-scanning-cicd/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/cloud-drift-detection-remediation.md b/src/content/blog/cloud-drift-detection-remediation.md
deleted file mode 100644
index 5e175d7..0000000
--- a/src/content/blog/cloud-drift-detection-remediation.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Drift Detection and Remediation: Closing the IaC Gap"
-description: "Cloud Drift Detection and Remediation—practical guidance on cloud drift detection for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud drift
-  - IaC
-  - CSPM
-  - remediation
-  - cloud security
-focusKeyword: cloud drift detection
-faq:
-  - question: Why does cloud drift detection matter for cloud teams?
-    answer: cloud drift detection reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud drift detection relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud drift detection gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud drift detection?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud drift detection without proprietary black boxes.
----
-
-**cloud drift detection** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud drift detection matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud drift detection | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud drift detection with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud drift detection at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud drift detection program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud drift detection** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/cloud-forensics.md b/src/content/blog/cloud-forensics.md
deleted file mode 100644
index 21f4662..0000000
--- a/src/content/blog/cloud-forensics.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Forensics: Evidence Collection Across AWS and Azure"
-description: "Cloud Forensics — expert guide to cloud forensics for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cloud forensics
-faq:
-  - question: Why does cloud forensics matter for cloud teams?
-    answer: cloud forensics reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud forensics relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud forensics gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud forensics?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud forensics without proprietary black boxes.
----
-
-**cloud forensics** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud forensics matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud forensics | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [container image scanning cicd](/blog/container-image-scanning-cicd/) and [azure key vault security hardening](/blog/azure-key-vault-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud forensics with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud forensics at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud forensics program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud forensics** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [container-image-scanning-cicd](/blog/container-image-scanning-cicd/) · [azure-key-vault-security-hardening](/blog/azure-key-vault-security-hardening/)
diff --git a/src/content/blog/cloud-identity-federation-sso-security.md b/src/content/blog/cloud-identity-federation-sso-security.md
deleted file mode 100644
index 9f166bc..0000000
--- a/src/content/blog/cloud-identity-federation-sso-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Identity Federation and SSO Security Best Practices"
-description: "Cloud Identity Federation and SSO Security Best Practices—practical guidance on cloud identity federation for AWS, Azure, GCP, and Kubernetes teams using CSP..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - identity
-  - SSO
-  - CIEM
-  - cloud security
-  - zero trust
-focusKeyword: cloud identity federation
-faq:
-  - question: Why does cloud identity federation matter for cloud teams?
-    answer: cloud identity federation reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud identity federation relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud identity federation gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud identity federation?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud identity federation without proprietary black boxes.
----
-
-**cloud identity federation** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud identity federation matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud identity federation | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [gcp security command center guide](/blog/gcp-security-command-center-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud identity federation with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud identity federation at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud identity federation program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud identity federation** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [gcp-security-command-center-guide](/blog/gcp-security-command-center-guide/)
diff --git a/src/content/blog/cloud-incident-response-playbook.md b/src/content/blog/cloud-incident-response-playbook.md
deleted file mode 100644
index c86d151..0000000
--- a/src/content/blog/cloud-incident-response-playbook.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Incident Response Playbook: Contain, Eradicate, Recover"
-description: "Cloud Incident Response Playbook—practical guidance on cloud incident response for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - incident response
-  - cloud security
-  - forensics
-  - SOC
-  - CNAPP
-focusKeyword: cloud incident response
-faq:
-  - question: Why does cloud incident response matter for cloud teams?
-    answer: cloud incident response reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud incident response relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud incident response gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud incident response?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud incident response without proprietary black boxes.
----
-
-**cloud incident response** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud incident response matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud incident response | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud incident response with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud incident response at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud incident response program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud incident response** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/cloud-penetration-testing.md b/src/content/blog/cloud-penetration-testing.md
deleted file mode 100644
index 121e0fa..0000000
--- a/src/content/blog/cloud-penetration-testing.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Penetration Testing Scope and Rules of Engagement"
-description: "Cloud Penetration Testing Scope and Rules of Engagement — expert guide to cloud penetration testing for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cloud penetration testing
-faq:
-  - question: Why does cloud penetration testing matter for cloud teams?
-    answer: cloud penetration testing reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud penetration testing relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud penetration testing gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud penetration testing?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud penetration testing without proprietary black boxes.
----
-
-**cloud penetration testing** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud penetration testing matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud penetration testing | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [gcp compute engine security hardening](/blog/gcp-compute-engine-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud penetration testing with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud penetration testing at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud penetration testing program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud penetration testing** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [gcp-compute-engine-security-hardening](/blog/gcp-compute-engine-security-hardening/)
diff --git a/src/content/blog/cloud-red-team.md b/src/content/blog/cloud-red-team.md
deleted file mode 100644
index c5a75de..0000000
--- a/src/content/blog/cloud-red-team.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Red Team Operations: Tactics and Tooling"
-description: "Cloud Red Team Operations — expert guide to cloud red team for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cloud red team
-faq:
-  - question: Why does cloud red team matter for cloud teams?
-    answer: cloud red team reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud red team relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud red team gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud red team?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud red team without proprietary black boxes.
----
-
-**cloud red team** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud red team matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud red team | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [gcp workload identity federation](/blog/gcp-workload-identity-federation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud red team with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud red team at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud red team program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud red team** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/)
diff --git a/src/content/blog/cloud-secrets-management-best-practices.md b/src/content/blog/cloud-secrets-management-best-practices.md
deleted file mode 100644
index 120aee6..0000000
--- a/src/content/blog/cloud-secrets-management-best-practices.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Secrets Management: AWS, Azure, and GCP Best Practices"
-description: "Cloud Secrets Management—practical guidance on cloud secrets management for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioriti..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - secrets management
-  - cloud security
-  - CIEM
-  - devsecops
-  - CSPM
-focusKeyword: cloud secrets management
-faq:
-  - question: Why does cloud secrets management matter for cloud teams?
-    answer: cloud secrets management reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud secrets management relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud secrets management gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud secrets management?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud secrets management without proprietary black boxes.
----
-
-**cloud secrets management** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud secrets management matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud secrets management | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure key vault security hardening](/blog/azure-key-vault-security-hardening/) and [gcp compute engine security hardening](/blog/gcp-compute-engine-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud secrets management with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud secrets management at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud secrets management program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud secrets management** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-key-vault-security-hardening](/blog/azure-key-vault-security-hardening/) · [gcp-compute-engine-security-hardening](/blog/gcp-compute-engine-security-hardening/)
diff --git a/src/content/blog/cloud-security-automation-remediation.md b/src/content/blog/cloud-security-automation-remediation.md
deleted file mode 100644
index 9f5033f..0000000
--- a/src/content/blog/cloud-security-automation-remediation.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Security Automation: Remediation Playbooks That Scale"
-description: "Cloud Security Automation—practical guidance on cloud security automation for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path priori..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - automation
-  - CSPM
-  - remediation
-  - cloud security
-  - devsecops
-focusKeyword: cloud security automation
-faq:
-  - question: Why does cloud security automation matter for cloud teams?
-    answer: cloud security automation reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud security automation relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud security automation gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud security automation?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud security automation without proprietary black boxes.
----
-
-**cloud security automation** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud security automation matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud security automation | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud security automation with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud security automation at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud security automation program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud security automation** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/) · [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/)
diff --git a/src/content/blog/cloud-security-maturity-model.md b/src/content/blog/cloud-security-maturity-model.md
deleted file mode 100644
index 59cda2c..0000000
--- a/src/content/blog/cloud-security-maturity-model.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Security Maturity Model: Stages and Metrics"
-description: "Cloud Security Maturity Model — expert guide to cloud security maturity model for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritiz..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cloud security maturity model
-faq:
-  - question: Why does cloud security maturity model matter for cloud teams?
-    answer: cloud security maturity model reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud security maturity model relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud security maturity model gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud security maturity model?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud security maturity model without proprietary black boxes.
----
-
-**cloud security maturity model** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud security maturity model matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud security maturity model | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud security maturity model with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud security maturity model at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud security maturity model program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud security maturity model** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/cloud-tagging-strategy-security-governance.md b/src/content/blog/cloud-tagging-strategy-security-governance.md
deleted file mode 100644
index b7be0fb..0000000
--- a/src/content/blog/cloud-tagging-strategy-security-governance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Tagging Strategy for Security Governance and Cost"
-description: "Cloud Tagging Strategy for Security Governance and Cost—practical guidance on cloud tagging strategy security for AWS, Azure, GCP, and Kubernetes teams using..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - governance
-  - tagging
-  - CSPM
-  - multi-cloud
-  - cloud security
-focusKeyword: cloud tagging strategy security
-faq:
-  - question: Why does cloud tagging strategy security matter for cloud teams?
-    answer: cloud tagging strategy security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud tagging strategy security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud tagging strategy security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud tagging strategy security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud tagging strategy security without proprietary black boxes.
----
-
-**cloud tagging strategy security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud tagging strategy security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud tagging strategy security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud tagging strategy security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud tagging strategy security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud tagging strategy security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud tagging strategy security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/)
diff --git a/src/content/blog/cloud-vendor-risk.md b/src/content/blog/cloud-vendor-risk.md
deleted file mode 100644
index c6ef169..0000000
--- a/src/content/blog/cloud-vendor-risk.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Vendor Risk Assessment Framework"
-description: "Cloud Vendor Risk Assessment Framework — expert guide to cloud vendor risk for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritizati..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cloud vendor risk
-faq:
-  - question: Why does cloud vendor risk matter for cloud teams?
-    answer: cloud vendor risk reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud vendor risk relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud vendor risk gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud vendor risk?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud vendor risk without proprietary black boxes.
----
-
-**cloud vendor risk** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud vendor risk matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud vendor risk | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) and [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud vendor risk with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud vendor risk at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud vendor risk program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud vendor risk** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/) · [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/)
diff --git a/src/content/blog/cloud-vulnerability-management-program.md b/src/content/blog/cloud-vulnerability-management-program.md
deleted file mode 100644
index 0c5629a..0000000
--- a/src/content/blog/cloud-vulnerability-management-program.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Building a Cloud Vulnerability Management Program That Works"
-description: "Building a Cloud Vulnerability Management Program That Works—practical guidance on cloud vulnerability management for AWS, Azure, GCP, and Kubernetes teams u..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - vulnerability management
-  - CNAPP
-  - cloud security
-  - CWPP
-  - prioritization
-focusKeyword: cloud vulnerability management
-faq:
-  - question: Why does cloud vulnerability management matter for cloud teams?
-    answer: cloud vulnerability management reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud vulnerability management relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud vulnerability management gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud vulnerability management?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud vulnerability management without proprietary black boxes.
----
-
-**cloud vulnerability management** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud vulnerability management matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud vulnerability management | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [azure defender cloud security](/blog/azure-defender-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud vulnerability management with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud vulnerability management at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud vulnerability management program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud vulnerability management** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [azure-defender-cloud-security](/blog/azure-defender-cloud-security/)
diff --git a/src/content/blog/cloud-workload-protection-cwpp-guide.md b/src/content/blog/cloud-workload-protection-cwpp-guide.md
deleted file mode 100644
index e617d52..0000000
--- a/src/content/blog/cloud-workload-protection-cwpp-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Workload Protection (CWPP): VMs, Containers, and Serverless"
-description: "Cloud Workload Protection (CWPP)—practical guidance on cloud workload protection for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - CWPP
-  - cloud security
-  - CNAPP
-  - runtime protection
-  - container security
-focusKeyword: cloud workload protection
-faq:
-  - question: Why does cloud workload protection matter for cloud teams?
-    answer: cloud workload protection reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cloud workload protection relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cloud workload protection gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cloud workload protection?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cloud workload protection without proprietary black boxes.
----
-
-**cloud workload protection** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cloud workload protection matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cloud workload protection | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) and [azure vm security baseline](/blog/azure-vm-security-baseline/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cloud workload protection with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cloud workload protection at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cloud workload protection program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cloud workload protection** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/) · [azure-vm-security-baseline](/blog/azure-vm-security-baseline/)
diff --git a/src/content/blog/cmmc-level-2-cloud-security-compliance.md b/src/content/blog/cmmc-level-2-cloud-security-compliance.md
deleted file mode 100644
index f98ea7a..0000000
--- a/src/content/blog/cmmc-level-2-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "CMMC Level 2 Cloud Security for Defense Contractors"
-description: "CMMC Level 2 Cloud Security for Defense Contractors — expert guide to CMMC Level 2 cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - CMMC Level 2
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: CMMC Level 2 cloud security
-faq:
-  - question: Why does CMMC Level 2 cloud security matter for cloud teams?
-    answer: CMMC Level 2 cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does CMMC Level 2 cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether CMMC Level 2 cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support CMMC Level 2 cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize CMMC Level 2 cloud security without proprietary black boxes.
----
-
-**CMMC Level 2 cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why CMMC Level 2 cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without CMMC Level 2 cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [dspm data security posture management](/blog/dspm-data-security-posture-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align CMMC Level 2 cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce CMMC Level 2 cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature CMMC Level 2 cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **CMMC Level 2 cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/)
diff --git a/src/content/blog/cnapp-buyers-guide.md b/src/content/blog/cnapp-buyers-guide.md
deleted file mode 100644
index f0612ed..0000000
--- a/src/content/blog/cnapp-buyers-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "CNAPP Buyers Guide: Evaluation Criteria for 2026"
-description: "CNAPP Buyers Guide — expert guide to cnapp buyers guide for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cnapp buyers guide
-faq:
-  - question: Why does cnapp buyers guide matter for cloud teams?
-    answer: cnapp buyers guide reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cnapp buyers guide relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cnapp buyers guide gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cnapp buyers guide?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cnapp buyers guide without proprietary black boxes.
----
-
-**cnapp buyers guide** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cnapp buyers guide matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cnapp buyers guide | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cnapp buyers guide with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cnapp buyers guide at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cnapp buyers guide program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cnapp buyers guide** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/)
diff --git a/src/content/blog/confidential-computing.md b/src/content/blog/confidential-computing.md
deleted file mode 100644
index 10d4690..0000000
--- a/src/content/blog/confidential-computing.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Confidential Computing in Public Cloud Platforms"
-description: "Confidential Computing in Public Cloud Platforms — expert guide to confidential computing for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: confidential computing
-faq:
-  - question: Why does confidential computing matter for cloud teams?
-    answer: confidential computing reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does confidential computing relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether confidential computing gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support confidential computing?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize confidential computing without proprietary black boxes.
----
-
-**confidential computing** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why confidential computing matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without confidential computing | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure vm security baseline](/blog/azure-vm-security-baseline/) and [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align confidential computing with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce confidential computing at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature confidential computing program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **confidential computing** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-vm-security-baseline](/blog/azure-vm-security-baseline/) · [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/)
diff --git a/src/content/blog/container-image-scanning-cicd.md b/src/content/blog/container-image-scanning-cicd.md
deleted file mode 100644
index 26f19e1..0000000
--- a/src/content/blog/container-image-scanning-cicd.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Container Image Scanning in CI/CD: From CVE Noise to Priority"
-description: "Container Image Scanning in CI/CD—practical guidance on container image scanning for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - container security
-  - CI/CD
-  - vulnerability management
-  - CNAPP
-  - devsecops
-focusKeyword: container image scanning
-faq:
-  - question: Why does container image scanning matter for cloud teams?
-    answer: container image scanning reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does container image scanning relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether container image scanning gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support container image scanning?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize container image scanning without proprietary black boxes.
----
-
-**container image scanning** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why container image scanning matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without container image scanning | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align container image scanning with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce container image scanning at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature container image scanning program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **container image scanning** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/cryptomining-detection.md b/src/content/blog/cryptomining-detection.md
deleted file mode 100644
index 5a81b5a..0000000
--- a/src/content/blog/cryptomining-detection.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cryptomining Detection in Cloud Accounts"
-description: "Cryptomining Detection in Cloud Accounts — expert guide to cryptomining detection for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prior..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: cryptomining detection
-faq:
-  - question: Why does cryptomining detection matter for cloud teams?
-    answer: cryptomining detection reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does cryptomining detection relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether cryptomining detection gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support cryptomining detection?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize cryptomining detection without proprietary black boxes.
----
-
-**cryptomining detection** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why cryptomining detection matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without cryptomining detection | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [multi cloud security governance](/blog/multi-cloud-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align cryptomining detection with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce cryptomining detection at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature cryptomining detection program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **cryptomining detection** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [multi-cloud-security-governance](/blog/multi-cloud-security-governance/)
diff --git a/src/content/blog/cyber-essentials-plus-cloud-security-compliance.md b/src/content/blog/cyber-essentials-plus-cloud-security-compliance.md
deleted file mode 100644
index 51e01d1..0000000
--- a/src/content/blog/cyber-essentials-plus-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cyber Essentials Plus for Cloud-Hosted UK Businesses"
-description: "Cyber Essentials Plus for Cloud-Hosted UK Businesses — expert guide to Cyber Essentials Plus cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CN..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - Cyber Essentials Plus
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: Cyber Essentials Plus cloud security
-faq:
-  - question: Why does Cyber Essentials Plus cloud security matter for cloud teams?
-    answer: Cyber Essentials Plus cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Cyber Essentials Plus cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Cyber Essentials Plus cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Cyber Essentials Plus cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Cyber Essentials Plus cloud security without proprietary black boxes.
----
-
-**Cyber Essentials Plus cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Cyber Essentials Plus cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Cyber Essentials Plus cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [ciem explained for cloud teams](/blog/ciem-explained-for-cloud-teams/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Cyber Essentials Plus cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Cyber Essentials Plus cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Cyber Essentials Plus cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Cyber Essentials Plus cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [CIEM explained](/blog/ciem-explained-for-cloud-teams/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/dora-cloud-security-compliance.md b/src/content/blog/dora-cloud-security-compliance.md
deleted file mode 100644
index 79bb5ff..0000000
--- a/src/content/blog/dora-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "DORA Resilience Requirements for Cloud Financial Services"
-description: "DORA Resilience Requirements for Cloud Financial Services — expert guide to DORA cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - DORA
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: DORA cloud security
-faq:
-  - question: Why does DORA cloud security matter for cloud teams?
-    answer: DORA cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does DORA cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether DORA cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support DORA cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize DORA cloud security without proprietary black boxes.
----
-
-**DORA cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why DORA cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without DORA cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align DORA cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce DORA cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature DORA cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **DORA cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/)
diff --git a/src/content/blog/dspm-data-security-posture-management.md b/src/content/blog/dspm-data-security-posture-management.md
deleted file mode 100644
index bc2bfc9..0000000
--- a/src/content/blog/dspm-data-security-posture-management.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "DSPM Explained: Data Security Posture Management in the Cloud"
-description: "DSPM Explained—practical guidance on DSPM cloud security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - DSPM
-  - data security
-  - cloud security
-  - CNAPP
-  - compliance
-focusKeyword: DSPM cloud security
-faq:
-  - question: Why does DSPM cloud security matter for cloud teams?
-    answer: DSPM cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does DSPM cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether DSPM cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support DSPM cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize DSPM cloud security without proprietary black boxes.
----
-
-**DSPM cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why DSPM cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without DSPM cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) and [azure vm security baseline](/blog/azure-vm-security-baseline/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align DSPM cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce DSPM cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature DSPM cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **DSPM cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/) · [azure-vm-security-baseline](/blog/azure-vm-security-baseline/)
diff --git a/src/content/blog/edge-cloud-security.md b/src/content/blog/edge-cloud-security.md
deleted file mode 100644
index ea3ebe8..0000000
--- a/src/content/blog/edge-cloud-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Edge Cloud Security for CDN and IoT Gateways"
-description: "Edge Cloud Security for CDN and IoT Gateways — expert guide to edge cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: edge cloud security
-faq:
-  - question: Why does edge cloud security matter for cloud teams?
-    answer: edge cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does edge cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether edge cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support edge cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize edge cloud security without proprietary black boxes.
----
-
-**edge cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why edge cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without edge cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) and [gcp iam security hardening](/blog/gcp-iam-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align edge cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce edge cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature edge cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **edge cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) · [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/)
diff --git a/src/content/blog/essential-eight-cloud-security-compliance.md b/src/content/blog/essential-eight-cloud-security-compliance.md
deleted file mode 100644
index 73bfdd9..0000000
--- a/src/content/blog/essential-eight-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Essential Eight Cloud Security Maturity for Australian Orgs"
-description: "Essential Eight Cloud Security Maturity for Australian Orgs — expert guide to Essential Eight cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, C..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - Essential Eight
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: Essential Eight cloud security
-faq:
-  - question: Why does Essential Eight cloud security matter for cloud teams?
-    answer: Essential Eight cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Essential Eight cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Essential Eight cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Essential Eight cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Essential Eight cloud security without proprietary black boxes.
----
-
-**Essential Eight cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Essential Eight cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Essential Eight cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Essential Eight cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Essential Eight cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Essential Eight cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Essential Eight cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/exposure-management-cloud-security.md b/src/content/blog/exposure-management-cloud-security.md
deleted file mode 100644
index a1983b5..0000000
--- a/src/content/blog/exposure-management-cloud-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Exposure Management in Cloud Security: Beyond Vulnerability Lists"
-description: "Exposure Management in Cloud Security—practical guidance on exposure management cloud for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - exposure management
-  - attack surface
-  - CSPM
-  - cloud security
-  - CNAPP
-focusKeyword: exposure management cloud
-faq:
-  - question: Why does exposure management cloud matter for cloud teams?
-    answer: exposure management cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does exposure management cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether exposure management cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support exposure management cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize exposure management cloud without proprietary black boxes.
----
-
-**exposure management cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why exposure management cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without exposure management cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align exposure management cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce exposure management cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature exposure management cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **exposure management cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/external-attack-surface-management.md b/src/content/blog/external-attack-surface-management.md
deleted file mode 100644
index e9bb1a7..0000000
--- a/src/content/blog/external-attack-surface-management.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "External Attack Surface Management for Cloud Assets"
-description: "External Attack Surface Management for Cloud Assets — expert guide to external attack surface management for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: external attack surface management
-faq:
-  - question: Why does external attack surface management matter for cloud teams?
-    answer: external attack surface management reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does external attack surface management relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether external attack surface management gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support external attack surface management?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize external attack surface management without proprietary black boxes.
----
-
-**external attack surface management** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why external attack surface management matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without external attack surface management | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align external attack surface management with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce external attack surface management at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature external attack surface management program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **external attack surface management** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/fedramp-moderate-cloud-security-compliance.md b/src/content/blog/fedramp-moderate-cloud-security-compliance.md
deleted file mode 100644
index 45e1ab5..0000000
--- a/src/content/blog/fedramp-moderate-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "FedRAMP Moderate Cloud Security Authorization Guide"
-description: "FedRAMP Moderate Cloud Security Authorization Guide — expert guide to FedRAMP Moderate cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - FedRAMP Moderate
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: FedRAMP Moderate cloud security
-faq:
-  - question: Why does FedRAMP Moderate cloud security matter for cloud teams?
-    answer: FedRAMP Moderate cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does FedRAMP Moderate cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether FedRAMP Moderate cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support FedRAMP Moderate cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize FedRAMP Moderate cloud security without proprietary black boxes.
----
-
-**FedRAMP Moderate cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why FedRAMP Moderate cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without FedRAMP Moderate cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) and [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align FedRAMP Moderate cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce FedRAMP Moderate cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature FedRAMP Moderate cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **FedRAMP Moderate cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) · [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/)
diff --git a/src/content/blog/finops-security.md b/src/content/blog/finops-security.md
deleted file mode 100644
index 4254f67..0000000
--- a/src/content/blog/finops-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "FinOps and Cloud Security: Cost Anomaly Detection"
-description: "FinOps and Cloud Security — expert guide to finops security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practiti..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: finops security
-faq:
-  - question: Why does finops security matter for cloud teams?
-    answer: finops security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does finops security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether finops security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support finops security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize finops security without proprietary black boxes.
----
-
-**finops security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why finops security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without finops security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align finops security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce finops security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature finops security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **finops security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/)
diff --git a/src/content/blog/fisma-moderate-cloud-security-compliance.md b/src/content/blog/fisma-moderate-cloud-security-compliance.md
deleted file mode 100644
index b4671a7..0000000
--- a/src/content/blog/fisma-moderate-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "FISMA Moderate Cloud Controls for US Agencies"
-description: "FISMA Moderate Cloud Controls for US Agencies — expert guide to FISMA Moderate cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - FISMA Moderate
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: FISMA Moderate cloud security
-faq:
-  - question: Why does FISMA Moderate cloud security matter for cloud teams?
-    answer: FISMA Moderate cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does FISMA Moderate cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether FISMA Moderate cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support FISMA Moderate cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize FISMA Moderate cloud security without proprietary black boxes.
----
-
-**FISMA Moderate cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why FISMA Moderate cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without FISMA Moderate cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [azure network security groups guide](/blog/azure-network-security-groups-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align FISMA Moderate cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce FISMA Moderate cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature FISMA Moderate cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **FISMA Moderate cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/)
diff --git a/src/content/blog/gcp-alloydb-security-guide.md b/src/content/blog/gcp-alloydb-security-guide.md
deleted file mode 100644
index 4567032..0000000
--- a/src/content/blog/gcp-alloydb-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google AlloyDB Security and High-Availability Design"
-description: "Google AlloyDB Security and High-Availability Design — expert guide to GCP AlloyDB security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - AlloyDB
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP AlloyDB security
-faq:
-  - question: Why does GCP AlloyDB security matter for cloud teams?
-    answer: GCP AlloyDB security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP AlloyDB security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP AlloyDB security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP AlloyDB security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP AlloyDB security without proprietary black boxes.
----
-
-**GCP AlloyDB security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP AlloyDB security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP AlloyDB security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP AlloyDB security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP AlloyDB security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP AlloyDB security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP AlloyDB security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/gcp-apigee-security-guide.md b/src/content/blog/gcp-apigee-security-guide.md
deleted file mode 100644
index 262b8ca..0000000
--- a/src/content/blog/gcp-apigee-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Apigee API Security Management Guide"
-description: "Google Apigee API Security Management Guide — expert guide to GCP Apigee security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prior..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Apigee
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Apigee security
-faq:
-  - question: Why does GCP Apigee security matter for cloud teams?
-    answer: GCP Apigee security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Apigee security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Apigee security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Apigee security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Apigee security without proprietary black boxes.
----
-
-**GCP Apigee security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Apigee security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Apigee security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Apigee security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Apigee security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Apigee security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Apigee security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/)
diff --git a/src/content/blog/gcp-app-engine-security-guide.md b/src/content/blog/gcp-app-engine-security-guide.md
deleted file mode 100644
index 1f79f26..0000000
--- a/src/content/blog/gcp-app-engine-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google App Engine Security for Legacy and New Apps"
-description: "Google App Engine Security for Legacy and New Apps — expert guide to GCP App Engine security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - App Engine
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP App Engine security
-faq:
-  - question: Why does GCP App Engine security matter for cloud teams?
-    answer: GCP App Engine security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP App Engine security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP App Engine security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP App Engine security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP App Engine security without proprietary black boxes.
----
-
-**GCP App Engine security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP App Engine security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP App Engine security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP App Engine security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP App Engine security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP App Engine security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP App Engine security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/gcp-artifact-registry-security-guide.md b/src/content/blog/gcp-artifact-registry-security-guide.md
deleted file mode 100644
index 6979f07..0000000
--- a/src/content/blog/gcp-artifact-registry-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Artifact Registry Security and Scanning"
-description: "Google Artifact Registry Security and Scanning — expert guide to GCP Artifact Registry security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Artifact Registry
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Artifact Registry security
-faq:
-  - question: Why does GCP Artifact Registry security matter for cloud teams?
-    answer: GCP Artifact Registry security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Artifact Registry security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Artifact Registry security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Artifact Registry security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Artifact Registry security without proprietary black boxes.
----
-
-**GCP Artifact Registry security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Artifact Registry security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Artifact Registry security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud vulnerability management program](/blog/cloud-vulnerability-management-program/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Artifact Registry security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Artifact Registry security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Artifact Registry security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Artifact Registry security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-vulnerability-management-program](/blog/cloud-vulnerability-management-program/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/gcp-bigquery-security-guide.md b/src/content/blog/gcp-bigquery-security-guide.md
deleted file mode 100644
index 5cfe9e7..0000000
--- a/src/content/blog/gcp-bigquery-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google BigQuery Security: IAM, Row Access, and Encryption"
-description: "Google BigQuery Security — expert guide to GCP BigQuery security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for pra..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - BigQuery
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP BigQuery security
-faq:
-  - question: Why does GCP BigQuery security matter for cloud teams?
-    answer: GCP BigQuery security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP BigQuery security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP BigQuery security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP BigQuery security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP BigQuery security without proprietary black boxes.
----
-
-**GCP BigQuery security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP BigQuery security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP BigQuery security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP BigQuery security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP BigQuery security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP BigQuery security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP BigQuery security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/)
diff --git a/src/content/blog/gcp-bigtable-security-guide.md b/src/content/blog/gcp-bigtable-security-guide.md
deleted file mode 100644
index 54e1a94..0000000
--- a/src/content/blog/gcp-bigtable-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Bigtable Security and Access Control Patterns"
-description: "Cloud Bigtable Security and Access Control Patterns — expert guide to GCP Bigtable security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Bigtable
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Bigtable security
-faq:
-  - question: Why does GCP Bigtable security matter for cloud teams?
-    answer: GCP Bigtable security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Bigtable security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Bigtable security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Bigtable security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Bigtable security without proprietary black boxes.
----
-
-**GCP Bigtable security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Bigtable security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Bigtable security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) and [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Bigtable security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Bigtable security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Bigtable security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Bigtable security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/) · [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/)
diff --git a/src/content/blog/gcp-binary-authorization-security-guide.md b/src/content/blog/gcp-binary-authorization-security-guide.md
deleted file mode 100644
index 4ae3779..0000000
--- a/src/content/blog/gcp-binary-authorization-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Binary Authorization for Supply Chain Security"
-description: "Google Binary Authorization for Supply Chain Security — expert guide to GCP Binary Authorization security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAP..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Binary Authorization
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Binary Authorization security
-faq:
-  - question: Why does GCP Binary Authorization security matter for cloud teams?
-    answer: GCP Binary Authorization security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Binary Authorization security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Binary Authorization security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Binary Authorization security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Binary Authorization security without proprietary black boxes.
----
-
-**GCP Binary Authorization security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Binary Authorization security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Binary Authorization security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) and [cloud vulnerability management program](/blog/cloud-vulnerability-management-program/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Binary Authorization security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Binary Authorization security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Binary Authorization security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Binary Authorization security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/) · [cloud-vulnerability-management-program](/blog/cloud-vulnerability-management-program/)
diff --git a/src/content/blog/gcp-certificate-manager-security-guide.md b/src/content/blog/gcp-certificate-manager-security-guide.md
deleted file mode 100644
index de369f7..0000000
--- a/src/content/blog/gcp-certificate-manager-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Certificate Manager TLS Security Guide"
-description: "Google Certificate Manager TLS Security Guide — expert guide to GCP Certificate Manager security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Certificate Manager
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Certificate Manager security
-faq:
-  - question: Why does GCP Certificate Manager security matter for cloud teams?
-    answer: GCP Certificate Manager security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Certificate Manager security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Certificate Manager security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Certificate Manager security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Certificate Manager security without proprietary black boxes.
----
-
-**GCP Certificate Manager security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Certificate Manager security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Certificate Manager security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [lateral movement aws mitigation](/blog/lateral-movement-aws-mitigation/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Certificate Manager security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Certificate Manager security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Certificate Manager security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Certificate Manager security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [lateral-movement-aws-mitigation](/blog/lateral-movement-aws-mitigation/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/gcp-chronicle-security-operations.md b/src/content/blog/gcp-chronicle-security-operations.md
deleted file mode 100644
index 469ede8..0000000
--- a/src/content/blog/gcp-chronicle-security-operations.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Chronicle SecOps for GCP and Hybrid Cloud Monitoring"
-description: "Google Chronicle SecOps for GCP and Hybrid Cloud Monitoring—practical guidance on GCP Chronicle security for AWS, Azure, GCP, and Kubernetes teams using CSPM..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Chronicle
-  - SIEM
-  - cloud security
-  - threat detection
-focusKeyword: GCP Chronicle security
-faq:
-  - question: Why does GCP Chronicle security matter for cloud teams?
-    answer: GCP Chronicle security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Chronicle security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Chronicle security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Chronicle security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Chronicle security without proprietary black boxes.
----
-
-**GCP Chronicle security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Chronicle security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Chronicle security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Chronicle security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Chronicle security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Chronicle security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Chronicle security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/gcp-cloud-build-security-guide.md b/src/content/blog/gcp-cloud-build-security-guide.md
deleted file mode 100644
index 5989892..0000000
--- a/src/content/blog/gcp-cloud-build-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Build Security for CI/CD Pipelines"
-description: "Google Cloud Build Security for CI/CD Pipelines — expert guide to GCP Cloud Build security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Build
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Build security
-faq:
-  - question: Why does GCP Cloud Build security matter for cloud teams?
-    answer: GCP Cloud Build security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Build security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Build security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Build security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Build security without proprietary black boxes.
----
-
-**GCP Cloud Build security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Build security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Build security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Build security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Build security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Build security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Build security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/)
diff --git a/src/content/blog/gcp-cloud-cdn-security-guide.md b/src/content/blog/gcp-cloud-cdn-security-guide.md
deleted file mode 100644
index 72e8e12..0000000
--- a/src/content/blog/gcp-cloud-cdn-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud CDN Security and Origin Shielding"
-description: "Google Cloud CDN Security and Origin Shielding — expert guide to GCP Cloud CDN security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud CDN
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud CDN security
-faq:
-  - question: Why does GCP Cloud CDN security matter for cloud teams?
-    answer: GCP Cloud CDN security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud CDN security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud CDN security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud CDN security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud CDN security without proprietary black boxes.
----
-
-**GCP Cloud CDN security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud CDN security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud CDN security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud CDN security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud CDN security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud CDN security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud CDN security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/gcp-cloud-deploy-security-guide.md b/src/content/blog/gcp-cloud-deploy-security-guide.md
deleted file mode 100644
index 5ff54bb..0000000
--- a/src/content/blog/gcp-cloud-deploy-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Deploy Security and Release Controls"
-description: "Google Cloud Deploy Security and Release Controls — expert guide to GCP Cloud Deploy security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Deploy
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Deploy security
-faq:
-  - question: Why does GCP Cloud Deploy security matter for cloud teams?
-    answer: GCP Cloud Deploy security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Deploy security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Deploy security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Deploy security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Deploy security without proprietary black boxes.
----
-
-**GCP Cloud Deploy security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Deploy security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Deploy security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Deploy security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Deploy security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Deploy security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Deploy security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/)
diff --git a/src/content/blog/gcp-cloud-dns-security-guide.md b/src/content/blog/gcp-cloud-dns-security-guide.md
deleted file mode 100644
index e8eaf04..0000000
--- a/src/content/blog/gcp-cloud-dns-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud DNS Security and DNSSEC Configuration"
-description: "Google Cloud DNS Security and DNSSEC Configuration — expert guide to GCP Cloud DNS security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud DNS
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud DNS security
-faq:
-  - question: Why does GCP Cloud DNS security matter for cloud teams?
-    answer: GCP Cloud DNS security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud DNS security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud DNS security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud DNS security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud DNS security without proprietary black boxes.
----
-
-**GCP Cloud DNS security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud DNS security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud DNS security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud DNS security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud DNS security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud DNS security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud DNS security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/gcp-cloud-functions-security-guide.md b/src/content/blog/gcp-cloud-functions-security-guide.md
deleted file mode 100644
index ede9547..0000000
--- a/src/content/blog/gcp-cloud-functions-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Functions Security Best Practices"
-description: "Google Cloud Functions Security Best Practices — expert guide to GCP Cloud Functions security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Functions
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Functions security
-faq:
-  - question: Why does GCP Cloud Functions security matter for cloud teams?
-    answer: GCP Cloud Functions security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Functions security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Functions security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Functions security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Functions security without proprietary black boxes.
----
-
-**GCP Cloud Functions security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Functions security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Functions security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [container image scanning cicd](/blog/container-image-scanning-cicd/) and [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Functions security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Functions security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Functions security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Functions security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [container-image-scanning-cicd](/blog/container-image-scanning-cicd/) · [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/)
diff --git a/src/content/blog/gcp-cloud-interconnect-security-guide.md b/src/content/blog/gcp-cloud-interconnect-security-guide.md
deleted file mode 100644
index 5ea70af..0000000
--- a/src/content/blog/gcp-cloud-interconnect-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Interconnect Security Guide"
-description: "Google Cloud Interconnect Security Guide — expert guide to GCP Cloud Interconnect security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Interconnect
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Interconnect security
-faq:
-  - question: Why does GCP Cloud Interconnect security matter for cloud teams?
-    answer: GCP Cloud Interconnect security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Interconnect security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Interconnect security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Interconnect security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Interconnect security without proprietary black boxes.
----
-
-**GCP Cloud Interconnect security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Interconnect security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Interconnect security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Interconnect security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Interconnect security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Interconnect security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Interconnect security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/gcp-cloud-load-balancing-security-guide.md b/src/content/blog/gcp-cloud-load-balancing-security-guide.md
deleted file mode 100644
index 01e5d63..0000000
--- a/src/content/blog/gcp-cloud-load-balancing-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Load Balancing Security Architecture"
-description: "Google Cloud Load Balancing Security Architecture — expert guide to GCP Cloud Load Balancing security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Load Balancing
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Load Balancing security
-faq:
-  - question: Why does GCP Cloud Load Balancing security matter for cloud teams?
-    answer: GCP Cloud Load Balancing security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Load Balancing security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Load Balancing security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Load Balancing security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Load Balancing security without proprietary black boxes.
----
-
-**GCP Cloud Load Balancing security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Load Balancing security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Load Balancing security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Load Balancing security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Load Balancing security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Load Balancing security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Load Balancing security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/gcp-cloud-logging-security-guide.md b/src/content/blog/gcp-cloud-logging-security-guide.md
deleted file mode 100644
index 3525ca0..0000000
--- a/src/content/blog/gcp-cloud-logging-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Logging Security and Retention Policies"
-description: "Google Cloud Logging Security and Retention Policies — expert guide to GCP Cloud Logging security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Logging
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Logging security
-faq:
-  - question: Why does GCP Cloud Logging security matter for cloud teams?
-    answer: GCP Cloud Logging security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Logging security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Logging security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Logging security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Logging security without proprietary black boxes.
----
-
-**GCP Cloud Logging security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Logging security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Logging security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure application gateway waf](/blog/azure-application-gateway-waf/) and [gcp iam security hardening](/blog/gcp-iam-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Logging security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Logging security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Logging security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Logging security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-application-gateway-waf](/blog/azure-application-gateway-waf/) · [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/)
diff --git a/src/content/blog/gcp-cloud-nat-security-guide.md b/src/content/blog/gcp-cloud-nat-security-guide.md
deleted file mode 100644
index c66b374..0000000
--- a/src/content/blog/gcp-cloud-nat-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud NAT Security for Egress Control"
-description: "Google Cloud NAT Security for Egress Control — expert guide to GCP Cloud NAT security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud NAT
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud NAT security
-faq:
-  - question: Why does GCP Cloud NAT security matter for cloud teams?
-    answer: GCP Cloud NAT security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud NAT security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud NAT security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud NAT security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud NAT security without proprietary black boxes.
----
-
-**GCP Cloud NAT security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud NAT security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud NAT security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) and [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud NAT security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud NAT security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud NAT security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud NAT security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/) · [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/)
diff --git a/src/content/blog/gcp-cloud-run-security-guide.md b/src/content/blog/gcp-cloud-run-security-guide.md
deleted file mode 100644
index 765ed77..0000000
--- a/src/content/blog/gcp-cloud-run-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Run Security: IAM, VPC, and Ingress Controls"
-description: "Google Cloud Run Security — expert guide to GCP Cloud Run security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Run
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Run security
-faq:
-  - question: Why does GCP Cloud Run security matter for cloud teams?
-    answer: GCP Cloud Run security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Run security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Run security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Run security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Run security without proprietary black boxes.
----
-
-**GCP Cloud Run security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Run security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Run security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) and [aws cloudtrail monitoring security](/blog/aws-cloudtrail-monitoring-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Run security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Run security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Run security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Run security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/) · [aws-cloudtrail-monitoring-security](/blog/aws-cloudtrail-monitoring-security/)
diff --git a/src/content/blog/gcp-cloud-scheduler-security-guide.md b/src/content/blog/gcp-cloud-scheduler-security-guide.md
deleted file mode 100644
index 4013f26..0000000
--- a/src/content/blog/gcp-cloud-scheduler-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Scheduler Security and IAM"
-description: "Google Cloud Scheduler Security and IAM — expert guide to GCP Cloud Scheduler security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Scheduler
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Scheduler security
-faq:
-  - question: Why does GCP Cloud Scheduler security matter for cloud teams?
-    answer: GCP Cloud Scheduler security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Scheduler security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Scheduler security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Scheduler security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Scheduler security without proprietary black boxes.
----
-
-**GCP Cloud Scheduler security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Scheduler security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Scheduler security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Scheduler security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Scheduler security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Scheduler security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Scheduler security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/gcp-cloud-sql-security-best-practices.md b/src/content/blog/gcp-cloud-sql-security-best-practices.md
deleted file mode 100644
index 7004818..0000000
--- a/src/content/blog/gcp-cloud-sql-security-best-practices.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Cloud SQL Security Best Practices: Auth and Network Controls"
-description: "GCP Cloud SQL Security Best Practices—practical guidance on GCP Cloud SQL security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud SQL
-  - database security
-  - cloud security
-  - CSPM
-focusKeyword: GCP Cloud SQL security
-faq:
-  - question: Why does GCP Cloud SQL security matter for cloud teams?
-    answer: GCP Cloud SQL security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud SQL security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud SQL security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud SQL security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud SQL security without proprietary black boxes.
----
-
-**GCP Cloud SQL security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud SQL security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud SQL security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [cloud vulnerability management program](/blog/cloud-vulnerability-management-program/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud SQL security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud SQL security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud SQL security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud SQL security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [cloud-vulnerability-management-program](/blog/cloud-vulnerability-management-program/)
diff --git a/src/content/blog/gcp-cloud-storage-access-control.md b/src/content/blog/gcp-cloud-storage-access-control.md
deleted file mode 100644
index e7b9450..0000000
--- a/src/content/blog/gcp-cloud-storage-access-control.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Cloud Storage Access Control: IAM, ACLs, and Uniform Access"
-description: "GCP Cloud Storage Access Control—practical guidance on GCP Cloud Storage security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Storage
-  - data security
-  - CSPM
-  - cloud security
-focusKeyword: GCP Cloud Storage security
-faq:
-  - question: Why does GCP Cloud Storage security matter for cloud teams?
-    answer: GCP Cloud Storage security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Storage security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Storage security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Storage security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Storage security without proprietary black boxes.
----
-
-**GCP Cloud Storage security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Storage security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Storage security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Storage security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Storage security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Storage security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Storage security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/)
diff --git a/src/content/blog/gcp-cloud-tasks-security-guide.md b/src/content/blog/gcp-cloud-tasks-security-guide.md
deleted file mode 100644
index b288558..0000000
--- a/src/content/blog/gcp-cloud-tasks-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Tasks Security for Async Workloads"
-description: "Google Cloud Tasks Security for Async Workloads — expert guide to GCP Cloud Tasks security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Tasks
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Tasks security
-faq:
-  - question: Why does GCP Cloud Tasks security matter for cloud teams?
-    answer: GCP Cloud Tasks security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Tasks security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Tasks security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Tasks security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Tasks security without proprietary black boxes.
----
-
-**GCP Cloud Tasks security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Tasks security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Tasks security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Tasks security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Tasks security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Tasks security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Tasks security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/)
diff --git a/src/content/blog/gcp-cloud-trace-security-guide.md b/src/content/blog/gcp-cloud-trace-security-guide.md
deleted file mode 100644
index 16287b0..0000000
--- a/src/content/blog/gcp-cloud-trace-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Trace Security for Microservices"
-description: "Google Cloud Trace Security for Microservices — expert guide to GCP Cloud Trace security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud Trace
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud Trace security
-faq:
-  - question: Why does GCP Cloud Trace security matter for cloud teams?
-    answer: GCP Cloud Trace security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud Trace security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud Trace security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud Trace security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud Trace security without proprietary black boxes.
----
-
-**GCP Cloud Trace security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud Trace security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud Trace security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud Trace security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud Trace security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud Trace security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud Trace security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/gcp-cloud-vpn-security-guide.md b/src/content/blog/gcp-cloud-vpn-security-guide.md
deleted file mode 100644
index d6db385..0000000
--- a/src/content/blog/gcp-cloud-vpn-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud VPN Security and HA Setup"
-description: "Google Cloud VPN Security and HA Setup — expert guide to GCP Cloud VPN security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path priorit..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Cloud VPN
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Cloud VPN security
-faq:
-  - question: Why does GCP Cloud VPN security matter for cloud teams?
-    answer: GCP Cloud VPN security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Cloud VPN security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Cloud VPN security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Cloud VPN security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Cloud VPN security without proprietary black boxes.
----
-
-**GCP Cloud VPN security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Cloud VPN security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Cloud VPN security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) and [cloud incident response playbook](/blog/cloud-incident-response-playbook/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Cloud VPN security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Cloud VPN security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Cloud VPN security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Cloud VPN security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/) · [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/)
diff --git a/src/content/blog/gcp-compute-engine-security-hardening.md b/src/content/blog/gcp-compute-engine-security-hardening.md
deleted file mode 100644
index e5cd07c..0000000
--- a/src/content/blog/gcp-compute-engine-security-hardening.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Compute Engine Security Hardening for Production VMs"
-description: "GCP Compute Engine Security Hardening for Production VMs—practical guidance on GCP Compute Engine security for AWS, Azure, GCP, and Kubernetes teams using CS..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Compute Engine
-  - CWPP
-  - cloud security
-  - hardening
-focusKeyword: GCP Compute Engine security
-faq:
-  - question: Why does GCP Compute Engine security matter for cloud teams?
-    answer: GCP Compute Engine security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Compute Engine security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Compute Engine security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Compute Engine security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Compute Engine security without proprietary black boxes.
----
-
-**GCP Compute Engine security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Compute Engine security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Compute Engine security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp workload identity federation](/blog/gcp-workload-identity-federation/) and [kubernetes pod security standards](/blog/kubernetes-pod-security-standards/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Compute Engine security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Compute Engine security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Compute Engine security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Compute Engine security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/) · [kubernetes-pod-security-standards](/blog/kubernetes-pod-security-standards/)
diff --git a/src/content/blog/gcp-dataflow-security-guide.md b/src/content/blog/gcp-dataflow-security-guide.md
deleted file mode 100644
index 8b68e86..0000000
--- a/src/content/blog/gcp-dataflow-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Dataflow Security for Streaming ETL"
-description: "Google Cloud Dataflow Security for Streaming ETL — expert guide to GCP Dataflow security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Dataflow
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Dataflow security
-faq:
-  - question: Why does GCP Dataflow security matter for cloud teams?
-    answer: GCP Dataflow security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Dataflow security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Dataflow security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Dataflow security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Dataflow security without proprietary black boxes.
----
-
-**GCP Dataflow security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Dataflow security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Dataflow security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp security command center guide](/blog/gcp-security-command-center-guide/) and [aws security groups best practices](/blog/aws-security-groups-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Dataflow security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Dataflow security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Dataflow security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Dataflow security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-security-command-center-guide](/blog/gcp-security-command-center-guide/) · [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/)
diff --git a/src/content/blog/gcp-dataproc-security-guide.md b/src/content/blog/gcp-dataproc-security-guide.md
deleted file mode 100644
index 4eb1701..0000000
--- a/src/content/blog/gcp-dataproc-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Dataproc Security for Spark and Hadoop"
-description: "Google Dataproc Security for Spark and Hadoop — expert guide to GCP Dataproc security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Dataproc
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Dataproc security
-faq:
-  - question: Why does GCP Dataproc security matter for cloud teams?
-    answer: GCP Dataproc security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Dataproc security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Dataproc security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Dataproc security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Dataproc security without proprietary black boxes.
----
-
-**GCP Dataproc security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Dataproc security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Dataproc security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure key vault security hardening](/blog/azure-key-vault-security-hardening/) and [cloud incident response playbook](/blog/cloud-incident-response-playbook/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Dataproc security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Dataproc security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Dataproc security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Dataproc security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-key-vault-security-hardening](/blog/azure-key-vault-security-hardening/) · [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/)
diff --git a/src/content/blog/gcp-error-reporting-security-guide.md b/src/content/blog/gcp-error-reporting-security-guide.md
deleted file mode 100644
index 03e0e70..0000000
--- a/src/content/blog/gcp-error-reporting-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Error Reporting Security Considerations"
-description: "Google Cloud Error Reporting Security Considerations — expert guide to GCP Error Reporting security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Error Reporting
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Error Reporting security
-faq:
-  - question: Why does GCP Error Reporting security matter for cloud teams?
-    answer: GCP Error Reporting security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Error Reporting security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Error Reporting security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Error Reporting security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Error Reporting security without proprietary black boxes.
----
-
-**GCP Error Reporting security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Error Reporting security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Error Reporting security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Error Reporting security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Error Reporting security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Error Reporting security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Error Reporting security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/)
diff --git a/src/content/blog/gcp-filestore-security-guide.md b/src/content/blog/gcp-filestore-security-guide.md
deleted file mode 100644
index 069bd32..0000000
--- a/src/content/blog/gcp-filestore-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Filestore Security and VPC Peering"
-description: "Google Cloud Filestore Security and VPC Peering — expert guide to GCP Filestore security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Filestore
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Filestore security
-faq:
-  - question: Why does GCP Filestore security matter for cloud teams?
-    answer: GCP Filestore security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Filestore security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Filestore security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Filestore security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Filestore security without proprietary black boxes.
----
-
-**GCP Filestore security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Filestore security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Filestore security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp organization policy constraints](/blog/gcp-organization-policy-constraints/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Filestore security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Filestore security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Filestore security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Filestore security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-organization-policy-constraints](/blog/gcp-organization-policy-constraints/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/gcp-firestore-security-guide.md b/src/content/blog/gcp-firestore-security-guide.md
deleted file mode 100644
index 67ec1ec..0000000
--- a/src/content/blog/gcp-firestore-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Cloud Firestore Security Rules and IAM Guide"
-description: "Cloud Firestore Security Rules and IAM Guide — expert guide to GCP Firestore security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Firestore
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Firestore security
-faq:
-  - question: Why does GCP Firestore security matter for cloud teams?
-    answer: GCP Firestore security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Firestore security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Firestore security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Firestore security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Firestore security without proprietary black boxes.
----
-
-**GCP Firestore security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Firestore security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Firestore security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Firestore security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Firestore security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Firestore security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Firestore security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/)
diff --git a/src/content/blog/gcp-gke-security-guide.md b/src/content/blog/gcp-gke-security-guide.md
deleted file mode 100644
index 930e5eb..0000000
--- a/src/content/blog/gcp-gke-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google GKE Security Hardening for Production Clusters"
-description: "Google GKE Security Hardening for Production Clusters — expert guide to GCP GKE security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - GKE
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP GKE security
-faq:
-  - question: Why does GCP GKE security matter for cloud teams?
-    answer: GCP GKE security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP GKE security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP GKE security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP GKE security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP GKE security without proprietary black boxes.
----
-
-**GCP GKE security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP GKE security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP GKE security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security groups best practices](/blog/aws-security-groups-best-practices/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP GKE security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP GKE security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP GKE security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP GKE security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-groups-best-practices](/blog/aws-security-groups-best-practices/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/gcp-identity-aware-proxy-security-guide.md b/src/content/blog/gcp-identity-aware-proxy-security-guide.md
deleted file mode 100644
index 26158fb..0000000
--- a/src/content/blog/gcp-identity-aware-proxy-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Identity-Aware Proxy for Zero Trust Access"
-description: "Google Identity-Aware Proxy for Zero Trust Access — expert guide to GCP Identity-Aware Proxy security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Identity-Aware Proxy
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Identity-Aware Proxy security
-faq:
-  - question: Why does GCP Identity-Aware Proxy security matter for cloud teams?
-    answer: GCP Identity-Aware Proxy security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Identity-Aware Proxy security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Identity-Aware Proxy security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Identity-Aware Proxy security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Identity-Aware Proxy security without proprietary black boxes.
----
-
-**GCP Identity-Aware Proxy security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Identity-Aware Proxy security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Identity-Aware Proxy security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Identity-Aware Proxy security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Identity-Aware Proxy security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Identity-Aware Proxy security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Identity-Aware Proxy security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/)
diff --git a/src/content/blog/gcp-memorystore-security-guide.md b/src/content/blog/gcp-memorystore-security-guide.md
deleted file mode 100644
index cedbc08..0000000
--- a/src/content/blog/gcp-memorystore-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Memorystore Redis Security Configuration"
-description: "Google Memorystore Redis Security Configuration — expert guide to GCP Memorystore security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Memorystore
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Memorystore security
-faq:
-  - question: Why does GCP Memorystore security matter for cloud teams?
-    answer: GCP Memorystore security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Memorystore security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Memorystore security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Memorystore security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Memorystore security without proprietary black boxes.
----
-
-**GCP Memorystore security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Memorystore security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Memorystore security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Memorystore security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Memorystore security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Memorystore security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Memorystore security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/gcp-organization-policy-constraints.md b/src/content/blog/gcp-organization-policy-constraints.md
deleted file mode 100644
index 2fec41a..0000000
--- a/src/content/blog/gcp-organization-policy-constraints.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Organization Policy Constraints for Security Baselines"
-description: "GCP Organization Policy Constraints for Security Baselines—practical guidance on GCP organization policy for AWS, Azure, GCP, and Kubernetes teams using CSPM..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - organization policy
-  - governance
-  - cloud security
-  - CSPM
-focusKeyword: GCP organization policy
-faq:
-  - question: Why does GCP organization policy matter for cloud teams?
-    answer: GCP organization policy reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP organization policy relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP organization policy gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP organization policy?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP organization policy without proprietary black boxes.
----
-
-**GCP organization policy** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP organization policy matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP organization policy | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP organization policy with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP organization policy at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP organization policy program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP organization policy** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/gcp-pub-sub-security-guide.md b/src/content/blog/gcp-pub-sub-security-guide.md
deleted file mode 100644
index d49685f..0000000
--- a/src/content/blog/gcp-pub-sub-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Pub/Sub Security and Message Encryption"
-description: "Google Cloud Pub/Sub Security and Message Encryption — expert guide to GCP Pub/Sub security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Pub/Sub
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Pub/Sub security
-faq:
-  - question: Why does GCP Pub/Sub security matter for cloud teams?
-    answer: GCP Pub/Sub security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Pub/Sub security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Pub/Sub security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Pub/Sub security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Pub/Sub security without proprietary black boxes.
----
-
-**GCP Pub/Sub security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Pub/Sub security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Pub/Sub security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [gcp workload identity federation](/blog/gcp-workload-identity-federation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Pub/Sub security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Pub/Sub security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Pub/Sub security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Pub/Sub security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/)
diff --git a/src/content/blog/gcp-secret-manager-security-guide.md b/src/content/blog/gcp-secret-manager-security-guide.md
deleted file mode 100644
index 5d749c4..0000000
--- a/src/content/blog/gcp-secret-manager-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Secret Manager Security and Rotation"
-description: "Google Secret Manager Security and Rotation — expert guide to GCP Secret Manager security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Secret Manager
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Secret Manager security
-faq:
-  - question: Why does GCP Secret Manager security matter for cloud teams?
-    answer: GCP Secret Manager security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Secret Manager security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Secret Manager security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Secret Manager security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Secret Manager security without proprietary black boxes.
----
-
-**GCP Secret Manager security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Secret Manager security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Secret Manager security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud vulnerability management program](/blog/cloud-vulnerability-management-program/) and [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Secret Manager security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Secret Manager security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Secret Manager security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Secret Manager security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-vulnerability-management-program](/blog/cloud-vulnerability-management-program/) · [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/)
diff --git a/src/content/blog/gcp-security-command-center-guide.md b/src/content/blog/gcp-security-command-center-guide.md
deleted file mode 100644
index 5e95311..0000000
--- a/src/content/blog/gcp-security-command-center-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Security Command Center: Findings, Sources, and Workflows"
-description: "GCP Security Command Center—practical guidance on GCP Security Command Center for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Security Command Center
-  - CSPM
-  - cloud security
-  - Google Cloud
-focusKeyword: GCP Security Command Center
-faq:
-  - question: Why does GCP Security Command Center matter for cloud teams?
-    answer: GCP Security Command Center reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Security Command Center relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Security Command Center gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Security Command Center?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Security Command Center without proprietary black boxes.
----
-
-**GCP Security Command Center** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Security Command Center matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Security Command Center | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Security Command Center with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Security Command Center at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Security Command Center program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Security Command Center** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/gcp-spanner-security-guide.md b/src/content/blog/gcp-spanner-security-guide.md
deleted file mode 100644
index bc2bbc5..0000000
--- a/src/content/blog/gcp-spanner-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Cloud Spanner Security for Global Databases"
-description: "Google Cloud Spanner Security for Global Databases — expert guide to GCP Spanner security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Spanner
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Spanner security
-faq:
-  - question: Why does GCP Spanner security matter for cloud teams?
-    answer: GCP Spanner security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Spanner security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Spanner security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Spanner security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Spanner security without proprietary black boxes.
----
-
-**GCP Spanner security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Spanner security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Spanner security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Spanner security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Spanner security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Spanner security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Spanner security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/gcp-vertex-ai-security-guide.md b/src/content/blog/gcp-vertex-ai-security-guide.md
deleted file mode 100644
index c16edf2..0000000
--- a/src/content/blog/gcp-vertex-ai-security-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Google Vertex AI Security for Enterprise ML Workloads"
-description: "Google Vertex AI Security for Enterprise ML Workloads — expert guide to GCP Vertex AI security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Vertex AI
-  - cloud security
-  - CSPM
-  - CNAPP
-focusKeyword: GCP Vertex AI security
-faq:
-  - question: Why does GCP Vertex AI security matter for cloud teams?
-    answer: GCP Vertex AI security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Vertex AI security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Vertex AI security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Vertex AI security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Vertex AI security without proprietary black boxes.
----
-
-**GCP Vertex AI security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Vertex AI security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Vertex AI security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Vertex AI security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Vertex AI security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Vertex AI security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Vertex AI security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/gcp-vpc-service-controls-explained.md b/src/content/blog/gcp-vpc-service-controls-explained.md
deleted file mode 100644
index 72d65d0..0000000
--- a/src/content/blog/gcp-vpc-service-controls-explained.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP VPC Service Controls Explained: Data Exfiltration Guardrails"
-description: "GCP VPC Service Controls Explained—practical guidance on GCP VPC Service Controls for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - VPC Service Controls
-  - data security
-  - cloud security
-  - DSPM
-focusKeyword: GCP VPC Service Controls
-faq:
-  - question: Why does GCP VPC Service Controls matter for cloud teams?
-    answer: GCP VPC Service Controls reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP VPC Service Controls relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP VPC Service Controls gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP VPC Service Controls?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP VPC Service Controls without proprietary black boxes.
----
-
-**GCP VPC Service Controls** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP VPC Service Controls matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP VPC Service Controls | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp organization policy constraints](/blog/gcp-organization-policy-constraints/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP VPC Service Controls with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP VPC Service Controls at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP VPC Service Controls program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP VPC Service Controls** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-organization-policy-constraints](/blog/gcp-organization-policy-constraints/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/gcp-workload-identity-federation.md b/src/content/blog/gcp-workload-identity-federation.md
deleted file mode 100644
index 8e89374..0000000
--- a/src/content/blog/gcp-workload-identity-federation.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GCP Workload Identity Federation: Keyless Access from CI/CD"
-description: "GCP Workload Identity Federation—practical guidance on GCP Workload Identity Federation for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - GCP
-  - Workload Identity
-  - CIEM
-  - devsecops
-  - cloud security
-focusKeyword: GCP Workload Identity Federation
-faq:
-  - question: Why does GCP Workload Identity Federation matter for cloud teams?
-    answer: GCP Workload Identity Federation reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GCP Workload Identity Federation relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GCP Workload Identity Federation gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GCP Workload Identity Federation?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GCP Workload Identity Federation without proprietary black boxes.
----
-
-**GCP Workload Identity Federation** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GCP Workload Identity Federation matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GCP Workload Identity Federation | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure application gateway waf](/blog/azure-application-gateway-waf/) and [dspm data security posture management](/blog/dspm-data-security-posture-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GCP Workload Identity Federation with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GCP Workload Identity Federation at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GCP Workload Identity Federation program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GCP Workload Identity Federation** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-application-gateway-waf](/blog/azure-application-gateway-waf/) · [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/)
diff --git a/src/content/blog/gdpr-cloud-security-compliance.md b/src/content/blog/gdpr-cloud-security-compliance.md
deleted file mode 100644
index c0c5c9f..0000000
--- a/src/content/blog/gdpr-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "GDPR Cloud Data Protection and Security Obligations"
-description: "GDPR Cloud Data Protection and Security Obligations — expert guide to GDPR cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - GDPR
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: GDPR cloud security
-faq:
-  - question: Why does GDPR cloud security matter for cloud teams?
-    answer: GDPR cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does GDPR cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether GDPR cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support GDPR cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize GDPR cloud security without proprietary black boxes.
----
-
-**GDPR cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why GDPR cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without GDPR cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align GDPR cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce GDPR cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature GDPR cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **GDPR cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/graphql-api-security.md b/src/content/blog/graphql-api-security.md
deleted file mode 100644
index 26bcc0f..0000000
--- a/src/content/blog/graphql-api-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "GraphQL API Security in Cloud-Native Architectures"
-description: "GraphQL API Security in Cloud-Native Architectures — expert guide to graphql api security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: graphql api security
-faq:
-  - question: Why does graphql api security matter for cloud teams?
-    answer: graphql api security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does graphql api security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether graphql api security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support graphql api security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize graphql api security without proprietary black boxes.
----
-
-**graphql api security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why graphql api security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without graphql api security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align graphql api security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce graphql api security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature graphql api security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **graphql api security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/hipaa-cloud-security-compliance.md b/src/content/blog/hipaa-cloud-security-compliance.md
deleted file mode 100644
index 64c6409..0000000
--- a/src/content/blog/hipaa-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "HIPAA Cloud Security Requirements for Healthcare Data"
-description: "HIPAA Cloud Security Requirements for Healthcare Data — expert guide to HIPAA cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - HIPAA
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: HIPAA cloud security
-faq:
-  - question: Why does HIPAA cloud security matter for cloud teams?
-    answer: HIPAA cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does HIPAA cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether HIPAA cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support HIPAA cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize HIPAA cloud security without proprietary black boxes.
----
-
-**HIPAA cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why HIPAA cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without HIPAA cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align HIPAA cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce HIPAA cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature HIPAA cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **HIPAA cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/)
diff --git a/src/content/blog/hitrust-cloud-security-compliance.md b/src/content/blog/hitrust-cloud-security-compliance.md
deleted file mode 100644
index 2f6c471..0000000
--- a/src/content/blog/hitrust-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "HITRUST CSF Cloud Security Certification Roadmap"
-description: "HITRUST CSF Cloud Security Certification Roadmap — expert guide to HITRUST cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - HITRUST
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: HITRUST cloud security
-faq:
-  - question: Why does HITRUST cloud security matter for cloud teams?
-    answer: HITRUST cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does HITRUST cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether HITRUST cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support HITRUST cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize HITRUST cloud security without proprietary black boxes.
----
-
-**HITRUST cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why HITRUST cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without HITRUST cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align HITRUST cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce HITRUST cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature HITRUST cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **HITRUST cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/hybrid-cloud-security.md b/src/content/blog/hybrid-cloud-security.md
deleted file mode 100644
index 1058c10..0000000
--- a/src/content/blog/hybrid-cloud-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Hybrid Cloud Security Architecture Best Practices"
-description: "Hybrid Cloud Security Architecture Best Practices — expert guide to hybrid cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: hybrid cloud security
-faq:
-  - question: Why does hybrid cloud security matter for cloud teams?
-    answer: hybrid cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does hybrid cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether hybrid cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support hybrid cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize hybrid cloud security without proprietary black boxes.
----
-
-**hybrid cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why hybrid cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without hybrid cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align hybrid cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce hybrid cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature hybrid cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **hybrid cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/insider-threat-cloud.md b/src/content/blog/insider-threat-cloud.md
deleted file mode 100644
index a9676dc..0000000
--- a/src/content/blog/insider-threat-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Insider Threat Detection in Cloud Control Planes"
-description: "Insider Threat Detection in Cloud Control Planes — expert guide to insider threat cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: insider threat cloud
-faq:
-  - question: Why does insider threat cloud matter for cloud teams?
-    answer: insider threat cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does insider threat cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether insider threat cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support insider threat cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize insider threat cloud without proprietary black boxes.
----
-
-**insider threat cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why insider threat cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without insider threat cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align insider threat cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce insider threat cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature insider threat cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **insider threat cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/)
diff --git a/src/content/blog/irap-cloud-security-compliance.md b/src/content/blog/irap-cloud-security-compliance.md
deleted file mode 100644
index 1d9945c..0000000
--- a/src/content/blog/irap-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "IRAP Cloud Security Assessment for Australian Government"
-description: "IRAP Cloud Security Assessment for Australian Government — expert guide to IRAP cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - IRAP
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: IRAP cloud security
-faq:
-  - question: Why does IRAP cloud security matter for cloud teams?
-    answer: IRAP cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does IRAP cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether IRAP cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support IRAP cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize IRAP cloud security without proprietary black boxes.
----
-
-**IRAP cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why IRAP cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without IRAP cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp workload identity federation](/blog/gcp-workload-identity-federation/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align IRAP cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce IRAP cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature IRAP cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **IRAP cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/iso-27001-cloud-security-compliance.md b/src/content/blog/iso-27001-cloud-security-compliance.md
deleted file mode 100644
index 978ce7d..0000000
--- a/src/content/blog/iso-27001-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "ISO 27001 Cloud Security Mapping for AWS and Azure"
-description: "ISO 27001 Cloud Security Mapping for AWS and Azure — expert guide to ISO 27001 cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - ISO 27001
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: ISO 27001 cloud security
-faq:
-  - question: Why does ISO 27001 cloud security matter for cloud teams?
-    answer: ISO 27001 cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does ISO 27001 cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether ISO 27001 cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support ISO 27001 cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize ISO 27001 cloud security without proprietary black boxes.
----
-
-**ISO 27001 cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why ISO 27001 cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without ISO 27001 cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp iam security hardening](/blog/gcp-iam-security-hardening/) and [azure defender cloud security](/blog/azure-defender-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align ISO 27001 cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce ISO 27001 cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature ISO 27001 cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **ISO 27001 cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/) · [azure-defender-cloud-security](/blog/azure-defender-cloud-security/)
diff --git a/src/content/blog/kubernetes-admission-controllers-security.md b/src/content/blog/kubernetes-admission-controllers-security.md
deleted file mode 100644
index 5793705..0000000
--- a/src/content/blog/kubernetes-admission-controllers-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Kubernetes Admission Controllers for Security Policy Enforcement"
-description: "Kubernetes Admission Controllers for Security Policy Enforcement—practical guidance on Kubernetes admission controllers for AWS, Azure, GCP, and Kubernetes t..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - admission control
-  - policy
-  - container security
-  - devsecops
-focusKeyword: Kubernetes admission controllers
-faq:
-  - question: Why does Kubernetes admission controllers matter for cloud teams?
-    answer: Kubernetes admission controllers reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes admission controllers relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes admission controllers gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes admission controllers?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes admission controllers without proprietary black boxes.
----
-
-**Kubernetes admission controllers** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes admission controllers matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes admission controllers | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud tagging strategy security governance](/blog/cloud-tagging-strategy-security-governance/) and [multi cloud security governance](/blog/multi-cloud-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes admission controllers with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes admission controllers at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes admission controllers program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes admission controllers** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-tagging-strategy-security-governance](/blog/cloud-tagging-strategy-security-governance/) · [multi-cloud-security-governance](/blog/multi-cloud-security-governance/)
diff --git a/src/content/blog/kubernetes-argo-cd-hardening-guide.md b/src/content/blog/kubernetes-argo-cd-hardening-guide.md
deleted file mode 100644
index 6408001..0000000
--- a/src/content/blog/kubernetes-argo-cd-hardening-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Argo CD Security Hardening for Production GitOps"
-description: "Argo CD Security Hardening for Production GitOps — expert guide to Kubernetes argo cd hardening for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes argo cd hardening
-faq:
-  - question: Why does Kubernetes argo cd hardening matter for cloud teams?
-    answer: Kubernetes argo cd hardening reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes argo cd hardening relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes argo cd hardening gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes argo cd hardening?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes argo cd hardening without proprietary black boxes.
----
-
-**Kubernetes argo cd hardening** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes argo cd hardening matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes argo cd hardening | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes argo cd hardening with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes argo cd hardening at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes argo cd hardening program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes argo cd hardening** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/kubernetes-calico-policies-guide.md b/src/content/blog/kubernetes-calico-policies-guide.md
deleted file mode 100644
index bec0057..0000000
--- a/src/content/blog/kubernetes-calico-policies-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Calico Network Policies for Kubernetes Segmentation"
-description: "Calico Network Policies for Kubernetes Segmentation — expert guide to Kubernetes calico policies for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes calico policies
-faq:
-  - question: Why does Kubernetes calico policies matter for cloud teams?
-    answer: Kubernetes calico policies reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes calico policies relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes calico policies gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes calico policies?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes calico policies without proprietary black boxes.
----
-
-**Kubernetes calico policies** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes calico policies matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes calico policies | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) and [aws security best practices 2026](/blog/aws-security-best-practices-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes calico policies with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes calico policies at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes calico policies program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes calico policies** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) · [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/)
diff --git a/src/content/blog/kubernetes-cert-manager-tls-guide.md b/src/content/blog/kubernetes-cert-manager-tls-guide.md
deleted file mode 100644
index 01c6ed7..0000000
--- a/src/content/blog/kubernetes-cert-manager-tls-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "cert-manager TLS Security for Kubernetes Ingress"
-description: "cert-manager TLS Security for Kubernetes Ingress — expert guide to Kubernetes cert manager tls for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes cert manager tls
-faq:
-  - question: Why does Kubernetes cert manager tls matter for cloud teams?
-    answer: Kubernetes cert manager tls reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes cert manager tls relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes cert manager tls gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes cert manager tls?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes cert manager tls without proprietary black boxes.
----
-
-**Kubernetes cert manager tls** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes cert manager tls matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes cert manager tls | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure defender cloud security](/blog/azure-defender-cloud-security/) and [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes cert manager tls with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes cert manager tls at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes cert manager tls program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes cert manager tls** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-defender-cloud-security](/blog/azure-defender-cloud-security/) · [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/)
diff --git a/src/content/blog/kubernetes-cilium-network-guide.md b/src/content/blog/kubernetes-cilium-network-guide.md
deleted file mode 100644
index e7f5260..0000000
--- a/src/content/blog/kubernetes-cilium-network-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cilium Network Security for Kubernetes Clusters"
-description: "Cilium Network Security for Kubernetes Clusters — expert guide to Kubernetes cilium network for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes cilium network
-faq:
-  - question: Why does Kubernetes cilium network matter for cloud teams?
-    answer: Kubernetes cilium network reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes cilium network relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes cilium network gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes cilium network?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes cilium network without proprietary black boxes.
----
-
-**Kubernetes cilium network** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes cilium network matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes cilium network | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes cilium network with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes cilium network at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes cilium network program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes cilium network** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/)
diff --git a/src/content/blog/kubernetes-cis-benchmark-k8s-guide.md b/src/content/blog/kubernetes-cis-benchmark-k8s-guide.md
deleted file mode 100644
index 0be9589..0000000
--- a/src/content/blog/kubernetes-cis-benchmark-k8s-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "CIS Kubernetes Benchmark Implementation Guide"
-description: "CIS Kubernetes Benchmark Implementation Guide — expert guide to Kubernetes cis benchmark k8s for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes cis benchmark k8s
-faq:
-  - question: Why does Kubernetes cis benchmark k8s matter for cloud teams?
-    answer: Kubernetes cis benchmark k8s reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes cis benchmark k8s relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes cis benchmark k8s gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes cis benchmark k8s?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes cis benchmark k8s without proprietary black boxes.
----
-
-**Kubernetes cis benchmark k8s** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes cis benchmark k8s matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes cis benchmark k8s | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [container image scanning cicd](/blog/container-image-scanning-cicd/) and [terraform security scanning iac drift](/blog/terraform-security-scanning-iac-drift/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes cis benchmark k8s with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes cis benchmark k8s at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes cis benchmark k8s program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes cis benchmark k8s** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [container-image-scanning-cicd](/blog/container-image-scanning-cicd/) · [terraform-security-scanning-iac-drift](/blog/terraform-security-scanning-iac-drift/)
diff --git a/src/content/blog/kubernetes-cluster-autoscaler-security-guide.md b/src/content/blog/kubernetes-cluster-autoscaler-security-guide.md
deleted file mode 100644
index 6b043c2..0000000
--- a/src/content/blog/kubernetes-cluster-autoscaler-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Cluster Autoscaler Security Considerations"
-description: "Kubernetes Cluster Autoscaler Security Considerations — expert guide to Kubernetes cluster autoscaler security for AWS, Azure, GCP, and Kubernetes with CSPM,..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes cluster autoscaler security
-faq:
-  - question: Why does Kubernetes cluster autoscaler security matter for cloud teams?
-    answer: Kubernetes cluster autoscaler security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes cluster autoscaler security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes cluster autoscaler security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes cluster autoscaler security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes cluster autoscaler security without proprietary black boxes.
----
-
-**Kubernetes cluster autoscaler security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes cluster autoscaler security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes cluster autoscaler security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) and [cloud drift detection remediation](/blog/cloud-drift-detection-remediation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes cluster autoscaler security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes cluster autoscaler security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes cluster autoscaler security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes cluster autoscaler security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/) · [cloud-drift-detection-remediation](/blog/cloud-drift-detection-remediation/)
diff --git a/src/content/blog/kubernetes-control-plane-hardening-guide.md b/src/content/blog/kubernetes-control-plane-hardening-guide.md
deleted file mode 100644
index 1208020..0000000
--- a/src/content/blog/kubernetes-control-plane-hardening-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Control Plane Hardening Checklist"
-description: "Kubernetes Control Plane Hardening Checklist — expert guide to Kubernetes control plane hardening for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes control plane hardening
-faq:
-  - question: Why does Kubernetes control plane hardening matter for cloud teams?
-    answer: Kubernetes control plane hardening reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes control plane hardening relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes control plane hardening gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes control plane hardening?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes control plane hardening without proprietary black boxes.
----
-
-**Kubernetes control plane hardening** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes control plane hardening matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes control plane hardening | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes control plane hardening with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes control plane hardening at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes control plane hardening program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes control plane hardening** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/kubernetes-cronjob-security-guide.md b/src/content/blog/kubernetes-cronjob-security-guide.md
deleted file mode 100644
index 9af30c5..0000000
--- a/src/content/blog/kubernetes-cronjob-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes CronJob Security and RBAC Scoping"
-description: "Kubernetes CronJob Security and RBAC Scoping — expert guide to Kubernetes cronjob security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes cronjob security
-faq:
-  - question: Why does Kubernetes cronjob security matter for cloud teams?
-    answer: Kubernetes cronjob security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes cronjob security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes cronjob security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes cronjob security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes cronjob security without proprietary black boxes.
----
-
-**Kubernetes cronjob security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes cronjob security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes cronjob security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure blob storage security guide](/blog/azure-blob-storage-security-guide/) and [kubernetes admission controllers security](/blog/kubernetes-admission-controllers-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes cronjob security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes cronjob security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes cronjob security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes cronjob security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-blob-storage-security-guide](/blog/azure-blob-storage-security-guide/) · [kubernetes-admission-controllers-security](/blog/kubernetes-admission-controllers-security/)
diff --git a/src/content/blog/kubernetes-csi-driver-security-guide.md b/src/content/blog/kubernetes-csi-driver-security-guide.md
deleted file mode 100644
index 4dc091c..0000000
--- a/src/content/blog/kubernetes-csi-driver-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes CSI Driver Security and Volume Encryption"
-description: "Kubernetes CSI Driver Security and Volume Encryption — expert guide to Kubernetes csi driver security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes csi driver security
-faq:
-  - question: Why does Kubernetes csi driver security matter for cloud teams?
-    answer: Kubernetes csi driver security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes csi driver security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes csi driver security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes csi driver security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes csi driver security without proprietary black boxes.
----
-
-**Kubernetes csi driver security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes csi driver security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes csi driver security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [azure network security groups guide](/blog/azure-network-security-groups-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes csi driver security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes csi driver security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes csi driver security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes csi driver security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/)
diff --git a/src/content/blog/kubernetes-egress-control-guide.md b/src/content/blog/kubernetes-egress-control-guide.md
deleted file mode 100644
index eaa134f..0000000
--- a/src/content/blog/kubernetes-egress-control-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Egress Control: Preventing Data Exfiltration"
-description: "Kubernetes Egress Control — expert guide to Kubernetes egress control for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization fo..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes egress control
-faq:
-  - question: Why does Kubernetes egress control matter for cloud teams?
-    answer: Kubernetes egress control reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes egress control relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes egress control gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes egress control?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes egress control without proprietary black boxes.
----
-
-**Kubernetes egress control** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes egress control matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes egress control | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [serverless security lambda azure functions](/blog/serverless-security-lambda-azure-functions/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes egress control with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes egress control at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes egress control program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes egress control** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [serverless-security-lambda-azure-functions](/blog/serverless-security-lambda-azure-functions/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/kubernetes-etcd-encryption-guide.md b/src/content/blog/kubernetes-etcd-encryption-guide.md
deleted file mode 100644
index 25e1cd2..0000000
--- a/src/content/blog/kubernetes-etcd-encryption-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes etcd Encryption at Rest Configuration"
-description: "Kubernetes etcd Encryption at Rest Configuration — expert guide to Kubernetes etcd encryption for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes etcd encryption
-faq:
-  - question: Why does Kubernetes etcd encryption matter for cloud teams?
-    answer: Kubernetes etcd encryption reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes etcd encryption relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes etcd encryption gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes etcd encryption?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes etcd encryption without proprietary black boxes.
----
-
-**Kubernetes etcd encryption** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes etcd encryption matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes etcd encryption | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [sbom supply chain cloud security](/blog/sbom-supply-chain-cloud-security/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes etcd encryption with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes etcd encryption at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes etcd encryption program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes etcd encryption** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [sbom-supply-chain-cloud-security](/blog/sbom-supply-chain-cloud-security/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/kubernetes-external-secrets-guide.md b/src/content/blog/kubernetes-external-secrets-guide.md
deleted file mode 100644
index 1288a27..0000000
--- a/src/content/blog/kubernetes-external-secrets-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "External Secrets Operator Security in Kubernetes"
-description: "External Secrets Operator Security in Kubernetes — expert guide to Kubernetes external secrets for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes external secrets
-faq:
-  - question: Why does Kubernetes external secrets matter for cloud teams?
-    answer: Kubernetes external secrets reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes external secrets relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes external secrets gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes external secrets?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes external secrets without proprietary black boxes.
----
-
-**Kubernetes external secrets** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes external secrets matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes external secrets | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes external secrets with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes external secrets at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes external secrets program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes external secrets** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/kubernetes-falco-runtime-guide.md b/src/content/blog/kubernetes-falco-runtime-guide.md
deleted file mode 100644
index ad0e13a..0000000
--- a/src/content/blog/kubernetes-falco-runtime-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Falco Runtime Security for Kubernetes Threat Detection"
-description: "Falco Runtime Security for Kubernetes Threat Detection — expert guide to Kubernetes falco runtime for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes falco runtime
-faq:
-  - question: Why does Kubernetes falco runtime matter for cloud teams?
-    answer: Kubernetes falco runtime reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes falco runtime relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes falco runtime gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes falco runtime?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes falco runtime without proprietary black boxes.
----
-
-**Kubernetes falco runtime** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes falco runtime matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes falco runtime | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) and [container image scanning cicd](/blog/container-image-scanning-cicd/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes falco runtime with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes falco runtime at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes falco runtime program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes falco runtime** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/) · [container-image-scanning-cicd](/blog/container-image-scanning-cicd/)
diff --git a/src/content/blog/kubernetes-gatekeeper-opa-guide.md b/src/content/blog/kubernetes-gatekeeper-opa-guide.md
deleted file mode 100644
index b995990..0000000
--- a/src/content/blog/kubernetes-gatekeeper-opa-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "OPA Gatekeeper Policies for Kubernetes Compliance"
-description: "OPA Gatekeeper Policies for Kubernetes Compliance — expert guide to Kubernetes gatekeeper opa for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes gatekeeper opa
-faq:
-  - question: Why does Kubernetes gatekeeper opa matter for cloud teams?
-    answer: Kubernetes gatekeeper opa reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes gatekeeper opa relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes gatekeeper opa gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes gatekeeper opa?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes gatekeeper opa without proprietary black boxes.
----
-
-**Kubernetes gatekeeper opa** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes gatekeeper opa matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes gatekeeper opa | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes gatekeeper opa with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes gatekeeper opa at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes gatekeeper opa program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes gatekeeper opa** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/kubernetes-gitops-security-guide.md b/src/content/blog/kubernetes-gitops-security-guide.md
deleted file mode 100644
index 989c3e4..0000000
--- a/src/content/blog/kubernetes-gitops-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "GitOps Security for Kubernetes: Argo CD and Flux"
-description: "GitOps Security for Kubernetes — expert guide to Kubernetes gitops security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritizat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes gitops security
-faq:
-  - question: Why does Kubernetes gitops security matter for cloud teams?
-    answer: Kubernetes gitops security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes gitops security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes gitops security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes gitops security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes gitops security without proprietary black boxes.
----
-
-**Kubernetes gitops security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes gitops security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes gitops security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud identity federation sso security](/blog/cloud-identity-federation-sso-security/) and [lateral movement aws mitigation](/blog/lateral-movement-aws-mitigation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes gitops security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes gitops security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes gitops security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes gitops security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-identity-federation-sso-security](/blog/cloud-identity-federation-sso-security/) · [lateral-movement-aws-mitigation](/blog/lateral-movement-aws-mitigation/)
diff --git a/src/content/blog/kubernetes-helm-chart-security-guide.md b/src/content/blog/kubernetes-helm-chart-security-guide.md
deleted file mode 100644
index 2356acd..0000000
--- a/src/content/blog/kubernetes-helm-chart-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Helm Chart Security Scanning and Best Practices"
-description: "Helm Chart Security Scanning and Best Practices — expert guide to Kubernetes helm chart security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes helm chart security
-faq:
-  - question: Why does Kubernetes helm chart security matter for cloud teams?
-    answer: Kubernetes helm chart security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes helm chart security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes helm chart security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes helm chart security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes helm chart security without proprietary black boxes.
----
-
-**Kubernetes helm chart security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes helm chart security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes helm chart security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws organizations scp security](/blog/aws-organizations-scp-security/) and [container image scanning cicd](/blog/container-image-scanning-cicd/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes helm chart security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes helm chart security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes helm chart security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes helm chart security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-organizations-scp-security](/blog/aws-organizations-scp-security/) · [container-image-scanning-cicd](/blog/container-image-scanning-cicd/)
diff --git a/src/content/blog/kubernetes-ingress-security-guide.md b/src/content/blog/kubernetes-ingress-security-guide.md
deleted file mode 100644
index 9cd05b5..0000000
--- a/src/content/blog/kubernetes-ingress-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Ingress Security: TLS, Auth, and WAF"
-description: "Kubernetes Ingress Security — expert guide to Kubernetes ingress security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritizatio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes ingress security
-faq:
-  - question: Why does Kubernetes ingress security matter for cloud teams?
-    answer: Kubernetes ingress security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes ingress security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes ingress security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes ingress security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes ingress security without proprietary black boxes.
----
-
-**Kubernetes ingress security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes ingress security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes ingress security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure management groups policy](/blog/azure-management-groups-policy/) and [lateral movement aws mitigation](/blog/lateral-movement-aws-mitigation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes ingress security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes ingress security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes ingress security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes ingress security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-management-groups-policy](/blog/azure-management-groups-policy/) · [lateral-movement-aws-mitigation](/blog/lateral-movement-aws-mitigation/)
diff --git a/src/content/blog/kubernetes-kyverno-policies-guide.md b/src/content/blog/kubernetes-kyverno-policies-guide.md
deleted file mode 100644
index fac00dd..0000000
--- a/src/content/blog/kubernetes-kyverno-policies-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kyverno Policy Engine Security for Kubernetes"
-description: "Kyverno Policy Engine Security for Kubernetes — expert guide to Kubernetes kyverno policies for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes kyverno policies
-faq:
-  - question: Why does Kubernetes kyverno policies matter for cloud teams?
-    answer: Kubernetes kyverno policies reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes kyverno policies relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes kyverno policies gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes kyverno policies?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes kyverno policies without proprietary black boxes.
----
-
-**Kubernetes kyverno policies** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes kyverno policies matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes kyverno policies | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) and [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes kyverno policies with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes kyverno policies at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes kyverno policies program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes kyverno policies** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/) · [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/)
diff --git a/src/content/blog/kubernetes-multi-tenancy-guide.md b/src/content/blog/kubernetes-multi-tenancy-guide.md
deleted file mode 100644
index 11c5fe7..0000000
--- a/src/content/blog/kubernetes-multi-tenancy-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Multi-Tenancy Security with Namespaces"
-description: "Kubernetes Multi-Tenancy Security with Namespaces — expert guide to Kubernetes multi-tenancy for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes multi-tenancy
-faq:
-  - question: Why does Kubernetes multi-tenancy matter for cloud teams?
-    answer: Kubernetes multi-tenancy reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes multi-tenancy relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes multi-tenancy gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes multi-tenancy?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes multi-tenancy without proprietary black boxes.
----
-
-**Kubernetes multi-tenancy** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes multi-tenancy matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes multi-tenancy | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes multi-tenancy with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes multi-tenancy at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes multi-tenancy program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes multi-tenancy** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/)
diff --git a/src/content/blog/kubernetes-network-policies-practical-guide.md b/src/content/blog/kubernetes-network-policies-practical-guide.md
deleted file mode 100644
index 1fd472b..0000000
--- a/src/content/blog/kubernetes-network-policies-practical-guide.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Kubernetes Network Policies: A Practical Implementation Guide"
-description: "Kubernetes Network Policies—practical guidance on Kubernetes network policies for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - NetworkPolicy
-  - container security
-  - cloud security
-  - micro-segmentation
-focusKeyword: Kubernetes network policies
-faq:
-  - question: Why does Kubernetes network policies matter for cloud teams?
-    answer: Kubernetes network policies reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes network policies relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes network policies gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes network policies?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes network policies without proprietary black boxes.
----
-
-**Kubernetes network policies** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes network policies matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes network policies | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) and [zero trust cloud architecture guide](/blog/zero-trust-cloud-architecture-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes network policies with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes network policies at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes network policies program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes network policies** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/) · [zero-trust-cloud-architecture-guide](/blog/zero-trust-cloud-architecture-guide/)
diff --git a/src/content/blog/kubernetes-node-hardening-guide.md b/src/content/blog/kubernetes-node-hardening-guide.md
deleted file mode 100644
index 5d1525c..0000000
--- a/src/content/blog/kubernetes-node-hardening-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Worker Node Hardening for Production"
-description: "Kubernetes Worker Node Hardening for Production — expert guide to Kubernetes node hardening for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes node hardening
-faq:
-  - question: Why does Kubernetes node hardening matter for cloud teams?
-    answer: Kubernetes node hardening reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes node hardening relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes node hardening gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes node hardening?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes node hardening without proprietary black boxes.
----
-
-**Kubernetes node hardening** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes node hardening matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes node hardening | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp organization policy constraints](/blog/gcp-organization-policy-constraints/) and [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes node hardening with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes node hardening at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes node hardening program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes node hardening** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-organization-policy-constraints](/blog/gcp-organization-policy-constraints/) · [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/)
diff --git a/src/content/blog/kubernetes-persistent-volume-security-guide.md b/src/content/blog/kubernetes-persistent-volume-security-guide.md
deleted file mode 100644
index 9f30d40..0000000
--- a/src/content/blog/kubernetes-persistent-volume-security-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Persistent Volume Security Best Practices"
-description: "Kubernetes Persistent Volume Security Best Practices — expert guide to Kubernetes persistent volume security for AWS, Azure, GCP, and Kubernetes with CSPM, C..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes persistent volume security
-faq:
-  - question: Why does Kubernetes persistent volume security matter for cloud teams?
-    answer: Kubernetes persistent volume security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes persistent volume security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes persistent volume security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes persistent volume security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes persistent volume security without proprietary black boxes.
----
-
-**Kubernetes persistent volume security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes persistent volume security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes persistent volume security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp organization policy constraints](/blog/gcp-organization-policy-constraints/) and [cloud workload protection cwpp guide](/blog/cloud-workload-protection-cwpp-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes persistent volume security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes persistent volume security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes persistent volume security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes persistent volume security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-organization-policy-constraints](/blog/gcp-organization-policy-constraints/) · [cloud-workload-protection-cwpp-guide](/blog/cloud-workload-protection-cwpp-guide/)
diff --git a/src/content/blog/kubernetes-pod-security-standards.md b/src/content/blog/kubernetes-pod-security-standards.md
deleted file mode 100644
index 3e7f1a7..0000000
--- a/src/content/blog/kubernetes-pod-security-standards.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Kubernetes Pod Security Standards: Enforcing Baseline and Restricted"
-description: "Kubernetes Pod Security Standards—practical guidance on Kubernetes Pod Security Standards for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and at..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - pod security
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes Pod Security Standards
-faq:
-  - question: Why does Kubernetes Pod Security Standards matter for cloud teams?
-    answer: Kubernetes Pod Security Standards reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes Pod Security Standards relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes Pod Security Standards gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes Pod Security Standards?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes Pod Security Standards without proprietary black boxes.
----
-
-**Kubernetes Pod Security Standards** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes Pod Security Standards matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes Pod Security Standards | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [kubernetes pod security standards](/blog/kubernetes-pod-security-standards/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes Pod Security Standards with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes Pod Security Standards at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes Pod Security Standards program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes Pod Security Standards** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [kubernetes-pod-security-standards](/blog/kubernetes-pod-security-standards/)
diff --git a/src/content/blog/kubernetes-runtime-threat-detection-guide.md b/src/content/blog/kubernetes-runtime-threat-detection-guide.md
deleted file mode 100644
index f44ad00..0000000
--- a/src/content/blog/kubernetes-runtime-threat-detection-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Runtime Threat Detection with eBPF"
-description: "Kubernetes Runtime Threat Detection with eBPF — expert guide to Kubernetes runtime threat detection for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes runtime threat detection
-faq:
-  - question: Why does Kubernetes runtime threat detection matter for cloud teams?
-    answer: Kubernetes runtime threat detection reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes runtime threat detection relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes runtime threat detection gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes runtime threat detection?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes runtime threat detection without proprietary black boxes.
----
-
-**Kubernetes runtime threat detection** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes runtime threat detection matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes runtime threat detection | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [dspm data security posture management](/blog/dspm-data-security-posture-management/) and [kubernetes network policies practical guide](/blog/kubernetes-network-policies-practical-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes runtime threat detection with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes runtime threat detection at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes runtime threat detection program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes runtime threat detection** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/) · [kubernetes-network-policies-practical-guide](/blog/kubernetes-network-policies-practical-guide/)
diff --git a/src/content/blog/kubernetes-sealed-secrets-guide.md b/src/content/blog/kubernetes-sealed-secrets-guide.md
deleted file mode 100644
index a664312..0000000
--- a/src/content/blog/kubernetes-sealed-secrets-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Sealed Secrets for GitOps Kubernetes Deployments"
-description: "Sealed Secrets for GitOps Kubernetes Deployments — expert guide to Kubernetes sealed secrets for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes sealed secrets
-faq:
-  - question: Why does Kubernetes sealed secrets matter for cloud teams?
-    answer: Kubernetes sealed secrets reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes sealed secrets relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes sealed secrets gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes sealed secrets?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes sealed secrets without proprietary black boxes.
----
-
-**Kubernetes sealed secrets** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes sealed secrets matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes sealed secrets | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) and [kubernetes pod security standards](/blog/kubernetes-pod-security-standards/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes sealed secrets with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes sealed secrets at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes sealed secrets program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes sealed secrets** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/) · [kubernetes-pod-security-standards](/blog/kubernetes-pod-security-standards/)
diff --git a/src/content/blog/kubernetes-service-mesh-mtls-guide.md b/src/content/blog/kubernetes-service-mesh-mtls-guide.md
deleted file mode 100644
index fdce938..0000000
--- a/src/content/blog/kubernetes-service-mesh-mtls-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Kubernetes Service Mesh mTLS Security Patterns"
-description: "Kubernetes Service Mesh mTLS Security Patterns — expert guide to Kubernetes service mesh mtls for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes service mesh mtls
-faq:
-  - question: Why does Kubernetes service mesh mtls matter for cloud teams?
-    answer: Kubernetes service mesh mtls reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes service mesh mtls relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes service mesh mtls gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes service mesh mtls?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes service mesh mtls without proprietary black boxes.
----
-
-**Kubernetes service mesh mtls** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes service mesh mtls matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes service mesh mtls | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [container image scanning cicd](/blog/container-image-scanning-cicd/) and [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes service mesh mtls with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes service mesh mtls at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes service mesh mtls program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes service mesh mtls** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [container-image-scanning-cicd](/blog/container-image-scanning-cicd/) · [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/)
diff --git a/src/content/blog/kubernetes-trivy-scanning-guide.md b/src/content/blog/kubernetes-trivy-scanning-guide.md
deleted file mode 100644
index 49e9218..0000000
--- a/src/content/blog/kubernetes-trivy-scanning-guide.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Trivy Container Scanning in Kubernetes CI/CD"
-description: "Trivy Container Scanning in Kubernetes CI/CD — expert guide to Kubernetes trivy scanning for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pat..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Kubernetes
-  - container security
-  - CNAPP
-  - cloud security
-focusKeyword: Kubernetes trivy scanning
-faq:
-  - question: Why does Kubernetes trivy scanning matter for cloud teams?
-    answer: Kubernetes trivy scanning reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Kubernetes trivy scanning relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Kubernetes trivy scanning gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Kubernetes trivy scanning?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Kubernetes trivy scanning without proprietary black boxes.
----
-
-**Kubernetes trivy scanning** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Kubernetes trivy scanning matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Kubernetes trivy scanning | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws security best practices 2026](/blog/aws-security-best-practices-2026/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Kubernetes trivy scanning with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Kubernetes trivy scanning at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Kubernetes trivy scanning program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Kubernetes trivy scanning** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-security-best-practices-2026](/blog/aws-security-best-practices-2026/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/lateral-movement-aws-mitigation.md b/src/content/blog/lateral-movement-aws-mitigation.md
deleted file mode 100644
index 8f44f5f..0000000
--- a/src/content/blog/lateral-movement-aws-mitigation.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Lateral Movement in AWS: Detection Patterns and Mitigation"
-description: "Lateral Movement in AWS—practical guidance on lateral movement AWS for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - AWS
-  - lateral movement
-  - cloud security
-  - IAM
-  - threat detection
-focusKeyword: lateral movement AWS
-faq:
-  - question: Why does lateral movement AWS matter for cloud teams?
-    answer: lateral movement AWS reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does lateral movement AWS relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether lateral movement AWS gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support lateral movement AWS?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize lateral movement AWS without proprietary black boxes.
----
-
-**lateral movement AWS** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why lateral movement AWS matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without lateral movement AWS | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws s3 bucket security hardening](/blog/aws-s3-bucket-security-hardening/) and [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align lateral movement AWS with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce lateral movement AWS at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature lateral movement AWS program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **lateral movement AWS** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-s3-bucket-security-hardening](/blog/aws-s3-bucket-security-hardening/) · [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/)
diff --git a/src/content/blog/llm-cloud-security.md b/src/content/blog/llm-cloud-security.md
deleted file mode 100644
index 09485cf..0000000
--- a/src/content/blog/llm-cloud-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "LLM Cloud Security: Prompt Injection and Data Leakage"
-description: "LLM Cloud Security — expert guide to llm cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practitioners."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: llm cloud security
-faq:
-  - question: Why does llm cloud security matter for cloud teams?
-    answer: llm cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does llm cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether llm cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support llm cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize llm cloud security without proprietary black boxes.
----
-
-**llm cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why llm cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without llm cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp workload identity federation](/blog/gcp-workload-identity-federation/) and [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align llm cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce llm cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature llm cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **llm cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/) · [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/)
diff --git a/src/content/blog/mas-trm-cloud-security-compliance.md b/src/content/blog/mas-trm-cloud-security-compliance.md
deleted file mode 100644
index 6061018..0000000
--- a/src/content/blog/mas-trm-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "MAS TRM Cloud Technology Risk Management Guide"
-description: "MAS TRM Cloud Technology Risk Management Guide — expert guide to MAS TRM cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - MAS TRM
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: MAS TRM cloud security
-faq:
-  - question: Why does MAS TRM cloud security matter for cloud teams?
-    answer: MAS TRM cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does MAS TRM cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether MAS TRM cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support MAS TRM cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize MAS TRM cloud security without proprietary black boxes.
----
-
-**MAS TRM cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why MAS TRM cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without MAS TRM cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) and [azure defender cloud security](/blog/azure-defender-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align MAS TRM cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce MAS TRM cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature MAS TRM cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **MAS TRM cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) · [azure-defender-cloud-security](/blog/azure-defender-cloud-security/)
diff --git a/src/content/blog/microservices-security.md b/src/content/blog/microservices-security.md
deleted file mode 100644
index aeceb0a..0000000
--- a/src/content/blog/microservices-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Microservices Security Patterns in the Cloud"
-description: "Microservices Security Patterns in the Cloud — expert guide to microservices security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: microservices security
-faq:
-  - question: Why does microservices security matter for cloud teams?
-    answer: microservices security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does microservices security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether microservices security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support microservices security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize microservices security without proprietary black boxes.
----
-
-**microservices security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why microservices security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without microservices security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [cloud secrets management best practices](/blog/cloud-secrets-management-best-practices/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align microservices security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce microservices security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature microservices security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **microservices security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [cloud-secrets-management-best-practices](/blog/cloud-secrets-management-best-practices/)
diff --git a/src/content/blog/mitre-att-ck-cloud.md b/src/content/blog/mitre-att-ck-cloud.md
deleted file mode 100644
index 929b8cb..0000000
--- a/src/content/blog/mitre-att-ck-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "MITRE ATT&CK for Cloud: Mapping Detections to TTPs"
-description: "MITRE ATT&CK for Cloud — expert guide to mitre att&ck cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prioritization for practiti..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: mitre att&ck cloud
-faq:
-  - question: Why does mitre att&ck cloud matter for cloud teams?
-    answer: mitre att&ck cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does mitre att&ck cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether mitre att&ck cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support mitre att&ck cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize mitre att&ck cloud without proprietary black boxes.
----
-
-**mitre att&ck cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why mitre att&ck cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without mitre att&ck cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure management groups policy](/blog/azure-management-groups-policy/) and [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align mitre att&ck cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce mitre att&ck cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature mitre att&ck cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **mitre att&ck cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-management-groups-policy](/blog/azure-management-groups-policy/) · [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/)
diff --git a/src/content/blog/mssp-cloud-security.md b/src/content/blog/mssp-cloud-security.md
deleted file mode 100644
index 929fb93..0000000
--- a/src/content/blog/mssp-cloud-security.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "MSSP Cloud Security Service Design Patterns"
-description: "MSSP Cloud Security Service Design Patterns — expert guide to mssp cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prior..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: mssp cloud security
-faq:
-  - question: Why does mssp cloud security matter for cloud teams?
-    answer: mssp cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does mssp cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether mssp cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support mssp cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize mssp cloud security without proprietary black boxes.
----
-
-**mssp cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why mssp cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without mssp cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) and [ciem explained for cloud teams](/blog/ciem-explained-for-cloud-teams/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align mssp cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce mssp cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature mssp cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **mssp cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) · [CIEM explained](/blog/ciem-explained-for-cloud-teams/)
diff --git a/src/content/blog/multi-cloud-security-governance.md b/src/content/blog/multi-cloud-security-governance.md
deleted file mode 100644
index 912f659..0000000
--- a/src/content/blog/multi-cloud-security-governance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Multi-Cloud Security Governance: Frameworks That Scale"
-description: "Multi-Cloud Security Governance—practical guidance on multi-cloud security governance for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - multi-cloud
-  - governance
-  - CSPM
-  - cloud security
-  - CNAPP
-focusKeyword: multi-cloud security governance
-faq:
-  - question: Why does multi-cloud security governance matter for cloud teams?
-    answer: multi-cloud security governance reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does multi-cloud security governance relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether multi-cloud security governance gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support multi-cloud security governance?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize multi-cloud security governance without proprietary black boxes.
----
-
-**multi-cloud security governance** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why multi-cloud security governance matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without multi-cloud security governance | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align multi-cloud security governance with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce multi-cloud security governance at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature multi-cloud security governance program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **multi-cloud security governance** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/nis2-directive-cloud-security-compliance.md b/src/content/blog/nis2-directive-cloud-security-compliance.md
deleted file mode 100644
index 51904a1..0000000
--- a/src/content/blog/nis2-directive-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "NIS2 Cloud Security Requirements for EU Operators"
-description: "NIS2 Cloud Security Requirements for EU Operators — expert guide to NIS2 Directive cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and a..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - NIS2 Directive
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: NIS2 Directive cloud security
-faq:
-  - question: Why does NIS2 Directive cloud security matter for cloud teams?
-    answer: NIS2 Directive cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does NIS2 Directive cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether NIS2 Directive cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support NIS2 Directive cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize NIS2 Directive cloud security without proprietary black boxes.
----
-
-**NIS2 Directive cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why NIS2 Directive cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without NIS2 Directive cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [azure defender cloud security](/blog/azure-defender-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align NIS2 Directive cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce NIS2 Directive cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature NIS2 Directive cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **NIS2 Directive cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [azure-defender-cloud-security](/blog/azure-defender-cloud-security/)
diff --git a/src/content/blog/nist-800-53-cloud-security-compliance.md b/src/content/blog/nist-800-53-cloud-security-compliance.md
deleted file mode 100644
index 2e1d9b5..0000000
--- a/src/content/blog/nist-800-53-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "NIST 800-53 Controls for Cloud Service Providers"
-description: "NIST 800-53 Controls for Cloud Service Providers — expert guide to NIST 800-53 cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - NIST 800-53
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: NIST 800-53 cloud security
-faq:
-  - question: Why does NIST 800-53 cloud security matter for cloud teams?
-    answer: NIST 800-53 cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does NIST 800-53 cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether NIST 800-53 cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support NIST 800-53 cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize NIST 800-53 cloud security without proprietary black boxes.
----
-
-**NIST 800-53 cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why NIST 800-53 cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without NIST 800-53 cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws kms encryption key management](/blog/aws-kms-encryption-key-management/) and [azure network security groups guide](/blog/azure-network-security-groups-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align NIST 800-53 cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce NIST 800-53 cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature NIST 800-53 cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **NIST 800-53 cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-kms-encryption-key-management](/blog/aws-kms-encryption-key-management/) · [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/)
diff --git a/src/content/blog/oauth-cloud-attacks.md b/src/content/blog/oauth-cloud-attacks.md
deleted file mode 100644
index f9ff65b..0000000
--- a/src/content/blog/oauth-cloud-attacks.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "OAuth and OIDC Attack Patterns in Cloud Apps"
-description: "OAuth and OIDC Attack Patterns in Cloud Apps — expert guide to oauth cloud attacks for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path prio..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: oauth cloud attacks
-faq:
-  - question: Why does oauth cloud attacks matter for cloud teams?
-    answer: oauth cloud attacks reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does oauth cloud attacks relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether oauth cloud attacks gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support oauth cloud attacks?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize oauth cloud attacks without proprietary black boxes.
----
-
-**oauth cloud attacks** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why oauth cloud attacks matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without oauth cloud attacks | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure network security groups guide](/blog/azure-network-security-groups-guide/) and [dspm data security posture management](/blog/dspm-data-security-posture-management/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align oauth cloud attacks with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce oauth cloud attacks at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature oauth cloud attacks program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **oauth cloud attacks** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-network-security-groups-guide](/blog/azure-network-security-groups-guide/) · [dspm-data-security-posture-management](/blog/dspm-data-security-posture-management/)
diff --git a/src/content/blog/opa-cloud-governance.md b/src/content/blog/opa-cloud-governance.md
deleted file mode 100644
index 4aaa295..0000000
--- a/src/content/blog/opa-cloud-governance.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Open Policy Agent for Cloud Security Policies"
-description: "Open Policy Agent for Cloud Security Policies — expert guide to opa cloud governance for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: opa cloud governance
-faq:
-  - question: Why does opa cloud governance matter for cloud teams?
-    answer: opa cloud governance reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does opa cloud governance relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether opa cloud governance gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support opa cloud governance?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize opa cloud governance without proprietary black boxes.
----
-
-**opa cloud governance** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why opa cloud governance matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without opa cloud governance | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws ec2 hardening checklist](/blog/aws-ec2-hardening-checklist/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align opa cloud governance with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce opa cloud governance at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature opa cloud governance program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **opa cloud governance** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-ec2-hardening-checklist](/blog/aws-ec2-hardening-checklist/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/pci-dss-4-0-cloud-security-compliance.md b/src/content/blog/pci-dss-4-0-cloud-security-compliance.md
deleted file mode 100644
index d2ddee3..0000000
--- a/src/content/blog/pci-dss-4-0-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "PCI DSS 4.0 Cloud Compliance for Payment Workloads"
-description: "PCI DSS 4.0 Cloud Compliance for Payment Workloads — expert guide to PCI DSS 4.0 cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and att..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - PCI DSS 4.0
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: PCI DSS 4.0 cloud security
-faq:
-  - question: Why does PCI DSS 4.0 cloud security matter for cloud teams?
-    answer: PCI DSS 4.0 cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does PCI DSS 4.0 cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether PCI DSS 4.0 cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support PCI DSS 4.0 cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize PCI DSS 4.0 cloud security without proprietary black boxes.
----
-
-**PCI DSS 4.0 cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why PCI DSS 4.0 cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without PCI DSS 4.0 cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [kubernetes rbac security best practices](/blog/kubernetes-rbac-security-best-practices/) and [open source cspm cnapp tools 2026](/blog/open-source-cspm-cnapp-tools-2026/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align PCI DSS 4.0 cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce PCI DSS 4.0 cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature PCI DSS 4.0 cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **PCI DSS 4.0 cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [kubernetes-rbac-security-best-practices](/blog/kubernetes-rbac-security-best-practices/) · [Open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/)
diff --git a/src/content/blog/policy-as-code-cloud.md b/src/content/blog/policy-as-code-cloud.md
deleted file mode 100644
index 70805d0..0000000
--- a/src/content/blog/policy-as-code-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Policy as Code for Multi-Cloud Security Governance"
-description: "Policy as Code for Multi-Cloud Security Governance — expert guide to policy as code cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack pa..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: policy as code cloud
-faq:
-  - question: Why does policy as code cloud matter for cloud teams?
-    answer: policy as code cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does policy as code cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether policy as code cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support policy as code cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize policy as code cloud without proprietary black boxes.
----
-
-**policy as code cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why policy as code cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without policy as code cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud compliance cis benchmarks](/blog/cloud-compliance-cis-benchmarks/) and [gcp chronicle security operations](/blog/gcp-chronicle-security-operations/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align policy as code cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce policy as code cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature policy as code cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **policy as code cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-compliance-cis-benchmarks](/blog/cloud-compliance-cis-benchmarks/) · [gcp-chronicle-security-operations](/blog/gcp-chronicle-security-operations/)
diff --git a/src/content/blog/purple-team-cloud.md b/src/content/blog/purple-team-cloud.md
deleted file mode 100644
index 7366be4..0000000
--- a/src/content/blog/purple-team-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Purple Team Exercises for Cloud Security Programs"
-description: "Purple Team Exercises for Cloud Security Programs — expert guide to purple team cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: purple team cloud
-faq:
-  - question: Why does purple team cloud matter for cloud teams?
-    answer: purple team cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does purple team cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether purple team cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support purple team cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize purple team cloud without proprietary black boxes.
----
-
-**purple team cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why purple team cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without purple team cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) and [gcp workload identity federation](/blog/gcp-workload-identity-federation/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align purple team cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce purple team cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature purple team cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **purple team cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/) · [gcp-workload-identity-federation](/blog/gcp-workload-identity-federation/)
diff --git a/src/content/blog/ransomware-cloud-recovery.md b/src/content/blog/ransomware-cloud-recovery.md
deleted file mode 100644
index ce72370..0000000
--- a/src/content/blog/ransomware-cloud-recovery.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Ransomware Recovery Planning for Cloud Workloads"
-description: "Ransomware Recovery Planning for Cloud Workloads — expert guide to ransomware cloud recovery for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: ransomware cloud recovery
-faq:
-  - question: Why does ransomware cloud recovery matter for cloud teams?
-    answer: ransomware cloud recovery reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does ransomware cloud recovery relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether ransomware cloud recovery gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support ransomware cloud recovery?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize ransomware cloud recovery without proprietary black boxes.
----
-
-**ransomware cloud recovery** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why ransomware cloud recovery matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without ransomware cloud recovery | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp compute engine security hardening](/blog/gcp-compute-engine-security-hardening/) and [multi cloud security governance](/blog/multi-cloud-security-governance/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align ransomware cloud recovery with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce ransomware cloud recovery at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature ransomware cloud recovery program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **ransomware cloud recovery** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-compute-engine-security-hardening](/blog/gcp-compute-engine-security-hardening/) · [multi-cloud-security-governance](/blog/multi-cloud-security-governance/)
diff --git a/src/content/blog/sbom-supply-chain-cloud-security.md b/src/content/blog/sbom-supply-chain-cloud-security.md
deleted file mode 100644
index 9569c7c..0000000
--- a/src/content/blog/sbom-supply-chain-cloud-security.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "SBOM and Supply Chain Security for Cloud-Native Teams"
-description: "SBOM and Supply Chain Security for Cloud-Native Teams—practical guidance on SBOM cloud security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, ..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - SBOM
-  - supply chain
-  - cloud security
-  - devsecops
-  - container security
-focusKeyword: SBOM cloud security
-faq:
-  - question: Why does SBOM cloud security matter for cloud teams?
-    answer: SBOM cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does SBOM cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether SBOM cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support SBOM cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize SBOM cloud security without proprietary black boxes.
----
-
-**SBOM cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why SBOM cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without SBOM cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure defender cloud security](/blog/azure-defender-cloud-security/) and [aws waf web application firewall guide](/blog/aws-waf-web-application-firewall-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align SBOM cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce SBOM cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature SBOM cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **SBOM cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-defender-cloud-security](/blog/azure-defender-cloud-security/) · [aws-waf-web-application-firewall-guide](/blog/aws-waf-web-application-firewall-guide/)
diff --git a/src/content/blog/security-architect-cloud.md b/src/content/blog/security-architect-cloud.md
deleted file mode 100644
index 7445ef2..0000000
--- a/src/content/blog/security-architect-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Cloud Security Architect Skills and Career Path"
-description: "Cloud Security Architect Skills and Career Path — expert guide to security architect cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: security architect cloud
-faq:
-  - question: Why does security architect cloud matter for cloud teams?
-    answer: security architect cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does security architect cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether security architect cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support security architect cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize security architect cloud without proprietary black boxes.
----
-
-**security architect cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why security architect cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without security architect cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [toxic combinations aws azure](/blog/toxic-combinations-aws-azure/) and [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align security architect cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce security architect cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature security architect cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **security architect cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) · [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/)
diff --git a/src/content/blog/security-chaos-engineering.md b/src/content/blog/security-chaos-engineering.md
deleted file mode 100644
index ab28957..0000000
--- a/src/content/blog/security-chaos-engineering.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Security Chaos Engineering in Cloud Environments"
-description: "Security Chaos Engineering in Cloud Environments — expert guide to security chaos engineering for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attac..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: security chaos engineering
-faq:
-  - question: Why does security chaos engineering matter for cloud teams?
-    answer: security chaos engineering reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does security chaos engineering relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether security chaos engineering gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support security chaos engineering?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize security chaos engineering without proprietary black boxes.
----
-
-**security chaos engineering** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why security chaos engineering matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without security chaos engineering | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [cloud incident response playbook](/blog/cloud-incident-response-playbook/) and [aws guardduty threat detection](/blog/aws-guardduty-threat-detection/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align security chaos engineering with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce security chaos engineering at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature security chaos engineering program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **security chaos engineering** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [cloud-incident-response-playbook](/blog/cloud-incident-response-playbook/) · [aws-guardduty-threat-detection](/blog/aws-guardduty-threat-detection/)
diff --git a/src/content/blog/serverless-security-lambda-azure-functions.md b/src/content/blog/serverless-security-lambda-azure-functions.md
deleted file mode 100644
index cc4952e..0000000
--- a/src/content/blog/serverless-security-lambda-azure-functions.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Serverless Security: AWS Lambda and Azure Functions Hardening"
-description: "Serverless Security—practical guidance on serverless security for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path prioritization."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - serverless
-  - Lambda
-  - Azure Functions
-  - cloud security
-  - CWPP
-focusKeyword: serverless security
-faq:
-  - question: Why does serverless security matter for cloud teams?
-    answer: serverless security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does serverless security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether serverless security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support serverless security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize serverless security without proprietary black boxes.
----
-
-**serverless security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why serverless security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without serverless security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure sentinel cloud siem](/blog/azure-sentinel-cloud-siem/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align serverless security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce serverless security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature serverless security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **serverless security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-sentinel-cloud-siem](/blog/azure-sentinel-cloud-siem/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)
diff --git a/src/content/blog/soc-2-type-ii-cloud-security-compliance.md b/src/content/blog/soc-2-type-ii-cloud-security-compliance.md
deleted file mode 100644
index e2ffe1a..0000000
--- a/src/content/blog/soc-2-type-ii-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "SOC 2 Type II Cloud Security Controls Checklist"
-description: "SOC 2 Type II Cloud Security Controls Checklist — expert guide to SOC 2 Type II cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and atta..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - SOC 2 Type II
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: SOC 2 Type II cloud security
-faq:
-  - question: Why does SOC 2 Type II cloud security matter for cloud teams?
-    answer: SOC 2 Type II cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does SOC 2 Type II cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether SOC 2 Type II cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support SOC 2 Type II cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize SOC 2 Type II cloud security without proprietary black boxes.
----
-
-**SOC 2 Type II cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why SOC 2 Type II cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without SOC 2 Type II cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) and [gcp vpc service controls explained](/blog/gcp-vpc-service-controls-explained/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align SOC 2 Type II cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce SOC 2 Type II cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature SOC 2 Type II cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **SOC 2 Type II cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [Attack path analysis](/blog/attack-path-analysis-cloud-security/) · [gcp-vpc-service-controls-explained](/blog/gcp-vpc-service-controls-explained/)
diff --git a/src/content/blog/sox-itgc-cloud-security-compliance.md b/src/content/blog/sox-itgc-cloud-security-compliance.md
deleted file mode 100644
index f8962c1..0000000
--- a/src/content/blog/sox-itgc-cloud-security-compliance.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "SOX IT General Controls in Cloud Environments"
-description: "SOX IT General Controls in Cloud Environments — expert guide to SOX ITGC cloud security for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - compliance
-  - SOX ITGC
-  - cloud security
-  - CSPM
-  - audit
-focusKeyword: SOX ITGC cloud security
-faq:
-  - question: Why does SOX ITGC cloud security matter for cloud teams?
-    answer: SOX ITGC cloud security reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does SOX ITGC cloud security relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether SOX ITGC cloud security gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support SOX ITGC cloud security?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize SOX ITGC cloud security without proprietary black boxes.
----
-
-**SOX ITGC cloud security** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why SOX ITGC cloud security matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without SOX ITGC cloud security | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [aws sso iam identity center hardening](/blog/aws-sso-iam-identity-center-hardening/) and [cloud api security rate limiting](/blog/cloud-api-security-rate-limiting/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align SOX ITGC cloud security with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce SOX ITGC cloud security at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature SOX ITGC cloud security program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **SOX ITGC cloud security** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [aws-sso-iam-identity-center-hardening](/blog/aws-sso-iam-identity-center-hardening/) · [cloud-api-security-rate-limiting](/blog/cloud-api-security-rate-limiting/)
diff --git a/src/content/blog/terraform-security-scanning-iac-drift.md b/src/content/blog/terraform-security-scanning-iac-drift.md
deleted file mode 100644
index 94bcd99..0000000
--- a/src/content/blog/terraform-security-scanning-iac-drift.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: "Terraform Security Scanning: Catch IaC Drift Before Deploy"
-description: "Terraform Security Scanning—practical guidance on Terraform security scanning for AWS, Azure, GCP, and Kubernetes teams using CSPM, CNAPP, and attack path pr..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - Terraform
-  - IaC
-  - CSPM
-  - cloud security
-  - devsecops
-focusKeyword: Terraform security scanning
-faq:
-  - question: Why does Terraform security scanning matter for cloud teams?
-    answer: Terraform security scanning reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does Terraform security scanning relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether Terraform security scanning gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support Terraform security scanning?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize Terraform security scanning without proprietary black boxes.
----
-
-**Terraform security scanning** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why Terraform security scanning matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without Terraform security scanning | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp iam security hardening](/blog/gcp-iam-security-hardening/) and [azure cspm implementation guide](/blog/azure-cspm-implementation-guide/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align Terraform security scanning with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce Terraform security scanning at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature Terraform security scanning program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **Terraform security scanning** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-iam-security-hardening](/blog/gcp-iam-security-hardening/) · [azure-cspm-implementation-guide](/blog/azure-cspm-implementation-guide/)
diff --git a/src/content/blog/third-party-cloud-access.md b/src/content/blog/third-party-cloud-access.md
deleted file mode 100644
index 4c773ae..0000000
--- a/src/content/blog/third-party-cloud-access.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Third-Party Cloud Access Risk Management"
-description: "Third-Party Cloud Access Risk Management — expert guide to third party cloud access for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path pri..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: third party cloud access
-faq:
-  - question: Why does third party cloud access matter for cloud teams?
-    answer: third party cloud access reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does third party cloud access relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether third party cloud access gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support third party cloud access?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize third party cloud access without proprietary black boxes.
----
-
-**third party cloud access** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why third party cloud access matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without third party cloud access | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [azure ad privileged identity management](/blog/azure-ad-privileged-identity-management/) and [aws organizations scp security](/blog/aws-organizations-scp-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align third party cloud access with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce third party cloud access at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature third party cloud access program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **third party cloud access** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [azure-ad-privileged-identity-management](/blog/azure-ad-privileged-identity-management/) · [aws-organizations-scp-security](/blog/aws-organizations-scp-security/)
diff --git a/src/content/blog/threat-modeling-cloud.md b/src/content/blog/threat-modeling-cloud.md
deleted file mode 100644
index 1b0ef93..0000000
--- a/src/content/blog/threat-modeling-cloud.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: "Threat Modeling for Cloud-Native Applications"
-description: "Threat Modeling for Cloud-Native Applications — expert guide to threat modeling cloud for AWS, Azure, GCP, and Kubernetes with CSPM, CNAPP, and attack path p..."
-author: OpenSourceOM Team
-noindex: true
-tags:
-  - cloud security
-  - CNAPP
-  - CSPM
-  - best practices
-focusKeyword: threat modeling cloud
-faq:
-  - question: Why does threat modeling cloud matter for cloud teams?
-    answer: threat modeling cloud reduces exploitable misconfigurations and identity risk before attackers chain them into paths to sensitive data—core outcomes for CSPM and CNAPP programs.
-  - question: How does threat modeling cloud relate to attack path analysis?
-    answer: Standalone scanners list issues in isolation; attack path analysis shows whether threat modeling cloud gaps sit on reachable routes from ingress to crown jewels.
-  - question: Can open-source tools support threat modeling cloud?
-    answer: Yes. Graph-native platforms like OpenSourceOM combine inventory, policy checks, and path queries so teams can operationalize threat modeling cloud without proprietary black boxes.
----
-
-**threat modeling cloud** is on every cloud security roadmap—but slides and benchmarks rarely translate into daily engineering decisions. This guide covers what practitioners implement, measure, and automate in production AWS, Azure, GCP, and Kubernetes environments.
-
-If you are drowning in flat findings from CSPM and vulnerability scanners, you are not alone. The fix is not another dashboard; it is **context**: identity, exposure, and whether a weakness sits on an exploitable **attack path**.
-
-## Why threat modeling cloud matters now
-
-Cloud estates change hourly. Terraform applies, autoscaling adds instances, engineers open temporary security group rules—and compliance snapshots go stale before the quarter ends.
-
-| Challenge | Without threat modeling cloud | With disciplined approach |
-|-----------|-------------------------|---------------------------|
-| Alert volume | Thousands of equal-priority tickets | Ranked by reachability and blast radius |
-| Identity risk | Hidden admin bindings | CIEM-style permission analytics |
-| Data exposure | Unknown public buckets | DSPM plus exposure management |
-| Tool sprawl | CSPM + scanner + IAM silos | Graph-correlated CNAPP model |
-
-Teams comparing [gcp cloud storage access control](/blog/gcp-cloud-storage-access-control/) and [attack path analysis cloud security](/blog/attack-path-analysis-cloud-security/) often discover that **prioritization** matters more than acquiring yet another point product.
-
-## Core controls and implementation steps
-
-Start with visibility, then enforcement, then continuous validation:
-
-1. **Inventory** — accounts, subscriptions, projects, clusters; tag owners and data classification
-2. **Baseline** — CIS or internal policy set mapped to CSPM checks
-3. **Exposure reduction** — internet-facing resources and anonymous access first
-4. **Identity review** — eliminate standing privilege; federation over long-lived keys
-5. **Graph or path analysis** — ask which findings connect ingress to sensitive assets
-6. **Automate remediation** — safe auto-fix for well-understood misconfigurations with rollback
-
-### AWS considerations
-
-On AWS, align threat modeling cloud with Organizations SCPs, Config rules, GuardDuty, and IAM Access Analyzer. Security groups and S3 public access blocks deliver fast wins before advanced analytics.
-
-### Azure considerations
-
-Use Defender for Cloud recommendations, Azure Policy initiatives, and Entra ID Conditional Access. Private Link and NSG tiering reduce lateral movement between application tiers.
-
-### GCP considerations
-
-Organization policies, VPC Service Controls, and Security Command Center findings form the native stack. Prefer Workload Identity Federation over downloaded service account keys.
-
-### Kubernetes considerations
-
-RBAC, Pod Security Standards, NetworkPolicies, and admission control enforce threat modeling cloud at the cluster layer—correlate compromised pods with cloud IAM via IRSA or Workload Identity.
-
-## Avoiding toxic combinations
-
-Individual misconfigurations often carry medium severity. **Toxic combinations**—public exposure plus privileged identity plus unpatched workload on a path to production data—are what attackers exploit.
-
-Review [toxic combinations in AWS and Azure](/blog/toxic-combinations-aws-azure/) and [how to prioritize cloud vulnerabilities](/blog/how-to-prioritize-cloud-vulnerabilities/) alongside this playbook. Graph queries like *show internet-reachable workloads with secrets access* outperform spreadsheet sorts.
-
-## Metrics that prove progress
-
-| Metric | Target direction |
-|--------|------------------|
-| Internet-facing resource count | Down |
-| Critical path findings open > 7 days | Down |
-| Standing admin bindings | Down |
-| Mean time to remediate path-critical issues | Down |
-| Repeat misconfiguration rate | Down |
-
-Executives care about trend lines, not raw finding counts—a mature threat modeling cloud program ** reduces reachable risk**, not merely closes tickets.
-
-## Open-source and self-hosted options
-
-Proprietary CNAPP suites popularized unified cloud security, but regulated and cost-conscious teams often need **auditable scoring** and **data residency**. [OpenSourceOM](https://opensourceom.org) builds a **security graph** across clouds with CSPM-style policies tied to attack path context—the [core repository](https://github.com/OpenSourceOM/core) is open source for teams extending collectors and queries.
-
-See also [open source CSPM and CNAPP tools](/blog/open-source-cspm-cnapp-tools-2026/) for a landscape view.
-
-## Operational cadence
-
-| Cadence | Activity |
-|---------|----------|
-| Continuous | CSPM scan, drift detection, GuardDuty/SCC alerts |
-| Weekly | Triage path-critical findings; IAM change review |
-| Monthly | Policy exemption audit; tabletop on credential theft |
-| Quarterly | Benchmark reassessment; red team focused on paths |
-
-## Key takeaways
-
-- **threat modeling cloud** succeeds when tied to exposure, identity, and path context—not checkbox compliance alone
-- **Automate baselines** but keep humans on exceptions, exemptions, and attack path triage
-- **Multi-cloud** programs need portable policy intent with cloud-native enforcement mechanics
-- **Graph-native tooling** (commercial or [OpenSourceOM](https://opensourceom.org)) scales prioritization when alert volume outgrows spreadsheets
-
----
-**Related:** [gcp-cloud-storage-access-control](/blog/gcp-cloud-storage-access-control/) · [Attack path analysis](/blog/attack-path-analysis-cloud-security/)