Sus desarrolladores tienen razón en que cualquier cambio en el repositorio se reflejará en un nuevo compromiso. Las confirmaciones anteriores no se pueden modificar sin que se notifique a todos los desarrolladores un conflicto grave al actualizar desde el repositorio remoto.
Dicho esto, sería trivial que un atacante agregue un nuevo compromiso al repositorio que se descargará automáticamente y se aplicará a los repositorios locales de los desarrolladores cuando se extraiga del servidor. Me parece extremadamente improbable que todas las confirmaciones en el repositorio se revisen manualmente a menos que este sea un proyecto muy poco utilizado. Incluso si se revisan, un atacante motivado podría realizar un cambio de apariencia inocua que tiene implicaciones de seguridad. Por ejemplo, en 2003, una persona desconocida agregó un compromiso al kernel de Linux que contenía una vulnerabilidad de escalada de raíz . Esto fue cuando Linux estaba usando CVS, pero la única protección real que tiene git contra este tipo de ataque es la confirmación firmada por gpg.
A menos que esté utilizando firmas criptográficas sólidas para proteger sus confirmaciones, no hay forma de saber realmente si un tercero modificó su repositorio sin realizar una auditoría completa de todas las confirmaciones por parte del desarrollador que supuestamente las creó desde la fecha de compromiso del servidor. Esta es la única forma de garantizar realmente que un atacante no haya forjado un compromiso por parte de uno de sus desarrolladores.
Depende de usted determinar si el riesgo de que el atacante haya hecho esto vale o no el esfuerzo que implica tratar de descubrirlo. Si usted es una pequeña empresa que crea software que no almacena, protege o accede a datos confidenciales y parece un compromiso típico de drive-by para convertir su servidor en un servidor de correo no deseado, probablemente no me molestaría. Si procesas grandes cantidades de dinero, probablemente lo haría.
Ahora también sería un buen momento para asegurarse de que no está almacenando ninguna credencial dentro de su repositorio. Cosas como las contraseñas de la base de datos, las claves API a otros servicios, las claves TLS y los secretos criptográficos utilizados para la autenticación de cookies de sesión nunca deben almacenarse junto con su código fuente, y debe tener en cuenta que se han comprometido y requieren rotación.