Insights sobre códigos de seguridad

Durante años, los responsables de seguridad han invertido mucho en programas de codificación segura, pero una pregunta fundamental sigue sin respuesta: ¿Sabemos realmente quién está introduciendo código y posee las habilidades necesarias para escribir, revisar y, en última instancia, entregar código seguro?

Los enfoques tradicionales de "cambio a la izquierda" dejan a las empresas luchando con enormes puntos ciegos cuando se trata de descubrir e incorporar desarrolladores para programas de codificación segura. Como los administradores de programas dependen de comprobaciones manuales, hojas de cálculo y estructuras orgánicas de RR.HH. para realizar un seguimiento de las habilidades de codificación segura de los desarrolladores, a menudo surgen "desarrolladores en la sombra" que contribuyen con código a través de bases de código críticas pero carecen de competencia en seguridad. Esta realidad socava gravemente los objetivos de un SDLC seguro y complica la gobernanza, dificultando la demostración de la competencia en materia de seguridad a la hora de enfrentarse a revisiones internas o externas.

Secure Code Warrior's Trust Agent elimina este riesgo, transformando su programa de codificación segura en una defensa verificable y supervisada continuamente que proporciona a los responsables de seguridad de aplicaciones y a los CISO la confianza necesaria para demostrar que sus desarrolladores poseen la competencia necesaria en materia de seguridad en cada commit.

Supervisión y garantía continuas con el agente fiduciario

Sin una supervisión continua, el riesgo para los desarrolladores permanece oculto. Trust Agent ofrece una visibilidad continua al hacer operativa la seguridad en el nivel de confirmación del código.

Descubrimiento continuo del desarrollador: Conocer el alcance

Antes de asegurar su código base, debe saber quién lo está tocando.

Trust Agent explora automáticamente sus repositorios integrados para descubrir a todos los contribuidores de código activos en toda su base de código. Esto ayuda a abordar un reto crítico de la incorporación, un proceso continuo, y responde a la pregunta: ¿sabe cuándo se incorporan nuevos ingenieros o contratistas, y si están recibiendo formación inmediata y relevante sobre codificación segura? Mediante la supervisión continua de los commits, nos aseguramos de que todos los desarrolladores sean identificados inmediatamente y de que su viaje hacia la codificación segura pueda comenzar, eliminando los retrasos típicos de la incorporación y garantizando el alcance integral del programa.

‍

Competencia verificada: Supervisar el código, no sólo la finalización del aprendizaje

Además de descubrir a todos los contribuidores de código, Trust Agent transforma los datos de aprendizaje en pruebas fehacientes mediante la supervisión continua de las habilidades de codificación segura aplicadas en tiempo real. Proporciona una profunda capacidad de observación mediante la correlación de cada confirmación de código con la competencia de codificación segura específica del lenguaje verificada del desarrollador.

Esto es crucial para mandatos como PCI DSS 4.0 (Requisito 6.2.2), que exige específicamente la formación en código seguro cada 12 meses en el lenguaje o marco en el que los desarrolladores envían el código. Trust Agent le proporciona las pruebas auditables necesarias para demostrar que la competencia en seguridad está alineada con los lenguajes y marcos de trabajo utilizados en sus aplicaciones críticas.

Además, Trust Agent proporciona información inmediata sobre su postura de riesgo al señalar qué equipos o repositorios de código tienen grandes volúmenes de commits de desarrolladores sin los conocimientos de seguridad adecuados. Esta visibilidad permite a los administradores del programa asignar fácilmente la formación adecuada a los desarrolladores adecuados basándose en los datos más relevantes en tiempo real.

Gobernanza integrada y control de las políticas

En última instancia, la gobernanza debe aplicarse para reducir realmente el riesgo para la seguridad de los desarrolladores. Trust Agent ofrece la posibilidad de hacer obligatoria la competencia en seguridad trasladando los controles directamente a los flujos de trabajo de desarrollo existentes, con la capacidad de definir políticas de confirmación basadas en la tolerancia al riesgo de su organización. Trust Agent automatiza la gobernanza directamente en el flujo de trabajo de confirmación, con puertas de políticas que pueden configurarse para registrar, advertir o bloquear solicitudes de extracción si el nivel de conocimientos de codificación segura de un desarrollador es insuficiente. Esta gobernanza integrada es la clave para garantizar realmente que la seguridad es un requisito y no una sugerencia opcional.
‍

Garantizar el futuro del desarrollo

El paso a una competencia verificable en codificación segura no consiste solo en pasar auditorías; al fin y al cabo, se trata de enviar código innovador y seguro. Incluso o especialmente con el aumento del desarrollo asistido por IA, el principio fundamental sigue siendo: los desarrolladores deben ser competentes en seguridad para reducir realmente el riesgo. Al hacer que la competencia en codificación segura de los desarrolladores sea un requisito medible, SCW Trust Agent es la pieza crítica que garantiza que su organización no solo cumpla las obligaciones normativas y de conformidad, sino que refuerce fundamentalmente su postura de seguridad desde dentro.

Para obtener más información, reserve una demostración o póngase en contacto con su Gestor de Éxito de Clientes hoy mismo.

‍

AI 지원 개발은 더 이상 가능하지 않습니다. 이제 AI 지원 개발이 현실로 다가왔고, 이로 인해 소프트웨어 작성 방식이 빠르게 바뀌고 있습니다.GitHub Copilot, Cline, Roo, Cursor, Aider, Windsurf와 같은 도구는 개발자를 자체 공동 파일럿으로 탈바꿈시켜 프로토타입 제작부터 주요 리팩토링 프로젝트까지 모든 것을 가속화하고 반복 작업을 가속화합니다.

하지만 이러한 변화에는 익숙한 긴장감이 따릅니다. 바로 속도와 보안입니다.

Secure Code Warrior에서는 개발자가 AI 코딩 도구를 사용하는 동안 보안을 유지할 수 있도록 지원하는 방법에 대해 많은 고민을 해왔습니다. 그래서 우리는 단순하고 강력하며 즉시 유용한 제품을 출시하게 되어 기쁩니다. 바로 우리의 AI 보안 규칙 — GitHub의 모든 사용자가 무료로 사용할 수 있는 공개 리소스입니다. Secure Code Warrior 고객이 아니어도 사용할 수 있습니다. Secure Code Warrior 고객은 누구나 이러한 규칙을 커뮤니티 중심의 무료 기반으로 제공하여 누구나 자신의 프로젝트에 적용하고 확장할 수 있습니다.

이러한 규칙은 개발자가 빠른 속도로 움직이고 있는 경우에도 AI 도구를 더 안전한 코딩 관행으로 유도하는 가드레일 역할을 하도록 설계되었습니다.

바쁘신 분들을 위한 요약:

Copilot 및 Cursor와 같은 AI 코딩 도구가 현대 개발의 필수 요소가 됨에 따라 보안은 더 이상 고려하지 않아도 됩니다.그래서 AI 코드 생성을 보다 안전한 기본값으로 안내하기 위해 가벼운 보안 우선 규칙 세트를 구축했습니다.

• 웹 프론트엔드, 백엔드, 모바일 포함
• AI 도구에 쉽게 적용
• 공개적이고 무료로 사용할 수 있으며 자체 프로젝트에 바로 적용 가능

규칙 살펴보기 → https://github.com/SecureCodeWarrior/ai-security-rules

키보드에서 AI를 사용하는 경우에도 보안 코딩을 기본값으로 설정해 보겠습니다.

