╔══════════════════════════════════════════════════════════════╗
║          CLOUD COMPLIANCE  ·  SECURITY AUTOMATION          ║
║                    Building in public.                      ║
╚══════════════════════════════════════════════════════════════╝

I'm a Security Engineer working at the intersection of cloud compliance and control framework mapping — translating complex cloud environments into auditable, evidence-backed compliance postures using frameworks like NIST 800-53, CCF, and SOC 2.

This GitHub is where I document that work publicly — control mappings, governance frameworks, and the applied knowledge I'm accumulating working at the intersection of compliance and security automation.

The focus: Deep expertise in security automation at the infrastructure and pipeline layer — taking any compliance requirement and making it machine-enforceable at scale.

domains:      Cloud Compliance | Security Automation | Control Framework Mapping
frameworks:   NIST 800-53 | CCF | SOC 2 | FedRAMP
building:     Control mapping → security automation in code
learning:     AWS Solutions Architect Associate | CISA prep
studying:     CISA | AWS Solutions Architect Associate

Every credential deepens something I am already applying in practice.

2025  ──── CompTIA Security+            ← core cybersecurity functions

2026  ──── AWS SAA                      ← design cloud infrastructure
      ──── CISA                         ← reduce infrastructure risk
      ──── AWS Security Specialty       ← automation targets
      ──── Terraform Associate          ← expert track foundation
      ──── CCNP                         ← enterprise network infrastructure
     
2027  ──── CCSP                         ← data & application security
      ──── CKA (Kubernetes Admin)       ← runtime enforcement
      ──── AWS SAP                      ← architecture authority
      ──── SANS SEC540                  ← capstone

Most compliance engineers can tell you what a control requires. Fewer can tell you why it exists, what evidence satisfies it, and how a cloud product actually produces that evidence.

That gap — between knowing the framework and understanding the system — is what this portfolio is about closing.

Every repo here starts with a real question I encountered in my work. The answer becomes the artifact. That's the opposite of tutorial hell, and it's how practitioners actually learn.

I publish short technical explainers on cloud compliance, control frameworks, and security automation for practitioners.

📺 YouTube: youtube.com/@davidyeti 🌐 Site: davidyeti.com

• Credential: CompTIA Security+
• Studying: Computer Engineering — GSU Perimeter College
• Domain experience: Cloud compliance, control framework mapping, security architecture
• Focus: Cloud compliance, security automation, and the engineering craft.

I came into security engineering through a technical sales background — two years working with enterprise security teams before moving to the engineering side. That experience gave me something most security engineers lack: I understand why controls exist, not just how to implement them. That context is what makes security automation meaningful rather than mechanical.

Everything in this portfolio is built from public frameworks — NIST, CIS, AWS documentation, vendor compliance reports. I don't publish internal tooling, proprietary processes, or anything that isn't mine to share.