Směrnice Cyber Resilience Act (CRA)

[unicast]

Cyber Resilience Act postupně vstupuje v platnost, zatím výrobci musejí jen hlásit známé zranitelnosti svých výrobků, od 11. prasince 2027 budou výrobci muset dokladovat splnění požadavků CRA, zákonodárce si to představuje asi podobně, jako se dnes dokladuje bezpečnost elektrická cetrifikátem CE. Sám si v reálu nedovedu představit, jak by to mohlo smysluplně fungovat, protože ani certifikace zdrojového kódu (pomíjím schopnost kohokoli si jej celý přečíst a pochopit jej) nezajistí, že nebude nějaká zranitelnost například v knihovních funkcích nebo že ten software nebude zkompilován "cinknutým" kompilátorem nebo slinkován "cinknutým" linkerem, takže prakticky to bude zase shitshow různých dalších certifikátů o ničem, jako tomu je třeba s ISO 27001 apod.

Co je podstatné pro nás, to je skutečnost, že to dopadne i na výrobce měničů a dost možná i složitějších MPP trackerů, ve kterých je nějaký software. Pokud něco neřeší logiku pomocí pár relé, tranzistorů nebo obvodů řady 74xxx, tak je v tom nějaký mikrokontrolér (jednočip. PIC) a jakmile je v něčem mikrokontrolér, je v tom i software. Jako první bude na ráně samozřejmě Deye. Že je hardware sám o sobě skvělý a konkurenční produkty jsou oproti tomu inferiorní, to nikoho nezajímá (to samé jsem mimochodem před pár lety zažil u síťového hardware od Huawei, naprosto identický případ). Vyplývá z toho jeden podstatný závěr -- bude asi rozumné koupit si do zásoby měniče "svých snů", případně se prodají někde na bazoši apod.



A abych nezapomněl, něco podobného čeká i smaltované bojlery, od 1.1.2027 se budou smět prodávat pouze nerezové nebo na přechodnou výjimku takové, které během roku 2026 získaly jakýsi certifikát, že neobsahují hafnium.

[glottis]

My, jako firma rodukujici software, to uz leta delame tak jak by to mel delat kazdy ... k nasemu software vydavame SBOM ... software bill of material. Z ceho se to sklada, z jakych knihoven. K tem vetsinou vychazi updaty a pripadne CVE s chybami.

Tohle je treba pohled na SBOM jednoho naseho produktu (i ten seal je teda nas produkt prave na reseni techto veci)

https://seal.sonpo.cz/p/3R6N4RacaEurfV2 ... m-projects

Pri buildu verze vznikne sbom, to se zanalyzuje a vypadnou zranitelsnosti. Bud tam nic neni nebo tam neco je a to je bud relevantni a nebo to zkusime upadatovat a vydat novou verzi. Kdyby nekdo zjistil chybu v nasel vlastnim kodu, muzeme to taky takto vydat klidne jako CVE.

Stejne by to melo fungovat i pro zarizeni, v kterych je software. Dnes neni uplne problem u mensiho firmware to predhodit treba gpt astra a nechat si to prozkoumat. Nejhorsi je prave nedostupnost toho SBOMu, protoze vsichni pouzivaj nejake knihovny a nikdo nevi z ceho co je a co tam ceka za bubaka.

[Kajap]

stačí zkrátit: “nikdo nevi z ceho co je”

S AGI bude (az bude) jeste sranda.

[Mex]

My, jako firma rodukujici software, to uz leta delame tak jak by to mel delat kazdy ... k nasemu software vydavame SBOM ... software bill of material. Z ceho se to sklada, z jakych knihoven. K tem vetsinou vychazi updaty a pripadne CVE s chybami.
...

Je to samozřejmě vaše věc a nic mi do toho není.
Ale podle mě tohle má smysl možná u něčeho, na čem je daný produkt fakt závislý.
Může být, že se v daném SW z nějaké velké knihovny používají třeba 1 nebo 2 funkce.
A pokud se pak v té knihovně objeví nějaká zranitelnost (která je třeba někde úplně jinde a v daném SW vůbec není použitá), tak případně rozbít funkční SW a způsobit výpadek nějakým zbytečným upgradem, to mně nepřipadá jako optimální řešení.
A zákazník tohle není schopný posoudit.

