Perspectivas sobre el código 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.

‍

人工智能辅助开发已不在眼前——它就在这里，它正在迅速重塑软件的编写方式。GitHub Copilot、Cline、Roo、Cursor、Aider和Windsurf等工具正在将开发人员转变为自己的副驾驶，从而加快迭代速度，加速从原型设计到重大重构项目的所有工作。

但是这种转变带来了熟悉的紧张局势：速度与安全。

在 Secure Code Warrior，我们一直在思考如何帮助开发人员在使用 AI 编程工具时保持安全。 这就是为什么我们很高兴推出一款简单、强大且立即有用的产品：我们的 AI 安全规则 — GitHub 上所有人均可免费使用的公开资源。 您无需成为 Secure Code Warrior 客户即可使用它们；我们将这些规则作为免费的、社区驱动的基础提供，任何人都可以采用并扩展到自己的项目中。

这些规则旨在充当护栏，推动人工智能工具走向更安全的编程实践，即使开发人员正在以惊人的速度前进。

对于那些赶时间的人，总结一下：

随着 Copilot 和 Cursor 等人工智能编码工具对现代发展至关重要，安全性不能成为事后才想到的。这就是为什么我们构建了一组轻量级、以安全为先的规则集，旨在指导 AI 代码生成朝着更安全的默认方向发展。

• 涵盖网络前端、后端和移动
• 易于使用 AI 工具
• 公开、免费使用，随时可以应用到自己的项目中

探索规则 → https://github.com/SecureCodeWarrior/ai-security-rules

让我们把安全编码设为默认值——即使键盘上有 AI 也是如此。

1。为什么规则在人工智能辅助编码时代很重要

AI 编码工具非常有用，但并非万无一失。尽管他们可以快速生成工作代码，但他们通常缺乏细微差别，无法理解给定团队或项目的具体标准、惯例和安全策略。

这就是项目级规则文件发挥作用的地方。

Cursor 和 Copilot 等现代 AI 工具支持影响代码生成方式的配置文件。这些规则文件就像在人工智能耳边低声说话，告诉它：

“在这个项目中，我们从不串联 SQL 字符串。”
“与不安全的默认值相比，更喜欢使用安全标头进行提取。”
“除非你想进行安全审计，否则请避免使用 eval ()。”

这些规则不是灵丹妙药，也不是强有力的代码审查实践和安全工具的替代品，但是它们可以帮助使人工智能生成的代码与团队在安全开发中已经遵循或应遵循的做法保持一致。

2。我们建造了什么（以及我们没有建造什么）

我们的入门规则现已推出 公共GitHub存储库。它们是：

• 按域名组织——包括 Web 前端、后端和移动设备
  
• 以安全为中心 — 涵盖反复出现的问题，例如注入漏洞、不安全处理、CSRF 保护、弱身份验证流程等
  
• 设计轻巧——它们本来是实用的起点，而不是详尽的规则手册

我们知道您的 AI 上下文窗口有多有价值，也知道代码消耗这些代币的速度有多快，因此我们的规则保持清晰、简洁，并严格关注安全性。我们做出了深思熟虑的决定，避免使用特定语言或框架的指导，而是选择了广泛适用、影响大的安全实践，这些措施适用于各种环境，而不会对架构或设计固执己见。

编写这些规则的目的是很容易地将其放入人工智能工具支持的配置格式中，几乎无需重构。可以将它们视为推动人工智能走向安全违约的起步政策。

3.新的防御层

以下是实际操作中的样子：

• 当 AI 建议处理用户输入的代码时，它倾向于验证和编码，而不是裸处理。
  
• 在构建数据库查询时，更有可能推荐参数化，而不是字符串连接。
  
• 在生成前端身份验证流程时，AI 更有可能推广代币处理最佳实践，而不是不安全的本地存储黑客攻击。

所有这些都无法取代安全计划中的战略开发人员风险管理，包括持续的安全技能提升。它也不能消除对精通安全的开发人员的需求，尤其是当他们越来越多地提示LLM和审查人工智能生成的代码时。这些护栏增加了一层有意义的防御层，尤其是在开发人员行动迅速、多任务处理或只是过于信任该工具时。

