Preoccupazioni e problemi con lo sviluppo di standard di programmazione sicura

Alcuni problemi che ho riscontrato recentemente nello sviluppo di una guida alla programmazione sicura del team:

• In che modo verranno applicate o incoraggiate le linee guida? Chi sarà responsabile per garantire che i prodotti sviluppati in conformità con le linee guida? È necessario assicurarsi che questa persona possa:
  • controlla se le guide sono state rispettate. Ciò significa che devono esaminare le revisioni del codice e i risultati dei test. E che significa che le revisioni e i test del codice devono esistere ed essere eseguiti:).
  • "genera un'eccezione" nel processo di sviluppo. Hanno bisogno dell'autorità per dire no, questa build non è sicura, non può uscire.
  • ispirare il team a prendere sul serio la sicurezza. Sembra un fastidioso gergo da manager, perché lo è, ma non vuoi che i tuoi sviluppatori facciano la sicurezza a malincuore (non ultimo perché diventano dipendenti scontenti, e tu raddoppi i problemi di sicurezza). Questo è particolarmente importante se il "proprietario" della sicurezza dell'app è un outsider del team di sviluppo, ad es. se hai un team di sicurezza trasversale che viene assegnato a progetti di sviluppo.
• In relazione a quanto sopra, in che modo verrà considerata la gestione della sicurezza? Se non lo sono, è un suggerimento sociale di cui i dipendenti non hanno bisogno. Quali sono i premi per l'impegno verso gli standard?
• Che feedback otterrai su come funzionano le linee guida? Vuoi davvero capire:
  • Quali vulnerabilità sono state rilevate durante il rilascio
  • Quali vulnerabilità sono rimaste nel prodotto e perché
  • La parte difficile: a che ora è stato dedicato il tempo a fare cose che significavano aderire alle linee guida, ma non ha avuto un impatto sufficiente sulla sicurezza del prodotto per giustificare il loro costo? La quantità misurabile più vicina che ho trovato è "stiamo spendendo del tempo per mitigare cose che non sono nel modello di minaccia?", Anche se passare molto tempo su articoli a basso rischio rispetto a rischi più elevati è un'altra bandiera rossa.
• Come verrà interpretato tale feedback? Gli sviluppatori possono apportare modifiche da soli se riscontrano un problema o devono essere sottoposti a escalation?

@ La risposta di Graham è molto buona, alcuni punti aggiuntivi da considerare:

• Avrai bisogno di un diverso insieme di linee guida per ogni linguaggio / tecnologia / piattaforma di programmazione. Le linee guida per la codifica in C ++ hanno molto in comune con le linee guida .NET, ma ancora di più non sono in comune.
• Dovrebbero preferibilmente essere adattati al contesto / esigenze / tecnologia / ecc del tuo progetto (ad esempio, tutto è client / server sulla intranet autenticata da 2 fattori, contro tutto è solo internet anonimo basato sul web ...)
• Devono essere sufficientemente dettagliati e prescrittivi per fornire una guida chiara, ma dall'altra non dovrebbero essere considerati onerosamente specifici.
• I campioni di codice sono un must.
• Spiega quali articoli sono obbligatori, che sono raccomandati ma facoltativi e che sono solo una delle loro opzioni. (Usare lo standard MUST/SHOULD/MAY di solito funziona bene qui.)
• In relazione a uno dei punti di @ Graham, hai bisogno del buy-in per i programmatori, che deve essere fatto (come la maggior parte delle cose politiche) delicatamente. Per esempio. fornire una versione di "bozza", per i direttori di sviluppo / i lead di gruppo / etc da esaminare, e dare un feedback specifico su, e l'applicabilità a "le loro situazioni molto speciali" (non è di tutti?). Inoltre, in questo modo potresti scoprire ulteriori tecnologie in uso, di cui non eri a conoscenza (ad esempio MVC, o AOP o ...)
• Formazione! Non scaricare semplicemente un file spesso sui loro desktop, superare i requisiti con gli sviluppatori e spiegare cosa intendono, e perché hanno bisogno di ognuno di essi. (Questa è una buona idea in generale, ovviamente, ma aiuta anche con il punto precedente di buy-in).
• Se hai un solido SDLC, rendilo parte di esso. Se le squadre stanno lavorando "Agile", rendi questa una user story. Tuttavia stanno lavorando, è necessario passare il messaggio, che questo è un deliverable. Ed è obbligatorio.
• Se non hai un SDLC, fallo subito! e fare in modo che le linee guida per la codifica siano parte di ciò.
• "Several levels of requirements" - Non ne hai troppi. Tendono a farsi prendere nella scelta di quello giusto e / o discutono con te di quale realmente hanno bisogno (dal momento che uno è meno lavoro dell'altro), e / o "discutono" di quale livello dovrebbe essere richiesto ogni oggetto da ... Penso che 2 (al massimo 3) dovrebbero funzionare, ad es "Alta sicurezza" e "Sicurezza di base". Comunque tu vada, assicurati che sia super-chiaro a quale livello cadono.
• Fai spazio per le eccezioni - autorizzi un progetto specifico per ottenere un passaggio su determinati articoli, in base alle circostanze (e ai controlli di compensazione). Preferibilmente temporaneo. Ma ben documentato.
• Tienilo aggiornato, rivedilo ogni tanto - con il feedback degli sviluppatori E le metriche, una nuova versione per soddisfare qualsiasi nuova tecnologia che usano, ecc.