¿Es urgente revocar el acceso a un repositorio privado una vez que una persona se lo ha concedido por error y se da cuenta de esto?

Hay varias razones:

• Si le ha pasado a una persona, podría haber ocurrido a más. Estas otras personas podrían no ser tan amables.
• Quién sabe, esta persona podría cambiar de opinión. Cuando hicieron el esfuerzo de contactarte, y solo recibe un "meh" a cambio, podrían estar un poco molestos y decidir castigarte por ello.
• O tal vez solo quieren hurgar un poco por diversión y romper algo accidentalmente.
• Probablemente desee revisar los registros para ver si esta persona está diciendo la verdad. Tal vez robaron silenciosamente sus claves de cifrado antes de ponerse en contacto con usted. Probablemente desee rotar todos sus secretos solo para estar seguro.
• Y lo más importante, este es un Big F * cking Deal ™. Cualquiera que no reaccione con sorpresa y horror, sino que ordene otra piña colada, claramente no entiende la gravedad de la situación.

Hay algunos puntos muy buenos en los comentarios y esta respuesta que todo puede estar bien en ciertas circunstancias (por ejemplo, lea Solo acceso, no hay secretos en el código, etc.). Eso es correcto, pero todavía argumentaría que esto debería tomarse más en serio. ¿Está realmente seguro al 100% de que no hay secretos en algún antiguo compromiso en su repositorio? El solo hecho de que alguien que no debería tener acceso a sus sistemas lo haya obtenido de todos modos es en sí mismo un mal presagio.

Si bien es imposible leer las mentes de las personas que juegan, creo que el programador independiente

A) No quiere ser acusado de impropiedad: es mucho más difícil ser acusado de robo de IP si pateas y gritas para que te revoquen tu acceso después de la prisa.

B) Está horrorizado por la postura de seguridad de la compañía que controla el repositorio privado y sabe que, si fuera responsable, querría estar informado.

Una cosa a tener en cuenta es que al dar acceso de usuario adicional a un repositorio se abre un nuevo vector de ataque posible. Si otra persona con intenciones maliciosas tiene acceso a la cuenta a la que se le ha otorgado acceso al repositorio sin que el titular de la cuenta original lo sepa, esa persona podría descargar fácilmente su código fuente completo.

Para proporcionar un punto de vista diferente al de la mayoría, realmente no debería ser un riesgo de seguridad iff el proyecto se maneja bien.

Hay básicamente dos cosas que deben cumplirse. Primero, que

• No puede introducir código en las sucursales de lanzamiento sin que otras personas tengan que firmarlo. Generalmente, esto se logra al requerir solicitudes de extracción y revisiones de código en cualquier código que ingrese a una sucursal de lanzamiento. En este caso, si la persona solo obtuvo acceso de lectura al repositorio, no tiene que preocuparse por esto. Pero aún así, debes tener esto en su lugar de todos modos.

y segundo que

• Nadie incluye secretos en el repositorio. Sí, es posible que tenga claves de API secretas, certificados de firma de código y lo que no, pero las reales deben NUNCA estar en su repositorio principal al alcance de todos. Si se requieren algunos secretos para que el código funcione, incluya algunas versiones de prueba / desarrollo ficticias en su repositorio. Pero los reales deben mantenerse separados con solo un pequeño número de personas que tienen acceso, preferiblemente para que su sistema de compilación los incluya automáticamente sin participación manual.

Si ambos son verdaderos, realmente no veo ningún daño desde el punto de vista de la seguridad. Si hay algunos secretos comerciales valiosos en el código que podrían filtrarse a un competidor es un tema diferente.

O otra forma de pensar acerca de esto: la situación aquí no es nada especial. ¡Usted tiene que lidiar con los mismos problemas, cada vez que un empleado se retira ! Si su repositorio contiene algún secreto, una persona externa ahora los conoce todos.

Si se roban cosas, ve primero a las personas que tienen una clave para la caja fuerte.