下一步是什么？

这不是成品，而是起点。

随着人工智能编码工具的发展，我们的安全开发方法也必须不断发展。我们的 AI 安全规则 可免费使用，适应性强，可扩展到您的项目。我们致力于不断发展这些规则集，我们很乐意听取您的意见——因此，请尝试一下，告诉我们您的想法。

在 GitHub 上浏览规则
阅读 SCW Explore 中的使用规则指南

人工智能辅助编码已经在重塑我们构建软件的方式。让我们从一开始就确保它是安全的。

如今，几乎每个团队都采纳了某种形式形式的合规规则，无论是确认保守公司遵循守护行业框架架构还是政府法规的初始认证流程的一部分，都是有用的，也是作为年度或审核的一部分。这是非常重要的例子，因为如果一个组织无法满足基本的合规要求，那么它的员工就无法切实行职责。

合规的规则存档是有原因的，因为任何规矩的都是有原因的，因为任何规格都必须对所有相关流程和程序进行少量对所有相关流程和程序以及适用的任何法律都有基本的了解。

尽管合规格性培训很重要，但已完成规约的最低限度且不可能确认保真正的应用程序安全。对于试图将安全编解码技术可以整理到日常工作流程中的开发人员来说尤其如此。几乎可以说，每位开发者都会通过某种形式接受接受，但是在接受调查时， 67% 的人承认他们经常在代码中留下漏洞。

¿Por qué?

2021年12月，Secure Code Warrior连续第二年与埃文斯数据公司合作进行了 “2022年开发者驱动的安全状况状况调查”。我们对全球 1,200 名开发人员进行了重新调查，以了解安全编程实战方方的技能、看法和行为，以及其在软件开发周期 (SDLC) 中的影片响应和感知相关性。

就合规性培训为何无法提高软件安全性而言，这是我们长久以来的期望直接在谈论的问题。最近的调查只是聚焦了这个问题。

一方面，开发人员通过在整个软件开发过程中（包括在最初为应用程序和程序编写 decodeCodeWriteCome）中被开发人员通过在整个软件开发过程中（包括在最初为应用程序和程序编译代码时）的网络安全来提升新职位。但是，编写 Safire Code，只有了解所有可能影响它的网络安全问题和漏洞，都不是一件容易的事。在调查中，63％的开发人员表示，编写 “安全代码” 是一项艰巨巨人的任务。

编写 safeDaidecode 的困难难度不足为奇。有这个多高的网络安全工作没有得到满意是有原因的，据最新统计，全球有超过350万个空缺职位。如果工作很容易，那么每一个人都会跳入这个领域。学习如何对抗威和消除代码中的漏洞很难，而在不断变化之中，再加上威格局在不断变化。静态合规培训或一次性课程无法跟上发展步伐，也无法提供开发人员所需的教育。它可能在合规性方方面面选择一个方针，但无法为你的应用提供真正的正向应用程序安全保障，也无法让开发人员编写安全代码，也无法发现和修复代码漏洞的技能。

合规和培训安全很重要，但有不一样之处

组织必须开始意识到并承认合规可以做什么，不可能做什么。不要放任合规框架，尤其是法律法规的合规框架。尤其是因为（即使使用当前的培训方法）92％的受访者表示他们至少需要接受一些有关合规性问题或安全框架构的问题，50％的受访者需要进行大量的合规性问题或安全框架构的接受，50％的受访者强迫需要进行大量的合规培训。

他们对培训最感兴趣的合规框架构包括针对各行各业的合规框架，尽量管道一些通用的网络安全框架也在清晰之中。它们包括独联体安全框架架、PCI DSS、OWASP前十名、MISRA C、ISO/IEC、《健康保险流通与责任法案》（HIPAA）等。

因为这个，是的，比如某些框架架构中正在进行中，但要明白，选中合规性培训并不会等于持续创建安全代码定位。

