DevSecOps Foundations Intermediate

DevSecOps extends DevOps by making security a first-class, shared concern across the whole delivery lifecycle rather than a separate, final checkpoint. The name expands to Development, Security and Operations, integrating the three so that secure software is built continuously, not inspected in at the end.

The driving idea is that security cannot be a final gate bolted on just before release. When a team builds for weeks and only then submits the result to a security review, every finding arrives late, when changes are expensive and the release is already under deadline pressure. DevSecOps moves security into the everyday flow of work so risks are found and fixed continuously.

Shift-left means moving security activities earlier in the lifecycle — to the left on a timeline that runs from plan through code, build and test to release. Instead of waiting for a penetration test just before go-live, you bring threat modelling, secure coding, dependency scanning and static analysis into design and development.

The motivation is cost and feedback: a flaw caught while a developer is still writing the code is cheap to fix and fresh in mind, whereas the same flaw found in production is far more costly and disruptive. Shift-left does not mean testing less; it means testing earlier and more often, with fast feedback to the people who can fix the issue.

In DevSecOps, security is a shared responsibility. Developers, operations and the security team all own the security of what they ship; security is not delegated entirely to a separate team that gatekeeps at the end. The central security function shifts from doing all the work to enabling others — providing guidance, tooling, paved roads and review where it matters most.

A common pattern is the security champion: an interested member embedded within a development team who raises security awareness, helps with threat modelling and triage, and acts as a bridge to the central security team. Champions scale security expertise without requiring a security specialist in every meeting.

A secure SDLC weaves security into each phase of building software rather than treating it as an add-on. Typical phases — requirements, design, implementation, verification and release/operations — each gain security activities: security requirements and abuse cases up front, threat modelling and secure design, secure coding and code review during implementation, security testing during verification, and hardening, monitoring and incident response in operations.

The point is continuity: security considerations appear from the first requirement to the last day a system runs, so no phase is a blind spot. Each phase produces evidence (a threat model, scan results, a review) that informs the next.

Threat modelling is a structured way to ask, early in design, “what can go wrong?” You describe the system (often with a data-flow diagram and trust boundaries), enumerate plausible threats, and decide how to mitigate the important ones. Done early, it shapes the design itself so security is built in rather than patched on.

Four useful questions frame the exercise: What are we building? What can go wrong? What are we going to do about it? Did we do a good enough job? Threat modelling is most valuable before code exists, because changing a design diagram is far cheaper than re-architecting a running system.

STRIDE is a mnemonic for six categories of threat, useful for enumerating “what can go wrong”. It stands for Spoofing (pretending to be someone else), Tampering (unauthorised modification of data), Repudiation (denying an action with no proof), Information disclosure (leaking data), Denial of service (making a system unavailable) and Elevation of privilege (gaining rights you should not have).

Each STRIDE category maps to a desirable property it violates: spoofing breaks authentication, tampering breaks integrity, repudiation breaks non-repudiation, information disclosure breaks confidentiality, denial of service breaks availability, and elevation of privilege breaks authorisation.

A useful map of delivery is the loop plan → code → build → test → release → deploy → operate → monitor. DevSecOps places a relevant security activity at each stage rather than concentrating them in one place.

In plan: threat modelling and security requirements. In code: secure coding, IDE linting and secrets-detection on commit. In build: software composition analysis of dependencies and static analysis. In test: dynamic and integration security testing. In release: signing and policy checks. In deploy: secure configuration and infrastructure-as-code scanning. In operate: least-privilege runtime and hardening. In monitor: logging, alerting and continuous vulnerability watch.

DevSecOps relies on automation so security checks run on every change without slowing people down. Common automated checks include SAST (static application security testing of source code), SCA (software composition analysis of dependencies for known vulnerabilities), DAST (dynamic testing of a running application), secrets scanning, and configuration/IaC scanning.

Automation makes checks consistent and repeatable — the same rules apply to everyone, every time — and fast enough to give feedback within a pipeline run. Manual review still matters for design and nuanced logic, but routine, well-defined checks should be automated so humans focus on judgement.

