DevSecOps

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.

I 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.

Det 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.

DevSecOps 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.