DevSecOps Foundation cheat sheet

DevSecOps integrates security controls into the same version-controlled pipeline that builds and deploys software, so security evidence is generated automatically rather than assembled after release.

The core driver is the cost-of-delay curve: a defect found in design costs least, a defect found in production costs most; shifting controls left reduces total remediation cost and breach exposure.

Deployment frequency, lead time for change, change failure rate, and mean time to restore are the four DORA measures; security work is judged by its effect on these, not by ticket counts.

A gate that blocks releases only at the end creates a bottleneck; the same control applied as a fast pre-commit or pull-request check preserves flow.

Traditional separation of duties between build and security teams produces hand-off latency measured in days; automated policy checks reduce that to seconds.

Compliance evidence produced continuously from pipeline logs and configuration scans replaces periodic manual evidence collection, shortening audit cycles.

Security debt compounds like technical debt: unremediated findings in a dependency persist across every release until the dependency is upgraded.

Threat landscape driver: most breaches exploit known, unpatched weaknesses or misconfiguration, both detectable by automated scanning inside the pipeline.

Blameless postmortem rule: describe the conditions and decisions that allowed the failure, not the individual; the goal is a system change that prevents recurrence.

Psychological safety is a precondition for reporting near misses; if reporting a mistake carries punishment, defect data becomes unreliable.

Security champions are embedded engineers in product teams who own threat modeling and triage for their team, with a defined time allocation and reporting line.

Executive sponsorship must be visible in funding, staffing, and release decisions; a program without budget authority stalls at the pilot stage.

Shared ownership model: product teams own the risk of their service, the central security function owns standards, tooling, and specialist response.

Change management for DevSecOps requires rewriting role descriptions and performance objectives so that security outcomes appear in engineer goals.

Metrics that punish teams (for example raw finding counts per developer) incentivize hiding findings; prefer coverage, time-to-remediate, and escape rate.

Training is most effective when delivered in the workflow: short guidance at the pull request, paired threat modeling, and internal capture-the-flag exercises.

Pilot-first strategy: select one high-value, low-coupling service, instrument the full pipeline, measure results, then scale the pattern rather than mandating org-wide change on day one.

Build-versus-buy decision: scanning engines and secret detection are commodity; invest engineering effort in policy, triage workflow, and remediation automation.

Tool sprawl is the most common failure mode; each added scanner needs an owner, a triage path, and a defined false-positive budget or it is ignored.

Risk-based prioritization uses exploitability and asset criticality, not raw severity score; a critical finding on an unreachable internal test host ranks below a high finding on an internet-facing payment API.

Migration sequencing for legacy estates: put compensating controls (network segmentation, WAF, runtime protection) around systems that cannot be rebuilt, and apply pipeline controls to new work.

Total cost of ownership includes scanner licensing, engineer triage hours, pipeline compute, and the cost of false positives consuming developer time.

Success criteria should be defined before rollout: for example percentage of repositories with automated dependency scanning, median time to remediate, and reduction in escaped defects.

Regulatory and contractual obligations (sector rules, customer security schedules) set the floor for control coverage and are inputs to strategy, not afterthoughts.

Defense in depth: assume any single control can fail and layer preventive, detective, and corrective controls so no single bypass yields full compromise.

Least privilege applies to humans, services, and pipeline agents; a build agent with broad cloud permissions is a high-value target because it holds credentials for deployment.

Threat modeling with STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) is performed at design time per data flow and trust boundary.

The OWASP Top 10 is an awareness baseline for common web weaknesses, not a complete control set; injection, broken access control, and cryptographic failures remain top categories.

Secrets must never be committed to source control; they belong in a managed secret store with rotation, and detection of committed secrets triggers immediate revocation.

Supply chain risk: dependencies, base images, and build plugins execute with your privileges, so provenance verification, pinned versions, and artifact signing are required controls.

Encryption: protect data in transit with current TLS versions and in storage with managed key services; key custody and rotation policy matter as much as the algorithm.

Vulnerability management requires a defined remediation SLA by severity and an exception process with an expiry date; unbounded exceptions are equivalent to accepted risk.

Authentication proves identity; authorization decides permitted actions; accounting records what was done. Conflating them is a design error.

