Ievads
Bug bounty var atrast ievainojamību.
CVD var nodrošināt ceļu, pa kuru par to paziņot.
Pentests var pārbaudīt noteiktu scope.
Red team var atrast negaidītu ceļu līdz mērķim.
Neviena no šīm lietām nevar atgriezt atpakaļ dizaina lēmumu, kas jau tūkstošiem instalāciju izlaists produkcijā.
Ja produkts pēc noklusējuma ļauj pārāk plašas privilēģijas, tam trūkst server-side autorizācijas, secrets glabājas nepareizi, audit logs nav pieejams vai kritiska dependency ir nekontrolēta, ārējais pētnieks var palīdzēt šo problēmu atklāt.
Viņš nevar padarīt sākotnējo arhitektūru drošu pēc fakta.
Tāpēc ārējās drošības izpētes vieta ir:
papildu assurance slānis virs iekšējas secure-development sistēmas, nevis tās aizvietotājs.
Šis princips tagad parādās ne tikai labajā praksē, bet arvien skaidrāk arī regulējumā.
NIS2 21. pants prasa būtiskajiem un svarīgajiem subjektiem piemērotus un samērīgus kiberdrošības riska pārvaldības pasākumus, tostarp drošību informācijas sistēmu iegādē, izstrādē un uzturēšanā, vulnerability handling un disclosure, kā arī pasākumu efektivitātes novērtēšanu.6
Cyber Resilience Act savukārt sasaista produkta dizainu, izstrādi, ražošanu, atjaunināšanu un vulnerability handling vienā produkta dzīves ciklā.7
Svarīgā robeža uz 2026. gada 25. septembri: CRA galvenās produkta cybersecurity prasības, tostarp 13. pants un I pielikums, kopumā sāks piemēroties 2027. gada 11. decembrī. No 2026. gada 11. septembra jau piemērojas 14. panta ziņošanas prasības, bet tas nav tas pats, kas visu Secure-by-Design prasību agrāka piemērošana.7
CISA Secure-by-Design princips pārbīda atbildību uz ražotāju
CISA un starptautiskie partneri Secure-by-Design pieeju formulē ap trim principiem:
- ražotājs uzņemas atbildību par klienta drošības rezultātiem;
- nodrošina radikālāku caurskatāmību un atbildību;
- vadība veido organizācijas struktūru, kur drošība ir produkta prioritāte.4
Šīs vadlīnijas nav ES tiesību norma.
Tomēr tajās ir noderīgs atbildības princips:
drošības slogu pēc iespējas nevajag pārlikt uz klientu.
Secure-by-Default ir tā pati ideja konfigurācijas līmenī.
Ja svarīga drošības kontrole:
- ir izslēgta pēc noklusējuma;
- pieejama tikai dārgākā plānā;
- prasa sarežģītu manuālu hardening;
- nedod vajadzīgos audit logs bez piemaksas;
organizācija faktiski pārdod klientam arī savu drošības parādu.
CRA šo atbildības virzienu padara daudz konkrētāku
CRA I pielikuma I daļa paredz, ka produkti ar digitāliem elementiem ir jāprojektē, jāizstrādā un jāražo tā, lai tie nodrošinātu riskam atbilstošu kiberdrošības līmeni.7
Atkarībā no riska novērtējuma produktam cita starpā jābūt:
- tirgū bez zināmām ekspluatējamām ievainojamībām;
- ar secure-by-default konfigurāciju;
- ar iespēju ievainojamības novērst ar security updates;
- ar atbilstošu aizsardzību pret neatļautu piekļuvi;
- ar datu konfidencialitātes un integritātes aizsardzību.7
CRA 13. pants papildus liek cybersecurity risk assessment ņemt vērā jau:
- plānošanā;
- dizainā;
- izstrādē;
- ražošanā;
- piegādē;
- uzturēšanā.7
Tas ir daudz tuvāk produktinženierijas modelim nekā “izlaidīsim produktu un pēc tam reaģēsim uz CVE”.
Vulnerability handling ir Secure SDLC daļa, ne pēcapkalpošana
Te ir vēl viena svarīga robeža.
Dažās organizācijās product security sadalās šādi:
Šāda robeža var būt administratīvi ērta.
Tehniski tā bieži ir nepareiza.
Ja ārējs pētnieks atrod IDOR, findings nedrīkst beigties ar:
endpoint salabots.
Tam jānonāk atpakaļ pie jautājuma:
Kāpēc mūsu autorizācijas projektēšanas un testēšanas process pieļāva šo patternu?
Ja atrod deserialisation vulnerability:
kāpēc nedrošs deserialisation ceļš vispār bija pieejams?
Ja atrod hardcoded secret:
kāpēc build pipeline to neaizturēja?
NIST SSDF tieši savieno vulnerability response ar root-cause novēršanu, lai līdzīgas problēmas neatkārtotos.1
Tāpēc nobriedis Secure SDLC veido cilpu:
Ne tikai:
development team
→ builds product
security / PSIRT
→ handles vulnerabilities laterfinding
→ fix
→ root-cause analysis
→ variant search
→ regression test
→ design/coding rule
→ pipeline controlfinding
→ ticket closedNIST SSDF: četri darba virzieni
Uz 2026. gada 25. septembri NIST SP 800-218 SSDF v1.1 joprojām ir gala publikācija. NIST 2025. gada decembrī publicēja SSDF v1.2 sākotnējo publisko projektu, bet tas nav jāpasniedz kā jaunais final baseline.12
SSDF v1.1 grupē praksi četros virzienos:
- Prepare the Organization (PO);
- Protect the Software (PS);
- Produce Well-Secured Software (PW);
- Respond to Vulnerabilities (RV).1
Šis sadalījums ir ļoti praktisks, jo atgādina:
droša programmatūra nav tikai “secure coding”.
Vajag arī:
- cilvēkus un lomas;
- toolchain drošību;
- source integrity;
- build/release aizsardzību;
- design review;
- verification;
- vulnerability response.
OWASP SAMM pievieno brieduma skatījumu
OWASP SAMM secure-development jautājumu strukturē piecās business functions:
- Governance;
- Design;
- Implementation;
- Verification;
- Operations.3
SAMM vērtība nav tajā, ka organizācijai obligāti jāievieš viens identisks process.
Projekts ir risk-driven un technology/process agnostic.3
Tas palīdz izvairīties no divām galējībām:
A. “Mums vajag visas iespējamās AppSec kontroles.”
un
B. “Mēs esam mazi; mums Secure SDLC nav vajadzīgs.”
Pareizā pieeja ir:
nepieciešamās kontroles izvēlas pēc produkta, riska un izstrādes modeļa, bet kritiskās robežas nedrīkst palikt tikai uz ārējo pētnieku cerību.
Pirmais gate: security requirements pirms arhitektūras
Ja komandai security requirements parādās tikai pentesta reportā, tās parādās par vēlu.
Pirms dizaina vajag definēt vismaz:
- galvenos assets;
- trust boundaries;
- lietotāju un servisu lomas;
- sensitīvos datus;
- svarīgākos abuse cases;
- kritiskos security invariants;
- third-party dependencies;
- atjaunināšanas un recovery modeli.
Security requirement nedrīkst būt:
“sistēmai jābūt drošai”.
Tam jābūt pārbaudāmam.
Piemēram:
tenant_idnekad netiek uzticēts no klienta requesta kā autorizācijas avots.
Vai:
privileged state-changing operation prasa server-side authorization neatkarīgi no UI lomas.
Tad vēlāk ir ko testēt.
Otrais gate: threat modelling pirms implementācijas
Threat modelling nav diagramma, kuru ieliek arhīvā.
Tā vērtība ir agrīnā lēmumā.
Labs threat model palīdz noteikt:
- kur ir trust boundary;
- kur data flow maina uzticības līmeni;
- kur trešā puse kļūst par dependency;
- kur viena kļūda var pārvērsties systemic issue;
- kur vajag defense in depth;
- kur jābūt fail-safe state.
Threat modelling vajadzētu atjaunot, ja būtiski mainās:
- autentifikācija;
- autorizācija;
- cloud architecture;
- data flows;
- privilege model;
- ārējās integrācijas;
- AI/tool use;
- administratīvā kontrole.
Ja modelis nemainās kopā ar produktu, tas kļūst par vēsturisku ilustrāciju.
Trešais gate: drošas noklusējuma izvēles
Daļa vulnerability burden rodas nevis no koda kļūdas, bet no produkta izvēles.
Piemēri:
- default admin credentials;
- MFA izslēgts;
- publisks storage;
- overly permissive CORS;
- debug endpoint produkcijā;
- detalizēti logs tikai premium plānā;
- plašas IAM permissions kā default;
- update mehānisms opt-in.
Secure-by-Default maina jautājumu.
Ne:
“Vai administrators var produktu droši sakonfigurēt?”
Bet:
“Kas notiek, ja administrators neko īpašu neizdara?”
CRA secure-by-default prasība šo principu padara īpaši svarīgu ES produktiem, kad galvenais regulas prasību bloks sāks piemēroties 2027. gada decembrī.7
Ceturtais gate: dependency un supply-chain kontrole
Mūsdienu produkts nav tikai paša kods.
Tas ietver:
- open-source libraries;
- containers;
- base images;
- build tools;
- package registries;
- CI/CD actions;
- SaaS;
- cloud services;
- third-party SDK.
Tāpēc “mēs pārbaudījām savu source code” nav pilns produkta security statement.
CRA 13. pants ražotājiem paredz pienācīgu rūpību, integrējot trešo pušu komponentus, tostarp FOSS, lai tie neapdraudētu produkta kiberdrošību.7
NIS2 21. panta 3. punkts savukārt liek būtiskajiem un svarīgajiem subjektiem supply-chain riskā ņemt vērā piegādātāju un pakalpojumu sniedzēju produktu un kiberdrošības prakses kvalitāti, ieskaitot secure-development procedures.6
Praktiski tas nozīmē:
- zināt dependencies;
- zināt versijas;
- zināt, kas tās uztur;
- saprast update ceļu;
- spēt reaģēt uz advisories;
- kontrolēt build provenance;
- neielaist neuzticamu dependency tikai tāpēc, ka “CI ir zaļš”.
Piektais gate: code-level un pipeline verification
Vienam toolam nevajag piešķirt maģisku statusu.
SAST neatrod visu.
DAST neatrod visu.
SCA neatrod visu.
Secret scanner neatrod visu.
Code review neatrod visu.
Tāpēc verification ir kombinācija.
Atkarībā no produkta tā var ietvert:
- code review;
- SAST;
- DAST;
- dependency/SCA;
- IaC scanning;
- secret scanning;
- fuzzing;
- unit/security tests;
- API authorization tests;
- tenant-boundary tests;
- negative tests;
- supply-chain checks.
Automatizācijas mērķis nav:
“pierādīt, ka kods ir drošs”.
Tas ir:
lēti un atkārtojami aizturēt kļūdu klases, kuras nav jēgas katru reizi nodot cilvēkam vai ārējam pētniekam.
Sestais gate: release security decision
CI passed nav pilns release security decision.
Pirms release vajag zināt:
- kas mainījās;
- kādas security boundaries tas skar;
- kādi testi tika izpildīti;
- kas netika pārbaudīts;
- vai ir open High/Critical findings;
- vai ir exception;
- kas šo exception pieņēma;
- vai ir rollback;
- vai monitoring spēs pamanīt kļūdu.
Risk-based nenozīmē:
viss bloķē release.
Tas nozīmē:
ja security evidence nav pietiekams, ir apzināts lēmums, ne klusējošs pieņēmums.
Septītais gate: production observability un recovery
Secure-by-Design nebeidzas pie deploy.
Ja sistēma pēc incidenta nespēj atbildēt:
- kas autentificējās;
- kāda privileģēta darbība notika;
- kas mainīja konfigurāciju;
- kāds release bija produkcijā;
- kuru dependency versiju tas izmantoja;
organizācija ir zaudējusi daļu no drošības kontroles.
CISA Secure-by-Design pieeja īpaši uzsver, ka klientam nepieciešamai drošības telemetry un kontroles iespējām nevajadzētu būt luksusa papildinājumam.5
Produkta dizainā tāpēc ietilpst arī:
- audit logs;
- alertable events;
- secure update;
- rollback;
- backup/recovery;
- safe degraded mode;
- incident forensics.
Drošība ir arī spēja saprast, kas notika pēc tam, kad preventīvā kontrole neizdevās.
Kad tad nāk ārējais pētnieks?
Patiesībā pētnieks var parādīties jebkurā laikā.
Tāpēc CVD kanālu nevajadzētu atlikt līdz brīdim, kad organizācija uzskata sevi par nobriedušu.
Taču ir liela atšķirība starp:
A. spēju saņemt negaidītu vulnerability report;
un
B. aktīvu uzaicinājumu plašai ārējai auditorijai testēt produktu.
A variants ir nepieciešams gandrīz uzreiz.
B variants prasa lielāku gatavību.
Pirms aktīvas bug bounty vai plašas ārējās testēšanas organizācijai vajadzētu būt vismaz:
- skaidram scope;
- tehniskam triage owner;
- drošai evidence saņemšanai;
- incident escalation;
- remediation kapacitātei;
- retest procesam;
- reward/dispute modelim, ja ir bounty;
- produkta komandai, kas spēj pieņemt findings bez haosa.
Ārējais pētnieks nav jāgaida līdz “perfect SDLC”.
Bet viņu arī nevajag izmantot, lai atklātu to, ko varēja lēti novērst pašu pipeline.
Ko ārējais pētnieks dara labāk par iekšējo procesu
Šī raksta tēze nav:
“ja SDLC ir labs, pētnieki nav vajadzīgi.”
Tieši pretēji.
Ārējā pētniecība ir īpaši vērtīga, jo tā var dot:
- negaidītu skatpunktu;
- citu skill profile;
- jaunu exploitation kombināciju;
- fresh-eyes efektu;
- production reality pārbaudi;
- business-logic abuse, ko automatizācija nesaprot;
- boundary case, kuru iekšējais modelis neparedzēja.
Labs SDLC samazina lēto un atkārtojamo defektu skaitu.
Tas ļauj ārējiem pētniekiem vairāk laika tērēt uz grūti atrodamu security value.
Tas ir daudz labāks crowdsourcing modelis nekā maksāt par pamata input validation kļūdām, kuras pipeline varēja aizturēt.
Ārējs findings ir Secure SDLC tests
Katrs kvalitatīvs vulnerability reports uzdod divus jautājumus.
Pirmais:
Kā salabot šo vulnerability?
Otrais:
Kura mūsu iekšējā kontrole neizdarīja savu darbu?
Piemēram:
Ja organizācija atbild tikai uz pirmo jautājumu, bounty/CVD kļūst par ārēju QA.
Ja atbild arī uz otro, ārējā izpēte kļūst par Secure SDLC sensoru.
| Ārējais findings | Iespējamais SDLC jautājums |
|---|---|
| IDOR | Vai authorization invariants bija definēti un testēti? |
| hardcoded secret | Kāpēc secret scanning / review to neaizturēja? |
| vulnerable dependency | Vai SCA un update ownership strādā? |
| SSRF | Vai outbound network trust boundary bija projektēta? |
| XSS | Vai output encoding / framework controls tika konsekventi lietoti? |
| privilege escalation | Vai lomu modelis un negative tests bija pilnīgi? |
| insecure default | Kas apstiprināja default configuration? |
Ne katrs findings prasa jaunu process gate
Arī šeit var pārregulēt.
Ja katram bugam organizācija izveido:
- jaunu checklist;
- jaunu komiteju;
- jaunu mandatory approval;
- jaunu Jira lauku;
pēc gada process kļūst neizpildāms.
Root-cause feedback jābūt samērīgam.
Labs jautājums:
Vai šī ir vienreizēja implementācijas kļūda vai atkārtojama sistēmiska kļūdu klase?
Ja vienreizēja — regression test var būt pietiekams.
Ja atkārtojas — jāmaina design rule, framework, library, pipeline vai training.
Secure SDLC mērķis nav maksimāls process.
Tas ir lētākais uzticamais controls tur, kur kļūda rodas.
Minimālais Secure SDLC evidence record
Es negribētu milzīgu dokumentu katram release.
Bet kritiskām izmaiņām saglabātu vismaz:
Tas nav obligāts standarts.
Tā ir autora praktiska evidence vienība.
Mērķis ir spēt pēc incidenta vai ārēja findinga atbildēt:
Ko mēs par šo risku zinājām pirms release, ko pārbaudījām un kurš pieņēma atlikušā riska lēmumu?
change:
release:
components_changed:
trust_boundaries_changed:
security_design:
requirements:
threat_model_updated:
new_abuse_cases:
verification:
code_review:
automated_security_checks:
authorization_negative_tests:
dependency_review:
manual_security_test:
open_findings:
critical:
high:
exceptions:
release_decision:
approver:
residual_risk:
rollback_ready:
production:
logging_ready:
detection_ready:
support_and_patch_owner:CRA padara šo jautājumu par produkta dzīves cikla jautājumu
CRA ir īpaši nozīmīgs tāpēc, ka tas nepietiek ar vienreizēju pre-market testu.
Regula sasaista:
- cybersecurity risk assessment;
- dizainu;
- izstrādi;
- ražošanu;
- piegādi;
- uzturēšanu;
- third-party components;
- vulnerability handling;
- security updates;
- coordinated vulnerability disclosure.7
I pielikuma II daļa prasa ražotājiem cita starpā:
- identificēt un dokumentēt vulnerabilities un komponentus;
- novērst vulnerabilities bez nepamatotas kavēšanās;
- veikt efektīvus un regulārus produkta drošības testus un reviews;
- ieviest un īstenot CVD politiku;
- nodrošināt contact point vulnerability reporting.7
Tas ir precīzs iemesls, kāpēc:
Secure-by-Design un vulnerability disclosure nav konkurējošas stratēģijas.
Tās ir viena lifecycle dažādas puses.
NIS2 dara to pašu organizāciju līmenī
NIS2 21. pants būtiskajiem un svarīgajiem subjektiem prasa riskam atbilstošus pasākumus ne tikai incidentu vadībā, bet arī:
- supply-chain security;
- sistēmu iegādē;
- izstrādē;
- uzturēšanā;
- vulnerability handling;
- disclosure;
- security-measure effectiveness assessment.6
Tāpēc organizācija, kura saka:
“mums ir CVD, tāpēc izstrādes drošību nokārtos researchers”
sajauc vienu 21. panta kontroles aspektu ar pārējiem.
Disclosure nav substitute development security.
Security debt, ko nevajag eksportēt pētniekam
Ārējam pētniekam nevajadzētu kļūt par bezmaksas aizvietotāju tam, ko organizācija varēja automatizēt.
Piemēram:
- publiski secrets;
- default credentials;
- veca dependency ar plaši zināmu CVE;
- trūkstoša autorizācija visos endpointos;
- reproducējama pamata input validation klase;
- regulāri atgriežas viens root cause.
Protams, ja researchers to atrod, reports joprojām var būt pilnīgi derīgs.
Jautājums ir organizācijai:
Kāpēc mēs šo izmaksu ārēji pērkam atkal un atkal, nevis izņemam root cause no izstrādes sistēmas?
Bug bounty maksā par security signal.
Tam nevajadzētu finansēt Secure SDLC neesamību.
Pirms aktīvas ārējās izpētes: readiness gate
Es izmantotu šādu minimumu.
Organizācija ir pietiekami gatava aktīvi paplašināt ārējo testēšanu, ja:
- ir zināms un aktuāls asset inventory;
- scope tiesības ir saprotamas, tostarp third-party robežas;
- kritiskās security requirements ir definētas;
- ir threat-modelling process vismaz būtiskām izmaiņām;
- ir code/dependency/pipeline kontroles;
- pastāv release-security decision;
- ir logging un incident escalation;
- ir CVD intake;
- ir tehnisks triage owner;
- ir remediation un retest kapacitāte;
- ārējais findings nonāk root-cause / SDLC feedback loop.
Tas nav “sertifikāts, ka tagad drīkst atvērt bounty”.
Tas ir sanity check.
Ja 8. punkts nav izpildīts, CVD jāizveido.
Ja 9.–10. punkts nav izpildīts, aktīvi uzaicināt lielāku pētnieku plūsmu var būt priekšlaicīgi.
Secinājums
Secure-by-Design nenozīmē mēģināt uzbūvēt produktu bez nevienas ievainojamības.
Tas nav reālistisks assurance claim.
Tas nozīmē ko citu:
organizācija pati uzņemas atbildību par paredzamu drošības kļūdu klašu samazināšanu pirms produkta nonākšanas klienta un ārējā pētnieka rokās.
Ārējais pētnieks tad dara to, ko viņš dara vislabāk:
- skatās no citas perspektīvas;
- kombinē neparedzētus ceļus;
- pārbauda realitāti;
- atrod boundary cases;
- apšauba iekšējos pieņēmumus.
Viņam nevajadzētu būt pirmajam cilvēkam, kurš organizācijai pasaka, ka:
- nav autorizācijas modeļa;
- nav dependency ownership;
- produkts pēc noklusējuma ir nedrošs;
- nav audit logs;
- neviens netestē negative cases.
Tāpēc ārējā izpēte ir visvērtīgākā nevis vājas izstrādes vietā, bet virs stipras izstrādes.
Īsāk:
CVD ir safety net. Bug bounty ir ārējās uzmanības tirgus. Pentests ir kontrolēts tests. Secure-by-Design ir atbildība, kuru produkta ražotājs nevar deleģēt nevienam no tiem.
Biežāk uzdotie jautājumi
Vai organizācijai jāgaida pilnīgi nobriedis Secure SDLC, pirms publicēt CVD?
Nē. CVD intake kanālam jābūt pieejamam arī nepilnīgi nobriedušai organizācijai, jo vulnerability var tikt atrasta jebkurā laikā. Augstāka gatavība ir īpaši svarīga pirms aktīvas plaša bug bounty vai citas ārējās testēšanas programmas atvēršanas.
Vai bug bounty var aizvietot SAST, code review vai pentestu?
Nē. Bug bounty dod citu discovery modeli. Tas negarantē sistemātisku coverage un nav paredzēts kā pamata secure-development kontroļu aizvietotājs.
Vai Secure-by-Design nozīmē, ka vulnerabilities nedrīkst būt vispār?
Nē. Reālistisks mērķis ir mazināt paredzamus defektus, padarīt exploitation grūtāku, nodrošināt drošus noklusējumus un spēt ātri identificēt, labot un izplatīt atjauninājumus.
Vai CRA Secure-by-Design prasības jau pilnībā piemērojas 2026. gada septembrī?
Nē. CRA kopumā piemēros no 2027. gada 11. decembra. 14. panta ziņošanas pienākumi piemērojas no 2026. gada 11. septembra, bet tas nav tas pats, kas 13. panta un I pielikuma pilna piemērošana.7
Kāda ir atšķirība starp Secure-by-Design un Secure-by-Default?
Secure-by-Design attiecas uz produkta drošības arhitektūru un izstrādes izvēlēm visā dzīves ciklā. Secure-by-Default nozīmē, ka produkts jau sākotnējā konfigurācijā izmanto drošu bāzes stāvokli un neprasa klientam pašam ieslēgt būtiskās kontroles.
Ko darīt ar ārēju findingu pēc tam, kad tas ir salabots?
Meklēt root cause, variantus un iespēju kļūdas klasi pārvērst regression testā, design rule vai automatizētā pipeline kontrolē. Citādi tas pats defekts var atkārtoties citā vietā.
Avotu statuss
Avoti un ES tiesību aktu statuss pārbaudīti 2026. gada 25. septembrī. NIST SSDF v1.1 ir pašreizējā gala publikācija; SSDF v1.2 uz šo datumu ir Initial Public Draft, ne gala standarts. CRA galvenās produkta un ražotāja Secure-by-Design/vulnerability-handling prasības kopumā sāk piemēroties 2027. gada 11. decembrī; 14. panta ziņošanas pienākumi piemērojas no 2026. gada 11. septembra. Šajā rakstā aprakstītie “gates”, readiness modelis un evidence record ir autora praktiska metodika.
Šis raksts ir secure software development un product-security assurance prakses analīze, ne individuāls juridisks padoms.
Avoti
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, Final, 03.02.2022 · NIST
- NIST SP 800-218 Rev. 1, SSDF Version 1.2, Initial Public Draft, 17.12.2025; publiskās apspriešanas periods ir slēgts · NIST
- OWASP, Software Assurance Maturity Model (SAMM), pārbaudīts 25.09.2026 · owasp.org
- CISA un starptautiskie partneri, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software · cisa.gov
- CISA, “When Tech Vendors Make Important Logging Info Available for Free, Everyone Wins”, 19.07.2023 · cisa.gov
- Eiropas Parlamenta un Padomes Direktīva (ES) 2022/2555 (NIS2), īpaši 21. panta 2. punkta d)–f) apakšpunkts un 3. punkts · EUR-Lex
- Eiropas Parlamenta un Padomes Regula (ES) 2024/2847 (Cyber Resilience Act), īpaši 6., 13. un 71. pants un I pielikuma I–II daļa · EUR-Lex