1.AI 지원 코딩 시대에 규칙이 중요한 이유

AI 코딩 도구는 매우 유용하지만 완벽하지는 않습니다.작업 코드를 빠르게 생성할 수는 있지만 특정 팀 또는 프로젝트의 특정 표준, 규칙 및 보안 정책을 이해하는 데 필요한 뉘앙스가 부족한 경우가 많습니다.

여기서 프로젝트 레벨 규칙 파일이 작동합니다.

Cursor 및 Copilot과 같은 최신 AI 도구는 코드 생성 방식에 영향을 주는 구성 파일을 지원합니다.이러한 규칙 파일은 AI의 귀에 속삭이는 소리와 같은 역할을 하며 다음과 같이 알려줍니다.

“이 프로젝트에서는 SQL 문자열을 절대 연결하지 않습니다.”
“안전하지 않은 기본값보다 안전한 헤더가 있는 가져오기를 선호합니다.”
“보안 감사를 원하지 않는 한 eval () 을 사용하지 마십시오.”

이러한 규칙은 강력한 코드 검토 관행과 보안 도구를 대체할 수 있는 것은 아니지만, AI 생성 코드를 팀이 보안 개발을 위해 이미 따르고 있거나 따라야 하는 관행에 맞추는 데 도움이 될 수 있습니다.

2.우리가 만든 것 (그리고 만들지 않은 것)

스타터 규칙은 현재 a에서 사용할 수 있습니다. 퍼블릭 깃허브 리포지토리.이들은 다음과 같습니다.

• 도메인별로 구성 — 웹 프론트엔드, 백엔드, 모바일 포함
  
• 보안 중심 — 주입 결함, 안전하지 않은 처리, CSRF 보호, 취약한 인증 흐름 등과 같은 반복되는 문제를 다룹니다.
  
• 가벼운 디자인 — 이 제품은 완전한 규칙서가 아니라 실용적인 출발점이 되기 위한 것입니다.

AI 컨텍스트 윈도우가 얼마나 중요한지, 코드가 이러한 토큰을 얼마나 빨리 소비하는지 잘 알고 있기 때문에 규칙을 명확하고 간결하게 유지하고 엄격하게 보안에 초점을 맞췄습니다.우리는 언어별 또는 프레임워크별 지침을 피하고, 대신 아키텍처나 디자인에 대해 의견이 분분하지 않고 광범위한 환경에서 작동하는 광범위하게 적용할 수 있고 영향력이 큰 보안 관행을 채택하기로 신중하게 결정했습니다.

이러한 규칙은 리팩토링을 거의 또는 전혀 하지 않고도 지원되는 AI 도구 구성 형식에 쉽게 적용할 수 있도록 작성되었습니다.AI를 안전한 기본값으로 유도하는 일련의 시작 정책이라고 생각하시면 됩니다.

3.새로운 방어 계층

실제 모습은 다음과 같습니다.

• AI가 사용자 입력을 처리하는 코드를 제안할 때는 베어 프로세싱이 아닌 검증과 인코딩 쪽으로 기울습니다.
  
• 데이터베이스 쿼리를 작성할 때는 문자열 연결이 아닌 매개변수화를 권장할 가능성이 높습니다.
  
• 프런트엔드 인증 흐름을 생성할 때 AI는 안전하지 않은 로컬 스토리지 해킹이 아닌 토큰 처리 모범 사례를 홍보할 가능성이 높습니다.

이 모든 것이 지속적인 보안 기술 향상을 포함하여 보안 프로그램 내의 전략적 개발자 위험 관리를 대체하는 것은 없습니다.또한 보안에 능숙한 개발자의 필요성이 사라지지는 않습니다. 특히 LLM을 도입하고 AI 생성 코드를 검토하는 개발자들이 점점 더 많아지고 있기 때문입니다.이러한 가드레일은 특히 개발자들이 빠르게 움직이거나 멀티태스킹을 하거나 단순히 툴을 지나치게 신뢰하는 경우 의미 있는 방어 체계를 제공합니다.

다음은 무엇일까요?

이것은 완성된 제품이 아니라 출발점입니다.

AI 코딩 도구가 진화함에 따라 보안 개발에 대한 우리의 접근 방식도 발전해야 합니다.우리의 AI 보안 규칙 무료로 사용할 수 있고 프로젝트에 맞게 조정 및 확장할 수 있습니다.우리는 이러한 규칙 세트를 지속적으로 발전시키기 위해 최선을 다하고 있으며, 여러분의 의견을 듣고 싶습니다. 시험해 보고 어떻게 생각하는지 알려주세요.

GitHub에서 규칙을 살펴보세요
SCW Explore에서 규칙 사용 지침을 읽어보십시오.

AI 지원 코딩은 이미 우리가 소프트웨어를 만드는 방식을 바꾸고 있습니다.처음부터 보안을 유지하도록 합시다.

Hoy en día, casi todos los equipos de desarrollo emplean algún tipo de formación en materia de cumplimiento normativo, ya sea como parte de un proceso de certificación inicial utilizado para garantizar que una empresa se mantiene dentro de los límites de los marcos del sector o de la normativa gubernamental, o como parte de un requisito o revisión anual. Es un paso importante, porque si una organización no puede cumplir los requisitos básicos de cumplimiento, sus trabajadores no pueden desempeñar sus funciones de forma realista.

Las normas de cumplimiento existen por una razón, porque cualquier persona que trabaje en el campo que cubren esas normas debe tener al menos una comprensión fundamental de todos los procesos y procedimientos pertinentes, así como de cualquier ley aplicable.

Aunque la formación en materia de cumplimiento es importante, completar los requisitos mínimos obligatorios no garantiza la verdadera seguridad de las aplicaciones. Esto es especialmente cierto para los desarrolladores que intentan integrar las habilidades de codificación segura en su flujo de trabajo diario. Casi todos los desarrolladores reciben algún tipo de formación sobre el cumplimiento de la normativa y, sin embargo, cuando se les encuestó, el 67% admitió que a menudo dejaban vulnerabilidades en su código.

¿Por qué?

Por segundo año, Secure Code Warrior realizó la encuesta "The state of developer-driven security survey, 2022" en colaboración con Evans Data Corp en diciembre de 2021. Encuestamos a 1200 desarrolladores de todo el mundo para conocer las habilidades, percepciones y comportamientos en lo que respecta a las prácticas de codificación segura, así como su impacto y relevancia percibida en el ciclo de vida del desarrollo de software (SDLC).

En cuanto a las razones por las que la formación sobre el cumplimiento de la normativa no consigue mejorar la seguridad de los programas informáticos, es una cuestión de la que llevamos hablando mucho tiempo. La reciente encuesta simplemente pone de manifiesto este problema.

Por un lado, se pide a los desarrolladores que asuman nuevas funciones incluyendo la ciberseguridad en todo el proceso de desarrollo de software, incluso cuando escriben inicialmente el código de las aplicaciones y programas. Pero escribir código seguro, o incluso simplemente aprender todo sobre los problemas de ciberseguridad y las vulnerabilidades que podrían afectarlo, no es una tarea fácil.En la encuesta, el 63% de los desarrolladores dijo que escribir código seguro era una tarea difícil.

