{"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://atlas.maintz.dev/)"},"id":"platform/devsecops","url":{"en":"https://atlas.maintz.dev/en/terms/platform/devsecops/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Get management to agree that development, security and operations share responsibility for security, and adopt a reference framework such as the NIST SSDF (SP 800-218) to describe what the teams must do.","Assess where you stand with a maturity model such as OWASP SAMM or DSOMM, and pick the few practices to improve first.","Add fast checks close to the developer - linters in the IDE and pre-commit hooks that catch secrets.","Run SAST, software composition analysis, IaC scanning and licence checks on every pull request, and require peer review before merge.","At build time scan container images, generate an SBOM, sign the artefact and record provenance; around deployment run DAST and enforce policy as code in admission control.","Tune the gates so the build fails only on high-confidence, high-severity findings, and use a baseline so only new findings block.","Send every finding to the owning team's backlog, prioritise with CISA's KEV catalogue, EPSS and reachability, and track mean time to remediate.","Appoint security champions in each team, offer hardened templates and reusable pipeline steps, and keep threat modelling and architecture review for new features.","Review the metrics and the maturity assessment every six months and choose the next improvements."],"da":["Få ledelsen til at bekræfte, at udvikling, sikkerhed og drift deler ansvaret for sikkerheden, og vælg en referenceramme som NIST SSDF (SP 800-218) til at beskrive, hvad teamene skal gøre.","Vurdér, hvor I står, med en modenhedsmodel som OWASP SAMM eller DSOMM, og vælg de få praksisser, I vil forbedre først.","Tilføj hurtige tjek tæt på udvikleren - linters i IDE'en og pre-commit-hooks, der fanger hemmeligheder.","Kør SAST, software composition analysis, IaC-scanning og licenstjek ved hver pull request, og kræv kollegial gennemgang før fletning.","Scan container-images, generér en SBOM, signér artefaktet, og registrér provenance ved build; kør DAST omkring udrulningen, og håndhæv policy as code i admission control.","Justér tjekkene, så buildet kun fejler på fund med høj sikkerhed og høj alvor, og brug en baseline, så kun nye fund blokerer.","Send hvert fund til det ansvarlige teams backlog, prioritér med CISA's KEV-katalog, EPSS og rækkevidde, og følg den gennemsnitlige tid til afhjælpning.","Udpeg security champions i hvert team, tilbyd hærdede skabeloner og genbrugelige pipelinetrin, og bevar trusselsmodellering og arkitekturgennemgang for nye funktioner.","Gennemgå målingerne og modenhedsvurderingen hvert halve år, og vælg de næste forbedringer."]},"pitfalls":{"en":["Buying scanners and switching them all on as blocking gates, so developers drown in false positives and route around the pipeline.","Measuring success by the number of findings rather than by how fast the important ones are fixed.","Believing automation replaces threat modelling, design review and monitoring in production.","Keeping security as a separate team that only signs off at the end, which is the old model with new tools."],"da":["At købe scannere og slå dem alle til som blokerende tjek, så udviklerne drukner i falske positiver og går uden om pipelinen.","At måle succes på antallet af fund i stedet for på, hvor hurtigt de vigtige bliver rettet.","At tro, at automatisering erstatter trusselsmodellering, designgennemgang og overvågning i drift.","At beholde sikkerhed som et separat team, der kun godkender til sidst, hvilket er den gamle model med nye værktøjer."]},"guides":[{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1","url":"https://csrc.nist.gov/pubs/sp/800/218/final","publisher":"NIST","tier":"standard"},{"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","publisher":"NIST","tier":"standard"},{"title":"OWASP DevSecOps Maturity Model (DSOMM)","url":"https://owasp.org/www-project-devsecops-maturity-model/","publisher":"OWASP","tier":"reference"},{"title":"OWASP SAMM - Software Assurance Maturity Model","url":"https://owaspsamm.org/","publisher":"OWASP","tier":"reference"}]},"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}