A security gate is a checkpoint in the pipeline that decides whether a change may proceed. Two broad modes exist. A blocking gate breaks the build when a check fails — for example, refusing to release if a critical, fixable vulnerability is present. A warn-only (non-blocking) gate reports findings but lets the pipeline continue.

Choosing between them is a trade-off. Blocking gives strong guarantees but, if tuned poorly, frustrates teams and tempts them to bypass it. Warn-only avoids friction but risks being ignored. A common, pragmatic approach is to start warn-only to build trust and baseline noise, then progressively block on the most severe, high-confidence findings.

Automated tools produce false positives — reported issues that are not real or not exploitable in context — and occasionally false negatives, real issues they miss. Too many false positives create alert fatigue and erode trust in the tooling, which is why triage matters: reviewing findings to confirm which are genuine, relevant and worth acting on.

Good practice includes tuning rules to your codebase, suppressing known-irrelevant findings with a documented justification (not silently), de-duplicating, and tracking accepted risks. The goal is a signal developers trust, so that when a gate flags something, they take it seriously.

You cannot fix everything at once, so DevSecOps prioritises by risk. The CVSS (Common Vulnerability Scoring System) gives a severity score from 0 to 10 reflecting how bad a vulnerability is if exploited — its intrinsic technical impact and exploitability characteristics.

Severity alone is not the whole story. EPSS (Exploit Prediction Scoring System) estimates the probability that a vulnerability will be exploited in the wild in the near term. Combining likelihood (EPSS), impact (CVSS) and your own context — is the asset exposed? is there a known exploit? — lets you fix what actually matters first rather than chasing every high score.

The principle of least privilege says every user, service and process should have only the permissions it needs to do its job — no more. Narrow permissions limit the blast radius: if a component is compromised, the attacker inherits only its small set of rights rather than broad access.

Closely related is secure by default: systems should ship in their safe configuration out of the box, so doing nothing is the secure choice and insecurity requires a deliberate, visible opt-out. Examples include denying access unless explicitly granted, encryption on by default, and disabling unused features and ports. Defaults shape behaviour, so safe defaults prevent whole classes of mistake.

Secrets are sensitive credentials such as API keys, database passwords, tokens and private keys. A foundational rule is to never commit secrets to source control — once a secret is in git history it must be considered exposed and rotated, even if later deleted. Secrets scanning in the pipeline helps catch accidental commits early.

Instead, secrets should live in a dedicated secrets manager or vault and be injected at deploy or runtime through environment configuration, never hard-coded. Good hygiene also includes rotating secrets regularly, scoping them narrowly (least privilege again), and preferring short-lived, automatically issued credentials over long-lived static ones.

Compliance and governance are often seen as bureaucratic brakes, but in DevSecOps they are reframed as enablers: clear, agreed guardrails that let teams move fast safely because the boundaries are explicit and automated. The aim is to satisfy real requirements continuously, not to produce paperwork once a year.

A central idea is compliance-as-code: expressing policies (for example, “production storage must be encrypted” or “no public S3 buckets”) as machine-readable rules that the pipeline checks automatically. This produces continuous, evidence-backed compliance and removes slow manual sign-offs from the critical path, while still giving auditors a reliable trail.

The OWASP DevSecOps Maturity Model (DSOMM) helps teams assess and grow their security practices along defined levels of maturity across several dimensions — such as build and deployment, culture and organisation, implementation, information gathering, and test and verification.

The value of a maturity model is direction, not a label: it lets a team see where they are, identify the next realistic improvement, and avoid skipping foundations. Early levels establish basics (for example, version control and automated builds with simple scanning); higher levels add more advanced, continuous and well-integrated practices. Progress is incremental and capability-based rather than all-or-nothing.

What gets measured gets improved, so DevSecOps tracks security metrics to see whether practices are working. Useful examples include vulnerability density (number of vulnerabilities relative to size, e.g. per thousand lines of code or per service), mean time to remediate (MTTR) (how long, on average, from discovering a vulnerability to fixing it), and escaped defects (security issues that reached production rather than being caught earlier).

