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

Il tuo collega è fuorviato, soprattutto perché non hai trovato nulla sulla responsabilità della sicurezza nel tuo contratto. Anche se così fosse, hai ricevuto un ordine in conflitto dalla gestione.

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

Nella maggior parte dei casi, la società possiede il software, in modo che possano godere dei profitti, ma significa anche che possono assumersi i rischi, non lo sviluppatore individuale.

Personalmente, mi assicuravo che il management fosse a conoscenza dei problemi con questa funzionalità di sicurezza, quindi è stato documentato in anticipo e continua a svolgere il mio lavoro.

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

Qualunque cosa accada: non scrivere mai tale codice senza avere un'e-mail o altra prova che dimostri chiaramente che hai appena seguito le istruzioni del tuo datore di lavoro.

Da un punto di vista legale, consultare un avvocato. Non ne sono uno, né abbiamo alcuna idea di quale giurisdizione o delle leggi in cui vivi potrebbe contribuire a spiegare alcune cose. Ma in ogni caso consulta un avvocato, ti fideresti di un sito internet di Q & un sito con il tuo futuro personale, professionale e finanziario.

Il consiglio aziendale generale è quello di assicurare che le tue riserve siano scritte per iscritto e che l'ordine diretto del tuo datore di lavoro di continuare a fornire i problemi di sicurezza per iscritto. Se le cose vanno a sud e colpisci la ventola, dovrai ricominciare da capo.

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

Non mi preoccuperei di questo - non è che tu stia decidendo te stesso maliziosamente di inserire la funzionalità insicura e sfruttarla in seguito, o semplicemente inserirla perché sei negligente. L'azienda vuole questo, qualcuno ha deciso che il trade off tra i tempi di sviluppo e le aspettative degli utenti è accettabile (come al solito) e quindi si dovrebbe andare avanti con esso. Se sei veramente preoccupato di eventuali ritorni, invia al tuo capo un'email e conserva la risposta. Una volta che lo hai fatto, come dipendente, sei coperto.

A volte ci sono dei motivi per cui questo è accettabile - ad esempio, so di alcune soluzioni molto mission-critical che memorizzano password in testo normale, ma il resto del sistema è protetto in modo che questo non diventi un problema. Ad esempio, questo sistema si trova 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 questa email dal tuo capo, puoi aspettarti che lui sappia cosa sta facendo.

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

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

Ecco cosa suggerisco:

1. Prima di tutto, con ogni mezzo - è la società che consegna il software all'altra azienda. A un individuo non viene dato un credito diretto (al di là di applausi all'interno della squadra e stipendio al massimo) e la proprietà del lavoro. Quindi, anche se non è una buona cosa come parte della nostra consegna, ma non sei il criminale qui - finché la decisione non è tua.

2. In qualità di programmatore professionista, dovresti indicare chiaramente i limiti del codice e i pericoli impliciti nel modo di mantenere le cose come parte del file README o della documentazione coinvolta. Se esiste un documento sui requisiti, il rapporto di prova suggerito, ecc. Dovrebbe menzionare chiaramente i limiti.

3. Per poter ritenere responsabile il vero decisore, chiederei la versione più alta per confermare il loro pensiero nell'e-mail di tali documenti.

4. Pesare correttamente il rischio. Il mio software per la scheda dati memorizza la password in pianifica il testo ma non è importante. Ma lo stesso non è accettabile se sto memorizzando la password della banca o se è l'accesso al database o al server. Pertanto, in base al rischio reale, è necessario eseguire l'escalation del problema per aumentare il più possibile.

A meno che non svolgete il vostro lavoro in modo volontariamente dannoso, vi è un piccolo svantaggio legale nel fare i compiti che vi vengono richiesti. Avrai un contratto di lavoro che indicherà le tue responsabilità, puoi consultare un avvocato sui dettagli tecnici. Ottieni l'approvazione scritta della decisione di progettazione sulle password in chiaro se ti senti veramente esposto.