He pateado y gritado en el pasado, no tener la tecla esa por lo que si (cuando) se robara algo, no me verían como un posible autor.

Entonces, esto podría haber sido lo mismo para ese programador. No quería tener la tecla que .

Tiene razón en que la situación podría no ser urgente en absoluto, y la reacción laxa de los empleados podría estar justificada. Tal vez el empleado no se molestó con el problema porque el código en cuestión ya no estaba en uso o no tienen secretos allí.

Una vez trabajé para una startup donde todos usaban las mismas claves SSH porque alguien pensó que sería más fácil eliminar / reemplazar una clave si alguien hace algo estúpido.

También existe la posibilidad de que el desarrollador tenga su clave almacenada en una máquina de acceso público como una computadora en la universidad. Esto puede sonar muy poco seguro, pero es adecuado para "Hello World" y "Practice Papers".

En este caso, como ha dicho, la compañía puede estar relativamente segura de que la persona que informó el incidente no intentará lastimar a la compañía. Pero nunca puede estar seguro de quién tiene acceso a la cuenta / claves de la persona que informó el incidente.

No leo polaco, así que perdona todo lo que ya se haya abordado:

Bitbucket aloja git y mercurial repo - ambos son CVS distribuidos; estos son generalmente incompatibles con los controles tecnológicos para proteger la propiedad intelectual / prevenir la salida de IP; cualquier clon / bifurcación existente podría clonarse sin visibilidad de pista de auditoría central.

Deben existir controles de seguridad adecuados para modificar cualquier repo, por ejemplo.

• Firma PKI para todos los confirmaciones
• repositorio de solo lectura con solicitudes de extracción

Por lo tanto, cualquier daño posible ya está hecho.

La seguridad, al final del día, es un conjunto de procesos y procedimientos y una mentalidad. Es no un conjunto de reglas estrictas y rápidas. Si cree que un sistema es vulnerable debido a una mísera infracción, entonces su mentalidad de seguridad es, en el mejor de los casos, defectuosa y podría ser útil solo para Henny Penny / Chicken Little .

• Si las credenciales no están expuestas, ¿a quién le importa? En mi experiencia como programador, administrador de sistemas Linux y encargado de la limpieza / reparación de la seguridad, el problema más grande con el código expuesto en un repositorio es simplemente el Riesgo de que las credenciales estén expuestas. La realidad es que la mayoría los programadores sanos saben cómo codificar sin credenciales de codificación en su código. Pero la mayoría de los programadores son perezosos y tienen idea de por qué, o cómo, alguien puede diseñar un sistema con credenciales separadas del código principal.

  Entonces, si este sistema fue ejecutado por programadores sanos, y el repositorio no expone las credenciales, ¿sabes qué? A quien le importa. Pero, como muchos de nosotros ya sabemos, hay codificadores de nivel de "policía de centro comercial" por ahí que simplemente meten las credenciales en el código del núcleo y eso es todo. Tienes que jugar de oído.

• La exposición a secretos comerciales es un riesgo. Esto depende de la industria y los requisitos en los que se creó el código. Si el código es para un blog o sitio web simple? Lo que sea. Incluso si es un sitio de comercio electrónico, si fuera una copia localizada de algo como Magneto, no es realmente un riesgo, ya que es un software de código abierto. Pero si este software fuera algo patentado y riesgoso para exponer, como algo que pudiera exponer registros financieros y tal vez incluso un código nuevo para un juego, es un riesgo.

Pero al final del día, el trabajo de un hacker de "sombrero blanco" es informar a otros sobre los problemas. Si van a adoptar una actitud de "¿A quién le importa?" Hacia la exposición, ese es su problema. Tal vez realmente no ven ningún riesgo? ¿Quizás realmente no les importa y la exposición perjudicará a los demás? ¿Quizás son idiotas? Tal vez sean tan inteligentes que la exposición a códigos solo significaría, tal vez, ¿unos días de refactorización para limitar el riesgo? Pero al final del día, hay tantas cosas que uno puede hacer para evitar que alguien se lastime a sí mismo.