I tuoi sviluppatori sono corretti in quanto qualsiasi modifica al repository sarà riflessa da un nuovo commit. I commit precedenti non possono essere modificati senza che a tutti gli sviluppatori venga notificato un conflitto grave durante l'aggiornamento dal repository remoto.
Detto questo, sarebbe semplice per un utente malintenzionato aggiungere un nuovo commit al repository che verrebbe automaticamente scaricato e applicato ai repository locali degli sviluppatori quando si estrae dal server. Trovo estremamente improbabile che i tutti che vengono sottoposti a commit al repository vengano riesaminati manualmente a meno che non si tratti di un progetto usato raramente. Anche se vengono esaminati, un aggressore motivato potrebbe apportare un cambiamento innocuo che ha implicazioni sulla sicurezza. Ad esempio, nel 2003, una persona sconosciuta ha aggiunto un commit al kernel Linux che conteneva una vulnerabilità di escalation della root . Questo accadeva quando Linux utilizzava CVS, ma l'unico vero git di protezione contro questo tipo di attacco è il commit di gpg.
A meno che tu non stia utilizzando firme crittografiche forti per proteggere i tuoi commit, non c'è modo di sapere veramente se una terza parte ha modificato il tuo repository senza eseguire una verifica completa di tutti i commit dello sviluppatore che li ha presumibilmente creati dalla data della compromissione del server. Questo è l'unico modo per assicurarsi veramente che un utente malintenzionato non abbia creato un commit da uno dei tuoi sviluppatori.
Spetta a te determinare se il rischio che l'attaccante lo faccia o no vale lo sforzo di cercare di scoprirlo. Se sei una piccola azienda che produce software che non memorizza, protegge o accede a dati sensibili e questo sembra un tipico compromesso drive-by per trasformare il tuo server in un host spam, probabilmente non mi preoccuperei. Se elaborate grandi quantità di denaro, probabilmente lo farei.
Ora sarebbe anche un buon momento per assicurarti di non memorizzare alcuna credenziale all'interno del tuo repository. Cose come le password del database, le chiavi API per altri servizi, le chiavi TLS ei segreti crittografici utilizzati per l'autenticazione dei cookie di sessione non devono mai essere archiviati insieme al codice sorgente e dovresti considerare quelli che sono stati compromessi e richiedono la rotazione.