取而代之的是，将合规性培训视角为扩展开发人员安全编程码科技的持续机将成为其中的一部分，这种技能可以在周末的期限内重复，比如他们每天都可以创建发布安全软件。将优先锋事从实现合规性转化到使开发团队能量通过持续学习安全编程编写代码。通过在开发人员支持方方面面投入时间和资源，那么，每年的复选框的规格练习或考试将使你的员工轻而易举地通过和完成，同时受益于整个生产力的提案。

如何转向开发者驱动的稳定性？

绝大多数开发人员都很喜欢表演示文稿的价钱，但对他们来说，他们多年来就受到了有关安全编程的培训类的型号表演示我怀疑。开发人员表示，他们希望通过与工作相关的真实示例（30%）来看更多地强调实例。26% 的受访者还认识到，增强强化互操作性至关重要，特别是，如果他们能的话，那么如果他们能的话，那么在某些练习中习惯用法写作安全代码。

23% 的受访开发者认为更多，接受《指导性报告》，重点关注他们在行业或行业中最有可能遇到的特定漏洞，这一愿望很重要，而 22% 的开发人员正在望培训课程中看到更多真实世界的漏洞示例。

显然，就可重复的开发人员安全技能而言，仅提供静态的非交互式互联网交换（通常是合规性培训的经验）几乎没有价格值。取而代之的是，组织将重点放置在准时培训之类的事件情绪上，即向开发人群的员工 cromfectradineCrompenseCromfeWorkredWorkseWorkRenceworkredWork你可以考虑分层学业学习计划。

使用分层方法法，比较的主题通常会被分解为离散的学者学习体或为概念。年龄开发者的进步，在已开启的概述中，分层构造更高级的概述，就像 “建筑物升高” 而建构造物理脚本手架一样。这是 sachcrombernecseSafe等困难不断演变的话题提供了一种行之有效的方法方法，方法是先锋将分解成更小、不太复杂的部分，然后在基础上构造更高的复杂性。

无论你决心采集何种种开发人员安全技能计划，都将把它与合规性练习开启是关键。合规和培训安全都很重要，两者都需要不同的方法才能取消。

Para más información

皮书：提高软件安全性的（和机遇）。

皮书： 开发人员保护软件的防御性方法法。

：报告开发者驱动的安全状况。

同样的 10 个软件漏洞 在过去的20多年中，造成的安全漏洞比其他任何漏洞都多。但是，许多企业仍然选择违规后、事后补救措施；混淆这一切的人力和业务后果。但是现在，一项新的研究指出了一个由人类主导的新方向。

‍以下内容讨论了Secure Code Warrior与Evans Data Corp共同进行的一项名为 “从反应转向预防：应用程序安全面貌的变化”（2021 年）的研究得出的见解，该研究探讨了开发人员对安全编码、安全代码实践和安全运营的态度。下载白皮书 这里。

‍‍在这份即将发布的研究中，向开发人员和开发经理询问了他们与安全编码相关的活动。排名前三的回复是：

• 在已部署的应用程序上使用扫描工具。
• 手动检查代码中是否存在漏洞。
• 编写防范漏洞的软件的积极而持续的做法。
  ‍

那么这告诉我们什么呢？前三名答复中有两个仍然集中在反应式方法上，第一个依赖于工具（扫描仪），第二个依赖于开发人员（即人工）执行手动检查——在这两种情况下 之后 代码已经写好了。使用这些方法检测到的漏洞必须返回给开发团队进行返工，这会对项目时间表和项目成本产生连锁反应。

同时，所提名的三项活动中有两项依赖于人为因素——这表明越来越多的人将安全视为人的问题。但是，在所有提名的活动中，最有说服力的是第3项，它确定了人为因素 在编写一开始就保护免受漏洞侵害的软件中。这凸显了向左起步的转变，这是一种积极主动的预防性方法，从软件开发生命周期一开始就为软件提供安全保障。

被动可能等于昂贵