La dificultad de escribir código seguro no debería ser una sorpresa. Hay una razón por la que tantos puestos de trabajo de ciberseguridad bien pagados no se cubren, con más de 3,5 millones de vacantes en todo el mundo según el último recuento. Si fuera un trabajo fácil, todo el mundo se lanzaría a ese campo. Aprender a combatir las amenazas y eliminar las vulnerabilidades dentro del código es difícil, y el panorama de las amenazas cambia constantemente. La formación estática sobre el cumplimiento de la normativa o las clases únicas no pueden seguir el ritmo ni proporcionar el tipo de educación que necesitan los desarrolladores. Puede marcar una casilla en términos de cumplimiento, pero no puede proporcionar garantías reales de seguridad de las aplicaciones para su organización o permitir a los desarrolladores escribir código seguro, o las habilidades para encontrar y corregir las vulnerabilidades del código.

El cumplimiento y la formación en seguridad son importantes, pero diferentes

Las organizaciones deben empezar a darse cuenta y reconocer lo que la formación en materia de cumplimiento puede hacer, y lo que no. No abandone la formación en materia de cumplimiento, especialmente si es obligatoria por ley. Y sobre todo porque (incluso con los métodos de formación actuales) el 92% de los encuestados declaró que necesitaba al menos algo de formación en cuestiones relacionadas con el cumplimiento o los marcos de seguridad, y el 50% subrayó la necesidad de una formación importante en materia de cumplimiento.

Entre los marcos de cumplimiento que más les interesan para formarse están los específicos de varios sectores, aunque también figuran en la lista varios marcos generales de ciberseguridad. Entre ellos se encuentran el Marco de Seguridad CIS, PCI DSS, el OWASP Top 10, MISRA C, ISO/IEC, la Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA) y otros.

Así que sí, forme en esos marcos, pero entienda que marcar una casilla en la formación de cumplimiento no equivale a proporcionar una base para la creación continua de código seguro.

En su lugar, considere la formación en materia de cumplimiento como parte de una oportunidad continua para ampliar las habilidades de codificación segura de sus desarrolladores, que pueden repetirse fuera del ciclo de cumplimiento, de modo que puedan crear y publicar software seguro todos los días. Cambie la prioridad de lograr el cumplimiento a permitir que los equipos de desarrollo codifiquen de forma segura con un aprendizaje continuo. Si invierte tiempo y recursos en la capacitación de los desarrolladores, los ejercicios o exámenes anuales de cumplimiento se convertirán en un juego de niños para que su personal los apruebe y los complete, mientras se beneficia de una mayor productividad en general.

¿Cómo se puede dar el paso a la seguridad impulsada por los desarrolladores?

Los desarrolladores afirmaron mayoritariamente que la formación era valiosa, pero se mostraron disconformes con el tipo de formación que han recibido en materia de codificación segura a lo largo de los años. Los desarrolladores dijeron que querían que se hiciera más hincapié en la formación práctica con ejemplos del mundo real que fueran relevantes para sus trabajos (30%). El 26% de los encuestados también considera que es fundamental una mayor interactividad, especialmente si pueden practicar la escritura de código seguro como parte de esos ejercicios.

El 23% de los desarrolladores encuestados consideró importante recibir una formación más guiada, centrada en las vulnerabilidades específicas con las que era más probable que se encontraran en su industria o sector, mientras que el 22% quería ver más ejemplos de vulnerabilidades del mundo real en su formación courses.

Está claro que limitarse a impartir una formación estática y no interactiva (que suele ser la experiencia de la formación en materia de cumplimiento) tiene poco valor en términos de habilidades de seguridad repetibles para los desarrolladores. En su lugar, las organizaciones deberían centrarse en cosas como la formación "justo a tiempo", en la que se enseña a los desarrolladores sobre seguridad a medida que trabajan. Incluso se podría considerar la posibilidad de implementar un programa de aprendizaje por niveles.

Con un enfoque escalonado, los temas más amplios suelen dividirse en experiencias de aprendizaje o conceptos discretos. A medida que los desarrolladores progresan, los conceptos más avanzados se superponen a los que ya dominan, al igual que se construye un andamiaje físico a medida que un edificio crece. Se trata de un método probado para enseñar un tema difícil y en constante evolución como la ciberseguridad, dividiéndolo primero en trozos más pequeños y menos complejos y luego construyendo más complejidad sobre esa base.

Sea cual sea el enfoque que le dé a su programa de habilidades de seguridad para desarrolladores, será clave mantenerlo separado de los ejercicios de cumplimiento. Tanto el cumplimiento como la formación en seguridad son importantes, y ambos requieren enfoques diferentes para lograr el éxito.

Para más información

Libro blanco: Los retos (y oportunidades) para mejorar la seguridad del software.

Libro blanco: El enfoque preventivo de los desarrolladores sobre la seguridad del software.

Informe: El estado de la seguridad impulsada por los desarrolladores.

Lasmismas 10 vulnerabilidades de software han causado más violaciones de seguridad en los últimos 20 años que cualquier otra. Sin embargo, muchas empresas siguen optando por la reparación posterior a la brecha y al evento, y se enfrentan a las ramificaciones humanas y empresariales de todo ello. Pero ahora un nuevo estudio de investigación apunta a una nueva dirección, dirigida por el ser humano.

Acontinuación se analizan las ideas derivadas de un estudio realizado por Secure Code Warrior con Evans Data Corp titulado "Shifting from reaction to prevention: La cara cambiante de la seguridad de las aplicaciones" (2021) que explora las actitudes de los desarrolladores hacia la codificación segura, las prácticas de código seguro y las operaciones de seguridad. Descargue el informe técnico aquí.

En el estudio, que se publicará próximamente, se preguntó a los desarrolladores y directores de desarrollo sobre las actividades que asocian a la codificación segura. Las tres primeras respuestas fueron:

• Uso de herramientas de escaneo en las aplicaciones desplegadas.
• Revisar manualmente el código en busca de vulnerabilidades.
• La práctica activa y continua de escribir software que esté protegido de las vulnerabilidades.
  

¿Qué nos dice esto? Dos de las tres respuestas principales siguen centrándose en enfoques reactivos, el primero dependiente de herramientas (escáneres) y el segundo del desarrollador (es decir, humano) que realiza comprobaciones manuales, en ambos casos después de escribir el código. Las vulnerabilidades detectadas con estos métodos tienen que devolverse al equipo de desarrollo para que las revise, lo que repercute en los plazos y los costes del proyecto.

Al mismo tiempo, dos de las tres actividades nominadas se basan en el elemento humano, lo que indica que la seguridad se percibe cada vez más como una cuestión humana. Pero de todas las actividades nominadas, la más reveladora es la número 3, que identifica el factor humano en la redacción de software protegido de las vulnerabilidades en primer lugar. Esto pone de manifiesto un cambio hacia la izquierda: un enfoque proactivo y preventivo que incorpora la seguridad al software desde el principio del ciclo de vida de su desarrollo. 

Reactivo puede ser igual a CARO

Según un estudio de IBM*, es treinta veces más caro arreglar las vulnerabilidades en el código posterior al lanzamiento que si se detectan y remedian al principio. Esto es un poderoso incentivo para un nuevo enfoque proactivo y más humano de la defensa de la seguridad del software que equipa a los desarrolladores para codificar de forma más segura, desde el principio. 

Esto es lo que podríamos llamar una defensa dirigida por el ser humano. Pero para que los desarrolladores empiecen a preocuparse por la seguridad, ésta tiene que formar parte de su forma de pensar y de codificar cada día. Se trata de un llamamiento a nuevos enfoques de formación que sean hiperrelevantes para el trabajo diario de los desarrolladores y que les inspiren el deseo de aprender, algo que no se puede decir de los modelos de formación actuales.

