The Cloud AppSec / IaC Security Engineer Role

What a cloud AppSec / IaC security engineer actually does

The cleanest definition: you are the security engineer who lives in the software delivery pipeline. Your controls ship as code alongside the application teams' code. When a developer opens a pull request to add a new S3 bucket, your Checkov check runs on the same PR. When they push a new container image, your scanner runs before it reaches the registry. When their pod lands in Kubernetes, your admission policy decides whether it's allowed to run. You are not downstream of the engineering process - you are embedded in it.

In practice, the work breaks down across a handful of persistent domains:

• IaC scanning and guardrails. Wiring Checkov, tfsec (now part of Trivy), KICS, or Terrascan into the CI pipeline so misconfigurations in Terraform, CloudFormation, CDK, or Pulumi fail the build before they reach production. Writing and tuning the rules - deciding which checks are hard blocks vs. advisory warnings, and which are false positives in your environment. This includes writing custom policies in OPA's Rego or Semgrep rules for things the off-the-shelf scanners miss.
• Container image security. Scanning Dockerfiles and built images for known CVEs, hardening gaps (running as root, unnecessary capabilities, writable root filesystem), and provenance questions. Owning the base-image policy - which registries are approved, how stale an image can be before it's pulled and rebuilt. Building the pipeline that auto-raises tickets or fails the build when a critical CVE appears in a deployed image.
• Supply-chain controls. Dependency scanning (Snyk, Dependabot, Grype, OSV-Scanner), SBOM generation and attestation, artifact signing (Sigstore/cosign), and the policy that enforces what your clusters or Lambda functions are allowed to run. This domain is the fastest-moving part of the role right now - it didn't meaningfully exist five years ago and now it's a first-class concern at most security-mature companies.
• Kubernetes admission and workload identity. Configuring admission controllers - OPA/Gatekeeper or Kyverno - with policies that enforce pod security standards (no privileged containers, required resource limits, approved registries). Managing workload identity: IRSA on AWS, Workload Identity on GCP, pod identity on Azure, so workloads authenticate to cloud services without static credentials at all. Reviewing RBAC and service account permissions, which have a habit of growing beyond their original scope.
• Secret detection and prevention. Running tools like GitGuardian, TruffleHog, or the provider-native secret scanning to catch credentials committed to source control. Setting up pre-commit hooks and CI checks that block secrets before they land. Tracking and rotating secrets when they do slip through.
• Security design review and threat modeling. Sitting in architecture reviews for new features and microservices, finding the IaC, container, and pipeline-level risks while the design is still cheap to change. Writing the "how to deploy this safely" guardrail doc so the team can self-serve rather than waiting on you each time.
• Developer enablement. Writing documentation, internal guides, and repeatable templates that let developers make the secure choice the easy choice. The best AppSec engineers measure success by how rarely developers have to ask - because the golden path already handles it.

The console is a minority of the job. You're in GitHub, GitLab, or your SCM most of the day - reviewing PRs, updating pipeline configs, iterating on policies. The engineering teams are your customers, and your credibility depends on your controls not slowing them down unnecessarily.

Title soup: DevSecOps, AppSec, Platform Security

The work described on this page goes by more names than almost any other cloud security specialty. Before you filter job listings, understand that all of these titles are often the same role - or close enough that the distinction is branding, not substance:

• Cloud AppSec Engineer / Application Security Engineer (Cloud) - the clearest title for the job. Usually found at companies that have a dedicated AppSec function and a cloud-native engineering org. Tends to imply ownership of both the code-level (SAST, dependency scanning) and infrastructure-level (IaC, container, admission) layers.
• DevSecOps Engineer - the most common title in the market, and the most variable in what it actually means. At some companies it's exactly this role; at others it's a generalist DevOps engineer who also runs a scanner. Read the job description, not the title. If it mentions IaC scanning, container security, admission controllers, and supply chain, it's this role regardless of what they call it.
• Platform Security Engineer - often used at companies where the security team is organized around the platform (the internal developer platform, not the cloud platform). Usually implies more emphasis on the developer-facing tooling and golden-path work than on day-to-day finding triage.
• Security Engineer - AppSec - common at large tech companies with a broad security org. The "AppSec" qualifier typically means code and pipeline security (SAST, supply chain, IaC) rather than product security (pen testing the app, threat modeling features). At some companies these are the same person; at others they're separate teams.
• Software Security Engineer - often used at companies that want to emphasize the engineering depth of the role. Implies strong coding expectations; the security knowledge is treated as a specialization on top of an SWE baseline rather than the reverse.
• Product Security Engineer - more commonly used at SaaS companies where the "product" is what you're securing. Tends to blend AppSec and cloud security; the IaC and pipeline work may be a smaller share of the job than at a cloud-native engineering org.
• Security Champion / Security Embedded Engineer - a variant where a security engineer is embedded within a specific product team rather than sitting on a central security team. Usually a more senior role - you're expected to operate more independently and translate security strategy into that team's specific context.

The practical advice: search broadly. Use keywords from the job description (IaC scanning, Checkov, Kubernetes admission, supply chain, SBOM, cosign, Semgrep) rather than exact title matching. The role you want may be titled "DevSecOps Engineer" at one company and "Cloud Security Engineer" at another - the compensation and scope can be identical.

Why the cloud version is a different job

Traditional application security is about the code running in a defined environment. Cloud AppSec means the environment itself is code, it changes on every deployment, and the security properties of the infrastructure layer are just as exploitable as application vulnerabilities. These are the specific twists that make the cloud version meaningfully different.

1. Security shifts left into the pipeline - so your controls live in CI, not consoles

In on-prem environments, security often reviewed systems after they were built - a scan here, an audit there, a firewall rule when someone asked. In cloud, the infrastructure is declared in IaC and shipped through a CI/CD pipeline, which means the right moment to catch a problem is before the PR merges, not after the Terraform has been applied to production. This is what "shift left" actually means operationally: your scanner runs at plan time, your policy check runs at PR review, and by the time something reaches production it should already have passed a security gate. If your controls live in a console instead, you're always chasing what already deployed.

2. The app teams adopt new languages, build tools, and IaC modules constantly - each is new attack surface