根据IBM的一项研究*，修复发布后代码中的漏洞的成本是最初发现并修复漏洞的成本的三十倍。这是一种强有力的激励措施，促使开发人员从一开始就采取更主动和更人性化的方法来捍卫软件安全，使开发人员能够更安全地进行编码。

这就是你可以称之为 人为主导的防御。但是，要让开发人员开始关注安全性，它必须成为他们每天思考和编码方式的一部分。这要求采用与开发人员日常工作高度相关的全新培训方法，激发他们的学习欲望，这两种方法在当前的训练模式中都无法说出来。

为了创建主动的安全文化，需要进行新的培训，以便：

• 在开发人员提高软件安全技能的同时，使安全编码成为积极而引人入胜的体验
• 鼓励开发人员通过安全思维来查看他们的日常编码任务
• 使安全编码成为他们日常工作流程的固有组成部分
  

当这些线索汇集在一起时，首先可以防止漏洞发生，从而允许团队发货 质量代码 更快，更有信心。好消息是，已经存在一个在软件开发过程中 “从左开始” 的学习平台——该平台已经为开发人员提供了从一开始就创建高质量代码的技能和工具。
‍‍

‍

*IBM 软件集团；最大限度地减少代码缺陷以提高软件质量并降低开发成本
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.

‍

这是一年中的那个特殊时刻（无论如何，对我们来说），我回顾了我们最近一次绕太阳的圈子，以及在过去的三百六十五天里为迎接充满成长、经验教训和不可避免的不可预测性的新的一年所做的工作。

尽管我认为没有人能预见到去年的曲折——毕竟，我认为我们大多数人面临的曲线比洛杉矶道奇队还要多，但我们仍然在这里。日历的变化并没有突然消除 “无法透露姓名的一年” 中的痛点，但在我周围，我看到了个人、企业和我们行业坚定不移的韧性。

那么，我们在实现保护整个银河系代码的目标方面取得了哪些进展呢？

我们为我们的产品套件增光添彩。

Secure Code Warrior 培训平台将永远是我们产品的核心和灵魂，但努力创造更多种类和更多开发人员选择的工具是我们的首要任务。

我们希望激励开发人员采用预防性安全编码方法，使每个团队都能放心地交付高质量的软件。

我很自豪地详细介绍我们的产品团队辛勤工作推出的内容；他们全年都设定了令人难以置信的目标：

• 我们收购了Adversary.io，并在不到9个月的时间内整合了他们的技术、技术精湛的团队和企业客户。
• 我们在支持方面达到了不可思议的里程碑 超过 50 种编程语言，包括基础设施作为代码支柱，例如Docker、Ansible、Terraform、Kubernetes、Powershell和CloudFormation，以及像Rust和Go这样的新成员。
• 通过发布全新内容为开发人员提供安全知识 扩展 适用于 GitHub 操作和问题，此外还有 Atlassian JIRA Cloud & Server，后者无需在任务之间切换即可在开发人员玩游戏时提供情境学习
• 在 IDE 中提供实时质量代码指导 老师，现已在 JetBrains 市场 让每位开发人员都能发现安全漏洞、执行最佳实践、共享知识并防止性能问题和技术债务
• 通过发布，使企业更容易与开发人员互动并扩展安全编码 课程，这是一项全新功能，允许通过精选的学习途径来实现与组织及其安全目标最相关的目标。我们还添加了 任务，这是对旗舰平台的一项令人兴奋的增强，使开发人员处于漏洞利用的试点位置。这是脚手架式学习方法的下一步，旨在为开发人员提供可行的终身成功基础。

... 如果你认识任何编程初学者，他们应该看看免费应用程序 Secure Code Bootcamp，开始他们的安全之旅。

我们着陆，我们扩张，我们影响了。

我们喜欢以不同的方式处理安全编码，当然，我们希望这种精神能够在整个行业中流行。开发人员必须认识到他们在与网络攻击者作斗争中的力量，让他们真正享受学习安全知识的乐趣是首要目标。

来自世界各地的数千名开发者参加了我们的虚拟锦标赛，仅在 2020 年就举办了 80 多场。我们很高兴能让人们参与其中 GitHub，全球 思科 活动，以及 DevSecCon。

