Google propozon të vendosë rregulla të reja për të përmirësuar sigurinë e burimit të hapur

Siguria e softuerit me burim të hapur ka tërhequr vëmendjen e industrisë, por zgjidhjet kërkojnë konsensus për sfidat dhe bashkëpunim në zbatim.

Problemi është kompleks dhe ka shumë aspekte për të mbuluar, nga zinxhiri i furnizimit, menaxhimi i varësisë, identiteti, ndër të tjera. Për ta bërë këtë, Google kohët e fundit lëshoi ​​një kornizë ("Di, Parandalo, Rregullo") që shpjegon se si industria mund të mendojë për dobësitë në burim të hapur dhe fusha specifike që duhet të adresohen më parë.

Google shpjegon arsyet e saj:

“Për shkak të ngjarjeve të fundit, bota e softuerit ka fituar një kuptim më të thellë të rrezikut real të sulmeve të zinxhirit të furnizimit. Softueri me burim të hapur duhet të jetë më pak i rrezikshëm nga perspektiva e sigurisë, pasi të gjitha kodet dhe varësitë janë të hapura dhe të disponueshme për inspektim dhe verifikim. Dhe ndërsa kjo është përgjithësisht e vërtetë, supozohet se njerëzit në të vërtetë po e bëjnë këtë punë inspektimi. Me kaq shumë varësi, është e pamundur të monitorohen të gjitha ato dhe shumë paketa me burim të hapur nuk mirëmbahen.

“Commonshtë e zakonshme që një program të varet, drejtpërdrejt ose indirekt, nga mijëra paketa dhe biblioteka. Për shembull, Kubernetes tani varet nga rreth 1000 pako. Burimi i hapur ndoshta përdor varësi sesa softuer të pronarit dhe vjen nga një gamë më e gjerë e shitësve; numri i subjekteve të pavarura që mund të besohen mund të jetë shumë i madh. Kjo e bën jashtëzakonisht të vështirë për të kuptuar se si përdoret burimi i hapur në produkte dhe cilat dobësi mund të jenë të rëndësishme. Nuk ka gjithashtu asnjë garanci se ajo që është ndërtuar do të përputhet me kodin burimor.

Brenda kornizës së propozuar nga Google, sugjerohet që kjo vështirësi të ndahet në tre zona problematike kryesisht të pavarura, secila me objektiva specifikë:

Njihni dobësitë e softuerit tuaj

Njohja e dobësive të softuerit tuaj është më e vështirë nga sa mund të prisni për shumë arsye. po ne rregull ekzistojnë mekanizma për të raportuar dobësitë, është e paqartë nëse ato ndikojnë vërtet në versionet specifike të softuerit që po përdorni:

  • Qëllimi: Të dhëna të sakta të cenueshmërisë: Së pari, është thelbësore për të kapur të dhënat e sakta të cenueshmërisë nga të gjitha burimet e të dhënave të disponueshme. Për shembull, të dish se cili version ka prezantuar një dobësi ndihmon në përcaktimin nëse softueri preket, dhe të dish se kur është rregulluar rezulton në rregullime të sakta dhe me kohë (dhe një dritare e ngushtë për shfrytëzim të mundshëm). Në mënyrë ideale, ky proces i klasifikimit duhet të jetë i automatizuar.
  • Së dyti, dobësitë më të mëdha qëndrojnë në varësitë tuaja, sesa në kodin që shkruani ose kontrolloni drejtpërdrejt. Pra, edhe kur kodi juaj nuk ndryshon, peizazhi i dobësive që ndikojnë në softuerin tuaj mund të ndryshojë vazhdimisht - disa janë rregulluar dhe disa shtohen.
  • Qëllimi: Skema standarde për bazat e të dhënave të cenueshmërisë Standardet e infrastrukturës dhe industrisë kërkohen për të gjurmuar dhe mirëmbajtur dobësitë e burimit të hapur, për të kuptuar pasojat e tyre dhe për të menaxhuar zbutjet e tyre. Një skemë standarde e ndjeshmërisë do të lejojë që mjetet e zakonshme të funksionojnë në baza të të dhënave të shumta të cenueshmërisë dhe të thjeshtojnë detyrën e gjurmimit, veçanërisht kur dobësitë kryqëzojnë gjuhë ose nënsisteme të shumëfishta.

Shmangni shtimin e dobësive të reja

Do të ishte ideale të shmangni krijimin e dobësive Dhe ndërsa mjetet e testimit dhe analizës mund të ndihmojnë, parandalimi do të jetë gjithmonë një temë e vështirë.

Këtu, Google propozon të përqendrohet në dy aspekte specifike:

  • Kuptoni rreziqet kur vendosni për një varësi të re
  • Përmirësoni proceset kritike të zhvillimit të softuerit

Riparoni ose hiqni dobësitë

Google pranon që problemi i përgjithshëm i riparimit është përtej fushëveprimit të tij, por botuesi beson se aktorët mund të bëjnë shumë më tepër për të adresuar problemin specifike për të menaxhuar dobësitë në varësi.

Ai gjithashtu përmend: 

“Sot ka pak ndihmë në këtë front, por ndërsa përmirësojmë saktësinë, ia vlen të investohet në procese dhe mjete të reja.

“Një opsion, natyrisht, është të rregullojmë cenueshmërinë direkt. Nëse mund ta bëni këtë në një mënyrë të përputhshme prapa, zgjidhja është në dispozicion për të gjithë. Por sfida është që nuk keni gjasa të keni përvojë me problemin ose aftësi të drejtpërdrejtë për të bërë ndryshime. Rregullimi i një dobësie supozon gjithashtu që ata që janë përgjegjës për mirëmbajtjen e softuerit janë të vetëdijshëm për problemin dhe kanë njohuri dhe burime për të zbuluar cenueshmërinë.

Fuente: https://security.googleblog.com


Lini komentin tuaj

Adresa juaj e emailit nuk do të publikohet. Fusha e kërkuar janë shënuar me *

*

*

  1. Përgjegjës për të dhënat: AB Internet Networks 2008 SL
  2. Qëllimi i të dhënave: Kontrolloni SPAM, menaxhimin e komenteve.
  3. Legjitimimi: Pëlqimi juaj
  4. Komunikimi i të dhënave: Të dhënat nuk do t'u komunikohen palëve të treta përveç me detyrim ligjor.
  5. Ruajtja e të dhënave: Baza e të dhënave e organizuar nga Occentus Networks (BE)
  6. Të drejtat: Në çdo kohë mund të kufizoni, rikuperoni dhe fshini informacionin tuaj.

  1.   José Antonio dijo

    Origjinali në anglisht thotë:

    Këtu përqendrohemi në dy aspekte specifike:

    - Kuptimi i rreziqeve kur vendosni për një varësi të re

    - Përmirësimi i proceseve të zhvillimit për softuer kritik

    Versioni "LinuxAdictos" thotë:

    Këtu, Google propozon të përqendrohet në dy aspekte specifike:

    - Kuptoni rreziqet kur zgjidhni një varësi të re.

    - Përmirësimi i proceseve kritike të zhvillimit të softuerit

    Një varësi e re!?