Security Foundation Map: Defense in Depth, Least Privilege

About this article

This article is the eighth deep dive in the “System Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering the security foundation to weave through the infrastructure layer.

WAF, DDoS protection, IDS/IPS, IAM, encryption, secrets management — layered into defense in depth — is the basis. Adding it later significantly increases costs. This article maps the functions to build in at the system-architecture stage; per-area deep dives (auth methods, authorization models, crypto algorithms, vulnerability assessment) live in the “Security Architecture” category.

What is a security foundation in the first place

A security foundation is, roughly speaking, “the complete set of defensive equipment to protect a system from external attacks and internal accidents.”

Imagine building security. The entrance has a gate (firewall), each floor has card keys (authentication / authorization), the vault has a combination lock (encryption), and security cameras (monitoring) are installed everywhere. Any one alone is insufficient — layering multiple defenses stops intruders. Infrastructure security follows the same “defense in depth” philosophy, combining WAF, DDoS protection, IAM, encryption, and secrets management.

Why security foundation design matters

What happens if you postpone security? Public IP addresses are scanned by bots 24/7/365. Even a tiny validation API server gets thousands of scan accesses logged within 24 hours. “Nobody knows about us yet, so we’re fine” is a premise that has never held on the Internet. The attacker is not a person but a bot, scanning every IP address in turn without picking targets. Security is unbolted-on-able — build it in from day one.

Defence in depth

Defense in depth is the principle of stopping attacks across multiple layers rather than relying on a single line. Build multiple gates from edge to interior so that breaching one stops at the next.

Stopping everything at the entrance is unrealistic. “Assume something gets breached somewhere” and design for damage minimization. The cloud-security default is defense in depth + Zero Trust. Configurations outside this aren’t getting picked anymore.

Don’t stop attacks at one wall. Designs where the next layer holds when the previous breaks are the basis.

The main building blocks of a security foundation

The list of components to “decide what goes where” at system-architecture design time. Detailed selection (products, settings, ops rules) is in the other-category articles. Use this for placement and gap-checking.

System-architecture design must answer every row at minimum. “Later” does not exist.

Work out the compliance requirements before designing

Industry, geography, and customer requirements set the security baselines you must meet. Certification takes time and money, so listing them at design time prevents major rebuilds later. This sits at system-architecture’s first decision rather than per-area deep dives, so it’s covered here.

A SaaS provider getting SOC 2 Type II dramatically improves enterprise sales. SaaS targeting Japanese finance / public sector often must comply with ISMS + FISC (Financial Information Systems Center safety standards). Deciding SOC 2 after launch produces months of delay redesigning logging.

A phased roadmap for adopting security

“Everything at once” is unrealistic. Required vs recommended by phase. Below is in order of incident-likelihood without it.

MFA, Dependabot, Secret Scanning, HTTPS — these four are mandatory even at MVP. Postponing means hours-after-launch IAM-key leaks and dependency-chain intrusion. The December 2021 Log4Shell (Log4j CVE-2021-44228) demonstrated how one library vulnerability cascaded into chained attacks worldwide.

Even at MVP, install MFA, Secret Scanning, Dependabot, HTTPS day one. “Later” does not exist.

Three scenarios

If you are building solo or at a startup

Separate production and development accounts, enforce MFA on every administrator, and go key-less with OIDC and an IAM role. That trio costs nothing and removes most of the ways in. Secret scanning is on by default in GitHub, so leave it on.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

Add audit logs in a separate account with Object Lock, and check the compliance requirements — SOC 2 and the like — before the design rather than after. Requirements at this level reach back into log design and network separation, which is why they cannot wait.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large or regulated enterprise

Organisation-level account separation, Policy as Code as the guardrail, and zero trust as the assumption about the internal network. In regulated industries the security investment is not optional, and failing it can mean leaving the business.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — Can it be expressed as Policy as Code?

With AI-driven development as the assumption, the deciding axis becomes “can it be expressed as Policy as Code?”

AI-generated code carries hallucination risks; SAST and dependency scanning (Dependabot/Snyk) must be in CI — “do not deploy AI-generated code unverified.”

1. List compliance requirements first and embed in design.
2. Each layer of defense in depth gets a “who owns this” assignment.
3. IAM strategy: SSO + Role switching as default; long-term keys are exceptions.
4. Policy-as-Code support as a check item for every product selection.

Security risks of AI-generated code and automated scanning

AI-generated infrastructure code tends to have security-setting gaps. For example, opening 0.0.0.0/0 in security groups, not setting S3 bucket public access blocks, allowing * resources in IAM policies — these are patterns AI writes when prioritizing “getting it to work.”

The countermeasure is embedding tfsec, Checkov, and AWS Config Rules in the CI pipeline to automatically scan all infrastructure changes including AI-generated code. Building a system that comprehensively detects security-setting mistakes that human review alone misses becomes the assumption.

Policy as Code becomes the AI-era security guardrail

Policy as Code tools like OPA (Open Policy Agent), Cedar, and tfsec declare security policies in code and auto-detect violations. They can enforce rules against AI-generated Terraform code like “no DB in public subnets” or “no * in IAM policy Actions.”

As AI-written code volume grows, human review burden rises. Expanding the scope of automated Policy as Code checks is the key to ensuring security-operations scalability in the AI era.

Pitfalls and forbidden moves

Here are the six most dangerous ways security goes wrong at the system-architecture stage.

Author’s note — the repository that was public for a few hours

A new engineer accidentally pushed a script with AWS access keys to a public repo, and within hours, attackers had spun up tens of thousands of dollars of EC2 instances for crypto mining. Reported repeatedly in many countries.

The moment it lands on GitHub, bots scrape within seconds. Even after deletion, Git history retains it.

The lesson: “noticing and deleting is too late.” Detect at pre-push hooks, or — better — never issue long-term keys (OIDC / temporary credentials only). Security’s “I’ll be careful” falls apart the moment it depends on human attention.

Don’t rely on individual willpower. Defend through structure. That’s the rule.

What to decide — what is your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

• Compliance requirements (SOC 2 / ISMS / PCI DSS, etc.)
• Per-layer products in defense in depth (WAF / DDoS / IDS/IPS)
• ZTNA adoption (timing of VPN migration)
• IAM strategy (SSO / Role / MFA mandatory scope)
• Secrets-management foundation (Secrets Manager / Vault)
• Encryption policy (in-transit / at-rest / app-layer)
• Audit-log isolated-account storage and WORM
• Scope of Policy as Code adoption

Per-item concrete selections live in the “Security Architecture” category articles.

Related Articles

Summary

This article covered the security foundation map at the system-architecture stage — defense in depth, compliance, phase-by-phase roadmap, and the AI-era angle.

Security cannot be bolted on, so build it in from line one of the design. Even at MVP, MFA, Dependabot, Secret Scanning, HTTPS are mandatory day one; further layers stack as scale and industry require.

The next article covers monitoring and operations (the three pillars of observability, the four golden signals).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.