Opencode.gov.sk (metodický portál pre zverejňovanie zdrojových kódov ISVS)

,
21

Tak ono neviem, ci rovno “automaticke”. Znie to carovne a spolahlivo, najma ak to GitHub uz dnes ma. Ale …

Projekt “statneho repozitara zdroj. kodov” este nie je ani len obstarany. T.j. bezi debata o alternativach. A takato podmienka sice moze zniet dobre, zaroven vsak moze vyradit vela uchadzacov ci alternativ. Co moze byt zbytocne, ak uvazime, ze “automat” aj tak najde vsetko (resp. bude produkovat privela “false positives”) a teda tak ci tak sa autor(-i) zdrojakov pred zverejnenim (resp. idealne uz pri commitovani) musia zamysliet, co davaju do repozitara. T.j “automat” (najma ak je povedzme zadarmo a funguje vcelku dobre) je fajn kriterium typu COULD alebo SHOULD, ale ako MUST by som ho nedaval.

Najma ked rovno na tomto konkretnom pripade vidime, ze zdrojaky sa sice davaju na GitHub, a GitHub ten “automat” ma, ale aj tak bum, doslo k chybe.

Velku vedu a procesy by som z toho nerobil, kedze to sa potom dostavame prave k tomu, ze aj z drobnych veci sa budu stavat velke. A velke veci potom uz len z titulu velkosti budu zlyhavat. Ako som uz pisal, poucili sme sa (dufam), podme dalej.

22

A ja by som ho práveže dal ako MUST :slight_smile: práve pre túto vetu co si napísal. A aj ďalšie veci. Neurobiť NIČ a VEDOME vystrcit do sveta potencialne deravé zdrojaky statnych systémov u mňa momentálne hraničí s vlastizradou. Sme na zozname nepriateľských krajín štátu, čo sponzoruje špičkové cyber útočné skupiny. To fakt im ideme pomáhať, nech sa nemusia namáhať?

Takéto a podobné veci sa deju denne.

1 Like
23

Tak som sa spýtal aj AI ze co si mysli o tom zverejnovani zdrojakov a dala mi za pravdu v podstate :slight_smile: :

The decision to publish the source code of important national information systems is a complex one and will depend on a variety of factors, including the sensitivity of the information being handled by the system, the potential risks associated with publishing the code, and the potential benefits of doing so.

One potential benefit of publishing the source code of a national information system is that it can allow for greater transparency and accountability, as it allows others to review and verify the security of the system. This can be particularly important for systems that handle sensitive or critical information. However, publishing the source code of a system can also potentially expose vulnerabilities or weaknesses in the system that could be exploited by malicious actors.

Ultimately, the decision to publish the source code of a national information system should be carefully considered and made based on a thorough risk assessment, taking into account all of the potential risks and benefits. It may also be advisable to consult with cybersecurity experts and other relevant stakeholders before making a final decision.

It is generally a good idea for organizations, including the Slovak Republic, to thoroughly review and assess the security of any software or source code before making it publicly available, such as on GitHub. This is particularly important for national information systems, which may contain sensitive or confidential information that could be accessed by unauthorized individuals if not properly protected.

There are several steps that organizations can take to ensure the security of their software and source code before making it publicly available. One option is to conduct a security scan or audit to identify any potential vulnerabilities that could be exploited by malicious actors. This can be done using tools and techniques such as static code analysis, dynamic analysis, and penetration testing.

In addition to security scans, organizations can also implement other best practices to ensure the security of their software and source code. These may include implementing strong access controls and authentication measures, regularly updating and patching software to fix known vulnerabilities, and following secure coding practices.

Overall, it is important for the Slovak Republic and other organizations to carefully consider the security implications of making their software and source code publicly available, and to take appropriate steps to protect against potential security threats.

24

GitHub makes it easier to scan your code for vulnerabilities

25

Ahojte, pár info o postupe na tomto fronte.

1)

Čo je asi teraz najdôležitejšie, je blížiace sa VO4 pre Otvorené údaje pre obstaranie Platformy pre zdieľanie zdrojových kódov GOVGIT.
Tu môžete nájsť

:point_right: GovGit - podklady pre VO na pripomienkovanie:
Katalóg požiadaviek: 2023-01-23-KATALOG_POZIADAVIEK_OD2.0-GovGit.xlsx
Opis predmetu zákazky: 2023-01-23-OD2.0-PlatformaPreZdielanieKodovISVS-OPZ.docx