Read together, these tell a story: falling vulnerability density and MTTR with few escaped defects suggests security is genuinely shifting left and feedback loops are tight. Metrics should drive improvement, not be weaponised to punish individuals, which would only encourage hiding problems.

Security is ultimately a culture problem as much as a technical one. A blameless approach treats incidents and mistakes as opportunities to learn and improve the system, not occasions to punish an individual. When people fear blame, they hide problems — the opposite of what security needs.

Blameless does not mean no accountability; it means focusing on why the system allowed the mistake and how to prevent recurrence, through blameless post-incident reviews and systemic fixes. Psychological safety — the confidence that raising a concern or admitting an error is welcomed — is what makes shift-left, champions and honest metrics actually work in practice.

Shift-left finds problems early, but it cannot find everything — production behaves in ways no test fully predicts. Shift-right complements it by extending security into runtime through continuous monitoring, observability and feedback from real operation. Together they form a complete loop: catch issues early and keep watching after release.

Shift-right practices include runtime monitoring and alerting, logging and audit trails, vulnerability and threat intelligence feeds that flag newly disclosed issues in already-deployed components, and controlled exercises such as chaos or security game days. The feedback gathered in operation flows back into planning and design, closing the DevSecOps loop so each cycle is more secure than the last.

Functional requirements describe what a system should do; security requirements describe what it must not allow and the properties it must preserve — confidentiality, integrity, availability, authentication, authorisation and auditability. Capturing them up front, alongside features, ensures security is designed in rather than retrofitted.

A powerful technique is the abuse case (or misuse case): the inverse of a user story, describing how a hostile actor might deliberately subvert the system. Where a use case says “a user resets their password by email”, an abuse case asks “an attacker triggers unlimited reset emails to flood a victim” or “an attacker enumerates valid accounts via reset responses”. Each abuse case becomes a concrete security requirement and test.

A secure design review evaluates the architecture of a system before significant code is written, looking for weaknesses in how components, data flows and trust boundaries are arranged. Unlike code review, which inspects implementation detail, a design review reasons about structure: authentication and session models, where trust boundaries lie, how data is protected in transit and at rest, and how failures are contained.

Reviews are most effective when they reference established security design principles — defence in depth, fail securely, complete mediation, least privilege, separation of duties and minimising attack surface. The output is a set of agreed design changes and risks, captured so later phases can verify they were addressed.

A vulnerability-management program is the repeatable process by which an organisation discovers, tracks, prioritises, remediates and verifies security weaknesses across its software and infrastructure. Ad-hoc fixing does not scale; a program gives findings a single home, an owner and a defined lifecycle from detection to closure.

A cornerstone is the remediation SLA (service-level agreement): a maximum time-to-fix tied to severity. For example, critical issues within 7 days, high within 30, medium within 90, low within 180. SLAs make expectations explicit, allow tracking of overdue items, and turn “we should fix that someday” into measurable commitments with escalation when breached.

As teams add many scanners — SAST, SCA, DAST, secrets, IaC — findings scatter across tools, formats and severities, making it hard to see overall risk. Application Security Posture Management (ASPM), sometimes called ASOC (application security orchestration and correlation), addresses this by aggregating findings from many sources into one normalised view, correlating and de-duplicating them, and tying them back to the applications and owners they affect.

The value is a single pane of glass: consistent prioritisation across tools, de-duplication so the same issue is not counted many times, and the ability to trace a finding to a service, team and remediation SLA. ASPM turns a pile of disconnected scanner outputs into an actionable, owned risk picture.

A security champions program turns the ad-hoc idea of an embedded advocate into a deliberate, supported structure. Champions are usually volunteer or nominated developers — roughly one per team — who keep their engineering role but take on extra security responsibilities: reviewing threat models, triaging findings, answering everyday questions and feeding team concerns back to the central security team.

A healthy program supplies champions with real support: dedicated time, training, a community of practice that meets regularly, recognition, and a direct line to security experts. It is not a way to offload all security onto unpaid volunteers; it is a force-multiplier that scales scarce security expertise across many teams while keeping context with the people who write the code.

