/moai-ref-secops

name: moai-ref-secops
description: >
  DevSecOps, container, and API operational defensive security reference: CI/CD
  pipeline hardening, secret scanning, IaC misconfiguration detection, SAST/DAST
  integration, container image scanning, Kubernetes RBAC hardening, container-escape
  defense, runtime threat detection, OWASP API Top 10 operational defense, WAF rule
  tuning, and GraphQL/REST depth and rate limiting. Agent-extending skill that
  amplifies backend, security, and platform-engineering work with production-grade
  defensive patterns for pipelines, containers, and running APIs.
  NOT for: offensive techniques (exploit execution, container-escape attack steps,
  privilege-escalation procedures, attack tooling), dev-time web-app OWASP Top 10
  (see moai-ref-owasp-checklist), LLM/AI security (see moai-ref-llm-security),
  supply-chain provenance and signing (see moai-ref-supply-chain), or general API
  design (see moai-ref-api-patterns).

when_to_use: >
  Use when hardening a CI/CD pipeline, scanning infrastructure-as-code for
  misconfiguration, hardening a container image or Kubernetes cluster, defending
  against container escape, writing runtime-detection rules, enforcing operational
  API defenses (BOLA detection in production, rate-limit enforcement, server-side
  authorization, WAF tuning), or limiting GraphQL/REST query depth and complexity.
  Loads as background knowledge for DevSecOps review, container-security hardening,
  and API operational-defense tasks across any language ecosystem.

user-invocable: false
metadata:
  version: "1.0.0"
  category: "domain"
  status: "active"
  updated: "2026-06-24"
  tags: "devsecops, container, kubernetes, rbac, api-security, owasp-api, cicd, iac-scanning, runtime-detection, waf, reference"

# MoAI Extension: Progressive Disclosure
progressive_disclosure:
  enabled: true
  level1_tokens: 100
  level2_tokens: 3000

DevSecOps, Container, and API Operational Security Reference

Defensive practitioner reference for the operational layer of a system — the pipeline that builds it, the container and orchestrator that run it, and the API surface it exposes at runtime. Every section is framed as defense, hardening, detection, or verification: it describes the misconfiguration, how to detect it, and how to prevent it, never how to exploit it.

This skill is split into three modules by sub-domain. The overview below gives the shared threat model and an entry point; the depth lives in the modules. The threat model is operational: a pipeline can be subverted to inject a build step, a container can be misconfigured into a host breakout, and a running API can leak one tenant's data to another. The defenses establish least privilege, isolation, detection, and runtime authorization at each layer.

Three Sub-Domains (modules)

| Sub-domain | Module | Covers | |------------|--------|--------| | DevSecOps | [modules/devsecops.md](modules/devsecops.md) | CI/CD pipeline hardening, secret scanning, IaC misconfiguration detection (Terraform / CloudFormation), SAST/DAST integration | | Container | [modules/container.md](modules/container.md) | Image scanning, Kubernetes RBAC hardening, container-escape defense (seccomp / AppArmor / read-only root / non-root), runtime threat detection | | API operational | [modules/api-ops.md](modules/api-ops.md) | OWASP API Top 10 operational defense (BOLA / broken-auth detection in production, rate-limit enforcement, server-side authorization), WAF rule tuning, GraphQL/REST depth and complexity limiting |

Operational Trust Boundaries

The core defensive insight: each operational layer is a boundary where an attacker who has reached it can move to the next. Defense-in-depth means each boundary assumes the one before it may have failed.

| Boundary | Operational risk | Primary defense | Module | |----------|------------------|-----------------|--------| | Source → pipeline | Injected build step, leaked secret, poisoned runner | Signed pipeline, secret scanning, runner isolation | DevSecOps | | Pipeline → infra config | Misconfigured cloud resource (open bucket, permissive IAM) | IaC scanning before apply | DevSecOps | | Image → registry | Vulnerable base image, embedded secret | Image scanning + admission control | Container | | Container → host | Container escape to the node | seccomp, AppArmor, read-only root, non-root, drop capabilities | Container | | Cluster identity → resources | Over-privileged ServiceAccount, broad RoleBinding | Least-privilege RBAC, PodSecurity admission | Container | | Client → API | Broken object/function authorization, resource exhaustion | Server-side authorization, rate limiting, WAF | API operational |

Ecosystem-Neutral Tooling

This skill names tools at the category level. Where a tool is the de-facto cross-ecosystem standard for its category, it is named but framed as "the standard \<category\> tool" — the concept transfers to any equivalent tool. No single language ecosystem is privileged; pipeline examples are CLI-shape, not language-specific source.

Distinction from moai-ref-owasp-checklist (operational, not dev-time)

The API-operational module covers the **runtime/operational** half of API security — detecting Broken Object Level Authorization in production traffic, enforcing rate limits at the gateway, tuning a WAF, limiting query depth on a live endpoint. The **dev-time** half — secure-coding patterns a developer applies while writing the endpoint (parameterized queries, input validation, authentication design, security headers) — lives in `moai-ref-owasp-checklist`. This skill keeps its coverage operational and does not duplicate them.

Cross-References

• `moai-ref-owasp-checklist` — dev-time web-app OWASP Top 10, authentication

patterns, input validation, HTTP security headers (the development-time surface; this skill is the operational surface).

• `moai-ref-supply-chain` — SBOM, SLSA provenance, Sigstore signing, dependency

hygiene (the supply-chai