Hneď požiadavka č.1 je jasná. Ide o nasadenie existujúcej platformy GitHub, GitLab alebo alternatívy, aby minimálne spĺňali požiadavky a definovanú funkcionalitu. Bude to teda na dodávateľovi, s ktorou vie dané dielo realizovať najlepšie. Súčasťou bude aj webová vyhľadávacia služba code.gov.sk (v ID-SK designe) nad týmto centrálnym repozitárom, ktorá poskytnutne OpenAPI službu pre opendata, ktorá bude skatalogizovaná na data.gov.sk, ktorá vráti zoznam repozitárov s ich metaúdajmi.

Sme presvedčení, že je to práve to, na čom sme sa na mnohých diskusiách dohodli. Nie vývoj veľkého custom riešenia ale použitie existujúcich nástrojov, metodík a podobne.

Chceme to predložiť na RV, obstarať, rozbehať a pokračovať v téme.
AK máte k tomu nejaké pripomienky, pošlite nám ich plís do konca týždňa.

2)

Verím že zdrojáky WebuMIRRI budú už čoskoro dostupné (kým nebude govgit, tam na githube mirri). Ešte riešime posledné veci. Dôležité je, že sa nám rozbehol kľúčový proces v spolupráci s oddelením CSIRT, ktorého súčasťou je bezpečnostná kontrola zdrojového kódu. Proces sa však musí viac zinštitucionalizovať a zabehať. Toto patrí medzi jedno z najväčších obmedzení zdieľania ISVS.

3)

Čo sa týka zdrojového kódu Slovensko v mobile, pracujeme na tom, aby sme ho mohli zverejniť. Tým že je to väčší projekt než nejaký malý web, asi to potrvá dlhšie. Zatiaľ sme v tomto na začiatku.

4)

Máme už aj zdrojáky MetaIS, ktoré sa snažíme tiež zverejniť na GitHube. Či sa nám to podarí s CSIRTom, alebo inak, to je ešte otvorené. V súčasnosti hľadáme riešenie aj ako to trvalo rozbehnúť, na stole je viac variánt.

5)

Tak či onak, kým bude v produkcii GovGit, stále chceme používať github MIRRI

na zverejnenie toho čo sa nám dovtedy podarí. Či je to webmirri, metais, slovensko v mobile ale iné.

Tu by sme chceli ale spraviť pár zmien v nastavení práv, a to nasledovne:

  • administrátori a memberi sú len ľudia z MIRRI, pričom len títo vidia zdrojové kódy v stave privátne. Ostatní budú len ako externí prispievatelia. Napr. mr. @peter_k je owner, asi preto že to niekedy založil, tak ak by sa nenahneval on, resp. memberi čo nepracujú na MIRRI, prehodil by som ich do externých prispevateľov, ak by ste boli s tým všetci OK. Boli by ste plís?
1 Like
26

Ahojte, zdrojový kód webu MIRRI je opäť prístupný.

Pracujeme na tom aby sa zverejnili aj ďaľšie zdrojové kódy, za mňa je to najmä MetaIS a Slovensko v Mobile. (napr. OD2.0 sú na githube od začiatku). Najväčší problém je s bezpečnostným testovaním kódu. Pracujeme aj na alternatíve verejného obstarávania pre bezpečnostný audit behu vybraných aplikácii MIRRI s ich zdrojovými kódmi pre ich zverejnenie.Toto je zatiaľ v počiatočných fázach.

2 Likes
27

Čím sa to bezpečnostné testovanie a audit riadi? Je dostupná metodika pre výkon bezpečnostných testov zdrojových kódov predtým ako sa zverejnia?

28

Metodika sa tvorí. Primárne vychádzame z odporúčaní uk-egovu

typy incidentov sme začali evidovať, ktoré sa vyskytli
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=101820748

ale samozrejme, toto všetko je skôr štartovacia fáza.
Hlavný posun bude projekt GovGit (vyššie sú linky na pripomienkovanie OPZ a katalógu požiadaviek) - a súčasné sním predpokladáme tvorbu aj metodiky ako popisujete (zatiaľ interne nie v rámci VO). Také Slovensko v Mobile predpokladám že bude zverejnené až po takomto komplexnom bezpečnostnom testovaní. Každopádne jedna vec bude príprava metodiky a druhá vec kto to bude reálne testovať. To sa tiež momentálne rieši.

1 Like
29

