Přesun DevOps na DevSecOps

Při vytváření nebo modernizaci disciplíny vývojového zabezpečení tento článek popisuje, jak integrace zabezpečení do postupů vývoje umožňuje přechod od vývojářských operací (DevOps) k operacím se zabezpečením vývojářů (DevSecOps) a pomáhá zabezpečit doručování aplikací.

Moderní organizace spoléhají na rychlý vývoj softwaru, aby poskytovaly inovace, reagovaly na měnící se obchodní požadavky a zachovaly konkurenční výhodu. DevOps umožňuje tuto flexibilitu prostřednictvím kontinuální integrace a doručování. Vyšší rychlost ale přináší také nová bezpečnostní rizika.

Průběžné cykly vydávání verzí zkracují dobu mezi rozhodováním o návrhu a produkčním nasazením, což zvyšuje pravděpodobnost, že se do produkčních prostředí zavádějí slabá místa, mezi které patří:

• Slabé stránky návrhu aplikací
• Ohrožené závislosti
• Chyby konfigurace
• Chyby automatizace infrastruktury
• Špatná správa tajemství nebo hygiena.

Riziko DevOps

Moderní prostředí DevOps rozšiřují prostor pro útoky napříč vývojovými, kanály a produkčními systémy. Nástroje DevOps, jako jsou úložiště zdrojového kódu, kanály a systémy automatizace, jsou vysoce hodnotné cíle pro útočníky.

Pokud je škodlivý kód zaveden dříve, může projít stávajícími kontrolami zabezpečení a dosáhnout produkčních systémů.

Mezi běžné cíle útoku patří:

• Vkládání škodlivého kódu do artefaktů sestavení.
• Ohrožení identit vývojářů nebo účtů služeb
• Přístup k produkčním datům nebo jejich exfiltrování.

Útočníci často cílí na vlastní aplikace a vývojová prostředí, aby získali přístup k:

• Citlivá data organizace nebo zákazníka.
• Proprietární obchodní logika a duševní vlastnictví.
• Produkční infrastruktura skrze kompromitované vývojové systémy.
• Navazující zákazníci prostřednictvím kompromitace softwarového dodavatelského řetězce

Potenciální rizika zabezpečení jsou shrnuta v následujícím diagramu:

Riziko aplikací a vývoje

Úlohy aplikací můžou být ohroženy slabými místy zavedeným během vývoje nebo ohrožením infrastruktury používané k jejich sestavení a nasazení.

Risk	Cíl	Potenciální výsledek
Návrh/implementace aplikace	Problémy se zabezpečením zavedené během návrhu nebo vývoje můžou vystavit úlohy technikám útoku, jako jsou: - Nesprávné ověření vstupu – Nezabezpečené ověřování nebo logika autorizace - Slabá nebo nesprávně implementovaná kryptografie - Vystavení citlivých dat prostřednictvím aplikační logiky	Tyto slabé stránky můžou útočníkům umožnit: – Přístup k datům aplikace nebo manipulace s nimi - Provádění neautorizovaných operací - Udržovat trvalý přístup prostřednictvím vložených logických chyb.
Vývojová infrastruktura / automatizace	Útoky můžou cílit: – Úložiště zdrojového kódu – Kanály sestavení – Automatizace nasazení – Šablony infrastruktury jako kódu (IaC) – Vývoj koncových bodů nebo identit služeb	Kompromitace může útočníkům umožnit: - Vložení škodlivého kódu do artefaktů sestavení – Úprava konfigurací nasazení - Zachování trvalého přístupu prostřednictvím implantované logické chyby – Získejte přihlašovací údaje nebo tajné kódy používané v produkčních prostředích.
Vývojový dodavatelský řetězec softwaru	Aplikace se běžně spoléhají na: – Knihovny třetích stran – Opensourcové balíčky – Image kontejnerů – Služby platformy	Ohrožení zabezpečení nebo škodlivý kód zavedený prostřednictvím těchto závislostí můžou ovlivnit: – Organizační produkční úlohy – Prostředí zákazníka nebo partnera

Integrace zabezpečení do vývojových procesů snižuje pravděpodobnost, že se tato rizika rozšíří do produkční verze.

Posun vlevo

Shift left je přístup bezpečnostního inženýrství, který začleňuje zabezpečení do dřívějších fází životního cyklu vývoje.

Místo ověřování zabezpečení později v procesu je organizace vloží do:

• Vize
• Design
• Vývoj
• Operations

Tím se snižují náklady na nápravu a rizika expozice.

Aby tento přístup podporovaly, měly by organizace"