Para crear una cultura de seguridad proactiva, se necesita una nueva formación que:

• hace que la codificación segura sea una experiencia positiva y atractiva para los desarrolladores a medida que aumentan sus conocimientos de seguridad del software 
• anima a los desarrolladores a ver sus tareas diarias de codificación con una mentalidad de seguridad 
• hace que la codificación segura sea intrínseca a su flujo de trabajo diario
  

Cuando estos hilos se unen, se evita que las vulnerabilidades se produzcan en primer lugar, lo que permite a los equipos enviar código de calidad más rápidamente, con confianza. La buena noticia es que ya existe un Learning Platform que "empieza por la izquierda" en el proceso de desarrollo de software, que ya está dotando a los desarrolladores de las habilidades y herramientas para crear código de calidad desde el principio.

‍

*IBM Software Group; Minimizar los defectos de código para mejorar la calidad del software y reducir los costes de desarrollo
https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.

Cuando hablo con los desarrolladores sobre seguridad, uno de mis mantras es que "el único código de calidad es el código seguro". Esto sigue siendo cierto; puede que nos hayamos librado del desastre cuando el software vulnerable estaba en la calle en los años 90, pero no vale la pena correr el riesgo hoy en día. A lo largo de los años, muchos han trabajado duro para inculcar a los desarrolladores una mentalidad consciente de la seguridad y, al hacerlo, han conseguido que la seguridad sea sinónimo de calidad cuando se trata de un autoassessment de su código.

Sin embargo, después de reflexionar (y de debatir con mis compañeros), quizá sea simplificar demasiado el concepto. Es totalmente posible crear un código que sea realmente seguro, pero que muestre signos de una técnica de desarrollo novata, o de otras áreas problemáticas que lo hagan menos que ideal.

Nuestro sector habla largo y tendido sobre la noción de "desplazamiento hacia la izquierda". En mi opinión, se trata de "empezar" por la izquierda permitiendo a las cohortes de ingenieros compartir la responsabilidad de la seguridad (al ser un aspecto de la calidad), y dándoles el poder de borrar las vulnerabilidades comunes al alcance de su mano (literalmente). Sin embargo, a la luz de este enigma actual, parece que hay que ir un poco más allá.

El código de cierto nivel de calidad es, por definición, también seguro, pero todo el código seguro no es necesariamente de buena calidad. ¿Es la fórmula de empezar por la "izquierda de la izquierda" para garantizar unos estándares de codificación seguros puros?

¿Qué aspecto tiene un código seguro de "mala calidad"?

Pongamos la lupa sobre este fragmento de código:

Si analizamos este código desde el punto de vista de la seguridad, este fragmento es efectivamente seguro, y no es un punto de entrada para que un atacante explote una vulnerabilidad de inyección SQL.  

¿Es un ejemplo de código de alta calidad? Desgraciadamente, no. Un simple cambio en el argumento de un int(eger) a un valor String permite que la entrada del usuario de forma libre manipule la consulta, en contraste con un número que no puede. Ese cambio -o un copiado y pegado desordenado del String sql desde otro lugar- crea inmediatamente un entorno en el que son posibles las vulnerabilidades de inyección SQL, y todos los riesgos asociados a ellas:

Las medidas de seguridad tenían aquí un alcance muy limitado, mientras que un desarrollador más minucioso (o, experimentado) podría haber adoptado un enfoque diferente y haber considerado las implicaciones de una estructura de argumentos ineficiente. Enviar código de esta manera no sólo es una mala práctica, sino que da un mal ejemplo a otros miembros de la cohorte de desarrollo.

La "triple amenaza" del software: Forma, función, ¿fortaleza?

Una "triple amenaza" en la industria del entretenimiento es un individuo que puede actuar, bailar y cantar con un nivel igualmente alto de habilidad. Son las personas temidas y envidiadas en cada audición, y son los unicornios de un espacio ya competitivo. Cada industria tiene su propia versión de un ejemplo excepcional de sus productos y servicios, y el software no es una excepción.

Si pensamos en tres elementos clave en las aplicaciones que son difíciles de equilibrar con una calidad igual (alta), podrían ser la funcionalidad/elegancia, más la seguridad férrea, más la rentabilidad si se tiene en cuenta la velocidad de entrega requerida. Ahora bien, este último atributo es, sin duda, un factor definitorio de la aplicación de las otras dos opciones, y puede ser un catalizador para que la calidad general decaiga con el tiempo.

Sin embargo, ¿es necesario que todos los programas informáticos actúen como Hugh Jackman, o podemos salirnos con la suya con Nicolas Cage? Pongámoslo así: si puedes tener a Lobezno en tu equipo, entonces da lo mejor de ti.

Martin Fowler se preguntó si la alta calidad merecía la pena en el desarrollo de software, y llegó a la conclusión de que no sólo "merecía la pena", sino que además era más barata con el tiempo. La mayoría de los usuarios no van a mirar bajo el capó para evaluar si el código es un desastre, ni si la seguridad se hizo tan importante todo lo demás. Sin embargo, los que están en las herramientas perderán un tiempo precioso rehaciendo el código descuidado para añadir nuevas características, o rastreando las partes principales del proyecto para entender lo que está pasando, o, el peor de los casos: arreglar una vulnerabilidad que ha rebotado del equipo de AppSec y ha retrasado la producción. Dedicar tiempo ahora a hacer que el código sea seguro y de buena calidad ahorra muchos dolores de cabeza en el futuro, por no mencionar el coste de desentrañar un trabajo mal ejecutado.

Los desarrolladores expertos en seguridad escriben un código que mantiene su visión creativa y de resolución de problemas en la entrega de características, teniendo en cuenta la eliminación de las trampas de seguridad comunes que los ingenieros pueden controlar en su etapa del proceso. El código seguro no es terriblemente eficaz de forma aislada, y por eso la noción de empezar "por la izquierda de la izquierda" ayudará a respaldar una cultura de seguridad como segunda naturaleza para los desarrolladores, incorporada a su capacidad de ofrecer características sorprendentes con un riesgo reducido.

Empezar por la "izquierda de la izquierda" es fundamental para una experiencia de usuario segura.

La seguridad ha sido una consideración en la experiencia del usuario de software durante mucho tiempo, aunque claramente ha tenido un éxito desigual. Los errores de configuración de la seguridad representaron el 21% de las filtraciones de datos en la nube durante el año pasado, con errores de aficionados como el almacenamiento de contraseñas en texto plano que provocaron graves pérdidas de productividad, ingresos y confianza de los clientes en las empresas afectadas.

Además, los propios usuarios pueden ser su peor enemigo cuando se trata de proteger sus propios datos. Demasiada gente sigue usando "contraseña" como contraseña, o usando la misma combinación en varias cuentas sensibles.

No conozco a ningún desarrollador que se ponga a dar puñetazos cuando le dicen que tiene que trabajar en una pantalla de inicio de sesión, y no es de extrañar: es un equilibrio delicado diseñar un flujo de seguridad que sea robusto, funcional y que los usuarios puedan navegar de una manera que tenga sentido para ellos, con la menor interrupción.