A software engineering org is never standing still. This quarter they're adopting a new Terraform provider for a managed database. Next quarter they migrate to a new base image for their Go services. The quarter after, they start building in a new language with a different dependency ecosystem. Every one of those transitions resets part of your scanner baseline and brings new CVEs, new IaC misconfiguration patterns, and new questions about the security model. You will regularly be reviewing infrastructure or pipelines you've never seen before, against a threat model you're building in real time. The skill is not "know every tool" - it's "get to a defensible security stance on something new, fast."

3. Container and Kubernetes churn

Kubernetes adds minor versions quarterly and major features yearly. The pod security admission model changed fundamentally when PodSecurityPolicy was deprecated and removed. The workload identity patterns evolve as providers improve their integrations. New admission controllers emerge, are adopted, and are superseded. The container runtime and image specification landscapes move. Each change can silently alter the security properties of your existing controls - a policy that was effective against one kubelet version may have edge cases in the next. You have to treat your Kubernetes security configuration as living code that requires continuous testing, not a one-time setup. See containers and Kubernetes.

4. The software supply chain - dependencies, SBOM, provenance, signing

In 2026 the supply chain is a first-class attack surface, not a theoretical one. The SolarWinds, Log4Shell, and XZ Utils incidents made concrete what was previously hypothetical: a compromised upstream dependency or build step can silently backdoor every application that depends on it. The cloud AppSec engineer now owns a set of controls that didn't meaningfully exist five years ago: SBOM generation, attestation, artifact signing with Sigstore/cosign, provenance verification, and the policy that decides which signed artifacts are allowed to run. This domain is still maturing rapidly, and the "right" architecture is not settled - which makes it simultaneously the most interesting and the most exhausting part of the job. See supply chain.

5. Policy-as-code via OPA and admission controllers

The enforcement mechanism for most of what a cloud AppSec engineer builds is policy written in code - OPA's Rego language for Kubernetes admission via Gatekeeper, or Kyverno's YAML-native policies. This means your security controls go through the same code-review and deployment workflow as application code. That's a feature: you get version history, PR review, CI testing, and rollback. It's also a discipline: badly written admission policies can break production workloads, and testing them is non-trivial. The engineers who do this well write tests for their policies the same way they'd write unit tests for application code.

6. Workload identity is replacing long-lived secrets - and the migration is never fully done

The right answer for application credentials in cloud is workload identity: IRSA (IAM Roles for Service Accounts) on AWS, Workload Identity on GCP, pod identity on Azure. The application proves who it is via the platform's identity mechanism and gets a short-lived token, with no static key to rotate, leak, or scan for. This is a much better model than secrets mounted in environment variables or stored in Kubernetes secrets that live in etcd with inadequate encryption. But migrating an existing application estate to workload identity is an ongoing project, not a one-time migration - new services are built, new teams join, and the old pattern re-appears if there's no guardrail preventing it. Part of the cloud AppSec engineer's job is maintaining that guardrail: the OPA policy that blocks pods from mounting static cloud credentials, the IAM controls that make the long-lived key path less attractive than the workload identity path.

7. IaC scanners and providers ship new resource types faster than you can write guardrails for them

AWS alone ships hundreds of service updates a year. Each new managed service has its own Terraform resource types, its own security-relevant configuration attributes, and its own misconfiguration patterns. The IaC scanner you use may not yet have a check for the new service your platform team just adopted. When the scanner has no rule for a resource, it silently passes - which looks like "no findings" but actually means "no coverage." Part of the job is tracking scanner coverage gaps: knowing when your scanner doesn't understand a new resource type, writing custom rules to fill the gap, or raising the issue upstream. You cannot delegate your security posture entirely to the scanner's default ruleset.

This is a structural property of the space that isn't going to fix itself. Cloud providers are in a feature race, IaC scanners lag by design, and your engineering teams don't wait for the scanner to catch up before adopting new services. The engineering discipline that helps most here: learn how to read a Terraform provider schema directly, identify which attributes control security-relevant behavior (authentication mode, public access, encryption settings, logging), and write a Checkov custom check or a Semgrep rule for the gap. One well-scoped custom rule that protects a specific high-risk service is worth more than a scanner with broad coverage you don't understand.

Traditional AppSec asks "is this code safe?" Cloud AppSec asks "is this code, and the infrastructure it runs on, and everything it was built from, deployed safely - and can we prove that on every commit?"

The learning treadmill, in detail

The learning load in this role is structurally different from the generalist cloud security engineer's treadmill. The generalist learns new cloud services as the engineering org adopts them. The AppSec engineer has that same treadmill plus a second one: the tooling ecosystem. CI/CD platforms, container runtimes, IaC providers, policy engines, supply-chain tooling, and scanner rule sets all evolve on their own independent schedules - none of them waiting for you to catch up.

Concretely, here is what that looks like week to week:

• The scanner ships new rules. Checkov, Trivy, and Semgrep add new checks regularly. Some of them will fire on code your teams have been deploying for months - which is great if the finding is real and awkward if it's a false positive you need to suppress or exclude. Either way, it takes time and judgment.
• A new Terraform provider gains traction. Your platform team starts using the AWS provider resource for a new AI inference endpoint. Checkov has no rule for it yet. You need to review it manually, understand the relevant security configuration attributes, and either write a custom rule or build awareness with the team until the scanner catches up.
• A CVE drops in a base image. A critical CVE is published against a popular Linux base image - which means every container image in your org built on top of it is now potentially vulnerable. How many images are affected? How many are deployed in production? What's the process for rebuilding and redeploying? If you don't have an automated answer to these questions, you find out the hard way.
• A supply-chain technique is published. A new attack technique against CI/CD pipelines surfaces - action injection, caching poisoning, a misconfigured GitHub Actions permission. You need to evaluate whether your org is exposed and build the detection or prevention for it. This is not hypothetical; the GitHub Actions attack surface grew substantially between 2022 and 2026.
• Kubernetes evolves under you. A new pod security feature lands in a minor version, or a previously allowed pattern is deprecated. If your Kubernetes clusters auto-upgrade (they often do), you may discover the behavior change in a broken admission policy rather than in release notes you read proactively.

