Preocupaciones y Gotcha con el desarrollo de estándares de programación segura

Algunos problemas que encontré al desarrollar la guía de programación segura de un equipo recientemente:

• ¿Cómo se aplicarán o alentarán las directrices? ¿Quién será responsable de garantizar que los productos se desarrollen de acuerdo con sus directrices? Debe asegurarse de que esta persona pueda:
  • ver si las guías están siendo adheridas. Esto significa que necesitan mirar las revisiones de código y los resultados de las pruebas. Y eso significa que las revisiones y pruebas del código deben existir y realizarse :).
  • "lanzar una excepción" en el proceso de desarrollo. Necesitan la autoridad para decir no, esta construcción no es segura, no puede salir.
  • inspira al equipo a tomar en serio la seguridad. Suena como un fastidioso discurso de administración, porque lo es, pero no quiere que sus desarrolladores hagan la seguridad a regañadientes (sobre todo porque se convierten en empleados descontentos y duplica sus dolores de cabeza). Esto es particularmente importante si el "propietario" de la seguridad de la aplicación es un forastero del equipo de desarrollo, por ejemplo. si tiene un equipo de seguridad transversal que se adscribe a proyectos de desarrollo.
• En relación con lo anterior, ¿cómo se verá que la administración está tomando en serio la seguridad? Si no lo son, entonces es un indicio social de que los empleados tampoco lo necesitan. ¿Cuáles son las recompensas por comprometerse con las normas?
• ¿Qué comentarios obtendrás sobre cómo funcionan las directrices? Realmente quieres entender:
  • ¿Qué vulnerabilidades se descubrieron durante la publicación?
  • ¿Qué vulnerabilidades quedaron en el producto y por qué?
  • Lo difícil: ¿qué tiempo se dedicó a hacer las cosas que significaban adherirse a las directrices pero no afectaron la seguridad del producto lo suficiente como para justificar su costo? La cantidad medible más cercana que he encontrado es "¿estamos dedicando tiempo a mitigar cosas que no están en el modelo de amenaza?", Aunque pasar mucho tiempo en artículos de bajo riesgo en comparación con riesgos más altos es otra bandera roja.
• ¿Cómo se actuará tal retroalimentación? ¿Pueden los desarrolladores hacer cambios por sí mismos si encuentran un problema o es necesario escalarlo?

La respuesta de @ Graham es muy buena, algunos puntos adicionales a considerar:

• Necesitará un conjunto diferente de directrices para cada lenguaje de programación / tecnología / plataforma. Las directrices de codificación de C ++ tienen mucho en común con las directrices de .NET, pero aún más no son comunes.
• Preferiblemente, deben adaptarse al contexto / necesidades / tecnología / etc de sus proyectos (por ejemplo, todo es cliente / servidor en la intranet autenticada de 2 factores, y todo es solo internet anónimo basado en web ...)
• Deben ser lo suficientemente detallados y prescriptivos para proporcionar una guía clara, pero por otro lado no deben sentirse tan específicamente específicos.
• Las muestras de código son obligatorias.
• Deje en claro qué elementos son obligatorios, cuáles son recomendados pero opcionales, y cuáles son solo una de sus opciones. (El uso del estándar MUST/SHOULD/MAY por lo general funciona bien aquí).
• Relacionado con uno de los puntos de @Graham, necesita la participación del programador, que debe hacerse (como la mayoría de las cosas políticas) con delicadeza. P.ej. proporcione una versión "borrador" para que los gerentes de desarrollo / jefes de equipo / etc los revisen, y proporcionen comentarios específicos sobre la aplicabilidad de wrt a "sus situaciones muy especiales" (¿no es de todos?). También de esta manera puede descubrir tecnologías adicionales en uso, que no conocía (por ejemplo, MVC, AOP o ...)
• Entrenamiento! No solo descargue un archivo grueso en sus escritorios, repase los requisitos con los desarrolladores y explique qué significan, y por qué necesitan cada uno. (Esta es una buena idea en general, por supuesto, pero también ayuda con el punto anterior de compra).
• Si tiene un SDLC sólido, haga de esto parte de él. Si los equipos están trabajando "Agile", haga de esta una historia de usuario. Sin embargo, están trabajando, es necesario transmitir el mensaje, que esto es un entregable. Y es un requisito.
• Si no tiene un SDLC, ¡haga uno ahora! y hacer las directrices de codificación parte de eso.
• "Several levels of requirements" - No tengas muchos de estos. Tendrán a estar atrapados en la selección de la correcta, y / o discutirán con usted acerca de cuál realmente necesitan (ya que una es menos laboriosa que la otra), y / o "discuten" a qué nivel se debe requerir cada elemento. por ... Creo que 2 (a lo sumo 3) deberían funcionar, por ejemplo "Alta seguridad" y "Seguridad básica". Sin embargo, vaya, asegúrese de que esté muy claro en qué nivel se encuentran.
• Haga espacio para las excepciones, es decir, autorice un proyecto específico para obtener un pase sobre ciertos elementos, según las circunstancias (y los controles de compensación). Preferiblemente temporal. Pero bien documentado.
• Manténgalo actualizado, revíselo periódicamente: con comentarios de los desarrolladores Y las métricas, tenga una nueva versión para conocer cualquier nueva tecnología que utilicen, etc.