Si se introducen demasiados pasos y restricciones complejas, los usuarios pueden desconectarse para no volver (un desastre para una aplicación nueva), si se hace demasiado confuso, se puede acabar provocando una migraña colectiva en el equipo de soporte mientras se atienden las consultas de los usuarios que intentan acceder a sus cuentas. Si lo haces demasiado fácil, estarás fallando en la parte de seguridad.

Una experiencia de usuario segura y satisfactoria debe integrar la seguridad en un flujo que tenga sentido y que se presente de forma que no desvirtúe todo lo demás que tiene de atractivo el software. Sin duda se puede cumplir el objetivo de codificar una función de inicio de sesión segura, poniendo todo tipo de requisitos de contraseñas complejas, CAPTCHA, mini-jefes y cuatro oleadas de zombis, pero si es un lío total que repele a los usuarios, se está perdiendo el objetivo.

Sentar las bases de la excelencia del software.

Como desarrollador, sé que la gran mayoría de nosotros nos sentimos orgullosos de nuestro trabajo y queremos hacer lo correcto. Las molestas bolas curvas, como las limitaciones de tiempo, los cambios repentinos en el objetivo actual o las correcciones urgentes, pueden interrumpir el flujo y conducir a errores, pero la cruda verdad es que muchos ingenieros de software no están preparados para el éxito.

Empezar por la "izquierda de la izquierda" es un concepto que da prioridad a los desarrolladores, y requiere que las organizaciones se tomen en serio la mejora de su cohorte de ingenieros. Los desarrolladores concienciados con la seguridad valen su peso en oro, y el apoyo en forma de formación, la provisión de las herramientas adecuadas y la oportunidad de ser tutelados por desarrolladores más experimentados fomentará un entorno en el que el código se elabore con una mentalidad que dé prioridad a la seguridad, con la precisión y la atención al detalle necesarias para llevar el software al siguiente nivel.

¿Listo para encender el fuego de la codificación segura en ti mismo? Acepta el reto.

‍

Es ese momento especial del año (para nosotros, al menos) en el que reflexiono sobre nuestra vuelta más reciente alrededor del sol, y sobre lo que se ha hecho en los trescientos sesenta y cinco días anteriores para posicionarnos para un nuevo año de crecimiento, lecciones e inevitable imprevisibilidad.

Aunque no creo que nadie pudiera prever los giros del año pasado -después de todo, creo que la mayoría de nosotros nos hemos enfrentado a más bolas curvas que los Dodgers de Los Ángeles-, seguimos aquí. El tic-tac del calendario no detuvo de golpe los puntos de dolor del Año que no puede ser nombrado, pero a mi alrededor veo la inquebrantable resistencia de las personas, las empresas y nuestro sector.

Entonces, ¿qué progresos hemos hecho en nuestro objetivo de asegurar el código en toda la galaxia?

Hemos ampliado nuestra gama de productos.

La plataforma de formación Secure Code Warrior siempre será el corazón y el alma de nuestra oferta, pero nuestras principales prioridades son crear más variedad y más herramientas elegidas por los desarrolladores.

Queremos inspirar a los desarrolladores para que adopten un enfoque de codificación segura y preventiva que permita a todos los equipos enviar software de calidad con confianza.

Estoy muy orgulloso de detallar lo que nuestro equipo de producto ha trabajado tan duro para lanzar; han pateado goles increíbles durante todo el año:

• Adquirimos Adversary.io e integramos su tecnología, su equipo increíblemente capacitado y sus clientes empresariales en menos de 9 meses.
• Hemos alcanzado el increíble hito de admitir más de 50 lenguajes de programación, incluidos los pilares de la infraestructura como código, como Docker, Ansible, Terraform, Kubernetes, Powershell y CloudFormation, así como los nuevos niños del bloque, como Rust y Go.
• Llevar el conocimiento de la seguridad al desarrollador mediante el lanzamiento de extensiones totalmente nuevas para GitHub Actions y Issues, además de Atlassian JIRA Cloud & Server, que proporciona aprendizaje contextual justo donde los desarrolladores juegan sin necesidad de cambiar de tarea
• Orientación sobre la calidad del código en tiempo real en el IDE con Sensei, ahora disponible en el mercado de JetBrains para que cada desarrollador detecte errores de seguridad, aplique las mejores prácticas, comparta conocimientos y evite problemas de rendimiento y deudas técnicas
• Facilitando a las empresas el compromiso con los desarrolladores y la ampliación de la codificación segura mediante el lanzamiento de Coursesuna nueva función que permite crear itinerarios de aprendizaje curados para los objetivos más relevantes para una organización y sus metas de seguridad. También hemos añadido Missionsuna emocionante mejora de la plataforma insignia, que pone a los desarrolladores en el asiento del piloto de un exploit. Se trata del siguiente paso en un enfoque de aprendizaje basado en andamios para ofrecer a los desarrolladores una base viable y permanente para el éxito.

... y si conoces a algún principiante en codificación, debería echar un vistazo a la aplicación gratuita, Secure Code Bootcamp, y comenzar su viaje por la seguridad.

Aterrizamos, nos expandimos, influimos.

Nos gusta enfocar la codificación segura de una manera un poco diferente y, naturalmente, esperamos que este espíritu se extienda por toda la industria. Es importante que los desarrolladores reconozcan su poder en la lucha contra los ciberatacantes, y conseguir que disfruten aprendiendo sobre seguridad es un objetivo primordial.

Miles de desarrolladores se unieron a nuestro tournaments virtual desde todo el mundo, con más de 80 celebrados solo en 2020. Nos encantó que la gente jugara como parte del Universo GitHub, los eventos globales de Cisco y la DevSecCon.

Hemos analizado nuestros datos y hemos visto que cientos de miles de usuarios únicos han jugado en nuestra plataforma en 2020, lo cual es alucinante si pienso en cómo empezamos hace seis años.

Me alegró mucho ver que habíamos aumentado significativamente nuestro alcance entre las empresas de la lista Fortune 1000, cada una de ellas dispuesta a probar algo nuevo como parte de sus programas de seguridad. Encontramos sinergias con las empresas tecnológicas en particular, muchas de las cuales pasaron a trabajar a distancia y vieron el valor de las opciones de formación a distancia.

El Equipo Asombroso se hizo más grande, y más fuerte, juntos.

Una de las mayores evoluciones que tuvimos como empresa el año pasado fue la adquisición de la empresa de ciberseguridad con sede en Islandia, Adversary. Teníamos mucho en común: una postura similar en el enfoque de la ciberseguridad centrado en las personas, valores alineados y productos complementarios. Acogimos a su equipo en el nuestro, ganando una experiencia y un talento inestimables entre grandes personas.

También hemos dado la bienvenida a John Wilson como vicepresidente senior de Ventas Globales, beneficiándose de su amplia trayectoria de 25 años impulsando el crecimiento y convirtiendo a las empresas de tecnología en la nube y de ciberseguridad en líderes del mercado. Sus amplios conocimientos técnicos han sido una fuerza innovadora en empresas como Symantec, Qualys, BlackBerry y Verizon, y no podríamos estar más contentos de tenerlo trabajando con nosotros.

La falta de oficinas físicas no nos impidió incorporar a sesenta nuevos empleados en cinco países y asegurarnos de que pudieran empezar a trabajar con apoyo virtual, presentaciones y, por supuesto, el codiciado paquete de regalos para empleados entregado en su puerta.

Seguimos creciendo en todos los departamentos, todos ellos de igual importancia para lograr nuestra misión global de permitir un código de calidad a gran velocidad. Y, sin embargo, sigue pareciendo que no hemos hecho más que empezar.