• V rané fázi procesu používejte strukturované osvědčené postupy, jako je SDL (Security Development Lifecycle), a ne pozdě, když jsou problémy nákladné a obtížně se opravují.
• Chcete-li tento přístup udržet, integrujte zásady správného řízení, rizika a dodržování předpisů (GRC) do strategie vývoje.

Co je DevSecOps?

DevSecOps poskytuje přístup k posunu doleva rozšířením DevOps a vložením zabezpečení do všech fází životního cyklu vývoje softwaru – od nápadu od vzniku návrhu, vývoje a provozu.

• V tradičních přístupech k vývoji se ověřování zabezpečení často provádělo jako konečná brána kvality před vydáním. To způsobilo zpoždění, zvýšilo náklady na nápravu a umožnilo, aby zranitelnosti přetrvávaly až do pozdní fáze životního cyklu.

• DevSecOps přesouvá zabezpečení dříve a průběžně ho vkládá do vývojových a provozních procesů.

• DevSecOps snižuje třecí plochy mezi vývojovými, provozními a bezpečnostními týmy, spojuje je se sdílenými cíli rychlosti inovací, spolehlivosti a odolnosti zabezpečení a umožňuje týmům včas a nepřetržitě řešit nejdůležitější problémy.

• DevSecOps integruje zabezpečení do:

  • Architektonický návrh
  • Implementace aplikace
  • Automatizace infrastruktury
  • Nasazení a provozní procesy

Benefits

DevSecOps umožňuje vývojovým, bezpečnostním a provozním týmům:

• Identifikujte a opravte problémy dříve v životním cyklu.
• Snižte expozici v produkčním prostředí.
• Udržujte rychlost doručování při správě rizik.

Zabezpečení se stává součástí toho, jak se software sestavuje a dodává, místo kontroly použité po doručení.

Životní cyklus zabezpečených inovací

Inovace obvykle prochází dvěma fázemi životního cyklu:

Etapa	Podrobnosti
Inkubace nápadů	Funkce je navržena, implementována a ověřena pro počáteční použití v produkčním prostředí. Začíná novým nápadem.
Počáteční vydání	První produkční verze splňuje minimální kritéria produktu pro bezpečné použití produktu. - Vývoj: Funkce splňují minimální obchodní požadavky. - Zabezpečení: Možnosti splňují zákonné požadavky na dodržování předpisů, zabezpečení a bezpečnost pro použití v produkčním prostředí. - Operace: Funkce splňují minimální požadavky na kvalitu, výkon a možnosti podpory, aby byly produkčním systémem.

Po počátečním vydání se vývoj stává iterativním vzhledem k tomu, jak se úlohy vyvíjejí:

• Změna tolerance rizika
• Požadavky na aplikace a vyspělost
• Zákonné povinnosti
• Podmínky hrozeb

Integrace zabezpečení do vývoje

Tradiční přístupy k vývoji ověřují zabezpečení v pozdní fázi životního cyklu jako konečnou bránu před vydáním po dokončení návrhu a implementace. V moderních vývojových prostředích oddalování validace zvyšuje:

• Složitost zranitelnosti
• Náklady na nápravu
• Provozní zpoždění a přerušení
• Zvýšené riziko vystavení aktivnímu využívání

DevSecOps integruje zabezpečení nepřetržitě během vývoje a provozu, aby se vyřešily problémy dříve, snížily riziko a zlepšily konzistenci.

Klíčové postupy

Zabezpečení musí být vloženo do stávajících vývojových procesů, aby byly efektivní, škálovatelné a udržitelné. Měla by být integrovaná přímo do toho, jak jsou aplikace navržené, sestavené, nasazené a provozované, neimplementované v samostatném nebo paralelním pracovním postupu. Naše doporučení:

• Mapování komplexních pracovních postupů od nápadu prostřednictvím vývoje, nasazení a průběžných operací
• Definování jasných rolí, nástrojů a zodpovědností za zabezpečení v každé fázi životního cyklu
• Vytvoření konzistentních nápravných cest pro chyby zabezpečení, vady a problémy s návrhem

Přizpůsobte si postupy zabezpečení na základě rizika úloh. Důležité obchodní aplikace vyžadují větší rigorii, zatímco scénáře s nižším rizikem mohou postupovat podle zjednodušených přístupů.

Minimálně se ujistěte, že:

• Identifikujte fáze, lidi a technologie, které jsou součástí vašeho životního cyklu vývoje.
• Definujte, jak se aktivity zabezpečení integrují do jednotlivých fází, a ne jako samostatné kontrolní body.
• Stanovte procesy pro zpracování hlavních změn i běžných oprav v průběhu životního cyklu.

