Un peligro para la seguridad pública. Este es el principal argumento del Juzgado Central de lo Contencioso Administrativo nº 8 para denegar a Civio el acceso al código fuente de BOSCO, una aplicación desarrollada por el Gobierno y que utilizan las eléctricas para saber si un usuario en situación de vulnerabilidad puede recibir descuentos en su factura de la luz. El Gobierno, para rechazar su apertura, alegó durante el juicio que difundir este código supondría problemas tanto de seguridad pública, como defensa nacional y propiedad intelectual.
Comentarios
#0 gracias por el envío. Por si alguien no sabe de qué va y no va a leerlo....
"En 2019, Civio demostró que BOSCO tenía fallos y denegaba el bono social a personas que tenían derecho recibirlo. Lo hicimos tras recibir decenas de avisos de personas afectadas y pedir, al amparo de la Ley de Transparencia, su especificación técnica, los resultados de las pruebas de comprobación de la aplicación y su código fuente"
Código abierto siempre, así se evitan trampas y cualquiera puede verificarlo.
#2 Cierto es que en algunos sectores igual tener el código fuente a la vista no es lo más seguro. Pero al menos permitir auditorias externas de ese código a cualquiera que las solicite y presente ciertas garantías, si que debería ser obligatorio.
#4 Tener el código a la vista siempre es más seguro
#8 No siempre... imagina el código para controlar los misiles nucleares de USA, en gitHub.
Ciertas cosas mejor que no sean tan públicas, pero que el acceso sea transparente para quien lo requiera con sus acreditaciones, motivos justificados y demás. Lo mismo para el software de control de un marcapasos.
#10 Me lo imagino perfectamente. ¿Donde está el problema?
Qué no publiques el código no quiere decir que no van a encontrar los fallos.
#11 No se trata de fallos, se trata de partes sensibles del mismo.
Un programa que gestione ayudas monetarias y tenga acceso a los datos bancarios de las personas maneja información muy muy sensible y protegida. Si se hace el código de acceso libre, sabiendo como sera la calidad del software, seria un desastre y muy peligroso.
SI para ese mismo programa se permite ver el código fuente y auditarlo a quien lo pida con una razón fundada, sería mucho mas seguro e igual de efectivo de cara a transparecia.
#12 No se trata de fallos, se trata de partes sensibles del mismo.
Claro que se trata de fallos.
¿Que parte sensible (patentes aparte) puede tener un código fuente bien diseñado?. Pon un ejemplo.
Un programa que gestione ayudas monetarias y tenga acceso a los datos bancarios de las personas...
Los datos bancarios de las personas NO FORMAN PARTE del código fuente.
maneja información muy muy sensible y protegida
Claro. Pero esa información NO FORMA PARTE del código fuente, y no se publica.
Si se hace el código de acceso libre, sabiendo como sera la calidad del software, seria un desastre y muy peligroso.
Sabiendo como será la calidad del software, no publicarlo es un desastre y muy peligroso. No publicar el código fuente garantiza que los fallos que se descubran (que si existen se descubrirán, no tengas ninguna duda) sean eternos zero-day eternamente explotables.
SI para ese mismo programa se permite ver el código fuente y auditarlo a quien lo pida con una razón fundada, sería mucho mas seguro e igual de efectivo de cara a transparecia.
Exactamente del mismo modo que si se hace público el código fuente. Ni más, ni menos.
Si "quien lo pide" se guarda luego los fallos para él mismo estamos aún más jodidos.
#12 ¿Partes sensibles?, ¿como el cálculo de prestaciones?
Sin datos, no veo donde están esas "partes sensibles".
#12 Un programa que gestione ayudas monetarias y tenga acceso a los datos bancarios de las personas maneja información muy muy sensible y protegida.
Esa información sensible sólo existe en tiempo de ejecución, no en el código del programa. La seguridad por ocultación es un sesgo cognitivo muy anclado en el subconsciente, pero se ha demostrado incontables veces que no sólo no es eficaz, sino todo lo contrario. La API de Windows es buena muestra de ello.
#11 mejor 2 ojos (de becarios de indra) o 2mil?
#16 Mejor 2mil para encontrar fallos, reportarlos y resolverlos. A lo que hay que añadir los incentivos de quién escribe código para que sea de mejor calidad cuando sabe que muchos podrán ver no solo sus resultados sino también el código que los genera.
La hipótesis de la seguridad por obscuridad ha quedado desmentida desde hace décadas.
#10 Imagina que ese código es muy malo, y se puede explotar con un mísero telnet. ¿No sería mejor publicarlo?
#2 eso no prueba nada. pueden publicar un codigo y usar otro.
Mucho más seguro tener un programa que no puedes auditar y te tienes que fiar de que lo que te dice el desarrollador. Sobre todo cuando ese desarrollador seguro que es un amiguito.
#3 Así el que encuentre un fallo tendrá un zero-day durante años.
BonoSocial(Persona p)
while(true)
#5
def BonoSocial(persona):
query='Select nombre from Afiliados_PP where dni='+persona.dni
resultado=cursor.execute(query)
if resultado != "":
return True
else:
return False
Están reconociendo que es una chapuza.
#6 Como no va a ser una chapuza si realmente el nuevo Bono social lo sacaron un Jueves y dijeron... Desde mañana ya está disponible, sin informar a las eléctricas... Que yo me comí esa época.
El programa fue avanzando y adaptando poco a poco las cosas.
Eso si, ahora no puede dar a fallo... Básicamente por que de consultan los datos con Hacienda para el tema de ingresos y si no tienen datos, hacen ir al cliente a Hacienda para ver qué pasa. Pero sin ese requisito, ni se anula ni se acepta, el programa no hace otra cosa. No entiendo la dificultad la verdad
Lo de mostrar el Código, pos no creo que sea muy loco... Total, solo solicita ingresos de la unidad familiar, si cumple con los del bono pos OK.
Es más gente pide el bono del 25% por ingresos y como tiene ingresos no contributivos les ponemos el 40% y lo flipan.
pues yo creo que el peligro para la seguridad pública es no abrirlo