Devo accettare di scrivere un codice non sicuro se il mio datore di lavoro mi chiede di farlo? [chiuso]

Il mio datore di lavoro mi ha chiesto di implementare una funzione che richiederebbe l'archiviazione di password in chiaro in un database (o l'utilizzo di un'oscura funzione di crittografia / decrittografia archiviata in un file binario, che è un po 'meglio, ma anche insicuro).

Risposi che ero disposto a implementare tale funzionalità, a condizione che i clienti fossero consapevoli delle implicazioni di sicurezza durante l'utilizzo.

Nel discutere questo problema con i colleghi, qualcuno mi ha detto che, in qualità di ingegnere del software, siamo personalmente responsabili (in senso giuridico) dei problemi di sicurezza che introduciamo nei nostri prodotti. Ho esaminato il mio contratto, ma non ho trovato nulla di simile a un caso simile.

Da un punto di vista legale, dovrei rifiutare di implementare tale funzione? È vero che il mio datore di lavoro potrebbe portarmi in tribunale se un cliente subisce un danno a causa di questa funzione, anche se era a conoscenza di problemi di sicurezza?

EDIT: capisco che questa domanda può essere risolta in modo affidabile solo da un avvocato. Lo stesso vale per le domande sulle licenze: le persone qui danno la loro comprensione e la loro esperienza, a volte dopo aver consultato un avvocato, senza alcuna garanzia che si applichi in un'altra giurisdizione. Ma la licenza è esplicitamente accettata come argomento qui, vedi Che tipo di domande posso porre qui? . Credo che altri programmatori potrebbero avere lo stesso problema, e altri potrebbero essersi già confrontati con questa situazione in precedenza, e per questo potrebbero aver consultato un avvocato.

Il tuo collega è fuorviato, soprattutto perché non hai trovato nulla sulla responsabilità della sicurezza nel tuo contratto. Anche se lo ha fatto, hai appena ricevuto un ordine in conflitto dalla direzione.

Penso che l'unica volta in cui ti sottoponi a potenziali contenziosi è se danneggi consapevolmente il prodotto da solo, crei la tua bomba a orologeria, un uovo di Pasqua, ecc.

Nella maggior parte dei casi, la società possiede il software, quindi possono godere dei profitti, ma significa anche che devono assumersi anche i rischi, non il singolo sviluppatore.

Personalmente, mi assicurerei che la direzione fosse a conoscenza dei problemi con questa funzione di sicurezza, in modo che fosse documentata in anticipo e continuasse a fare il mio lavoro.

Detto questo, consultare un avvocato, yada-yada-yada.

Qualunque cosa accada: non scrivere mai tale codice senza avere una e-mail o altre prove che dimostrino chiaramente che hai appena seguito le istruzioni del tuo datore di lavoro.

Da un punto di vista legale, consultare un avvocato. Non sono uno, né abbiamo idea di quale giurisdizione o legge vivi in ​​base alla quale potresti aiutare a spiegare alcune cose. In ogni caso, consulta un avvocato, ti fideresti di un sito di domande e risposte su Internet con il tuo futuro personale, professionale e finanziario.

Il consiglio aziendale generale è quello di assicurarsi che le tue prenotazioni siano scritte per iscritto e l'ordine diretto del tuo datore di lavoro di continuare, dato i problemi di sicurezza scritti. Se le cose vanno a sud e colpiscono il ventilatore, dovrai ricorrere a questo.

Un altro modo per aggirare questo sarebbe approfondire i requisiti: hai condiviso il piano e non il problema che stai risolvendo. Esistono più modi per scuoiare un gatto o gestire i requisiti di ricerca della password.

Non me ne preoccuperei - non è come se stessi decidendo maliziosamente di inserire la funzionalità non sicura e sfruttarla in seguito, o semplicemente inserirla perché sei negligente. La società lo desidera, qualcuno ha deciso che il compromesso tra i tempi di sviluppo e le aspettative degli utenti è accettabile (come al solito) e quindi dovresti andare avanti. Se sei davvero preoccupato per eventuali ritorni, invia un'email al tuo capo e mantieni la risposta. Una volta che lo hai fatto, come dipendente, sei coperto.

