Skip to content
sec/atlas
knowledge base · engineering

Security engineering, mapped.

An interactive map of the engineering behind security: IaC, policy as code, hardened pipelines, reliability at scale, automation and AI, from code to platform.

$ click a card for details · ctrl+k to search

learning map

Topics are laid out by level, from foundations to advanced. Arrows point from a prerequisite to what builds on it. Select a topic to preview it, or follow the highlighted next step.

Your next step

0 of 8 studied
start this topic

02 Practitioner

Apply the controls and make them work in practice.

03 Advanced

Design, scale and operate at depth.

  • studied
  • ready to study
  • prerequisites missing

engineering cycle

From definition as code to automation: the control lives in every phase. Each chip opens the matching topic.

  1. 01define

    controls described as code

    secure infrastructure as codeexecutable policiesapproved modules and standards

    gate: no infra change without review and passing policy

  2. 02deliver

    a trustworthy pipeline, no static secrets

    ephemeral runners and OIDCpinned actions and dependenciessigned artifacts

    gate: the pipeline itself is treated as a target

  3. 03scale

    pipelines that withstand volume and failure

    retries, idempotency and backpressureobserve the pipeline itself

    gate: pipeline lag, latency and errors have an SLO and an alert

  4. 04automate

    automated response, with brakes

    playbooks as codeAI in triage and mitigationhuman approval for destructive actions

    gate: every automation is idempotent, auditable and reversible

topics

Secure infrastructure as code
When infrastructure is code, its security can be code too: reviewed in a PR, scanned before apply and compared with reality to catch what changed out of band.
technique· stage: definir
Policy as code
A policy written in a document depends on someone remembering it. A policy written as code is enforced on every change, equally for everyone, and leaves a trail of what was decided.
technique· stage: definir
CI/CD hardening
The pipeline holds credentials, runs third-party code and publishes what goes to production. Compromising it is the shortest route to compromising everything.
practice· stage: entregar
Reliability at scale: idempotency, retries and backpressure
In distributed systems everything fails at some point. What separates a reliable security platform is how it behaves when that happens: no lost events and no acting twice.
practice· stage: escalar
Observability of the security platform itself
A detection that stopped working makes no noise: it simply stops catching attacks. Observing the pipeline itself is what turns that silent failure into an alert.
practice· stage: escalar
Security automation and playbooks as code
Automating response takes minutes off every incident, but a poorly designed automation is an incident waiting to happen. What separates the two are the brakes.
practice· stage: automatizar
AI in triage and mitigation
Language models speed up alert triage and the writing of mitigations, but they read untrusted data and can be confidently wrong. The right design treats the output as a suggestion, not a decision.
technique· stage: automatizar
Security as an internal product
Controls that get in the way are bypassed. A security platform that treats devs as customers, with a paved path, adoption metrics and low friction, is the one that actually protects.
concept