A secure coding standard is an agreed, written set of rules and patterns that help developers avoid common vulnerability classes — for example, always use parameterised queries to prevent injection, encode output to prevent cross-site scripting, validate input against an allow-list, and never roll your own cryptography. Standards turn hard-won security knowledge into repeatable guidance and give code review an objective reference.

Standards only help if people know them, so training is the partner practice: regular, role-relevant, hands-on education rather than a once-a-year slideshow. Effective training is contextual (tied to the languages and frameworks a team actually uses), reinforced by the standard, and connected to the findings tooling produces so lessons are concrete and timely.

Modern applications are mostly third-party code, so a dependency policy governs what open-source and external components a team may use and how. Typical clauses cover allowed licences, minimum maintenance and reputation criteria, a ban on known-vulnerable versions, pinning and lockfiles for reproducibility, and a defined process for adding or updating a dependency.

Software composition analysis enforces parts of the policy automatically, but policy adds the human-agreed rules: prefer well-maintained libraries, avoid abandoned ones, and keep dependencies current so security patches arrive promptly. A useful related practice is generating a software bill of materials (SBOM) — an inventory of every component — so that when a new vulnerability is disclosed, you can quickly tell whether you are affected.

Your attack surface is the total set of points where an attacker could try to enter or extract data — exposed endpoints, open ports, public-facing services, APIs, subdomains, cloud assets and forgotten test environments. Attack-surface management (ASM) is the continuous discovery, inventory and monitoring of these exposures, often including assets the organisation has lost track of (“shadow IT”).

The defensive goal is twofold: reduce the surface by decommissioning unused assets, closing unnecessary ports and minimising exposure, and watch what remains for change and risk. Because cloud and SaaS make it trivial to spin up new internet-facing resources, surfaces grow silently; continuous external discovery catches the rogue staging server before an attacker does.

Cloud Security Posture Management (CSPM) continuously checks cloud configurations against security best practice and detects misconfigurations — the leading cause of cloud breaches — such as public storage buckets, over-permissive identity policies, unencrypted databases or open security groups. In DevSecOps, CSPM shifts left: the same checks run against infrastructure-as-code in the pipeline, before resources are ever created.

Scanning IaC templates (for example, with policy-as-code rules) means a misconfiguration is caught at pull-request time rather than discovered live in production. Runtime CSPM still matters to catch drift — changes made outside the pipeline — but pushing the checks into the pipeline prevents whole classes of cloud misconfiguration from ever shipping.

Operations sees things tests cannot: which code paths actually run, which packages are loaded, which endpoints face real traffic, and which attacks are attempted. Runtime feedback channels this back to developers so they can prioritise what genuinely matters. For example, knowing a vulnerable library function is never reached in production — or, conversely, is exercised on every request — sharply changes how urgently it should be fixed.

Mechanisms include application-level monitoring, runtime application self-protection signals, observability traces that show real call paths, and alerts surfaced directly in the developer’s workflow (issue tracker or pull request) rather than buried in a separate console. The aim is a tight loop where production reality continuously informs and re-prioritises development.

Organisations must often satisfy external frameworks such as SOC 2, ISO 27001 and PCI-DSS. Rather than treating each as a separate fire drill, DevSecOps maps controls: it links the security activities a team already performs — access control, encryption, logging, change management, vulnerability management — to the specific requirements of each framework, so one good practice satisfies many obligations.

The practical win is evidence collection as a by-product. If pipelines already enforce reviews, scans and signed artifacts and record the results, that record is audit evidence. A control matrix that maps “we encrypt data at rest” to the relevant SOC 2, ISO 27001 and PCI-DSS clauses turns continuous engineering practice into continuous compliance, avoiding a scramble before each audit.

Effective pipelines do not rely on a single gate; they place layered gates at each stage, each suited to what is knowable there. On commit: fast checks such as secret detection and lint, tuned to be near-instant so developers are not slowed. On build: dependency (SCA) and static (SAST) analysis against the assembled artifact. On test: dynamic testing (DAST) against a deployed instance. On release: artifact signing and policy verification. On deploy: IaC and configuration checks.