我们仔细研究了数据，发现2020年有成千上万的独立用户在我们的平台上玩过游戏，当我想起六年前我们从哪里开始时，这真是令人难以置信。

我很高兴看到我们在财富1000强公司中的影响力显著增加，每家公司都愿意尝试一些新的东西，作为其安全计划的一部分。我们特别发现了与科技公司的协同效应，其中许多公司转向了远程办公，并看到了远程培训选项的价值。

Awesome 团队一起变得更大、更强大。

在过去的一年中，我们公司最大的发展之一是收购了总部位于冰岛的网络安全公司Adversary。我们有很多共同点：对以人为本的网络安全方法、统一的价值观和互补产品的立场相似。我们欢迎他们的团队加入我们自己的团队，在优秀的人才中获得宝贵的专业知识和才能。

我们还欢迎约翰·威尔逊担任全球销售高级副总裁，这得益于他在推动增长以及将云技术和网络安全公司打造成市场领导者方面25年来的广泛往绩。他广泛的技术技能一直是赛门铁克、Qualys、黑莓和威瑞森等公司的创新力量，能让他与我们一起发挥自己的魔力，我们再高兴不过了。

缺乏实体办公室并没有阻止我们在五个国家招聘六十名新员工，并确保他们能够通过虚拟支持、介绍，当然还有送到他们家门口的梦寐以求的员工礼包，顺利进入工作岗位。

我们在每个部门都持续发展，这对于实现我们快速实现质量代码的全球使命同样重要。但是，仍然感觉我们才刚刚开始。

2021 年，改变对话方式的一年。

长期以来，我一直觉得社会对网络安全根本不够关心，只有在发生极其激烈的事情时，我们才会看到行动和意识的发展。

随着去年年底SolarWinds大规模漏洞的爆发，更多细节浮出水面。损失的全部程度尚不清楚，但这起事件可能成为广泛变革的催化剂。美国政府部门已经在彻底改革其安全计划，而网络间谍活动是损失惨重的话题。

我们仍然可以为所做的一切带来一点乐趣，但是现在是时候卷起袖子开始努力真正改变对话了。

每个具有安全意识的开发人员都能让我们的世界更安全地免受网络攻击，为他们提供成功所需的知识——甚至可能喜欢它——将永远是我们的目标。我们每天都在努力创建工具，供开发人员在学习安全性和创建最高质量的代码时选择使用。安全代码应该是标准，我们都可以伸出援手实现这一目标。

感觉就像 “网络安全合规” 已经流行了多年，无休止的文章、举措和委员会都在讨论世界应如何最好地应对网络犯罪这一巨大的、多重威胁的野兽。

问题是，我们似乎没有做到 那个 取得了长足的进步。在全球范围内，数据泄露的成本一直在稳步上升，五年内增长了12％，稳定在大约 392 万美元 每次违规行为 在 2019 年。随着我们在短短几十年内互联网的使用激增，许多公司在迅速上线、开设商店并应对不安全软件、有限的AppSec资源以及在某些情况下滥用客户信任所带来的后果，只能在没有盔甲的情况下奋斗。

如今，我们无可辩驳地变得更加成熟。我们了解并详细讨论了威胁的范围，各公司都非常清楚网络攻击可能对客户情绪、声誉和利润产生的影响，许多地方都在积极寻求通过合规培训、熟练招聘以及越来越多的DevSecOps计划来改善软件安全性。尽管取得了巨大的飞跃，但我们并没有赢得这场战斗——甚至还差得很远。至少有 四十亿条记录被盗 仅在 2019 年的数据泄露中。

缺少的一个要素是网络安全标准、预期和违规后果方面的渗透有些缓慢（在政府层面）。的来临 GDPR 至少在欧洲，一些人已经开始迎头赶上，但许多政府机构直到现在才迎头赶上，突然需要迅速遵守新出台的合规举措可能会在未来产生一些不利影响。

傻瓜冲进来（参加错误的训练）