2021, el año de cambiar la conversación.

Hace tiempo que tengo la sensación de que la sociedad simplemente no se preocupa lo suficiente por la ciberseguridad, y sólo cuando ocurre algo increíblemente drástico podemos ver cómo se mueve la aguja de la acción y la concienciación.

Con la enorme brecha de SolarWinds que se produjo a finales del año pasado, están saliendo a la luz más detalles. Todavía no se conoce el alcance total de los daños, pero este incidente podría ser el catalizador de un cambio generalizado. Los departamentos gubernamentales estadounidenses ya están revisando sus programas de seguridad, y el ciberespionaje es un tema muy candente entre los que tienen mucho que perder.

Todavía podemos poner un poco de diversión en todo lo que hacemos, pero ahora es el momento de arremangarse y ponerse a trabajar para cambiar de verdad la conversación.

Cada desarrollador consciente de la seguridad hace que nuestro mundo sea un poco más seguro frente a los ciberataques, y darles los conocimientos necesarios para que tengan éxito -y tal vez incluso les guste- será siempre nuestro objetivo. Trabajamos duro cada día para crear herramientas que los desarrolladores elijan para aprender sobre seguridad y crear código de la más alta calidad. El código seguro debería ser el estándar, y todos podemos echar una mano para hacerlo realidad.

Da la sensación de que el "cumplimiento de la ciberseguridad" es una tendencia desde hace años, con un sinfín de artículos, iniciativas y comités que debaten sobre la mejor manera de afrontar la enorme bestia de múltiples amenazas que es la ciberdelincuencia.

El problema es que no parece que hayamos avanzado tanto. A nivel mundial, el coste de las filtraciones de datos ha aumentado constantemente, un 12% en cinco años para establecerse en aproximadamente 3,92 millones de dólares por filtración en 2019. A medida que nuestro uso de Internet se disparó en tan solo un par de décadas, muchas empresas simplemente se vieron obligadas a luchar sin armadura mientras se conectaban rápidamente, se establecían y lidiaban con las consecuencias de un software inseguro, recursos limitados de AppSec y, en algunos casos, el abuso de la confianza de los clientes.

Hoy en día, somos irrefutablemente más maduros. Comprendemos y debatimos ampliamente el alcance de la amenaza, las empresas son muy conscientes del impacto que un ciberataque puede tener en la opinión de los clientes, su reputación y sus resultados, y muchos lugares buscan activamente mejorar la seguridad del software a través de la formación en materia de cumplimiento, la contratación de personal cualificado y, cada vez más, las iniciativas de DevSecOps. A pesar de estos enormes saltos, no estamos ganando la lucha, ni siquiera cerca. Se han robado al menos cuatro mil millones de registros en violaciones de datos solo en 2019.

Un ingrediente que faltaba ha sido un goteo algo lento (a nivel gubernamental) sobre las normas de ciberseguridad, las expectativas y las consecuencias de una violación. La llegada del GDPR ha hecho que algunas cabezas empiecen a rodar, al menos en Europa, pero muchos organismos gubernamentales solo se están poniendo al día ahora, y la repentina necesidad de acatar rápidamente las iniciativas de cumplimiento recién florecidas podría tener algunos efectos no deseados en el futuro.

Los tontos se precipitan (a la formación equivocada)

Las sólidas directrices del NIST, la nueva normativa del Estado de Nueva York y la creación del Consejo de Ciberseguridad del Reino Unido han sido victorias monumentales para los que luchan por mantener nuestros datos seguros. Reconocen los problemas en el desarrollo de software actual y toman medidas para orientar a las organizaciones sobre las normas que deben cumplir ahora para ser consideradas éticas y conformes, en términos de mejores prácticas de seguridad.

Lamentablemente, en este momento, algunos de los elementos más importantes están demasiado abiertos a la interpretación. Por ejemplo, uno de los mandatos de la legislación del Consejo de Ciberseguridad del Reino Unido es:

"Crear una lista definida de certificaciones y un marco fácil de entender sobre cómo se relacionan entre sí y qué capacidades transmiten, basándose en el trabajo de itinerarios profesionales ya realizado".

Aunque sus iniciativas sin duda mejorarán y crecerán con el tiempo, si las organizaciones ya están pulsando el botón del pánico y saltando a la formación ahora, podrían encontrarse mal equipadas para el futuro.

Las exigencias de ciberseguridad de una organización cambian rápidamente, y es poco probable que las soluciones de formación estática frenen el flujo de software inseguro al ritmo necesario. El panorama cambia más rápido de lo que un curso tradicional puede actualizar, lo que puede hacer que algunos lugares caigan en la trampa del ejercicio de cumplimiento de "marcar la casilla"; los desarrolladores, contratistas y otros profesionales de la seguridad no reciben la formación adecuada, y volvemos a ser blancos fáciles.

La formación estática y las herramientas estáticas sufren los mismos problemas

Las herramientas de análisis estático son una parte integral del SDLC, haciendo su trabajo como caballos de batalla para los escasos y sobrecargados especialistas de AppSec que se encuentran en la mayoría de las grandes organizaciones. Hacen un buen trabajo, pero hay un defecto: ninguna herramienta puede escanear todas las vulnerabilidades, soportando la enorme gama de marcos de programación existentes. También es un proceso lento, y basta con que un solo fallo de seguridad se cuele entre las grietas para dejar una puerta abierta a un atacante.

En el caso de la formación estática, existe un problema similar. Si los desarrolladores reciben la formación en seguridad como un curso rígido, "de una sola vez", es muy poco probable que se haya mantenido al día con los problemas de seguridad más prevalentes en ese período de tiempo. Sirve como una instantánea del momento en que se escribió, y rara vez se revisa lo suficiente, se imparte en el lenguaje y el marco de trabajo preferidos por el estudiante, ni es contextual a las vulnerabilidades a las que probablemente se enfrenten en su trabajo diario. Imagina que intentas recordar una pieza de información relevante de un vídeo que viste hace meses, mientras intentas cumplir con los plazos de entrega y sacar el código por la puerta... es poco probable que suceda.

Los métodos tradicionales de educación están siendo reevaluados en muchas industrias, pero cuando se trata de la formación en seguridad para desarrolladores, sólo hay que ver el gran volumen de violaciones de datos que todavía experimentamos (especialmente aquellas que pueden ser atribuidas a vulnerabilidades que hemos sabido evitar en la codificación durante décadas, como la inyección SQL) para darse cuenta de que debemos intentar una manera diferente.

Necesitamos una formación que vaya más allá de los límites de un curso único y lineal, que pueda flexibilizarse y adaptarse a las necesidades siempre cambiantes de las mejores prácticas de ciberseguridad.

Entrenamiento dinámico: el estándar de oro

Al ofrecer a los desarrolladores una solución de formación dinámica, que puede adaptarse rápidamente a la empresa, al nivel de habilidad individual y a los movimientos generales de la industria, les está proporcionando la mejor base para codificar de forma segura, manteniendo la seguridad en primer plano y actuando con una mentalidad consciente de la seguridad.

Una formación única, que nunca se revisa y que no es atractiva en primer lugar, será una completa pérdida de tiempo y, por desgracia, eso significa que podría acabar comprando por impulso un programa ineficaz en aras del cumplimiento. Podría quedar obsoleto antes de que lo ponga en marcha, o apenas se puede relacionar con las necesidades de su trabajo diario.

