Como verás, he editado uno de tus comentarios y borrado los otros dos, por no tener absolutamente nada que ver con el post ni con la temática del blog. Creo que este no es el foro para presentar las reivindicaciones y protestas que comentas, justas o no, por lo que te ruego desistas de continuar en ello.

Gracias y un saludo.

[...]

En cualquier caso, y aun estando contigo en que tanto el ENS como la norma ISO 27002 son mejorables (¿qué no lo es?), es lo que tenemos, y como decía aquél, peor sería una patada en un ojo. Son referenciales, en un caso de obligado cumplimiento y en el otro no, pero son eso, referenciales y puntos de partida a partir de los cuales se puede construir. Es cierto que sobre todo el ENS pasa de puntillas por el tema del desarrollo seguro, y en este ámbito hay que buscar otros referentes como OWASP.
Interesante el artículo que propones. Por cierto, y al hilo de escribir un GOTO sobre el tema: ¿por qué no te animas? Estaremos encantados de recibir tu colaboración, no tienes más que ponerte en contacto con Manuel Benet, el editor de SecurityArtWork.

Un saludo.

Gracias por abrir debate sobre desarrollo seguro y el ENS. No parece que diga gran cosa relativa a seguridad en el ciclo de vida de desarrollo.

El artículo que mencionas (art. 19) parece más enfocado a __hardening__ que a desarrollo seguro.

Tenemos las breves medidas de seguridad sobre desarrollo:

* Desarrollo de aplicaciones [mp.sw.1]
* Aceptación y puesta en servicio [mp.sw.2]

Aunque son un punto de partida, creo que se podrían especificar más, ya que esta ambiguedad y generalidad frente a otras medidas mucho más concretas genera unas diferencias de alcance en las medidas similares a las que se presentan en la ISO 27002 (y es por eso que la odio, por cierto).

En esta línea, os animo a leer [este artículo][1] sobre las promesas rotas en cuanto a la ingeniería de la seguridad que justo he visto cuando leía tu artículo.

[1]: http://lcamtuf.blogspot.com/2010/05/security-engineering-broken-promises.html

Por cierto, que el ENS hace mucho hincapié en productos certificados (hay que promocionar los CC, supongo). ¿Os hace un GOTO sobre este punto? ¿Es la certificación la panacea? ¿Son los productos certificados mejores o sólo los que tienen detrás una empresa capaz de pagar la certificación? ¿Y los perfiles de protección, hasta qué punto pueden ser limitantes y, por lo tanto, reducir la efectividad de la certificación? ¿Y qué pasa con los productos de software libre que no pueden acceder a esta certificación?