以下形式的强有力的指导方针 NIST，新规定 纽约州 以及形成 英国网络安全委员会 对于那些为保护我们的数据安全而奋斗的人来说，所有这些都是巨大的胜利。他们承认当前软件开发中的问题，并采取措施指导组织在安全最佳实践方面，他们现在必须达到的标准，才能被视为合乎道德和合规性。

不幸的是，在现阶段，一些最重要的内容有点难以解释。例如，英国网络安全委员会立法中的一项授权是：

“在已经开展的职业道路基础上，创建明确的认证清单和易于理解的框架，说明它们如何联系在一起以及它们传递了哪些能力”。

尽管随着时间的推移，他们的举措无疑将得到改善和发展，但如果组织现在已经按下紧急按钮并开始培训，他们可能会发现自己没有为未来做好准备。

组织的网络安全需求变化迅速，静态培训解决方案不太可能以所需的速度阻止不安全软件的流动。格局的变化速度比传统课程更新的速度快，这可能会使一些地方陷入 “按需计时” 的合规工作陷阱；开发人员、承包商和其他安全专业人员没有接受足够的培训，我们又回到了袖手旁观的状态。

静态训练和静态工具也会遇到同样的问题

静态分析工具是 SDLC 不可或缺的一部分，它们是大多数大型组织中稀缺且劳累过度的 AppSec 专家的扫描工具。它们做得很好，但有一个缺陷：没有 “一个” 工具可以扫描每一个漏洞，支持现有的各种编程框架。这也是一个缓慢的过程，只需要一个安全漏洞就能为攻击者敞开大门。

在静态训练中，也存在类似的问题。如果开发人员接受严格的 “一劳永逸” 的课程进行安全培训，那么在这段时间内，他们就不太可能跟上最普遍的安全问题。它可以作为写作时间的快照，很少有人对其进行足够的重新审视，以学生的首选语言和框架提供，也与他们在日常工作中可能面临的漏洞无关。想象一下，试图回忆起你几个月前观看的视频中的一条相关信息，同时试图在交货截止日期之前发布代码... 这不太可能发生。

许多行业正在重新评估传统的教育方法，但是当涉及到开发人员的安全培训时，您只需要看看我们仍然经历的大量数据泄露事件（尤其是那些可以归咎于我们几十年来在编程中如何避免的漏洞的泄露事件）， 像 SQL 注入一样）才能意识到我们必须尝试不同的方式。

我们需要的培训超越单一线性课程的局限，能够灵活适应网络安全最佳实践不断变化的需求。

动态训练：黄金标准

通过为开发人员提供动态培训解决方案，该解决方案可以根据业务、个人技能水平和一般行业动态进行快速调整，您可以为他们提供安全编程、将安全放在首位并以安全意识思维行事的最佳基础。

一刀切、从不重新审视、一开始就不参与的培训将完全是在浪费时间，不幸的是，这意味着你最终可能会为了合规而冲动购买一个无效的计划。它可能在你推出之前就已经过时了，或者与他们的日常工作需求几乎无关。

动态训练是一种活生生的呼吸工具，它会不断更新，符合日常需求，让用户进行批判性思维和 实际上是赋予他们学习技能和解决问题的能力。

那么，在安全背景下，动态培训计划是什么样子呢？

它将是：

• 一口大小：开发者可以用可管理的部分学习技能，这些技能比冗长的训练套牌和视频更容易记住（更重要的是应用）
• 相关： 当开发人员主要使用Java编写代码时，如果示例以（比如）C＃编写，则通用安全培训有什么用？任何培训都应直接适用于他们的角色，让他们在编程时能够看到需要发现和修复什么（最好是首先要避免）。
• 当前： 这似乎很明显，但通常不是。网络安全格局一直在变化，代码越多，责任就越大。要让开发人员成为您的第一道防线，他们需要接受与现代安全最佳实践保持同步。
• 引人入胜： 开发人员会觉得 “安全” 是一件苦差事，这已经不是什么秘密了，尤其是当它干扰了他们的创作流程时。正确的培训将向他们展示他们在解决可能演变为巨大风险的日常安全问题、建立责任文化和安全意识方面的能力。
• 乐趣： 动态训练很少是无聊的；从设计上讲，它至少应该有些令人兴奋。想想开发人员喜欢什么：解决问题、与同行竞争，以及像我们许多员工一样，奖励和认可。发挥自己的优势，专注于取得最佳成绩。