La formación dinámica es una herramienta viva, que se actualiza constantemente, que se adapta a las necesidades cotidianas, que involucra a los usuarios con el pensamiento crítico y que realmente les permite aprender habilidades y solucionar problemas.

Entonces, ¿cómo es un programa de formación dinámico en un contexto de seguridad?

Lo será:

• En trozos: Los desarrolladores pueden aprender habilidades en trozos manejables que son mucho más fáciles de recordar (y, lo que es más importante, de aplicar) que los largos mazos de formación y los vídeos
• Es relevante: ¿De qué sirve una formación genérica en materia de seguridad en la que los ejemplos están en, por ejemplo, C#, cuando el desarrollador codifica principalmente en Java? Cualquier formación debería aplicarse directamente a su función, permitiéndoles ver lo que deben encontrar y corregir (e, idealmente, evitar en primer lugar) mientras codifican.
• Actual: Esto parece obvio, pero a menudo no lo es. El panorama de la ciberseguridad cambia constantemente, y con más código viene más responsabilidad. Para que los desarrolladores sean su primera línea de defensa, necesitan una formación que se mantenga al día con las mejores prácticas de seguridad modernas.
• Atractivo: No es ningún secreto que los desarrolladores pueden encontrar la "seguridad" como una tarea, especialmente si interfiere con su flujo creativo. La formación adecuada les mostrará el poder que tienen en la resolución de problemas de seguridad cotidianos que pueden convertirse en grandes riesgos, creando una cultura de responsabilidad y conciencia de seguridad.
• Divertido: La formación dinámica rara vez es aburrida; se supone que debe ser al menos algo emocionante por su diseño. Piensa en lo que les gusta a los desarrolladores: resolver problemas, competir con sus compañeros y, como a muchos de nosotros en el trabajo, las recompensas y el reconocimiento. Aproveche sus puntos fuertes y concéntrese en obtener los mejores resultados.

Es un momento emocionante para ser ingeniero de software; desempeñan un papel integral en la innovación digital, ayudan a crear empresas increíbles e incluso toman el mundo por sorpresa con sus propias creaciones. Sin embargo, ahora que los organismos gubernamentales y las grandes empresas son conscientes del papel que deben desempeñar en el establecimiento de normas de seguridad del software, es importante apoyarlos con soluciones de formación eficaces y dinámicas que fomenten el amor por la codificación segura, y no un ejercicio burocrático de marcar casillas.

Según un estudio de IBM, es treinta veces más caro arreglar las vulnerabilidades después de su lanzamiento que encontrarlas y arreglarlas inicialmente. Teniendo esto en cuenta, no es de extrañar que los directores de sistemas de información con visión de futuro estén aplicando prácticas de codificación segura. Esto significa formar y equipar a los desarrolladores para que escriban un código más seguro desde el principio, convirtiéndolos en la "primera línea de defensa" de su organización. Para medir el impacto real de esta tendencia, Secure Code Warrior se asoció con Evans Data Corp* y encargó un estudio reciente sobre las actitudes de los desarrolladores hacia la codificación segura, las prácticas de código seguro y las operaciones de seguridad. Esta investigación revela que la aplicación de prácticas de código seguro es transitoria para las empresas en varios frentes diferentes. Descargue su copia del libro blanco aquí.

Codificación segura con más confianza y atención

Sin duda, la aplicación de prácticas de codificación seguras aumenta la conciencia de seguridad de los desarrolladores de manera que beneficia a sus empleadores. Nuestro estudio revela que el 55% de los desarrolladores afirma que una buena formación ha aumentado su confianza en sus técnicas de codificación, y el 53% dice que una buena formación les ha permitido ser más cuidadosos al depurar y probar su propio código. El mismo 53% cree que se ha vuelto más consciente de la seguridad al escribir el código.

¿Qué nos dice esto? Nos dice que, con un poco de capacitación, los desarrolladores pueden transformarse en su primera línea de defensa.

Selección de herramientas más inteligente y mayor velocidad de lanzamiento

Cuando preguntamos a los directivos sobre el impacto de la formación en código seguro, sus perspectivas reflejaron sus responsabilidades de gestión. El 43% de los directivos coincidieron en que la formación en código seguro ha ayudado a sus organizaciones a ser más cuidadosas a la hora de depurar y probar su código. El 47% reveló que una buena formación les ha permitido ser más selectivos con la elección de herramientas que proporcionan más seguridad. Pero quizás lo más importante es que el 44% indicó que la formación y las técnicas de código seguro han ayudado a ahorrar tiempo y a acelerar la publicación de software, una ventaja sustancial cuando la velocidad de comercialización lo es todo.

Aumento de la productividad en todos los ámbitos

Cuando preguntamos a los desarrolladores cómo ha ayudado la codificación segura a la productividad, más de la mitad consideró que había contribuido a aumentar la calidad tanto de la codificación como del diseño de la aplicación.  

El 63% dijo que reduce el retrabajo al prevenir las vulnerabilidades recurrentes. El 70% dijo que ayudó a eliminar los errores que conducen a retrabajo o parches. El 56% afirma que ha mejorado la productividad en la depuración y las pruebas. Podemos ver la transformación en curso en múltiples etapas del ciclo de vida del desarrollo de software.

Dinámica de equipo y calidad del código

Las prácticas de código seguro también tienen un impacto en la dinámica del equipo. Aunque los desarrolladores aprenden individualmente a codificar de forma más segura, su código no existe en el vacío. Su código suele depender del trabajo de los demás y viceversa. La aplicación de prácticas de codificación segura hace que los desarrolladores compartan y busquen conocimientos de codificación segura, impulsando una mejor comunicación entre los desarrolladores, los desarrolladores y la dirección, y el equipo de desarrollo y sus partes interesadas.

• El 60% de los desarrolladores encuestados cree que el empleo de prácticas de código seguro ha aumentado su comunicación con otros desarrolladores
• El 45% afirma que el contacto con la dirección ha aumentado.

Los directivos se hacen eco de estos sentimientos, aunque desde una perspectiva diferente. El 62% de los directivos encuestados afirman que las prácticas de código seguro les obligan a dedicar más tiempo a la gestión de personas y contribuyen a aumentar la velocidad de las publicaciones de código.

Para las organizaciones que implementan prácticas de código seguro, el aumento de la comunicación tiene un impacto trans-formativo en la dinámica del equipo, impactando positivamente en la calidad del código y la velocidad de comercialización.

Pasar de la reacción a la prevención

Por último, el código seguro influye en la forma en que los desarrolladores y los gestores de desarrollo aplican las medidas de seguridad y las métricas que las acompañan.

En la actualidad, el 81% de las organizaciones sigue confiando en las métricas reactivas, como el recuento de defectos y las métricas de los escáneres, para determinar la calidad de la seguridad.

Pero estas actividades reactivas se complementan cada vez más con métricas proactivas o preventivas o dan paso a ellas. El 67% de las organizaciones miden ahora el conocimiento de los desarrolladores sobre el OWASP Top 10 como métrica para la preparación de la seguridad. Otras métricas proactivas que se utilizan cada vez más son:

• Medir la competencia de los desarrolladores en torno a la seguridad de las aplicaciones
• Uso de código preaprobado
• Cumplimiento de los requisitos reglamentarios.

El 90% de los desarrolladores prestan ahora atención a estas medidas preventivas. Sin embargo, aunque la concienciación y la aplicación de las prácticas de codificación segura van en aumento, aún queda camino por recorrer para aprovechar todo su potencial.