Podle mě by měl za funkčnost celku ručit dodavatel toho systému. Ten si má hlídat potenciální zranitelnosti a vyhodnocovat, jestli se to jeho SW týká nebo ne.

U auta taky předpokládám, že svolávačku při nějakém problému třeba airbagu nebo brzd udělá výrobce auta.
A ne že výrobce auta dá zákazníkovi seznam dílů, co tam jsou použité, a zákazník aby si sám hlídal, jestli třeba Takata neoznámí, že nějaká série airbagů má problém, nebo Brembo, že mají problém brzdy, nebo X, že Y má problém atd.

[glottis]

Nepochopil jsi to nebo jsem neřekl vše. Výrobce dodává s verzí sbom. Ten se vyhodnocuje v čase na známé zranitelnosti. Ty výrobce posuzuje podle toho co píšeš. Možná to vůbec zranitelné není. To vyhodnotí a vydá druhý dokument co to zohledňuje. A spojí se to s sbom a zákazník vidí, že je potřeba update a nebo ne. Výrobci to ulehčí život s vyhodnocením rizik a jestli je potřeba dělat novou verzi a zákazníkovi jestli má dělat update aplikace, pokud je nová verze.

[glottis]

Zákazník si samozřejmě žádné knihovny nemění. To je blbost. Ale je to o transparentnosti. Nemůže ti tajit že tam je pět let stará díra v log4j.

[Mex]

Nepochopil jsi to nebo jsem neřekl vše. Výrobce dodává s verzí sbom. Ten se vyhodnocuje v čase na známé zranitelnosti. Ty výrobce posuzuje podle toho co píšeš. Možná to vůbec zranitelné není. To vyhodnotí a vydá druhý dokument co to zohledňuje. A spojí se to s sbom a zákazník vidí, že je potřeba update a nebo ne. Výrobci to ulehčí život s vyhodnocením rizik a jestli je potřeba dělat novou verzi a zákazníkovi jestli má dělat update aplikace, pokud je nová verze.

Asi to moc nechápu. Ale samozřejmě nemusím chápat všechno.

Podle mě by správný postup byl, že to hlídá výrobce. A objeví-li se problém, tak osloví zákazníka s tím, že je třeba okamžitě/v nejbližší době/příležitostně udělat upgrade (podle závažnosti objeveného problému).

Nekvalifikovanému zákazníkovi je nějaký sbom ku prdu.
Je to jen případné rozmělnění odpovědnosti, kdy dodavatel pak v případě nějakého excesu může říct "ale to jste si měli hlídat sami, máte přece sbom, a neznalost dokumentace neomlouvá".

Ale znovu: nic mi do toho není a nemusím chápat všechno.
Byla to jenom poznámka.

[glottis]

Ale vzdyt to pisu ze to hlida vyrobce. SBOM verejne se dava z duvodu transparentnosti, aby sto to mohl kdokoliv overit. Softwarovy dodavatele pro USA meli povinost sbom dodavat. Ted se to nejak zmirnilo. U nas z nejaek firmy vyrazit sbom je neresitelny problem. Hlavne pro to, ze ho nemaji vubec. A nechci si pak vubec predstavovat, jak resi aktualizace.

A nebo to mzue byt i jinak. Dodali jsme software do banky. Oni si nainstalovali na server qualys. Software co sanuje stroj a zjistuje co tam je. Zjisti to i knihovny v aplikaci. Je pro nas jednodusi jim dat SBOM s vyjadrenim, nez jim kazdy tyden po scanu vysvetlovat, proc tam mame tuhle verzi knihovny, v ktere je zranitelnost. Pritom nase apka tu funkcionalitu nepouziva a je ok.

[unicast]

Určitě to je krok pro zlepšení stávající situace, ale všeobjímající řešení to samozřejmě není.

Další věc jsou programy pro jednočipy, kde vývojáři prostě fungují jinak, než u velkých projektů. Budou si nejspíš těžko zvykat. Stejně tak hobby producenti opensource apod.

[ChlapeczDediny]

Cyber Resilience Act postupně vstupuje v platnost,..., takže prakticky to bude zase shitshow různých dalších certifikátů o ničem, jako tomu je třeba s ISO 27001 apod.

Víš, jak se zvyšuje HDP? Zvyšováním cen čehokoliv anebo zavedením nových předpisů, např. helmy na kolo nebo mopedy.