Automatizace zabezpečení do vývoje a nasazení

Automatizace je nezbytná k konzistentnímu a škálovatelnému vynucování zabezpečení napříč vývojem a provozem.

• Integrujte ovládací prvky zabezpečení a nástroje přímo do kanálů CI/CD.
• Automatizujte klíčové aktivity, jako je modelování hrozeb, prohledávání kódu, ověřování a vynucování zásad.
• Použití infrastruktury jako kódu (IaC) k povolení opakovatelných a zabezpečených nasazení

Základy platformy, jako jsou cílové zóny Azure, můžou tento přístup podporovat

Základy platforem, jako jsou Azure cílové zóny můžou tento přístup podporovat tím, že poskytují standardizované vzory pro integraci zabezpečení, zásad správného řízení a DevOps.

Očekávané výsledky

Organizace, které přejdou z DevOps na DevSecOps, můžou:

• Snižte pravděpodobnost, že do produkčních úloh budou zavedeny zranitelnosti.
• Omezení schopnosti útočníků zneužít vývojovou infrastrukturu nebo automatizaci
• Zlepšení odolnosti aplikací za účelem vývoje technik útoku
• Podpora zákonných a organizačních požadavků na dodržování předpisů
• Zajištění rychlosti inovací bez zvýšení provozního nebo bezpečnostního rizika

Tipy pro navigaci na cestě

Přijetí DevSecOps vyžaduje organizační a kulturní změny.

Změny v oblasti vzdělávání a kultury

Jedná se o kritické kroky v rané fázi. Tým, který máte, musí rozvíjet nové dovednosti a přijímat nové perspektivy, abyste porozuměli modelu DevSecOps.

Změna vzdělání a kultury trvá čas, zaměření, sponzorství vedení a pravidelná následná akce, která jednotlivcům pomůže plně pochopit a vidět hodnotu změny.

Zásadní změny firemní kultury a dovedností se někdy mohou výrazně dotknout profesní identity jednotlivců, což může vyvolat silný odpor. Je důležité pochopit a vyjádřit proč, co a jak se mění pro každého jednotlivce a jejich situaci.

Změna nějakou dobu trvá

Pokud se váš tým může přizpůsobit důsledkům provádění věcí novými způsoby, můžete se rychle přesunout. Týmy musí během transformace provádět své stávající úlohy.

Je důležité pečlivě určit prioritu toho, co je nejdůležitější, a spravovat očekávání o tom, jak rychle se tato změna může stát.

Zaměření na postupný přístup, v němž jsou nejprve řešeny nejdůležitější a základní prvky, je pro vaši organizaci přínosné.

Změna zavádí (dočasné) tření

Všechny nové technologie, metodologie a další změny přinášejí tření a nejasnosti. Je důležité se zaměřit na zdravé tření, které řídí kritické myšlení, aby se snížilo riziko a zároveň se vyhnulo nezdravým třením, které zpomaluje procesy s omezenou výhodou nebo snížením rizika.

Omezené prostředky

Výzvou, kterou organizace obvykle čelí dříve, je najít talent a dovednosti v oblasti vývoje zabezpečení i aplikací.

Jakmile organizace začnou efektivněji spolupracovat, mohou objevit skryté talenty, například vývojáře s bezpečnostním zaměřením nebo odborníky na zabezpečení se zkušenostmi s vývojem.

Probíhající směny

Aplikace se rychle mění. Kromě nových funkcí se technická definice a složení aplikace zásadně mění díky zavedení technologií, jako je cloud, bezserverová architektura a AI.

Tento posun mění vývojové postupy, zabezpečení aplikací a dokonce umožňuje nedeveloperům vytvářet aplikace.

Zvažte model SRE.

Některé implementace DevSecOps kombinují provozní a bezpečnostní odpovědnosti do role SRE (Site Reliability Engineer).

I když takový model může fungovat, je to často extrémní změna ze stávající podnikové kultury a postupů.

Pokud uvažujete o modelu SRE, doporučujeme začít vložením zabezpečení do DevOps pomocí praktických rychlých výher a přírůstkového pokroku popsaného v těchto doprovodných materiálech, abyste měli jistotu, že máte dobrou návratnost investic (ROI) a splňujete okamžité potřeby.

Tím se postupně přidají odpovědnosti za zabezpečení vašim provozním a vývojovým pracovníkům, což týmy přesune blíž ke koncovému stavu SRE.

Další kroky

Seznamte se s osvědčenými postupy zabezpečeného vývoje.