对于成为一名软件工程师来说，这是一个激动人心的时刻；他们在数字创新中发挥着不可或缺的作用，帮助打造出色的公司，甚至用自己的创作席卷全球。但是，随着政府机构和大型企业意识到他们在制定软件安全标准方面需要发挥的作用，重要的是要通过有效、动态的培训解决方案来支持他们，培养对安全编码的热爱，而不是官僚主义的勾选活动。

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 (s) 压缩文件

通过共享食谱，Sensei 帮助团队合作进行知识共享。此次合作有助于改善沟通并嵌入商定的代码质量方法。

例如，分享一本食谱：

• 帮助团队成员互相分享有用的食谱。
• 支持团队领导为初级员工编纂商定的编码惯例，以识别常见的违规行为，快速修复商定版本。
• 促进团队间合作的增强，例如 AppSec 团队可能会创建配方来突出代码中的问题，开发团队可以编写快速修复方法。

接下来的几节将解释如何实现每种共享机制。

在版本控制下将食谱存储在项目中

项目 .sensei 文件夹是创建食谱文件时的默认选项。

• `project: //.sensei`

所有食谱和食谱都将存储在项目的 .sensei 文件夹中。

最简单的共享方法是将项目 .sensei 文件夹添加到版本控制中。

然后，可以像管理与项目相关的任何其他共享代码工件一样管理 .sensei 文件夹。食谱以 YAML 配置存储，因此在任何提交和审阅过程中都可以轻松合并。

这是公共感知博客示例项目所采用的方法。

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

.sensei 文件夹包含包含所有食谱的食谱，任何克隆存储库的人都可以使用它们。

将食谱存储在任何文件夹中

团队还可以使用存储在中心位置的食谱。

将食谱保存到任何具有共享写入权限的文件夹，将允许整个团队更新食谱，并将它们导入他们碰巧正在处理的任何项目中。

该位置将设置为目录路径。

在 Github 存储食谱

Sensei 还可以访问存储在 Github 存储库中的食谱。支持私有和公共存储库。

基于 SSH 的 Git

使用以下位置语法配置 SSH 存储库访问权限

git@github.com: SecureCodeWarrior/cookbook.git

为了使其起作用，存储库将包含食谱文件夹的内容。

也可以为食谱配置分支和子文件夹，例如在食谱子文件夹的主分支中

Por ejemplo

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

需要为私有存储库配置 SSH 密钥。

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

而且密钥不应该有密码。

基于 HTTPS 的

也可以通过 HTTPS 访问公共存储库，并且使用相同的 repo.git|branch|folder 语法，例如

对于我们的博客示例项目：

• 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 访问压缩后的食谱。

例如，如果我有一个 HTTP 服务器在本地监听端口 8000

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

压缩食谱文件应包含食谱文件夹的内容，例如 rules.sensei 文件。

分享摘要

Sensei 支持使用多本食谱，这样个人程序员就可以拥有支持他们自己的学习和生产力的食谱。

更重要的是，我们知道共享知识时团队的工作效率最高。共享团队存储库，例如针对特定项目、特定库，或共享一组迁移模式，可以帮助提高团队生产力并整理团队的经验。

共享食谱时，多个团队可以使用同一本食谱，这也可以改善从不同学科（例如 AppSec 到开发）的团队间协作。

Sensei 有四种核心共享机制可供选择，希望您至少有一种方法可以用来加强知识共享方面的协作。

---

你可以使用 “首选项\ 插件”（Mac）或 “设置\ 插件”（Windows）从 IntelliJ 中安装 Sensei，然后只需搜索 “sensei 安全代码” 即可。

所有的 Sensei 博客文章、代码和食谱都位于 Github 上：

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