Super. Ak by bolo treba, “bezpecnostnu cast” metodiky rad “orieviewujem” pripadne ked bude treba dam vstupy. Aby bolo jasne ako v praxi chapat toto: " You may also need to keep some code closed for security reasons, for example code that protects against fraud. Follow the guidance on code you should keep closed and security considerations for open code."

3 Likes
30

Ďakujeme pekne za ponuku.
:+1:
Keď sa veci viac vyjasnia, prípadne spracujeme prvú verziu metodiky, zavesím ju sem a tagnem Vás. Pekný deň.

2 Likes
31

V zasade sulasim.

Narazam skor na to, ci sa to ma prilepit k obstaravaniu “statneho GIT-u” alebo to moze/ma byt separatne obstarane riesenie. Co je v zasade “klasicky problem” nasho obstaravania: ak sa to prilepi, moze to byt lacnejsie, zaroven to vsak obmedzi sutaz. Ale ak sa neprilepi, tak sutaz moze byt sirsia a vysledok lepsi, zaroven vsak kvoli tomu cele obstarko moze trvat strasne dlho alebo rovno cele zhavarovat. Karle, nevim.

Ale ano, urtcite sa na git nema hodit vsetko bez akehokolvek rozmyslu. Aj preto som sem (ci uz tu alebo inde) prilepoval odkazy na UK metodiky, kde to maju podchytene. A som rad, ze ich na MIRRI citaju.

