{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/devsecops","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/devsecops/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/devsecops/"},"term":{"en":"DevSecOps","da":"DevSecOps"},"aka":{"en":["secure DevOps"],"da":[]},"domain":["platform","security"],"cluster":"delivery","layer":"process","status":"current","era":2012,"summary":{"en":"Building security checks into the everyday work of the teams that write and run software, rather than adding them at the end.","da":"At bygge sikkerhedstjek ind i det daglige arbejde hos de teams, der skriver og driver software, i stedet for at tilføje dem til sidst."},"body":{"formal":{"en":"A way of working in which development, security and operations share responsibility for security, and checks such as code review, vulnerability scanning, SBOM creation and secrets checks run automatically in the pipeline on every change.","da":"En arbejdsform, hvor udvikling, sikkerhed og drift deler ansvaret for sikkerheden, og tjek som kodegennemgang, sårbarhedsscanning, SBOM-generering og kontrol af hemmeligheder kører automatisk i pipelinen ved hver ændring."},"plain":{"en":"Like building a house with the fire inspector on site from day one, instead of calling them in when the keys are about to be handed over.","da":"Som at bygge et hus med brandinspektøren på pladsen fra første dag i stedet for at kalde vedkommende ind, når nøglerne skal overdrages."},"inPractice":{"en":"A developer on a ministry's digital team opens a change request; an automatic check flags a password left in the code, and she removes it before review, so it never reaches production.","da":"En udvikler i ministeriets digitale team opretter en ændringsanmodning; et automatisk tjek finder en adgangskode, der er efterladt i koden, og hun fjerner den før gennemgangen, så den aldrig når driften."},"whyItMatters":{"en":"Flaws found while code is being written cost far less to fix than flaws found by attackers, and automatic checks keep pace with teams that release many times a day.","da":"Fejl, der findes, mens koden skrives, er langt billigere at rette end fejl, som angribere finder, og automatiske tjek kan følge med teams, der frigiver mange gange om dagen."}},"deepDive":{"en":"The idea was popularised around 2012, when Gartner's Neil MacDonald argued for \"DevOpsSec\" - making security a participant in DevOps rather than a gate in front of it. It is not a standard but a set of practices, and its concrete content is usually described with reference frameworks: NIST SP 800-218, the Secure Software Development Framework (SSDF v1.1, 2022), groups secure development practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV); NIST SP 800-204D maps supply-chain controls onto CI/CD pipelines; OWASP SAMM and the OWASP DevSecOps Maturity Model (DSOMM) provide maturity levels for assessing a programme.\n\nIn practice the pipeline is instrumented at each stage. Before commit: IDE linters and pre-commit hooks for secrets (gitleaks, detect-secrets). On pull request: SAST (CodeQL, Semgrep, SonarQube), software composition analysis of manifests and lockfiles, IaC scanning (Checkov, tfsec/Trivy, KICS), licence checks and mandatory peer review. On build: container image scanning, SBOM generation, signing and SLSA provenance. Before or after deployment: DAST against a running test environment (OWASP ZAP), API fuzzing, and policy-as-code admission control (OPA Gatekeeper, Kyverno). In production: runtime detection, cloud security posture management and a vulnerability-management loop that feeds findings back to the owning team's backlog.\n\nThe hard part is signal-to-noise. SAST and SCA produce many findings that are unreachable, disputed or low-impact, and a pipeline that fails on every medium finding is quickly bypassed. Mature programmes break the build only on high-confidence, high-severity issues, use baselines or ratchets so that only new findings block, triage with reachability or exploitability data (EPSS, CISA's Known Exploited Vulnerabilities catalogue, VEX statements), and measure mean time to remediate rather than number of findings. \"Shift left\" does not mean \"shift everything left\": threat modelling, architecture review and runtime monitoring cannot be replaced by scanners. Organisationally, security champions embedded in teams and security-owned paved roads (hardened templates, reusable pipeline steps) scale better than a central team reviewing every change.\n\nDevSecOps relates to a secure development lifecycle (SDL) as automation relates to process: Microsoft's SDL, introduced in 2004, defined phase-based security activities for comparatively long release cycles, whereas DevSecOps executes the automatable subset continuously on every change and relies on humans for the rest. In an EU context the same evidence - reviewed changes, scan results, SBOMs, vulnerability handling records - supports NIS2 Article 21(2)(e) on security in network and information system acquisition, development and maintenance, and the Cyber Resilience Act's essential requirements for manufacturers.","da":"Idéen blev udbredt omkring 2012, da Gartners Neil MacDonald argumenterede for \"DevOpsSec\" - at sikkerhed skulle være en deltager i DevOps frem for en port foran det. Det er ikke en standard, men et sæt praksisser, og det konkrete indhold beskrives normalt med referencerammer: NIST SP 800-218, Secure Software Development Framework (SSDF v1.1, 2022), grupperer praksisser for sikker udvikling i Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) og Respond to Vulnerabilities (RV); NIST SP 800-204D kobler kontroller for forsyningskæden på CI/CD-pipelines; OWASP SAMM og OWASP DevSecOps Maturity Model (DSOMM) giver modenhedsniveauer til at vurdere et program.\n\nI praksis instrumenteres pipelinen i hver fase. Før commit: linters i IDE'en og pre-commit-hooks, der leder efter hemmeligheder (gitleaks, detect-secrets). Ved pull request: SAST (CodeQL, Semgrep, SonarQube), software composition analysis af manifester og lockfiler, IaC-scanning (Checkov, tfsec/Trivy, KICS), licenstjek og obligatorisk kollegial gennemgang. Ved build: scanning af container-images, SBOM-generering, signering og SLSA-provenance. Før eller efter udrulning: DAST mod et kørende testmiljø (OWASP ZAP), fuzzing af API'er og admission control med policy as code (OPA Gatekeeper, Kyverno). I drift: detektion under kørsel, cloud security posture management og en sårbarhedshåndteringsløkke, der sender fund tilbage til det ansvarlige teams backlog.\n\nDet svære er forholdet mellem signal og støj. SAST og SCA giver mange fund, der ikke kan nås, er omstridte eller har lille betydning, og en pipeline, der fejler på hvert medium-fund, bliver hurtigt omgået. Modne programmer bryder kun buildet på fund med høj sikkerhed og høj alvor, bruger baselines eller ratchets, så kun nye fund blokerer, prioriterer med data om rækkevidde og udnyttelighed (EPSS, CISA's katalog over Known Exploited Vulnerabilities, VEX-erklæringer) og måler gennemsnitlig tid til afhjælpning frem for antal fund. \"Shift left\" betyder ikke \"flyt alt til venstre\": trusselsmodellering, arkitekturgennemgang og overvågning i drift kan ikke erstattes af scannere. Organisatorisk skalerer security champions i teamene og sikre standardveje ejet af sikkerhedsfunktionen (hærdede skabeloner, genbrugelige pipelinetrin) bedre end et centralt team, der gennemgår hver ændring.\n\nDevSecOps forholder sig til en sikker udviklingslivscyklus (SDL), som automatisering forholder sig til proces: Microsofts SDL, indført i 2004, definerede sikkerhedsaktiviteter per fase til forholdsvis lange udgivelsescyklusser, mens DevSecOps udfører den automatiserbare del løbende ved hver ændring og overlader resten til mennesker. I en EU-sammenhæng understøtter den samme dokumentation - gennemgåede ændringer, scanningsresultater, SBOM'er, registreringer af sårbarhedshåndtering - NIS2-direktivets artikel 21, stk. 2, litra e, om sikkerhed ved erhvervelse, udvikling og vedligeholdelse af net- og informationssystemer, og Cyberrobusthedsforordningens væsentlige krav til producenter."},"edges":[{"type":"requires","to":"platform/ci-cd","confidence":"high","strength":"normal"},{"type":"implements","to":"security/security-by-design","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/sbom","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/vulnerability-scanning","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/secure-development-lifecycle","why":{"en":"The SDL sets which security steps happen at each stage; DevSecOps automates them in the pipeline so they run on every change.","da":"SDL fastlægger, hvilke sikkerhedstrin der sker i hver fase; DevSecOps automatiserer dem i pipelinen, så de kører ved hver ændring."},"confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"NIST SP 800-204D - Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines","url":"https://csrc.nist.gov/pubs/sp/800/204/d/final","tier":"standard","publisher":"NIST"},{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF)","url":"https://csrc.nist.gov/pubs/sp/800/218/final","tier":"standard","publisher":"NIST"}],"draft":true}