A week in the life

No two weeks are the same, but the shape is predictable. Here is a representative week for a senior cloud AppSec engineer at a mid-size company running a mix of Kubernetes workloads and Lambda, with a platform team that moves fast.

• Monday. The weekend's automated scan found three new Checkov findings in a PR that merged Friday night - two are noise from a new module version, one is a real privilege escalation risk in a new IAM role. You suppress the two false positives with a documented inline comment (so the next engineer understands why), file a ticket for the real finding with a Terraform snippet showing the fix, and ping the owning team. You also review the weekly Dependabot digest - twelve dependency bumps across five repos, all auto-merged by the team's policy except one that touches a critical auth library; you review that one manually and approve.
• Tuesday. Architecture review for a new data pipeline. The team wants to run a batch job on ECS Fargate that writes to S3 and reads from an RDS instance. You spot that the task role has a wildcard on S3 and the RDS instance has publicly accessible set to true in their starter Terraform. You write up the remediation - scoped resource ARNs in the IAM policy, VPC placement and security group for RDS, and a private S3 bucket policy - and add a Checkov custom check for the "publicly accessible RDS" pattern so the scanner catches it next time without your involvement.
• Wednesday. Heads-down: a new Kubernetes admission policy you've been building for two weeks. The goal is to enforce that every pod in the production namespace uses workload identity (IRSA) rather than static credentials. You write the Kyverno ClusterPolicy, write unit tests using the kyverno-cli, validate it against the existing pod specs in staging, and open the PR. Two edge cases surface in code review from the platform team - you work through both and land on a policy that enforces the right thing without breaking the CI runner pods that legitimately use a different auth pattern.
• Thursday. A new supply-chain attack technique was published overnight targeting GitHub Actions workflows. You spend the morning reviewing your org's workflow files for the specific pattern (an untrusted input flowing into a run: step via github.event.pull_request.head.ref), find two occurrences, fix them in PRs, and write a Semgrep rule to detect the pattern going forward. You also review a new GitHub advisory against a transitive dependency in a critical service - it's a medium CVSS in a non-reachable code path, and you write up why it's a low-priority exception so the owning team doesn't have to re-research it next month when it resurfaces.
• Friday. Triage the week's scanner findings across the three main repos, close out resolved tickets, update the internal guide on approved base images (two new distroless variants are now canonical; one older image tag is being sunset in 60 days). Review the Kubernetes minor-version release notes for anything security-relevant. Drop into the CSOH Friday session and take notes on a new container escape technique someone's presenting - add it to the backlog for next week's admission policy review.

Notice what's absent: there's almost no time in a cloud console. There is a lot of reading, code review, writing, and convincing engineers. The "security" and "engineering" halves of the job are genuinely inseparable.

A rough time budget for a representative week:

The skill stack

The role sits firmly on the engineering side of the security spectrum. The stable core is heavier on coding than any other cloud security specialty. The moving edge is faster than almost any other.

The stable core