¿Qué hacer a partir de ahora?

Como campeones del cambio en la codificación segura, Secure Code Warrior adopta un enfoque dirigido por el ser humano para ayudarle a transformar a sus desarrolladores en su primera línea de defensa, y a que su enfoque general de seguridad pase de reactivo a proactivo. Nuestro probado learning platform ofrece formación contextual y práctica en 52 categorías específicas de lenguaje y marco de trabajo, con retos que imitan los que los desarrolladores afrontan en el mundo real. Sabemos por experiencia que los desarrolladores prefieren el método de aprender haciendo a la lucha del aprendizaje estático basado en la teoría. Si desea ver el impacto trans-formativo que esto puede tener en sus equipos y su capacidad para enviar código de calidad con confianza, reserve una demostración ahora.

‍

*Pasar de la reacción a la prevención: The changing face of application security. Secure Code Warrior y Evans Data Corp. 2020
1. IBM Software Group; Minimización de los defectos de código para mejorar la calidad del software y reducir el coste de desarrollo - https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

‍

팀 내에서 쿡북 공유

한 사람이 코드 품질이나 생산성을 개선하기 위해 Sensei 레시피를 만들면 쿡북을 공유하면 팀원 모두가 혜택을 누릴 수 있습니다.

Sensei는 쿡북 공유를 위한 다양한 메커니즘을 제공합니다.

• 버전 관리 하에 프로젝트에 쿡북 저장
• 쿡북을 공유 폴더에 저장
• Github에 쿡북 저장하기
• HTTP를 통해 압축된 파일

Sensei는 쿡북을 공유함으로써 팀이 협업하여 지식을 공유할 수 있도록 도와줍니다.협업을 통해 커뮤니케이션을 개선하고 합의된 코드 품질 접근 방식을 적용할 수 있습니다.

예를 들어, 요리책 공유:

• 팀원들이 서로 유용한 레시피를 공유할 수 있도록 도와줍니다.
• 팀 리더가 합의된 버전의 빠른 수정을 통해 주니어 직원을 위해 합의된 코딩 관행을 체계화하여 일반적인 위반 사항을 식별할 수 있도록 지원합니다.
• 팀 간 협력을 촉진합니다. 예를 들어 AppSec 팀은 코드의 문제를 강조하기 위한 레시피를 만들 수 있고 개발 팀은 빠른 수정 사항을 작성할 수 있습니다.

다음 몇 섹션에서는 각 공유 메커니즘을 구현하는 방법을 설명합니다.

버전 관리 하에 프로젝트에 쿡북 저장

프로젝트 .sensei 폴더는 쿡북 파일을 만들 때 기본 옵션입니다.

• `프로젝트: //.sensei`

모든 쿡북과 레시피는 프로젝트의.sensei 폴더에 저장됩니다.

가장 쉬운 공유 방법은 프로젝트 .sensei 폴더를 버전 제어에 추가하는 것입니다.

그러면.sensei 폴더를 프로젝트와 관련된 다른 공유 코드 아티팩트처럼 관리할 수 있습니다.쿡북은 YAML 구성으로 저장되므로 커밋 및 검토 프로세스 중에 쉽게 병합할 수 있습니다.

이것이 퍼블릭 센세이-블로그-예제 프로젝트에서 취한 접근 방식입니다.

• https://github.com/SecureCodeWarrior/sensei-blog-examples

.sensei 폴더에는 모든 레시피가 포함된 쿡북이 들어 있으며 저장소를 복제하는 모든 사용자가 사용할 수 있습니다.

쿡북을 모든 폴더에 저장

팀은 중앙 위치에 저장된 쿡북을 사용할 수도 있습니다.

공유 쓰기 권한이 있는 폴더에 쿡북을 저장하면 팀 전체가 레시피를 업데이트하고 작업 중인 프로젝트로 가져올 수 있습니다.

위치는 디렉토리 경로로 설정됩니다.

깃허브에 레시피 저장하기

Sensei는 Github 리포지토리에 저장된 레시피에 액세스할 수도 있습니다.프라이빗 리포지토리와 퍼블릭 리포지토리가 모두 지원됩니다.

SSH를 통한 깃허브

SSH 리포지토리 액세스는 위치에 대한 다음 구문을 사용하여 구성됩니다.

git@github.com: 시큐어 코드 워리어/ACookbook.git

이 작업을 수행하려면 저장소에 쿡북 폴더의 내용이 포함되어야 합니다.

쿡북의 브랜치와 하위 폴더 (예: 쿡북 하위 폴더의 마스터 브랜치) 를 구성할 수도 있습니다.

예:

• git@github.com: 시큐어 코드 워리어/센세이-블로그-예제.git|Master|.sensei

프라이빗 리포지토리에 대해 SSH 키를 구성해야 합니다.

• https://github.com/settings/keys

그리고 키에는 암호가 없어야 합니다.

HTTPS를 통한 깃허브

HTTPS를 통해 퍼블릭 리포지토리에 액세스할 수도 있으며, 예를 들어 동일한 repo.git|branch|폴더 구문이 사용됩니다.

블로그 예제 프로젝트의 경우:

• https://github.com/SecureCodeWarrior/sensei-blog-examples.git|master|.sensei

기본 보호 예제 세트의 경우 기본적으로 마스터 브랜치를 가져오고 `rules.sensei` 파일이 루트 폴더에 있기 때문에 브랜치와 하위 폴더를 무시해도 됩니다.:

• https://github.com/SecureCodeWarrior/cookbook-basic-protection-set

HTTP (s) 를 압축했습니다.

또한 Sensei는 HTTP 또는 HTTPS를 통해 압축된 쿡북에 액세스할 수 있습니다.

예를 들어 포트 8000에서 로컬로 수신 대기하는 HTTP 서버가 있는 경우

• http://localhost:8000/rules.sensei.zip

zip 쿡북 파일에는 쿡북 폴더의 내용 (예: rules.sensei 파일) 이 포함되어야 합니다.

공유 요약

Sensei는 개별 프로그래머가 자신의 학습과 생산성에 도움이 되는 레시피를 만들 수 있도록 여러 쿡북 사용을 지원합니다.

더 중요한 것은 지식을 공유할 때 팀이 가장 효과적으로 일한다는 것을 알고 있다는 것입니다.예를 들어 특정 프로젝트, 특정 라이브러리 또는 공유 마이그레이션 패턴 세트를 위해 팀 리포지토리를 공유하면 팀 생산성을 높이고 팀 경험을 체계화하는 데 도움이 될 수 있습니다.

쿡북을 공유하면 여러 팀이 동일한 쿡북을 사용할 수 있어 AppSec과 개발 등 다양한 분야의 팀 간 협업도 개선할 수 있습니다.

네 가지 핵심 공유 메커니즘을 사용할 수 있으므로 Sensei는 지식 공유에 대한 협업을 증진하는 데 사용할 수 있는 접근 방식을 하나 이상 갖게 되기를 바랍니다.

---

Solo tienes que instalar Sensei en IntelliJ usando «Preferencias\Complementos» (Mac) o «Configuración\Complementos» (Windows) y buscar el «código de seguridad Sensei».

모든 Sensei 블로그 게시물, 코드 및 레시피는 다음과 같은 Github에 있습니다.

•  https://github.com/SecureCodeWarrior/sensei-blog-examples