I won't reveal which software it is until I'm sure this feature makes it in the final release. I still have hope we manage to inform customers in a way I find it acceptable.

Un po 'più preoccupante è la tua citazione su "informare i clienti". Se danneggiate le vostre aziende, la reputazione ecc. (Una clausola su cui si trova il contratto), la vostra azienda potrebbe farvi causa e una difesa "informatore" potrebbe non essere d'aiuto quando avete bisogno di un riferimento o di un altro lavoro.

Se non sei soddisfatto delle implicazioni delle falle della sicurezza, rispolverai il tuo curriculum e prosegui, ma se non fosse una tua decisione e non la tua azienda non potrei capire perché questo sarebbe "incolpato" (legalmente ) su di te.

La tua azienda dovrebbe aver stipulato una forma di assicurazione per la responsabilità professionale quando ti ha assunto. Questo dovrebbe fornire un'adeguata protezione legale per tutti i suoi dipendenti in caso di qualsiasi cosa che va storto con il software, o uso improprio di software o difetti che si trovano nel software (come password non criptate) ).

Come dipendente dovresti fare quello che chiedono, e dovrebbero fare quello che il cliente vuole, purché nessuna delle parti stia violando la legge, non ci sono problemi, ma se fai quello che vuole la compagnia, e quindi si scopre che non è ciò che il cliente desidera / richiede, quindi questo è tra di loro, e l'assicurazione di responsabilità professionale dovrebbe coprirti da qualsiasi colpa personale / responsabilità.

IANAL, ma vorrei parlarne con il team legale delle società, oltre a verificare con i tuoi avvocati.

PS, se sei seriamente spaventato da questo, salva tutte le e-mail rilevanti in formato elettronico & copia cartacea da qualche parte fuori sede, se possibile.

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

Inoltre, non aver paura quando vai in contatto in modo anonimo con uno dei tanti gruppi che segnalano buchi di sicurezza nel software per i popoli. Questo è un disastro che aspetta di accadere. Non c'è assolutamente alcuna ragione valida per archiviarli. Il tuo capo ti ha dato una ragione? Vogliono accedere come utenti? Vogliono rendere più facile il recupero delle password? A meno che tu non abbia una risposta a una di queste sopra che puoi affrontare in modo più sicuro, è ora di andare avanti. Quando esci, sarebbe meglio non dirgli perché.

che cosa puoi fare per seguire le indicazioni per memorizzare le password in un formato recuperabile mentre è ancora impossibile recuperarle se hai pieno accesso al programma utilizza la crittografia asimmetrica

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

e quando le password sono necessarie in testo semplice, un essere umano deve fornire la chiave privata altrimenti tenuta al sicuro dal server

Personalmente, non ho mai sentito parlare di un ingegnere del software, senza una clausola nel contratto o in un altro accordo formale, essendo ritenuto legalmente responsabile dei problemi di sicurezza dei prodotti su cui lavorano. Da quello che ho letto su leggi ed etica nell'ingegneria del software, i requisiti di sicurezza per un sistema sono dettati dalla specifica dei requisiti, che si riferisce anche a qualsiasi requisito legale, industriale o aziendale. Quando si crea un sistema, il mancato rispetto dei requisiti di sicurezza viene considerato come un errore nel completare i termini del contratto in quanto il sistema non è stato costruito come specificato. Il modo in cui gli eventi specifici si svolgono dipende dai contratti tra l'ingegnere e il datore di lavoro, il datore di lavoro e il cliente.

Le leggi inoltre non ti dicono cosa dovresti fare, ma cosa puoi / non puoi fare. Non menzionate in quale settore siete, ma alcuni hanno leggi, regolamenti e regole su come gestire tipi specifici 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 del software non richiamano requisiti o standard di sicurezza, potrebbe essere più un problema etico che un problema legale.

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

Conformi semplicemente al processo di sviluppo del tuo progetto: se questa funzione è scritta nel documento del requisito, devi implementarla.