A volte ci sono ragioni per cui questo è accettabile - ad esempio, conosco alcune soluzioni mission-critical che memorizzano password in testo semplice, ma il resto del sistema è protetto in modo che questo non diventi un problema. Questo sistema è ad esempio su una rete separata. Se non conosci il resto della storia (una situazione comune nella maggior parte delle aziende), puoi ragionevolmente aspettarti che qualcun altro lo abbia preso in considerazione. Allo stesso modo, se hai quell'e-mail dal tuo capo, puoi aspettarti che sappia cosa sta facendo.

Per inciso ... è un prodotto che io (come consumatore) potrei usare? Se è così ... che cos'è, quindi posso evitarlo? :)

Ci rendiamo conto che numerosi bug vengono aggiunti dagli sviluppatori che danneggiano i clienti durante le operazioni dal vivo a risorse altrettanto grandi. Non pensiamo che siano intenzionali, ma è ancora il risultato di alcuni dei nostri lavori concreti e non è ancora all'altezza. Quindi l'esempio che hai fatto non è un caso isolato, in cui le decisioni dello sviluppatore (o dei piani superiori) influiscono sul cliente.

Ecco cosa suggerisco:

1. Prima di tutto, è assolutamente la compagnia che consegna il software all'altra società. A un individuo non viene dato un credito diretto (al di là degli applausi all'interno della squadra e della busta paga al massimo) e della proprietà dell'opera. Quindi, anche se questa non è una buona cosa come parte della nostra consegna, ma tu non sei il criminale qui - a condizione che la decisione non sia tua.

2. Come programmatore professionista, indichi chiaramente i limiti del codice e i pericoli connessi a come mantenere le cose come parte del file README o della documentazione in questione. Se esiste un documento sui requisiti, il rapporto di prova suggerito ecc. Dovrebbe menzionare chiaramente i limiti.

3. Al fine di ritenere responsabile il vero decisore, chiederei ai superiori di confermare il loro pensiero nell'e-mail di tali documenti.

4. Pesare correttamente il rischio. Il software della mia scheda dati memorizza la password nel testo del piano, ma ciò non è importante. Ma lo stesso non è accettabile se sto memorizzando la password della banca o se si tratta di accesso al database o al server. Pertanto, in base al rischio reale, è necessario aumentare il problema per aumentare il più possibile.

A meno che tu non svolga il tuo lavoro in modo intenzionalmente dannoso, c'è poco svantaggio legale nel fare i compiti che ti vengono richiesti. Avrai un contratto di lavoro che indicherà le tue responsabilità, puoi consultare un avvocato sui tecnicismi. Ottieni l'approvazione scritta della decisione di progettazione sulle password in chiaro se ti senti davvero esposto.

Non rivelerò quale software è fino a quando non sono sicuro che questa funzione sia disponibile nella versione finale. Spero ancora che riusciamo a informare i clienti in un modo che ritengo accettabile.

Un po 'più preoccupante è la tua citazione sull'informazione dei clienti. Se danneggi la tua azienda, la reputazione, ecc. (Una clausola sulla quale sarà nel tuo contratto), la tua azienda potrebbe farti causa - e una difesa "informatore" potrebbe non aiutarti quando hai bisogno di un riferimento o di un altro lavoro.

Se non sei soddisfatto delle implicazioni dei buchi di sicurezza, rispolvera il tuo curriculum e vai avanti, ma se non fosse una tua decisione e non è la tua azienda, non riesco a capire perché questo sarebbe "incolpato" (legalmente) su di te .