Multi-factor authentication reduces credential-theft impact; phishing-resistant factors (FIDO2 security keys, passkeys) resist real-time relay attacks that one-time codes do not.

OAuth 2.0 is a delegated authorization framework; OpenID Connect adds an identity layer on top of it and issues an ID token containing user claims.

For machine identity prefer short-lived workload credentials from a platform identity service over long-lived static keys stored in configuration.

Role-based access control grants by job function; attribute-based access control evaluates attributes such as department, resource tag, and time, enabling finer and context-aware rules.

Just-in-time elevation: grant privileged access for a bounded window with approval and logging, rather than standing administrator rights.

Access reviews are periodic attestations that each entitlement is still required; orphaned accounts and unused entitlements are the usual findings.

Zero trust principle: no implicit trust from network location; every request is authenticated and authorized based on identity, device posture, and context.

SAST analyzes source or bytecode without executing it; it finds issues early but produces false positives and cannot see runtime configuration.

DAST probes a running application from outside; it finds runtime and configuration issues but lacks code context and cannot reach unexercised paths.

SCA inventories third-party components and maps them to known vulnerability records; it does not detect flaws written in your own code.

IAST combines runtime instrumentation with code context, giving lower false-positive rates than SAST alone but requiring instrumented test execution.

Secret scanning inspects commits and history for credentials and keys; a finding requires revocation, not just removal from the current revision.

Security unit and integration tests encode abuse cases (for example authorization bypass attempts) as executable regression checks in the pipeline.

Input validation is an allow-list at trust boundaries; output encoding is context-specific (HTML, attribute, JavaScript, SQL) and must match the sink.

Software composition and container scanning should fail the build only on policy-defined thresholds, otherwise developers disable the check.

Immutable infrastructure: servers and containers are replaced, not patched in place; this eliminates configuration drift and makes rollback deterministic.

Infrastructure as code must be scanned for misconfiguration before apply, and state files must be treated as sensitive because they often contain secrets.

Hardened base images, minimal runtime images, and non-root container users reduce the attack surface available after an initial compromise.

Network segmentation limits lateral movement; default-deny ingress and egress rules with explicit allow-lists are the baseline for production workloads.

Patch SLAs by severity with automated dependency updates; the mean time to patch is the operative metric, not the existence of a patch process.

Backups require tested restore procedures and protection against deletion by a compromised account (immutable or offline copies).

Runtime protection (for example workload behavior monitoring) is a compensating control for legacy systems that cannot be rebuilt into the pipeline.

Environment separation: production credentials must never be available to development or test pipelines; promotion moves artifacts, not secrets.

Policy as code turns written standards into executable checks evaluated in the pipeline, producing continuous evidence instead of annual snapshots.

Risk register entries need an owner, likelihood and impact rating, treatment decision (mitigate, transfer, accept, avoid), and a review date.

Control mapping links each technical check to the framework requirement it satisfies; one check can satisfy several frameworks, which avoids duplicate audits.

Audit evidence should be machine-generated and time-stamped: pipeline run logs, scan results, approval records, and configuration snapshots retained per policy.

Segregation of duties in the pipeline means the person who writes code is not the sole approver of the production deployment.

Change traceability: every production artifact should be traceable to a commit, a reviewer, a passing test run, and an approval record.

Exception handling requires a documented risk acceptance with an expiry date, an approver with authority, and a compensating control where applicable.

Frameworks commonly referenced include ISO/IEC 27001 for management systems, SOC 2 for service controls, and PCI DSS for cardholder data environments.

Log the security-relevant events: authentication successes and failures, authorization denials, privilege changes, secret access, and configuration changes.

Logs must be shipped off the host to a central store with restricted write access; an attacker with host access must not be able to erase evidence.

Retention periods are set by legal, contractual, and investigation needs; short retention destroys the ability to investigate slow and quiet intrusions.

Alert on high-signal conditions (impossible travel, spike in authorization denials, new admin grant) rather than raw event volume, to keep the queue actionable.

Detection engineering treats alerts as code: version-controlled rules, tested against known-bad samples, with owners and tuning history.

Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident review with lessons recorded.

Mean time to detect and mean time to respond are the operative response metrics; both depend on telemetry coverage more than on headcount.

Tabletop exercises and game days validate that runbooks, contacts, and access paths work before a real incident exposes the gaps.