Zaroven MIRRI drzim palce, lebo pointou zverejnovania nie je pomahat povedzme ruzzku v hladani nasich zranitelnosti, ale napr. vyhnut sa rizikam vendor-lock, zlepsenie kontroly projektov a zvysenie kvality dodavanych rieseni (vid dovodovu spravu: https://www.slov-lex.sk/legislativne-procesy?p_p_id=processDetail_WAR_portletsel&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-2&p_p_col_count=1&_processDetail_WAR_portletsel_fileCooaddr=COO.2145.1000.3.2199302&_processDetail_WAR_portletsel_file=05_dovodova_ITVS_MPK.DOCX&_processDetail_WAR_portletsel_action=getFile - cast “K § 14”) alebo tiez zvysenie re-use, aby sa dokola neprogramovalo a neplatilo to iste.

Ak sa zamotame az tak, ze nikto nezverejni nic, tak cela ta cast zakona a aj velka cast MIRRI straca zmysel. T.j. dufam, ze neskoncime pri klasickom “nevieme, nemozeme, neda sa”. Pricom pri vzniku tohto celeho bol OPIS, t.j. “miliarda” o ktorej je silne presvedcenie, ze velka cast bola neefektivne rozflakana, ak nie rovno ukradnuta.

32

Ivan, vďaka že tu zastupuješ bezpečácky pohľad. (myslené bez irónie)
Jasné že “neurobiť nič” je v súčasnosti brutálne riziko. Akurát že to nie je spojené so “zverejnením kódu”. Opatrenia majú byť rovnaké, či máš prístup k zdrojovému kódu alebo nie. Ináč je to security-by-obscurity, ktorú iste neobhajuješ.

No a potom sú typy SW, kde sú úplne iné priority. Špeciálne mám na mysli eGov aplikácie určené na inštaláciu používateľom. Keďže ja mám aplikáciu používať na mojom zariadení, ja chcem mať možnosť si overiť, čo ten kód vlastne robí. Zdrojový kód by mal byť absolútne automaticky zverejňovaný. Čiže najmä aplikácia SvM a eID klient. V čom je problém, @liska kde to viazne?
Prečo nebol od začiatku zverejnený zdrojový kód ku Green Pass (očkovacie potvrdenia Covid) - a prečo stále nie je?

3 Likes
33

Stále to viazne na vytvorení metodiky Bezpečnostného testovania zdrojových kódov pre ich zverejnenie. Existuje návrh, že túto metodiku vytvorí CSIRT, musím zistiť aktuálny stav.

Toto je samozrejme škoda. My sme mali ľahšiu úlohu s OD2.0, keďže už aj prepoužitý zdrojový kód data.gov.cz je na githube. Nebudem teraz hovoriť aký sme my transparentný, kto vie ak by to nebol projekt OpenData.

Myslím ale, že keď sa tá metodika vytvorí, tak to naštartuje zverejňovanie kódov. Skutočne nemám ani mili-pocit, že to robíme za MIRRI zámerne.

Tu napr. môžete vidieť nachystaný MetaIS na githube:

obrázok
obrázok1043×213 28.2 KB

ale stále je repozitár neprístupný. :disappointed:

34

Hm. Vytvorenie metodiky by v prvom rade malo naštartovať zvýšenie bezpečnosti štátnych IS, tym že prispeje k odhaľovaniu zneuzitelnych chyb a zranitelnosti v kodoch (a dúfam aj k následným opravam). To nebude triviálne, zaviesť riadené procesy tohto typu. . Ale keď sa toto podarí zaviesť do praxe, tak to bude veľmi solídny vedlajsi efekt zverejňovania kódov. :slight_smile:

2 Likes
35

K tomuto pridam toto pekne video:

Je sice k apke, ktoru v UK uz vypli, ale pointa ostava.

Nie ze by som bol priaznivcom chvatnych rieseni, ale zase aby sme nedopadli, ze ideme byt papezskejsi ako papez a bude to cele najsamsuper, ale doziju sa toho az moje vnucata.

A rypnem (a dufam, ze nepodlanem ako onehda s “API Katastra”, vid nizsie): A nevadi, ze zrojove kody aktualneho data.gov.sk su vonku bez metodiky?

A neopovazte sa to stiahnut! :slight_smile:

(preco “API katastra”: Tu sme popisali, ze oni ho vlastne maju/mali, a ze vlastne chyba iba drobna dokumentacia. Na UGKK sa prudko zamysleli, oznacili to za “bezpecnostne riziko” a ze to zrusia.)

1 Like
36

Ako si napisal:

  1. OVM vyhlási, že so zverejnením nejakého kódu je spojené riziko. Kto ho vyhodnoti? Kto posúdi ci je zanedbateľné alebo neakceptovateľné ? Kto príjme opatrenia tak, aby so zverejním nebolo spojené riziko?

  2. Kto je vlastníkom tohto rizika a bude zodpovedať za dôsledky jeho nastatia?

37

Nie, toto na nejakej metodike určite neviazne, prosím neklamme sa aspoň tu. Ešte raz: eGov aplikácie určené na inštaláciu používateľom - SvM, eID klient, GreenPass. Ak je kód deravý, riziko pre servery a údaje verejnej správy = žiadne. V čo to viazne skutočne? Imho sa tomu doteraz nikto na MIRRI ani kúsok nevenoval. “Zámerne”?

Za bezpečnosť ITVS vo svojej správe zodpovedá správca, odjakživa, nič sa nezmenilo. Táto diskusia sa veľmi podobá na tému “bezpečnosť na zasnežených chodníkoch v správe mesta”. Tiež tu boli rôzne zaujímavé nápady, napr. keď nasneží tak sa chodník uzavrie, dá sa ceduľka že prechod iba na vlastné riziko, alebo sa zodpovednosť prehodí na vlastníka nehnuteľnosti hneď vedľa chodníka - našťastie common sense v tomto prípade zatiaľ funguje, za bezpečnosť zodpovedá mesto a má vyhodnotiť riziko a spraviť opatrenia aké považuje za vhodné.
Ďalšiu otázku prosím.

1 Like
38

Ok. Tak správca vyhlási že vzhľadom na povahu kódu su so zverejnením spojené neakceptovateľné bezpečnostné riziká, boli identifikované zásadné potenciálne zraniteľnosti a kod zverejnení až po ich odstránení (= na sv. Dindi). Now what?

39

Dobrý point, začal som ho interne komunikovať. Zozbieram na to pohľady a dám vedieť. Mohlo by to publikovanie takýchto zdrojákov oveľa zjednodušiť.

V rámci projektu OD2.0 sme do zmluvy vložili klauzulu o zverejnení kódu na Githube, takže nie je to úplne nikto. Musím ale uznať, že v zákone je táto povinnosť už oveľa dlhšie : 95/2019 §15
Mám ale také info, resp. som v tom, že sa má naša zmluva začať používať ako vzor pre iné projekty. Či tomu ale tak tak naozaj je, o tom nemám prehľad.

Každopádne je to na našu obrovskú škodu (MIRRI), že práve teraz by to mohla byť jedna z ultra priorít, nakoľko nie je ju ani ťažké realizovať (kontrolovať zmluvy, či sú podľa uvedeného zákona). Profitovali by z toho všetky strany.

40

@liska ja v zmluvách SKIT - MIRRI vidím toto:

image
image969×242 35.5 KB

Čiže zhrnuté: zdrojový kód zverejnený nebude, a to úmyselne, lebo to MIRRI nechce ani pri vlastných aplikáciách! Hanba.