• Infrastructure as code fluency. Terraform is the baseline. You should be able to read a plan, write a module, understand the provider schema well enough to identify which attributes are security-relevant, and run a local scanner against your own code. CloudFormation and CDK are common second languages; Pulumi is gaining ground in engineering-heavy orgs.
• Container fundamentals. How images are built (Dockerfiles, multi-stage builds, layer caching), what's in a base image and why it matters, how the OCI image spec works, the difference between image scanning at build time vs. registry scan vs. runtime. Understanding the relevant Dockerfile instructions from a security standpoint: USER, COPY vs. ADD, ENTRYPOINT, RUN with package installs.
• Kubernetes security model. Pod security standards and admission, RBAC, service accounts, network policies, secrets management (the default etcd-based secrets and why they're not encryption at rest), workload identity patterns (IRSA/WI/pod identity), and the basics of how admission webhooks work. Not "can operate a cluster" but "can reason about what a given pod spec allows and whether it should."
• CI/CD pipeline literacy. GitHub Actions, GitLab CI, Jenkins, or CircleCI - whatever your org runs. Understanding where in the pipeline security checks run, what the trust model is (which secrets are available at which stages, what triggers can be influenced by a pull request), and how to add or modify a workflow without breaking it. See CI/CD.
• Scripting and policy languages. Python for automation, API glue, and custom tooling. OPA's Rego for Kubernetes admission policies and Conftest checks. Regular expression and AST-level understanding for writing Semgrep rules. Bash for the glue scripts in CI that nobody likes but everyone uses.
• Attacker mental model. Specifically: how a compromised dependency package can steal credentials or exfiltrate data; how a misconfigured IRSA annotation can allow cross-namespace privilege escalation; how a privileged container can escape to the node; how a CI pipeline with overly permissive permissions can be used to push malicious code. CloudGoat has supply-chain and pipeline scenarios worth working through.
• DevSecOps culture and persuasion. The technical controls only work if engineers adopt them. You'll spend a meaningful portion of your time explaining trade-offs, helping teams understand findings, reducing friction for the secure path, and building the internal reputation that makes people come to you rather than route around you. This is not optional - it's load-bearing.

The moving edge

• Supply-chain tooling: SBOM formats (CycloneDX, SPDX), Sigstore/cosign, SLSA framework levels, in-toto attestations.
• New IaC providers as your org adopts them (the specific Terraform provider for every new managed service that shows up in your environment).
• Emerging scanner capabilities: Trivy's secret scanning, SBOM generation, and misconfiguration checks converging into one tool; Semgrep's cloud-security rule packs.
• Kubernetes policy evolution: Kyverno vs. Gatekeeper tradeoffs, the CEL-native admission policies in newer Kubernetes versions, and the ValidatingAdmissionPolicy GA.
• AI/ML workload security: model-serving infrastructure has its own IaC patterns, supply-chain risks (model provenance), and container configurations - it's the newest lane on the treadmill.
• GitHub Actions attack surface: action injection, fork PR risks, reusable workflow security, the GitHub Actions permissions model.

Certifications worth getting

This role has a sparser certification landscape than the broader cloud security field - most of the relevant knowledge is demonstrated through portfolio and tooling fluency rather than exams. That said, a few credentials are genuinely useful:

• Certified Kubernetes Security Specialist (CKS) - the most directly relevant cert for the Kubernetes admission and workload identity layer. It's a hands-on exam, not multiple choice, and it covers pod security, RBAC, network policies, image scanning, and admission controllers. Getting CKS-ready involves building in a real cluster, which is also exactly the portfolio work the interview asks for. See certifications guide.
• AWS Security Specialty / AZ-500 / GCP Professional Cloud Security Engineer - covers the cloud provider's native security services and the shared-responsibility model. Less directly specific to IaC and pipeline security, but establishes credibility with hiring managers who filter on cloud depth before the technical screen. Pick the one matching your primary cloud.
• CSSLP (Certified Secure Software Lifecycle Professional) - the ISC2 cert for the software security engineering space. It covers secure design, code review, supply chain, and testing - the right conceptual territory - and is recognized by enterprises that value formal credentials for AppSec practitioners.
• SANS SEC540 (Cloud Security and DevSecOps Automation) - a course with a GIAC exam (GCSA). Covers IaC security, container security, pipeline security, and cloud-native security tooling. Directly on-topic for this role and the GIAC credential carries weight in organizations that value SANS training.

The honest ranking for this role: portfolio artifacts (public repos, published write-ups, open-source scanner rule contributions) outweigh all of the above in most technical interviews. Certs help with resume screening and with structured learning if you're building depth from scratch - not as a substitute for hands-on work.

Tools of the trade

The categories are stable; the specific products at each layer are in flux. Learn the category before picking a product preference, because the products will shift under you. The useful framing is to think in pipeline stages - what runs at PR, what runs at build, what runs at registry push, and what enforces at deploy time.

IaC scanning

Checkov (Bridgecrew/Prisma Cloud) is the most widely deployed open-source IaC scanner - broad provider coverage, Python-based custom checks, active rule updates. Trivy has converged to cover IaC alongside containers and SBOMs in a single tool, which simplifies CI pipeline config. KICS (Checkmarx) covers a wider range of IaC formats including Ansible and Helm. tfsec is now merged into Trivy's IaC mode. Terrascan (Tenable) covers Terraform, Helm, and Dockerfiles. Most orgs run one primary scanner with custom rules layered on top via OPA/Conftest or Semgrep. The practical difference between scanners at the same tier is mostly the rule library for your specific Terraform providers and how easy custom rules are to write - evaluate on that, not on marketing.

Container image scanning

Trivy and Grype (Anchore) are the leading open-source options - both scan OCI images for OS package CVEs, language ecosystem vulnerabilities, and misconfiguration. Snyk Container adds reachability analysis (is the vulnerable code path actually called?) which reduces noise but requires deeper integration. Amazon Inspector v2 provides integrated ECR scanning with Security Hub findings; GCP Artifact Registry uses Container Analysis; Azure Container Registry uses Defender for Containers. For base image management, distroless (Google) and Chainguard Images are the current best-practice choices for minimal attack surface - know what's in your org's approved base image list and who maintains it. Image scanning is only useful if someone acts on the findings; having a clear policy for critical CVE SLAs (patch within N days or document the exception) is as important as the scanner itself.

Supply-chain and SBOM tooling

Syft (Anchore) is the standard open-source SBOM generator - outputs CycloneDX or SPDX format from container images, filesystems, or source trees. cosign (Sigstore project) handles image signing, attestation, and verification; the keyless signing mode using Fulcio and Rekor is the current best practice for CI pipelines because it avoids key management entirely. The SLSA framework defines provenance levels (1-4); most orgs targeting Level 2 or 3 use GitHub's artifact attestation (built on cosign) or SLSA GitHub Generator. Binary Authorization (GCP) and Notary v2 (broader ecosystem) are admission-side enforcement mechanisms that verify signatures before deployment. GitHub's dependency review action and Dependabot handle the ecosystem-specific (npm, pip, maven, go.sum) dependency side of supply-chain scanning. GitGuardian and TruffleHog cover secret detection in git history, CI logs, and live commit scanning. See supply chain.

Kubernetes admission controllers

OPA/Gatekeeper is the mature option - Rego-based policies deployed as CRDs, a large existing policy library (the Gatekeeper Policy Library covers many pod security cases), and strong community support. The downside is Rego's learning curve and the verbosity of the ConstraintTemplate / Constraint pattern. Kyverno is the YAML-native alternative - policies are Kubernetes resources written in YAML/JSON with a more approachable syntax, and it adds mutation and generation capabilities beyond what Gatekeeper covers. The ValidatingAdmissionPolicy API (GA in Kubernetes 1.30) brings a CEL-native admission mechanism without a separate controller - simpler for basic cases but less expressive than full OPA/Kyverno for complex policies. Conftest (OPA) is the CLI tool for testing Rego policies offline before deploying them - essential for a sensible policy development workflow. See Kubernetes security.

SAST and code-level scanning

Semgrep is the tool with the best combination of ease-of-use, custom rule expressiveness, and multi-language coverage for this role - the security-specific rule packs (aws, terraform, docker) cover common patterns, and writing a new rule for a org-specific pattern takes minutes rather than days. CodeQL (GitHub) is deeper for application security vulnerabilities in supported languages and integrates natively into GitHub Advanced Security. Bandit covers Python, gosec covers Go - useful additions to the pipeline when those languages are in scope. Snyk Code (commercial) adds AI-assisted fix suggestions which the teams you're partnering with will find useful for adoption. The secret scanning category has matured: GitHub Advanced Security secret scanning covers 200+ credential patterns natively; GitGuardian provides higher coverage with real-time alerting and historical scanning.

Workload identity and secret management

The target state for every workload is no static credentials at all. The path to get there: AWS uses IRSA (annotate the Kubernetes service account, create a trust policy on the IAM role that scopes to the OIDC issuer and namespace/SA name) or the newer EKS Pod Identity (simpler setup, same security model). GCP uses Workload Identity Federation with a binding between the Kubernetes service account and a GCP service account via an IAM policy binding. Azure uses Workload Identity (federated credentials on a managed identity, projected service account token). For Lambda and ECS: execution roles and task roles respectively - no credential management needed. For workloads that still need to read secrets (third-party credentials, API keys, certs), the reference pattern is secrets manager + SDK integration (not environment variables) + IAM-scoped access via workload identity. See data security and KMS.

Developer-facing tooling and golden paths

The controls only work at scale if developers can self-serve. The tools in this layer: pre-commit hooks (detect-secrets, checkov pre-commit, gitleaks) that catch issues before the commit even leaves the developer's machine; approved Terraform module libraries that embed secure defaults so developers get the right configuration without thinking about it; base image catalogs with documented CVE SLAs and automated rebuild pipelines; and internal policy documentation that explains the why behind each gate so that when a control fires, the developer understands it rather than routing around it. The best AppSec programs are measured by how few exceptions engineers request - not by how many findings they generate.

The multi-cloud dimension

The IaC scanning and container/supply-chain work is largely cloud-agnostic - Checkov doesn't care which provider your Terraform talks to, and Trivy scans any OCI-compliant container image. But the workload identity and admission control story differs materially across the three major clouds, and that's where the multi-cloud complexity lives.

• AWS uses IRSA (IAM Roles for Service Accounts) for Kubernetes workload identity. A service account annotation binds a pod to an IAM role via an OIDC provider; the Kubernetes-issued token is exchanged for AWS credentials automatically. The pattern is mature and well-documented but requires setting up the OIDC provider per cluster and maintaining IAM role trust policies per service account. EKS adds Pod Identity, a simpler newer variant. Lambda and ECS have their own workload identity mechanisms (execution roles). AWS ECR has native scanning via Amazon Inspector; the findings feed into Security Hub. See AWS security.
• Azure uses pod managed identity (the older, node-level VMSS approach) and Workload Identity Federation (the newer, token-projection approach that mirrors IRSA). The newer approach is significantly better but not universally adopted yet - you will encounter both in the wild. Azure Defender for Containers covers AKS Kubernetes admission policy via Azure Policy for Kubernetes, which wraps OPA/Gatekeeper. Azure Container Registry has integrated vulnerability scanning. Entra ID workload identity is the identity plane for everything. See Azure security.
• GCP has arguably the cleanest workload identity story: Workload Identity Federation binds Kubernetes service accounts to GCP service accounts via a project-level pool. GCP's Container Analysis service provides vulnerability scanning integrated into Artifact Registry. Binary Authorization is the GCP-native admission control mechanism - it enforces attestation requirements (the image must be signed by a named attestor) rather than arbitrary policy, which is a different model than OPA/Kyverno but cleaner for supply-chain enforcement. See GCP security.

The general advice for this role: go deep on the cloud your org primarily runs. Workload identity is not a concept you learn once and apply anywhere - the implementation details are different enough across providers that "I understand IRSA deeply" and "I understand Workload Identity Federation deeply" are actually different skills. Learn the second one when you need it.

How the role changes by company stage

• Startup (you're the whole security team, possibly part-time). You're not a dedicated AppSec engineer - you're the engineer who also handles security. In practice this usually means wiring in one IaC scanner and one dependency scanner, setting up a basic Kubernetes admission policy, and shipping it. Scope is small enough that you can review almost every PR with a security eye. The treadmill is fast but you're close to the code and the teams. Learn the practices before tooling complexity takes over.
• Scale-up (dedicated security team, 3-10 engineers). The role starts to specialize. You're the dedicated AppSec / pipeline person while other engineers own detection, IAM, or posture. You own the scanner toolchain end-to-end, write the policies, and build the internal library of secure Terraform modules and Kubernetes patterns that teams self-serve from. The developer-enablement part of the job becomes more important - you can't review every PR anymore.
• Enterprise / big tech (multiple security sub-teams). The role often splits further. One team owns the SAST/DAST and code-level scanning; another owns the IaC/container/supply-chain layer; another owns Kubernetes platform security. You may own a specific part of this stack across a large engineering org - dozens of teams, hundreds of repos, thousands of container images. The job becomes more about building platform capabilities (a centralized scanner result aggregation service, a curated base image catalog with SLAs, an attestation system) than about reviewing individual findings. Policy-as-code governance and metrics (coverage gaps, mean time to remediation) become your deliverables as much as individual rules.

Salary & compensation

US, 2026, base salary. The coding depth of this role tends to command a slight premium over the cloud security generalist band at the same level; big-tech total comp with equity runs 1.5-2x base. Outside the US, halve and add a question mark.

• Junior / associate (0-2 yrs): $100K-$140K. Often titled "DevSecOps Engineer," "Security Engineer - AppSec," or "Platform Security Engineer" rather than "Cloud AppSec Engineer." Expect a heavier coding screen than most cloud security entry roles.
• Mid-level (2-5 yrs): $145K-$195K. You own a domain of the toolchain and contribute to pipeline and policy decisions. The title is commonly "Cloud Security Engineer - AppSec" or "Application Security Engineer (Cloud)".
• Senior (5-8 yrs): $185K-$250K. You design the toolchain architecture, write the organization's IaC and container security standards, mentor others, and make the supply-chain decisions. Often titled "Senior Security Engineer, AppSec" or "Staff Security Engineer."
• Staff / principal (8+ yrs): $240K-$330K base; often $450K+ total comp at large tech. You set the direction for pipeline security and developer experience across a large engineering org. You're the person other security engineers and engineering leaders turn to when the architecture decision is hard.

A few notes on the compensation landscape specific to this role. First, it pays slightly above the cloud security generalist band at the same tenure level at most companies - the coding baseline is higher and the supply-chain/Kubernetes domain expertise is genuinely scarce. Second, developer-background pivots often have negotiating leverage they underuse: if you're coming from a mid-level SWE role at a tech company, your base may already be at the bottom of the senior AppSec band - ask for senior rather than mid. Third, the title varies more than the pay: "DevSecOps Engineer," "Platform Security Engineer," "Application Security Engineer," and "Cloud Security Engineer - AppSec" all describe roughly the same market-rate job; don't filter by title when you negotiate or evaluate offers.

Cross-check live numbers at levels.fyi (filter for security engineering), the BLS information security analysts data for general industry baselines, and r/netsec or r/cybersecurity salary threads for anecdata. The careers salary section has the full picture.

The interview loop for this role

The AppSec / IaC loop is the most code-heavy of all the cloud security specialties. Expect most of the following, with technical depth calibrated to level. The single differentiating habit for candidates: bring a specific example from your own work for every category below - not a hypothetical, not a textbook answer, a real artifact or incident you can walk through in detail. Hiring managers in this role have heard the generic answers; concrete examples cut through immediately.

• IaC security review. They paste a Terraform file or CloudFormation template and ask what's wrong with it. This is nearly universal and is the single most-tested skill. Practice on real Terraform - not toy examples - until you can read a provider resource block and immediately identify which attributes are security-relevant, what the safe vs. dangerous values are, and how you'd fix it. Common targets: S3 bucket policies, IAM roles, security groups, EKS cluster configs, RDS instance settings.
• Container or Dockerfile review. Similar format - they show a Dockerfile or a Kubernetes pod spec and ask for the security issues. For Dockerfiles: running as root, unnecessary packages installed in the final stage, writable filesystem, COPY vs ADD, secrets baked into layers. For pod specs: privileged, hostPath mounts, missing resource limits, service account annotation vs. static credentials.
• Supply-chain scenario. "A critical CVE was just published in a library that you believe is in your container images. Walk me through how you'd find out which images are affected and what you'd do about it." This tests whether you have an SBOM and image scanning practice, whether your CI rebuilds images on dependency updates, and whether you can scope a problem under uncertainty.
• Admission policy design. "Design an admission policy that prevents pods from running as root in the production namespace while allowing it in the developer sandbox namespace." They want to see that you understand the Kubernetes admission model, can write or describe a Kyverno or Gatekeeper policy, and have thought about the edge cases (existing workloads, CI runners, init containers).
• Pipeline security review. They show a GitHub Actions workflow and ask for the security issues. Common findings: pull_request_target without checkout restrictions, overly permissive permissions: blocks, secrets available to untrusted code via github.event inputs, caching that could be poisoned.
• Take-home or live lab. Increasingly common at mid-to-senior level: "here's a Terraform repo / container image / GitHub Actions workflow with security issues - find them, document them, and fix what you can." This is the strongest signal you can give. Hiring managers are grading: did you find everything real, did you prioritize correctly, did you explain the risk clearly, and did your fixes actually work?
• Behavioral - developer experience focus. "Tell me about a time you introduced a security control that made developers' lives harder. What happened and what did you do?" The right answer acknowledges that friction is real and your job is to reduce it, not to gate everything. Candidates who treat every developer complaint as invalid don't last long in this role.

Portfolio projects that prove the role

For this role, the portfolio needs to show that you can build and operate the pipeline security controls - not just that you understand the theory. Pick two or three, execute them end-to-end, and write each up with the context of why you made the choices you made:

1. Build a multi-account AWS Organization with SCPs. IaC-first from start to finish, with Checkov wired into the CI pipeline. Demonstrate that IaC changes can't merge without passing your scanner, and that you've written at least one custom policy for something the default rules miss.
2. Work the CloudGoat supply-chain and container scenarios. Document the attack path and the specific IaC misconfigurations or container settings that enabled it. Show what the Checkov or Trivy finding looks like before and after remediation.
3. Wire OPA/Gatekeeper or Kyverno into a local Kubernetes cluster. Write policies that enforce pod security standards and workload identity requirements. Test them with the kyverno-cli or conftest. Document a case where you had to write an exception for a legitimate use case and how you constrained the scope of that exception. See Kubernetes.
4. Build an end-to-end SBOM and signing pipeline. Take a real (or test) container image, generate a CycloneDX SBOM with Syft, sign the image with cosign, and write the admission policy that only allows signed images into a namespace. Write up what an attacker would have to do to bypass it and what the residual risk is.
5. Contribute a rule to an open-source IaC scanner. Checkov, Trivy, and KICS all accept community rule contributions. Writing a rule for a real misconfiguration pattern you've seen at work, getting it merged, and documenting why it matters is one of the strongest portfolio signals in this role - it proves you understand the tool internals, not just how to run it.
6. Run Trivy + Checkov against a real or synthetic environment. Compare the coverage, document the gaps, write up which tool catches what the other misses. This directly mimics the "evaluate tooling" work you'll do on day one of most jobs.

The full playbook with time estimates is the portfolio projects guide. The differentiating move is publishing write-ups, not just repos - explain your choices, the trade-offs, and what you'd do differently next time.

How to break in and pivot from adjacent roles

This is the cloud security specialty with the clearest on-ramp from a software engineering background. The summary from the careers overview nails it: if you already write code, you are not starting from zero.

You're a natural fit if you currently:

• Are a software engineer who already does code review. You already spend time reading others' code looking for bugs. Security is a specialization of that skill: you're now reading for a specific class of bugs (auth, injection, IaC misconfigurations) with a specific set of tools. The gap is learning what to look for, not learning how to read and review code.
• Did web AppSec work, OWASP Top 10 testing, or hold Burp Suite Certified Practitioner / GWAPT. Traditional web AppSec translates directly into cloud AppSec - same shift-left philosophy, overlapping toolchain (SAST, dependency scanning), and the same fundamental question: what does an attacker do with this? The addition is the infrastructure layer: IaC, containers, pipelines.
• Are a build or release engineer who lives in GitHub Actions / GitLab CI / Jenkins pipelines. You know the CI/CD trust model from the inside - you've seen what secrets are available, what can be triggered by an outside PR, and where the obvious failure modes are. Security is a natural extension of reliability: the same instinct that makes you test edge cases makes you good at finding attack paths.
• Trained on the SANS DevSecOps track (SEC540) or did Snyk / GitGuardian / Semgrep work in your current role. You have the vocabulary and some of the tooling; the gap is depth in IaC security and Kubernetes, which are learnable in a few months of focused lab work.
• Are in DevOps / platform engineering and already write Terraform or Helm charts for a real environment. This is the fastest pivot - you already own the IaC. Learn the scanner ecosystem, learn what findings map to real risk vs. noise, and add the Kubernetes admission and workload identity layer.

The practical path: take the IaC you write at work, run Checkov against it, and fix every finding. Then spin up a local Kubernetes cluster (k3s or kind), install Kyverno, write a policy, and test it. Those two projects, documented publicly, are enough to pass a mid-level technical screen at most companies. The learning path, home lab guide, and certifications guide (CSSLP, Certified Kubernetes Security Specialist, AWS Security Specialty) round out the preparation.

First 30 / 60 / 90 days

The shape of a strong start in this role. The specifics vary by company, but the pattern holds across most mid-size and enterprise orgs.

First 30 days: listen, map, and don't break anything

Your first month is reconnaissance. Read the existing IaC - all of it, or as much as is practical. What Terraform providers are in use? Which modules are internal vs. public registry? Are there patterns that recur everywhere (a base module for S3, a standard ECS task definition, a common Lambda IAM role pattern)? Understanding the existing shape before you start scanning is what separates someone who files useful findings from someone who files noise.

Meet the platform team and the most active IaC contributors on the engineering side. Ask what the biggest pain points are - not "what are the security problems" but "what slows you down." The answers will tell you where security friction is already high and where you can reduce it rather than add to it. Find out what scanning, if any, already exists. Where is it wired in? Is it blocking or advisory? How are findings tracked?

Map the CI/CD topology: how many pipelines, what runs in them, what secrets are available where, which pipelines have outside-PR-triggered jobs. This is your attack surface assessment for the pipeline layer. Don't start fixing yet; you don't know enough about which changes will have side effects.

Days 30-60: establish baseline and pick one win

Run your IaC scanner across the main repos in audit mode - report only, no blocks. Review the output critically: which findings are real risk in this specific environment, which are false positives against your organization's module patterns, and which are medium-noise items that should be on a roadmap but not a hot fix list. Write up the baseline: here is the current state, here is the risk distribution, here is what I'd prioritize. Share it with your manager and with the platform lead. The act of writing it builds more credibility than filing 300 tickets.

Pick one high-value, low-friction win for your first 30 days of active work. Good candidates: a Checkov check that catches a pattern that shows up in 10+ repos and has a clear, scripted fix; a base image policy that updates one aging image to a current distroless equivalent; a Dependabot config rollout across repos that don't have automated dependency updates. Something that engineers can see as useful rather than as a new compliance burden.

Days 60-90: start gating and building the roadmap

By day 60 you know the environment well enough to start making enforcement decisions. Pick one or two scanner checks to flip from advisory to blocking - the ones where you have high confidence the finding is always real risk and the remediation is well-understood. Communicate the change clearly in advance: what is being blocked, why, and what the fix looks like with a code example. Track exceptions carefully from day one - they tell you where the real edge cases are and prevent the "exception creep" that eventually hollows out a policy.

Draft your 6-month roadmap: what scanner coverage do you want to close, what admission policy do you want to deploy, what supply-chain control is the highest-priority gap? Get it reviewed by your manager and by a key engineering stakeholder. The roadmap is a forcing function that turns the permanent learning treadmill into a prioritized backlog rather than an anxiety spiral. Revisit it monthly; the IaC scanner ships new rules, Kubernetes releases a new minor version, a supply-chain incident changes what's urgent. The plan is not the point - the discipline of having one is.

Where this role leads

The AppSec / IaC engineer has several natural exit paths, and the one you take depends on which part of the work you find most interesting after a few years:

• Security SRE / Platform Security Engineer - if you gravitate toward building the systems (shared SIEM pipelines, secret rotation services, account vending) that other engineers self-serve from. The platform engineering background combines with your security knowledge to make you exceptionally strong in this adjacent role.
• Cloud Security Architect - the staff+ IC path. After several years of IaC and pipeline security, you've built up deep knowledge of how systems are designed and where they fail. The architect role is largely systems-design-at-scale, which is what you've been doing in the AppSec lane.
• Cloud Security Engineer (generalist) - if you want broader scope. Many AppSec engineers spend a few years building depth in pipeline security and then deliberately broaden into IAM, posture management, and detection. The coding background makes the generalist role more powerful than it is for people who came from a non-coding background.
• Cloud Incident Responder - less common but real. Deep IaC and pipeline knowledge means you understand exactly how a misconfiguration became a breach, and you can reconstruct the deployment history that traditional IR specialists can't. Some AppSec engineers find the incident work engaging enough to pivot fully.
• Supply chain security lead or product security engineer. As supply-chain security has grown into a standalone discipline, dedicated roles for it have emerged at large tech companies and at vendors. If the supply-chain parts of your work are what you find most interesting, this is a natural terminus. The combination of IaC fluency, container security, SBOM/signing, and pipeline security is exactly the job description.
• Security-focused engineering leadership. AppSec engineers who stay close to the engineering org for several years often develop strong influence, credibility, and perspective that positions them well for engineering management or principal engineer roles with a security focus - particularly at companies where security is a genuine product differentiator.

Common mistakes

• Treating scanner output as ground truth. The scanner is a starting point, not a verdict. Every finding needs a human judgment: is this real risk in this environment? Is the remediation the scanner suggests actually correct for this Terraform resource, this Kubernetes version, this application architecture? Blindly filing every finding as a ticket is how you burn your credibility with engineering teams. The practical discipline: before you file a ticket, spend two minutes confirming the finding is real and the remediation is actionable. If you can't write a one-line description of why it matters and what to do, don't file it yet.
• Breaking builds before you've earned the trust to break builds. Wiring a scanner into CI as a hard block before you've tuned false positives, before you've communicated the policy, and before you've built developer relationships is a reliable way to become the team everyone routes around. The correct sequence: audit mode first (report only, no fail), tune until the signal-to-noise is acceptable, document what will be blocked and why, then flip to enforcement. Engineering managers remember the first time you broke their pipeline without warning. That reputation is slow to recover.
• Over-investing in one tool before understanding coverage gaps. Every IaC scanner has blind spots. Checkov doesn't know about every new Terraform provider the moment it ships. Trivy's IaC mode has different coverage than its container-scanning mode. Learning one tool deeply is fine; assuming it covers everything is how you end up with a false sense of coverage. Run two scanners on the same IaC corpus periodically and compare - the delta tells you what each misses.
• Ignoring workload identity migration in favor of adding more scanning. Scanning for hardcoded secrets and then filing tickets to rotate them is slower and less effective than eliminating the credential pattern altogether via workload identity. Every static credential you scan for today is one you could prevent entirely with an OPA policy that blocks pods from mounting static AWS credentials. The prevention side of the job compounds more than the detection side - measure and report on both.
• Building policies in isolation from the engineering teams. Admission policies that break legitimate use cases, IaC rules that don't account for how your org's Terraform modules are structured, supply-chain gates that block the CI runner - these erode trust and get exceptions carved out until the policy is effectively dead. The meta-mistake is moving fast without involving the platform team who knows all the edge cases. One two-hour design session with the platform lead before you deploy a new admission policy saves weeks of exception management after.
• Falling behind on Kubernetes changes. Kubernetes moves faster than most cloud security practitioners track. Pod security admission replacing PodSecurityPolicy was a multi-year deprecation that still catches people. Workload identity improvements, new admission mechanisms, CEL-based ValidatingAdmissionPolicy - each one can change the security properties of your existing controls or open a better path that makes your current approach obsolete. Subscribe to the Kubernetes release notes specifically (not just the blog), read them when they drop, and block time each minor version to evaluate whether your admission setup needs updating.
• Treating supply chain as a one-time project. Generating an SBOM once and scanning images on build day is not a supply-chain security program. The attack surface is dynamic: dependencies get updated overnight, CVEs are published against versions you deployed six months ago, new build tools get adopted by teams without asking security. The controls have to be continuous: scheduled rescans of deployed images, Dependabot or Renovate configured for automatic PR updates, CVE alerting wired to your ticketing system, and periodic reviews of your artifact signing keys and trust roots. If you set it up and walk away, it's already stale.
• Measuring success by findings count rather than risk reduction. The AppSec engineer who reports "we found 2,000 IaC findings this quarter" has told you nothing about whether the org is more secure. The one who reports "we eliminated the publicly-accessible RDS pattern from 100% of accounts and migrated 40% of workloads to workload identity" has told you something useful. Measure what you've fixed and prevented, not what you've surfaced.

How AI is changing the role

AI is reshaping this role on three vectors simultaneously - as a tool you use, as an attack surface you have to secure, and as a supply-chain risk vector you need to track. Each one is moving fast enough that a description from two years ago is already out of date.

As a tool you use. AI coding assistants (GitHub Copilot, Cursor, and similar) are now generating significant amounts of the Terraform, Helm charts, Dockerfiles, and GitHub Actions workflows that you scan. That's both an opportunity and a risk. AI-generated IaC tends to pass basic scanner rules because it's drawn from publicly available patterns - but it tends to miss organization-specific context (your naming conventions, your approved module patterns, the specific security configuration your environment requires). The signal: your scanner may be finding fewer obvious misconfigurations in AI-generated code while missing the subtler, context-dependent ones that only a human familiar with your environment would catch. The bigger productivity gain for AppSec engineers is in writing custom rules: describing a misconfiguration pattern to a code-capable AI model and iterating on the Rego or Semgrep output is significantly faster than writing from scratch. Use it for the scaffolding; review the security logic yourself before deploying it.

As an attack surface to secure. AI/ML workloads are now mainstream in most engineering orgs, and they introduce new IaC patterns that your scanners were not written for: model inference endpoint configurations with misconfigured authentication, training job IAM roles with broad S3 and EFS access, embedding databases (vector stores) with public endpoints and no access controls, AI gateway services sitting in front of LLMs with injection-vulnerable prompt templates. These are container and IaC security problems wearing new clothes. The threat model is documented on the AI/ML security page; your practical job is writing Checkov/Semgrep rules for the new resource types and IaC patterns before they proliferate across your environment.

As a supply-chain risk vector. AI models themselves are now supply-chain artifacts. Model weights downloaded from HuggingFace, LoRA adapters from community repos, fine-tuned checkpoints with opaque provenance, and third-party model providers accessed via API keys - each of these carries the same supply-chain questions you ask about software dependencies: who built it, was the build process tampered with, are there known vulnerabilities or malicious behaviors, and is it being verified before it runs in production? The tooling to answer these questions is much less mature than what exists for software packages; there is no OSV database for model weights and no Sigstore equivalent that the AI community has standardized on yet. The security engineers who build these practices early - model provenance verification, sandboxed model execution, IAM-scoped API key management for LLM providers - will be setting the standard others follow. It is the newest and fastest-moving lane on the treadmill.

Quick answers

What does a cloud AppSec / IaC security engineer actually do?

Owns security in the software delivery pipeline: IaC scanning in CI, container image and dependency scanning, supply-chain controls (SBOM, signing, attestation), Kubernetes admission policy, and workload identity migration. Almost all of the work is in code and pull requests, not in security consoles.

How is cloud AppSec different from traditional application security?

Traditional AppSec focuses on the application code. Cloud AppSec extends to everything the application runs on - the IaC, the container image, the build pipeline, the supply chain, and the cluster configuration. A misconfigured IAM role attached to a pod is as exploitable as an XSS, but it's an infrastructure problem, not an application code problem.

How much does it pay?

US 2026: roughly $145K-$195K base mid-level, $185K-$250K senior, $240K+ base at staff level (often $450K+ total comp in big tech). The role's coding depth commands a slight premium over the cloud security generalist band.

Do I need to know Kubernetes?

At most companies, yes - admission control and workload identity are core domains. You don't need to operate a cluster from scratch, but you need to read pod specs, understand RBAC and service accounts, and write or evaluate admission policies.

I'm a developer - how do I start?

Run Checkov against your existing Terraform, fix every finding, and document why each one matters. Wire it into a GitHub Actions workflow. Then spin up a local Kubernetes cluster with Kyverno and write one admission policy. Two portfolio artifacts later, you can talk concretely to any mid-level interviewer in this space.