Google proposa establir noves regles per millorar la seguretat de l'open source

La seguretat del programari de codi obert ha atret l'atenció de la indústria, Però les solucions requereixen consens sobre els desafiaments i cooperació en l'execució.

El problema és complex i hi ha moltes facetes per cobrir, des de la cadena de subministrament, gestió de dependències, identitat, entre altres coses més. Per a això Google va donar a conèixer fa poc un marc ( «Conèixer, prevenir, reparar») en què explica com la indústria pot pensar en les vulnerabilitats en el codi obert i en àrees concretes que s'han d'abordar primer.

Google explica els seus motius:

"A causa de esdeveniments recents, el món del programari ha adquirit una comprensió més profunda de el risc real d'atacs a la cadena de subministrament. El programari de codi obert hauria de ser menys arriscat des d'una perspectiva de seguretat, ja que tot el codi i les dependències estan oberts i disponibles per a inspecció i verificació. I si bé això és generalment cert, se suposa que les persones realment estan fent aquesta feina d'inspecció. Amb tantes dependències, és impossible monitorearlas totes i molts paquets de codi obert no estan ben mantinguts.

"És comú que un programa depengui, directament o indirectament, de milers de paquets i biblioteques. Per exemple, Kubernetes ara depèn d'al voltant de 1000 paquets. El codi obert probablement fa servir dependències més que programari propietari i prové d'una gamma més àmplia de proveïdors; el nombre d'entitats independents en què es pot confiar pot ser molt elevat. Això fa que sigui extremadament difícil comprendre com es fa servir el codi obert en els productes i què vulnerabilitats poden ser rellevants. Tampoc es garanteix que el que es construeix coincideixi amb el codi font.

Dins el marc proposat per Google es suggereix dividir aquesta dificultat en tres àrees problemàtiques en gran mesura independents, cadascuna amb objectius concrets:

Conèixer les vulnerabilitats del seu programari

Conèixer les vulnerabilitats del seu programari és més difícil del que es podria esperar per moltes raons. si bé existeixen mecanismes per informar vulnerabilitats, no està clar si realment afecten les versions específiques del programari que utilitzeu:

  • Objectiu: dades de vulnerabilitat precisos: En primer lloc, és fonamental capturar metadades de vulnerabilitat precisos de totes les fonts de dades disponibles. Per exemple, saber quina versió va introduir una vulnerabilitat ajuda a determinar si el programari està afectat, i saber quan s'ha pedaç dóna com a resultat correccions necessàries i oportunes (i una finestra reduïda per a una possible explotació). Idealment, aquest flux de treball de classificació hauria automatitzar.
  • En segon lloc, la majoria de les vulnerabilitats es troben en les seves dependències, més que en el codi que escriu o controla directament. Llavors, fins i tot quan el seu codi no canvia, el panorama de vulnerabilitats que afecten al seu programari pot canviar constantment: algunes es corregeixen i altres s'agreguen.
  • Propòsit: Esquema estàndard per a bases de dades de vulnerabilitat La infraestructura i els estàndards de la indústria són necessaris per rastrejar i mantenir les vulnerabilitats de codi obert, comprendre les seves conseqüències i administrar els seus mitigacions. Un esquema de vulnerabilitat estàndard permetria que les eines comunes s'executessin en múltiples bases de dades de vulnerabilitats i simplificaria la tasca de seguiment, especialment quan les vulnerabilitats creuen múltiples llenguatges o subsistemes.

Evitar l'addició de noves vulnerabilitats

Seria ideal evitar la creació de vulnerabilitats i, si bé les eines de prova i anàlisi poden ajudar, la prevenció sempre serà un tema difícil.

aquí, Google proposa centrar-se en dos aspectes específics:

  • Comprendre els riscos a l'decidir sobre una nova dependència
  • Millorar els processos de desenvolupament de programari crític

Reparar o eliminar vulnerabilitats

Google reconeix que el problema general de la reparació està més enllà del seu abast, però l'editor creu que els actors poden fer molt més per abordar el problema específic d'administrar les vulnerabilitats a les dependències.

A més esmenta: 

"Avui dia hi ha poca ajuda en aquest front, però a mesura que millorem la precisió, val la pena invertir en nous processos i eines.

"Una opció, per descomptat, és posar pegats a la vulnerabilitat directament. Si pot fer això d'una manera compatible amb versions anteriors, la solució està disponible per a tots. Però el desafiament és que és poc probable que tingui experiència en el problema o la capacitat directa per fer canvis. La reparació d'una vulnerabilitat també suposa que els responsables de l'manteniment del programari són conscients el problema i tenen el coneixement i els recursos per revelar la vulnerabilitat.

font: https://security.googleblog.com


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: AB Internet Networks 2008 SL
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   José Antonio va dir

    L'original en anglès diu:

    Here we focus on two specific aspects:

    - Understanding risks when deciding on a new dependency

    - Improving development processes for critical programari

    La versió «LinuxAdictos» diu:

    Aquí, Google proposa centrar-se en dos aspectes específics:

    - Comprendre els riscos a l'triar una nova addicció.

    - Millora dels processos de desenvolupament de programari crític

    ¿Una nova addicció!?