Buďme upřímní ohledně současného stavu vývoje softwaru: všichni postupujeme příliš rychle. Snaha o kontinuální integraci a kontinuální nasazení (CI/CD) obrátila tradiční cyklus vydávání naruby. Dříve jsme měli na konci projektu "bezpečnostní fáze" – několik týdnů, kdy tým prozkoumával kód před jeho spuštěním. Ale ve světě každodenního nasazování a mikroslužeb je tento starý model mrtvý. Pokud čekáte až do konce s testováním bezpečnosti, nejenže zpožďujete spuštění; v podstatě posíláte do světa loterijní tiket a doufáte, že výhercem nebude hacker.
Zde přichází na řadu DevSecOps. Myšlenka je jednoduchá: "posunout doleva." Přesuňte zabezpečení z konce pipeline na začátek. Ale tady je ta část, kterou lidé obvykle přehlížejí – posunout doleva je těžké. Většina týmů jen hodí několik nástrojů pro statickou analýzu (SAST) do své pipeline, získá 5 000 False Positives a pak zprávy zcela ignoruje. Statické nástroje jsou skvělé pro nalezení chybějícího středníku nebo známé zastaralé funkce, ale nemohou vám říct, zda je vaše obchodní logika chybná nebo zda specifická kombinace cloudových konfigurací vytváří zadní vrátka do vaší databáze.
Abyste skutečně zabezpečili moderní pipeline, potřebujete něco, co se chová jako lidský útočník, ale škáluje se jako stroj. Zde se hodí cloudové Penetration Testing. Integrací dynamických, cloud-nativních bezpečnostních hodnocení přímo do vašeho DevSecOps workflow přestanete hádat, zda je váš kód bezpečný, a začnete to dokazovat.
Zásadní tření mezi rychlostí a bezpečností
Pokud jste strávili nějaký čas řízením vývojového týmu, znáte to napětí. Vývojáři jsou hodnoceni podle rychlosti – kolik funkcí dodají a jak rychle to udělají. Bezpečnostní týmy jsou hodnoceny podle rizika – kolik děr dokážou zacelit. Když se tyto dva cíle střetnou, bezpečnost obvykle prohrává. Je běžné, že je bezpečnost vnímána jako "oddělení ne," skupina, která zasáhne v jedenáctou hodinu, aby zablokovala vydání kvůli zranitelnosti, která měla být odhalena před třemi měsíci.
Problém není v nedostatku vůle; je to nedostatek nástrojů, které by odpovídaly rychlosti cloudu. Tradiční Penetration Testing je často manuální, periodická událost. Najmete si firmu, ta stráví dva týdny útokem na vaše staging prostředí a předá vám 60stránkový PDF. Než dočtete desátou stránku, kód, který testovali, byl již pětkrát aktualizován. Zpráva je zastaralá ještě předtím, než je nahrána do Jiry.
Cloudové Penetration Testing mění tuto dynamiku. Místo jednorázové události se stává kontinuální službou. Protože je hostována v cloudu, lze ji spouštět a vypínat tak, aby odpovídala vašemu prostředí. Umožňuje vám simulovat reálné útoky proti vaší skutečné cloudové infrastruktuře – nejen její sanitizované verzi – aniž byste museli kupovat drahý hardware nebo trávit týdny konfigurací VPN pro dodavatele třetí strany.
Proč statická analýza nestačí
Mnoho organizací si myslí, že mají "DevSecOps", protože používají nástroj, který skenuje GitHub na přítomnost hesel napevno zadaných v kódu. I když je to nutné, je to jen základ. Static Analysis Security Testing (SAST) se dívá na kód v klidovém stavu. Je to jako kontrolovat plány domu, abyste zjistili, zda mají dveře zámky.
Dynamic Analysis (DAST) a Penetration Testing jsou jako skutečný pokus o vykopnutí dveří. Testují aplikaci za běhu. Nacházejí problémy, které se objeví pouze tehdy, když kód, server, databáze a konfigurace sítě interagují. Například nástroj SAST nemusí najít problém se způsobem, jakým vaše API zpracovává autentizační tokeny, ale Penetration Test rychle zjistí, že s těmito tokeny lze manipulovat a získat tak přístup k datům jiného uživatele.
Integrace cloudového Penetration Testing do CI/CD Pipeline
Cílem je, aby bylo zabezpečení neviditelné. Když je bezpečnostní testování bezproblémovou součástí pipeline, vývojáři s ním přestanou bojovat. Trikom je umístit různé typy testování do různých fází životního cyklu.
Fáze Pre-Commit a Build
V této fázi to berte zlehka. Zde žijí vaše lintery a nástroje SAST. Neděláte zde plnohodnotné Penetration Testy, protože trvají příliš dlouho a zabily by rychlost sestavení. Místo toho hledáte "nízko visící ovoce" – známé zranitelné knihovny nebo zjevné chyby v kódování.
Fáze Staging a QA
Toto je ideální místo pro cloudové Penetration Testing. Jakmile je kód nasazen do staging prostředí, které zrcadlí produkční prostředí, můžete spustit automatizované bezpečnostní hodnocení. Zde přichází na řadu platforma jako Penetrify. Místo čekání na dostupnost lidského testera pipeline spustí cloudový sken, který zkoumá běžné zranitelnosti (OWASP Top 10), testuje API endpointy a kontroluje nesprávně nakonfigurovaná cloudová oprávnění.
Pokud je nalezena kritická zranitelnost, pipeline může automaticky "selhat" sestavení. Vývojář obdrží upozornění okamžitě, dokud je kontext jeho změn ještě čerstvý v jeho mysli. Oprava chyby pět minut po jejím napsání je exponenciálně levnější a rychlejší než její oprava o tři týdny později poté, co se dostala do produkce.
Produkční fáze (kontinuální monitoring)
Zabezpečení nekončí nasazením. Nové zranitelnosti (Zero Day) jsou objevovány každý den. Systém, který byl v úterý bezpečný, může být ve středu zranitelný, protože byla nalezena nová chyba v běžné knihovně Java. Kontinuální cloudové Penetration Testing monitoruje vaše živé prostředí a zajišťuje, že nové hrozby jsou identifikovány v reálném čase.
| Fáze | Typ testování | Cíl | Příklad nástroje |
|---|---|---|---|
| Vývoj | SAST / Linting | Odchytit chyby syntaxe a knihoven | SonarQube, Snyk |
| Build | SCA (Software Composition Analysis) | Najít zranitelné závislosti | Dependabot |
| Staging | Cloud Pentesting / DAST | Najít chyby za běhu a logické chyby | Penetrify |
| Produkce | Continuous Monitoring / RASP | Detekovat živé útoky/nové CVE | Penetrify, CloudWatch |
Posun za hranice PDF: Akční náprava
Jedním z největších selhání v tradičním zabezpečení je doručení "Bezpečnostní zprávy". Obrovské PDF je místo, kde bezpečnostní poznatky umírají. Vývojáři nechtějí číst vyprávění o tom, jak tester našel SQL Injection; chtějí ticket v Jiře s přesným endpointem, payloadem použitým ke spuštění chyby a návrhem, jak ji opravit.
Cloud-nativní platformy to řeší přímou integrací do pracovního postupu vývojáře. Když cloudový Penetration Test identifikuje zranitelnost, data by měla proudit přímo do issue trackeru.
Anatomie užitečného bezpečnostního nálezu
Aby byl nález akční, potřebuje čtyři věci:
- Důkaz: Přesný požadavek a odpověď, které dokazují existenci zranitelnosti. Žádné "máme podezření, že by to mohl být problém."
- Závažnost: Realistické skóre rizika založené na skutečném prostředí, nejen generické skóre CVSS. (např. zranitelnost "High" na serveru bez přístupu k internetu je ve skutečnosti riziko "Low").
- Umístění: Konkrétní řádek kódu nebo nastavení konfigurace cloudu, které je za to zodpovědné.
- Oprava: Jasný příklad kódu nebo podrobný návod k nápravě problému.
Když používáte cloudové řešení, jako je Penetrify, tento proces je automatizovaný. Platforma vám neříká jen to, že máte zranitelnost "Cross-Site Scripting" (XSS); poskytuje vám technické podrobnosti potřebné k jejímu odstranění, aniž byste potřebovali tříhodinovou schůzku mezi vedoucím zabezpečení a vedoucím vývojářem.
Řešení běžných slepých míst v zabezpečení cloudu
Mnoho týmů se domnívá, že protože používají AWS, Azure nebo GCP, "poskytovatel cloudu" se stará o zabezpečení. Toto je nebezpečné nepochopení Modelu sdílené odpovědnosti. Poskytovatel zabezpečuje "cloud" (fyzická datová centra, hypervisory), ale vy jste zodpovědní za zabezpečení "v cloudu" (váš OS, vaše data, vaše síťová pravidla).
Zde jsou nejčastější slepá místa, která cloudový Penetration Testing odhaluje:
1. Nesprávné konfigurace S3 Bucket a Blob Storage
Stává se to každý týden: společnost omylem ponechá úložný bucket otevřený pro veřejnost. Statické nástroje mohou zkontrolovat zásady, ale Penetration Test se ve skutečnosti pokusí o přístup k datům z veřejného internetu. Dokazuje, zda data skutečně unikají, nebo zda jsou oprávnění skutečně neprodyšná.
2. Nadměrně privilegované role IAM
Ve spěchu, aby věci fungovaly, vývojáři často přiřadí AdministratorAccess funkci Lambda nebo instanci EC2. To je dar pro útočníky. Pokud hacker najde malou zranitelnost ve vaší aplikaci, může použít tuto nadměrně privilegovanou roli k laterálnímu pohybu v celém vašem cloudovém účtu. Cloudový Penetration Testing simuluje tento "laterální pohyb", aby vám ukázal, jak přesně by útočník mohl přeskočit z veřejného webového serveru do vaší soukromé zákaznické databáze.
3. API Shadow Endpoints
Jak projekt roste, vývojáři často vytvářejí "testovací" nebo "debug" endpointy (např. /api/v1/debug_user_data) a zapomenou je odstranit. Tyto endpointy často obcházejí autentizaci. Protože nejsou zdokumentovány v oficiální specifikaci API, vaše standardní testy je minou. Komplexní cloudový Penetration Test prochází aplikaci, aby našel tyto "shadow" endpointy dříve, než to udělá aktor.
4. Selhání správy hesel
Pevné zakódování API klíčů je klasická chyba, ale existují i subtilnější. Například ukládání hesel do proměnných prostředí, které jsou protokolovány do centrálního systému protokolování (jako je CloudWatch nebo ELK), zpřístupňuje tato hesla komukoli s přístupem pro čtení protokolů. Penetration Testing hledá tyto úniky ve skutečném běhovém prostředí.
Uvedení do praxe: Průvodce integrací krok za krokem
Pokud chcete transformovat svůj pipeline, nesnažte se dělat všechno najednou. Přetížíte svůj tým a oni najdou způsoby, jak bezpečnostní kontroly deaktivovat. Postupujte podle tohoto fázovaného přístupu.
Fáze 1: Základní linie (týdny 1-4)
Začněte implementací základního SAST a SCA (Software Composition Analysis) do svého build pipeline. Zvykněte své vývojáře na to, že ve svých PR vidí bezpečnostní varování. V této fázi nastavte tyto nástroje na "Pouze varování" – zatím build neblokujte. Chcete shromáždit data o tom, kolik False Positives získáváte, a vyladit pravidla.
Fáze 2: Staging Gate (týdny 5-8)
Zaveďte cloudový Penetration Testing do svého staging prostředí. Připojte platformu, jako je Penetrify, k vaší staging URL. Spusťte úplné skenování pokaždé, když je nasazen release candidate.
Během této fáze se zaměřte na zranitelnosti "Critical" a "High". Vytvořte pravidlo: Jakákoli kritická zranitelnost nalezená ve staging automaticky blokuje nasazení do produkce. Zde se "Sec" v DevSecOps stává skutečností.
Fáze 3: Zpětnovazební smyčka (týdny 9-12)
Integrujte svá zjištění zabezpečení přímo do Jira nebo GitHub Issues. Nastavte si dashboard, který sleduje "Time to Remediate" (dobu potřebnou k nápravě). Pokud trvá dva týdny, než opravíte kritickou chybu, váš proces je stále příliš pomalý. Cílem je zkrátit tuto dobu na hodiny nebo několik dní.
Fáze 4: Průběžné zajištění (Ongoing)
Přejděte na model průběžného testování. Místo skenování pouze při nasazení naplánujte denní nebo týdenní automatizované Penetration Testing napříč všemi prostředími. Tím se zachytí "configuration drift" – když někdo ručně změní nastavení bezpečnostní skupiny v AWS konzoli, aby "vyřešil problém", a zapomene ho změnit zpět, čímž nechtěně otevře port do celého internetu.
Porovnání tradičního Pentestingu vs. Cloud-Native Continuous Testing
Pro pochopení, proč je tento posun nutný, je užitečné podívat se na oba modely vedle sebe. Většina společností stále uvízla ve sloupci "Tradiční", i když používají cloudovou infrastrukturu.
| Funkce | Tradiční Penetration Testing | Cloud-Native Continuous Testing (např. Penetrify) |
|---|---|---|
| Frekvence | Roční nebo čtvrtletní | Průběžné / Při každém nasazení |
| Výstup | Rozsáhlá PDF zpráva | API integrace / Jira tickety |
| Infrastruktura | Ruční nastavení, VPN, White-listing | Cloud-native, škálování na vyžádání |
| Zpětná vazba | Týdny nebo měsíce | Minuty nebo hodiny |
| Cenový model | Velké kapitálové výdaje (projektově) | Předvídatelné provozní náklady (předplatné) |
| Rozsah | Statický snímek bodu v čase | Dynamický pohled na vyvíjející se prostředí |
| Zkušenost vývojáře | "Bezpečnostní tým nás blokuje" | "Mám ticket na opravu chyby" |
Řešení problému s "False Positives"
Nejčastější stížnost vývojářů ohledně bezpečnostních nástrojů je: "Je to jen False Positive." Když nástroj křičí "Zranitelné!" a vývojář stráví čtyři hodiny dokazováním, že je to ve skutečnosti bezpečné, ztratí v nástroj důvěru. Jakmile je tato důvěra pryč, začnou ignorovat všechna upozornění, včetně těch skutečných.
Cloudový Penetration Testing tento problém snižuje, protože je založený na důkazech. Statický nástroj říká: "Tato funkce vypadá nebezpečně." Platforma pro Penetration Testing říká: "Odeslal jsem tento konkrétní payload do tohoto endpointu a server odpověděl s heslem administrátora."
Je těžké argumentovat se screenshotem vaší vlastní databáze, která je dumpována.
Žádný nástroj však není dokonalý. Pro správu False Positives v DevSecOps pipeline:
- Implementujte mechanismus "Suppress": Umožněte zkušeným vývojářům nebo vedoucím zabezpečení označit nález jako "False Positive" nebo "Risk Accepted", aby neblokoval budoucí buildy.
- Vylaďte své profily: Nespouštějte každý jednotlivý test při každém buildu. Používejte "Quick Scans" pro každý PR a "Deep Scans" pro týdenní releasy.
- Spolupracujte na "Proč": Když dojde k False Positive, využijte to jako moment k poučení. Proč si nástroj myslel, že se jedná o zranitelnost? Často jsou "False Positives" ve skutečnosti porušení "best practice", která nejsou okamžitě zneužitelná, ale stále představují špatnou bezpečnostní hygienu.
Role shody v moderní pipeline
Pro mnoho organizací není Penetration Testing jen dobrý nápad – je to zákonný požadavek. Ať už se jedná o SOC 2, HIPAA, PCI-DSS nebo GDPR, téměř každý regulační rámec vyžaduje "pravidelné bezpečnostní posudky".
Starý způsob, jak dosáhnout shody, byl "Compliance Theater". Jednou ročně byste si najali firmu, získali zprávu o úspěšném absolvování a uložili ji do složky pro auditora. Problém je v tom, že jste mohli být v pondělí v souladu a v úterý zcela kompromitováni.
DevSecOps mění shodu z události "bodu v čase" na "průběžný stav". Když používáte cloudovou platformu k provádění pravidelných Penetration Testů, generujete průběžnou auditní stopu. Místo toho, abyste auditorovi ukázali šest měsíců starý PDF, můžete mu ukázat dashboard každého provedeného skenu, každé nalezené zranitelnosti a přesně kdy byla každá z nich opravena.
Tím se proces auditu transformuje ze stresujícího shonu na jednoduchou demonstraci vašeho stávajícího workflow.
Běžné chyby při implementaci Cloud Security Testing
I se správnými nástroji je snadné zkazit implementaci. Zde jsou nejčastější úskalí, která jsem viděl:
1. Testování v produkci bez plánu
I když je testování produkce nezbytné, provádět ho bez strategie je recept na útok typu Denial of Service (DoS), který si sami způsobíte. Automatizované skenery mohou odesílat tisíce požadavků za sekundu. Pokud vaše omezení rychlosti není správně nakonfigurováno, vaše bezpečnostní skenování může způsobit pád vaší aplikace.
- Náprava: Začněte skenovat v stagingu. Při přechodu do produkce nejprve použijte "bezpečné" profily a postupně zvyšujte intenzitu.
2. Ignorování "lidského" elementu
Nástroje neopravují zranitelnosti; dělají to lidé. Pokud implementujete Penetrify, ale nedáte svým vývojářům čas nebo školení na opravu problémů, které najde, právě jste vytvořili velmi drahý seznam problémů, které se rozhodnete ignorovat.
- Náprava: Vyčleňte čas na "Security Debt" v každém sprintu. Zacházejte s bezpečnostními chybami se stejnou prioritou jako s funkčními chybami.
3. Spoléhání se pouze na automatizaci
Automatizace je skvělá pro hledání „známých neznámých“ – běžných chyb, chybných konfigurací a CVE. Ale má problémy s „neznámými neznámými“ – složitými chybami v obchodní logice. Například automatizovaný nástroj může najít SQL Injection, ale neuvědomí si, že uživatel může změnit cenu položky v nákupním košíku ze 100 $ na 1 $ úpravou skrytého pole.
- Řešení: Použijte hybridní přístup. Využijte cloudovou automatizaci pro 90 % běžných chyb a manuální expertní Penetration Testing pro vysoce rizikovou logiku a revize architektury.
4. Fragmentace Toolchainu
Některé týmy používají jeden nástroj pro SAST, další pro DAST, další pro konfiguraci cloudu a čtvrtý pro manuální testování. To vede k „Dashboard Fatigue“, kdy jsou bezpečnostní data rozptýlena na čtyřech různých platformách.
- Řešení: Centralizujte svá zjištění. Ať už prostřednictvím jednotné platformy, nebo odesláním všeho do jediného systému pro správu ticketů (jako je Jira), zajistěte, aby existoval jeden jediný zdroj pravdy o vašem bezpečnostním stavu.
Škálování zabezpečení pro středně velké a podnikové týmy
Jednou z největších překážek pro rostoucí společnosti je „Security Talent Gap“. Nemůžete najmout dostatek penetration testerů, abyste udrželi krok s týmem 50 vývojářů. Matematika prostě nefunguje.
Zde přichází na řadu efekt „Force Multiplier“ cloudového zabezpečení. Automatizací základního testování uvolníte několik svých bezpečnostních expertů, aby se mohli soustředit na vysoce hodnotnou práci. Místo toho, aby trávili den spouštěním základních skenů a psaním opakujících se zpráv, mohou trávit čas modelováním hrozeb, revizí architektury a hledáním složitých chyb, které by nástroj nikdy nenašel.
Pro poskytovatele služeb Managed Security Service Providers (MSSP) je cloudová platforma ještě důležitější. Umožňuje jim škálovat jejich nabídky napříč desítkami klientů, aniž by museli ručně konfigurovat nové testovací prostředí pro každého zákazníka. Mohou nasazovat standardizované testovací profily, monitorovat více klientů z jedné konzole a poskytovat vyšší úroveň služeb za nižší cenu.
FAQ: Cloud Penetration Testing v DevSecOps
Otázka: Zpomalí automatizovaný cloud Penetration Testing můj CI/CD pipeline? Odpověď: Může, pokud to uděláte špatně. Klíčem je být strategický. Nespouštějte úplný, hloubkový Penetration Test při každém commitu. Používejte rychlé, cílené skeny pro PR a vyhraďte si komplexní, časově náročné skeny pro staging prostředí nebo noční build.
Otázka: Potřebuji stále lidské penetration testery, pokud používám automatizovanou platformu? Odpověď: Ano. Automatizace je fantastická pro hledání běžných zranitelností a zajištění, že nedojde k žádným regresím. Lidé jsou však stále lepší v hledání složitých chyb v logice a „řetězení“ malých zranitelností dohromady k dosažení závažného narušení. Nejlepší strategií je „hybridní“ model: automatizace pro nepřetržité pokrytí a lidé pro periodické hloubkové analýzy.
Otázka: Je bezpečné spouštět Penetration Testy proti cloudovému prostředí? Odpověď: Obecně ano, za předpokladu, že dodržujete pravidla svého poskytovatele cloudu. AWS, Azure a GCP mají specifické zásady týkající se Penetration Testing. Většina automatizovaných nástrojů je navržena tak, aby fungovala v rámci těchto pokynů. Vždy se však ujistěte, že testujete prostředí, která vlastníte, a máte řádné oprávnění.
Otázka: Jak se cloud Penetration Testing liší od skenování zranitelností? Odpověď: Skenování zranitelností je jako kontrolní seznam – hledá známá čísla verzí softwaru se známými chybami. Penetration Testing je aktivní pokus o zneužití těchto chyb. Skener říká: „Máte starou verzi Apache, která může být zranitelná.“ Penetration Test říká: „Použil jsem tuto zranitelnost Apache k získání shellu na vašem serveru a přečetl jsem vaše proměnné prostředí.“
Otázka: Jak mám zvládnout „šum“ příliš mnoha bezpečnostních upozornění? Odpověď: Stanovte priority na základě dosažitelnosti. „Kritická“ zranitelnost v knihovně, která ve skutečnosti není volána vaším kódem, má „Nízkou“ prioritu. Zaměřte se na zranitelnosti, které jsou přítomny v útočné cestě – částech vaší aplikace, které jsou skutečně vystaveny internetu.
Souhrnný kontrolní seznam pro vaši DevSecOps transformaci
Pokud jste připraveni posunout se směrem k bezpečnějšímu cloudovému pipeline, použijte tento kontrolní seznam, abyste mohli začít:
- Auditujte svůj současný pipeline: Kde se nyní děje zabezpečení? Je na konci (Waterfall) nebo integrované (DevSecOps)?
- Implementujte SAST/SCA: Zajistěte základní skenování kódu a závislostí spuštěné ve vaší fázi sestavení.
- Nastavte zrcadlové prostředí: Zajistěte, aby vaše staging prostředí bylo skutečným odrazem produkčního prostředí (včetně cloudových oprávnění a síťových pravidel).
- Integrujte Cloud Pentesting: Připojte platformu jako Penetrify do svého staging prostředí.
- Definujte kritéria „Build-Fail“: Dohodněte se se svými zainteresovanými stranami, které úrovně zranitelností (např. Kritické/Vysoké) by měly zastavit nasazení.
- Připojte se ke sledování ticketů: Zajistěte, aby zjištění šla přímo k vývojářům v nástroji, který již používají.
- Vytvořte kadenci: Přejděte od testování „per-release“ k nepřetržitému, plánovanému testování.
- Naplánujte manuální revizi: Jednou ročně nebo po zásadní architektonické změně přiveďte lidské odborníky, aby otestovali logiku, kterou nástroje přehlédnou.
Závěrečné myšlenky: Zabezpečení jako nástroj, nikoli překážka
Konečným cílem integrace cloudového Penetration Testing do vašeho DevSecOps pipeline není jen „být zabezpečený“. Je to rychlejší postup s jistotou. Když víte, že každé jednotlivé vydání bylo automaticky šťoucháno, zkoumáno a napadeno cloudovou bezpečnostní platformou, přestanete se bát tlačítka „Deploy“.
Zabezpečení by nemělo být brána, která se otevírá a zavírá na konci projektu. Mělo by to být svodidlo, které vašim vývojářům umožňuje běžet plnou rychlostí, aniž by spadli z útesu. Přesunutím vašeho Penetration Testing do cloudu a jeho integrací přímo do vašeho pracovního postupu přestanete zacházet se zabezpečením jako s dodatečnou myšlenkou a začnete s ním zacházet jako s funkcí vašeho produktu.
Pokud vás už nebaví cyklus manuálních zpráv a bezpečnostních panik v pozdní fázi, je čas na modernizaci. Platformy jako Penetrify zpřístupňují a škálují profesionální bezpečnostní testování, což vám umožní najít mezery ve vaší infrastruktuře dříve, než to udělají ti špatní. Nečekejte na narušení, abyste si uvědomili, že ve vašem pipeline chybí kritický článek. Začněte se posouvat doleva ještě dnes.