La tua azienda avrebbe dovuto stipulare una forma di assicurazione di responsabilità professionale quando ti ha assunto. Questo dovrebbe fornire una protezione giuridica adeguata per tutti i suoi dipendenti in caso di qualche cosa che non va con il software, o uso improprio di software o difetti essere trovati nel software (come ad esempio le password in chiaro).

Come dipendente dovresti fare quello che chiedono e loro dovrebbero fare quello che il cliente vuole, fintanto che nessuna delle parti infrange la legge, non ci sono problemi, ma se fai ciò che l'azienda vuole, e poi si scopre che non è quello che il cliente voleva / richiesto, quindi che è tra di loro, e l'assicurazione della responsabilità civile professionale dovrebbe coprirti da qualsiasi colpa / responsabilità personale.

IANAL, ma lo prenderei con il team legale delle aziende, oltre a verificare con i tuoi avvocati.

PS, se ne sei seriamente spaventato, salva tutte le email pertinenti in formato elettronico e cartaceo da qualche parte fuori sede, se possibile.

Tempo per un nuovo lavoro. Dimentica l'implementazione. È tempo di muoversi. Se sono disposti a essere così sprezzanti e ingannevoli con questo, non avranno nemmeno paura di buttarti sotto l'autobus.

Inoltre, non aver paura una volta che sei andato a contattare anonimamente uno dei tanti gruppi che indicano buchi di sicurezza nel software delle persone. Questo è un disastro in attesa di accadere. Non c'è assolutamente alcun motivo valido per archiviarli. Il tuo capo ti ha dato una ragione? Vogliono accedere come utenti? Vogliono semplificare il recupero delle password? A meno che tu non ottenga una risposta a una di queste sopra che puoi affrontare in modo più sicuro, allora è tempo di andare avanti. Quando parti, sarebbe meglio non dire loro perché.

cosa puoi fare per seguire le indicazioni per archiviare le password in un formato recuperabile mentre è ancora impossibile recuperare se hai pieno accesso al programma sta usando la crittografia asimmetrica

crittografate la chiave (salata come sempre) con la chiave pubblica memorizzata nel file binario

e quando le password sono necessarie in testo normale, un essere umano deve fornire la chiave privata che altrimenti sarebbe protetta dal server

Personalmente, non ho mai sentito parlare di un ingegnere del software, senza una clausola nel contratto o un altro accordo formale, ritenuto legalmente responsabile per problemi di sicurezza nei prodotti su cui lavorano. Da quanto ho letto sulle leggi e sull'etica nell'ingegneria del software, i requisiti di sicurezza di un sistema sono dettati dalle specifiche dei requisiti, che si riferiscono anche a qualsiasi requisito legale, industriale o aziendale. Durante la costruzione di un sistema, il mancato rispetto dei requisiti di sicurezza viene considerato come un mancato completamento dei termini del contratto poiché il sistema non è stato creato come specificato. Come si svolgono gli eventi specifici dipende dai contratti tra l'ingegnere e il datore di lavoro e il datore di lavoro e il cliente.

Anche le leggi non ti dicono cosa dovresti fare, ma cosa puoi / non puoi fare. Non menzionate il settore in cui vi trovate, ma alcuni hanno leggi, regolamenti e regole su come gestire specifici tipi di dati: cosa deve essere crittografato, livelli minimi di crittografia, requisiti per la gestione / controllo dell'accesso, e così via. Se la tua area (paese, stato) non ha regole sulla sicurezza, il tuo settore non ha regole sulla sicurezza e i requisiti software non definiscono requisiti o standard di sicurezza, potrebbe essere più un problema etico che un problema legale.

Quando si tratta di questioni etiche nello sviluppo del software, sottoscrivo il Codice etico e la pratica professionale di ingegneria del software . In definitiva, è la tua chiamata. Tuttavia, ritengo che archiviare le password in testo semplice o in un formato che può essere decrittografato non sia etico.

Basta conformarsi al processo di sviluppo del progetto: se questa funzionalità è scritta nel documento dei requisiti, è necessario implementarla.