Two principles keep this workable. First, fail fast: cheap, high-signal checks run earliest so most problems are caught before slow stages. Second, graduated enforcement: each gate blocks only on findings appropriate to that stage and confidence level, so the pipeline stays both safe and fast rather than a wall of brittle failures.

Even with strong internal practices, external researchers find issues teams miss. A vulnerability disclosure policy (VDP) provides a safe, advertised channel — often a security.txt file and a clear inbox — for anyone to report a flaw without fear of legal reprisal. A bug bounty program extends this by paying rewards scaled to severity, incentivising skilled researchers to look.

Integrating these into DevSecOps means external findings flow into the same vulnerability-management process as internal ones: triaged, prioritised by risk, assigned an owner and a remediation SLA, and verified on fix. Coordinated disclosure keeps the reporter informed and agrees a timeline so the issue is fixed before public details appear. Bug bounty complements, never replaces, internal testing.

Threat intelligence is curated information about current threats — newly disclosed vulnerabilities, active exploitation trends, malicious packages, indicators of compromise and adversary techniques. Feeding it into the pipeline lets defences respond to the real-world threat landscape rather than a static checklist.

Practical uses include enriching vulnerability prioritisation (for instance, raising urgency when a CVE in your stack is reported as actively exploited, complementing CVSS and EPSS), watching for malicious or typosquatted packages before they enter a build, and updating detection rules as new techniques emerge. The aim is to make prioritisation and gates adaptive: what was low risk yesterday can become urgent today when exploitation begins.

DevSecOps competes for time and budget, so it needs a business case stated in terms leaders value: reduced risk of costly breaches, faster and safer delivery, fewer late-stage surprises that delay releases, and lower remediation cost because issues are caught early. Framing security as an enabler of reliable delivery — not a tax on it — is what wins sustained investment.

A metrics dashboard makes the case visible and ongoing. It surfaces leading and lagging indicators — open vulnerabilities by severity and age, SLA compliance, mean time to remediate, scan coverage, escaped defects — aimed at different audiences. Engineers see actionable backlog; leaders see trends and risk. Dashboards should drive improvement and informed decisions, not vanity numbers or individual blame.

A security maturity assessment is a structured, periodic evaluation of how well an organisation performs its security practices, measured against a model such as OWASP SAMM (Software Assurance Maturity Model) or the DevSecOps Maturity Model. Rather than a pass/fail audit, it scores capability levels across domains — governance, design, implementation, verification and operations — to reveal strengths and gaps.

The output is a baseline and a prioritised, realistic roadmap: pick the next achievable level in the weakest high-value domains rather than chasing perfection everywhere. Repeating the assessment over time shows whether investments are actually raising maturity. The point is direction and honest self-knowledge, not a trophy — an inflated self-score helps no one.

Change management ensures that what reaches production is intended, reviewed and traceable. In DevSecOps this is automated rather than ceremonial: every change flows through version control and a reviewed pull request, builds are reproducible, artifacts are signed and their integrity verified, and a provenance record links the running artifact back to the exact commit and pipeline that produced it.

Secure release adds control over how change reaches users: progressive delivery (canary or staged rollouts) limits blast radius, automated rollback restores a known-good state quickly if something goes wrong, and an audit trail records who deployed what and when. The goal is to move fast and retain confidence that only authorised, verified changes run — and that any one can be undone.

Privacy by design embeds the protection of personal data into systems from the outset rather than adding it later. Core ideas include data minimisation (collect and retain only what you genuinely need), purpose limitation (use data only for the stated reason), and strong defaults so the most privacy-protective setting is the starting point.

Practical controls support this: encryption of personal data in transit and at rest, pseudonymisation or anonymisation where full identification is unnecessary, defined retention and deletion so data does not linger forever, and access limited on a need-to-know basis with auditing. In DevSecOps these can be checked continuously — for example, flagging fields that look like personal data in logs — so privacy, like security, is verified throughout the lifecycle rather than assumed.