安全代码洞察

多年来，安全领导者在安全编码项目上投入了大量资金，但一个基本问题仍未得到解答：我们是否真正了解谁在提交代码，他们是否具备编写、审查并最终交付安全代码所需的技能？

传统的 "左移 "方法使企业在为安全编码项目发现和录用开发人员时存在大量盲点。由于项目管理人员依赖人工检查、电子表格和人力资源组织结构来跟踪开发人员的安全编码技能，因此经常会出现 "影子开发人员"，他们在关键代码库中贡献代码，但却缺乏安全技能。这种情况严重损害了安全 SDLC 目标，并使管理复杂化，在面对内部或外部审查时难以证明安全能力。

Secure Code Warrior信任代理消除了这一风险，将您的安全编码程序转化为持续监控、可验证的防御，让 CISO 和 AppSec 领导者有信心证明他们的开发人员在每次提交时都具备必要的安全能力。

信托代理的持续监督和保证

没有持续的监督，开发人员的风险就会隐藏起来。Trust Agent 通过在代码提交级别实现安全操作，提供持续的可视性。

持续发现开发人员：了解你的范围

在确保代码库安全之前，您必须知道谁在接触它。

Trust Agent 会自动扫描您的集成资源库，以发现整个代码库中所有活跃的代码贡献者。这有助于解决入职（一个持续的过程）的关键挑战，并回答以下问题：您是否知道新工程师或承包商何时加入，以及他们是否立即接受了相关的安全编码教育？通过持续监控提交，我们可以确保立即识别每一位开发人员，并开始他们的安全编码之旅，消除典型的入职延迟，确保全面的计划范围。

‍

验证能力：监控代码，而不仅仅是学习完成情况

除了发现所有代码贡献者之外，Trust Agent 还通过持续实时监控安全编码技能的应用，将学习数据转化为确凿证据。它将每次代码提交与开发人员经过验证的特定语言安全编码能力关联起来，从而提供深度可观察性。

这对于 PCI DSS 4.0（要求 6.2.2）等规定至关重要，该规定明确要求每 12 个月对开发人员提交代码的语言或框架进行一次安全代码培训。Trust Agent 为您提供所需的可审计证据，以证明安全能力与关键应用程序中使用的语言和框架相一致。

此外，Trust Agent 还能准确指出哪些团队或代码库中有大量来自缺乏足够安全技能的开发人员的提交，从而即时洞察您的风险态势。这种可视性使程序管理员能够根据最相关的实时数据，轻松地将正确的教育分配给正确的开发人员。

综合治理和政策控制

归根结底，要想真正降低开发人员的安全风险，就必须实施治理。Trust Agent 能够将控制措施直接移入现有的开发工作流中，并根据企业的风险承受能力定义提交策略，从而使安全熟练程度成为强制性要求。Trust Agent 可直接在提交工作流中自动进行管理，如果开发人员的安全编码技能水平不足，可配置策略门以记录、警告或阻止拉取请求。这种集成式管理是真正确保安全的关键所在，而不是可有可无的建议。
‍

确保发展的未来

向可验证的安全编码能力迈进并不仅仅是为了通过审计--归根结底，这是为了交付创新、安全的代码。即使或特别是随着人工智能辅助开发的兴起，基本原则仍然是：开发人员必须具备安全能力，才能真正降低风险。 通过将开发人员的安全编码能力作为一项可衡量的要求，SCW Trust Agent 是确保您的组织不仅能履行合规性和监管义务，而且能从根本上从内部加强其安全态势的关键一环。

要了解更多信息，请预订演示或联系您的客户成功经理！

‍

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

如今，几乎每个开发团队都采用了某种形式的合规性培训，无论是用于确保公司在行业框架或政府法规范围内的初始认证过程的一部分，还是作为年度要求或审查的一部分。这是一个重要的步骤，因为如果一个组织不能满足基本的合规要求，那么它的员工就不能现实地履行他们的职责。

合规规则的存在是有原因的，因为在这些规则所涵盖的领域内工作的任何人都必须至少对所有相关的过程和程序以及任何适用的法律有一个基本的了解。

虽然合规培训很重要，但完成规定的最低要求并不能确保真正的应用安全。对于试图将安全编码技能融入日常工作流程的开发人员来说，这一点尤其重要。几乎每个开发人员都接受了某种形式的合规性培训，但在接受调查时，67%的人承认，他们经常在代码中留下漏洞。

为什么？

2021年12月，Secure Code Warrior ，与埃文斯数据公司合作进行了 "2022年开发者驱动的安全状况调查"，这是第二年。我们在全球范围内调查了1200名开发人员，以了解安全编码实践时的技能、看法和行为，以及它们在软件开发生命周期（SDLC）中的影响和感知的相关性。

关于为什么合规性培训没有达到提高软件安全的目的，这是一个我们已经讨论了很久的问题。最近的调查只是点出了这个问题。

一方面，开发人员被要求加强新的角色，将网络安全纳入整个软件开发过程，包括在他们最初为应用程序和程序编写代码时。但是，编写安全代码，甚至只是了解所有可能影响它的网络安全问题和漏洞，并不是一件容易的事。在调查中，63%的开发人员表示，编写安全代码是一项困难的任务。

编写安全代码的难度不应该是一个惊喜。这么多高薪的网络安全工作没有得到满足是有原因的，据统计，全球有超过350万个职位空缺。如果它是容易的工作，每个人都会跳进这个领域。学习如何打击威胁和消除代码中的漏洞是很困难的，而且威胁的情况也在不断变化。静态合规培训或一次性课程无法跟上或提供开发人员所需的教育。它可能会在合规性方面打勾，但不能为你的组织提供真正的应用安全保证，或使开发人员能够编写安全的代码，或发现和修复代码漏洞的技能。

合规和安全培训很重要，但不同

组织必须开始意识到并承认合规性培训能做什么，以及不能做什么。不要放弃合规性培训，尤其是在法律规定的情况下。尤其是因为（即使采用目前的培训方法）92%的调查对象表示，他们至少需要一些与合规性有关的问题或安全框架的培训，其中50%强调需要大量的合规性培训。

他们对培训最感兴趣的合规性框架包括那些针对不同行业的框架，尽管一些一般的网络安全框架也在名单上。它们包括CIS安全框架、PCI DSS、OWASP Top 10、MISRA C、ISO/IEC、健康保险可携性和责任法案（HIPAA）以及其他。

因此，是的，在这些框架中进行培训，但要明白，在合规性培训上打勾并不等同于为持续创建安全代码提供基础。

相反，将合规性培训视为扩展开发人员安全编码技能的持续机会的一部分，可以在合规性周期之外重复进行，这样他们就可以每天创建和发布安全软件。将优先权从实现合规性转移到使开发团队能够通过持续学习进行安全编码。通过投入时间和资源给开发人员，那么那些每年的复选框合规性练习或考试对你的员工来说将变得轻而易举地通过和完成，同时受益于整体生产力的提高。

如何实现向开发者驱动的安全转变？

开发人员绝大多数都说培训是有价值的，但对他们多年来接受的安全编码培训的类型有异议。开发人员说，他们希望看到更多的强调使用与他们工作相关的真实世界的例子的实际培训（30%）。26%的受访者认为更多的互动性也是至关重要的，特别是如果他们能够实际练习编写安全代码作为这些练习的一部分。

23%的受访开发者认为，希望接受更多的指导性培训，专注于他们在行业或部门中最有可能遇到的特定漏洞，而22%的人希望在培训中看到更多真实世界的漏洞案例courses 。

很明显，简单地提供静态的、非互动的培训（这通常是合规性培训的经验）在可重复的开发人员安全技能方面没有什么价值。相反，企业应该把重点放在及时培训等方面，让开发人员在工作中学习安全知识。你甚至可以考虑实施一个分层的学习计划。

通过分层方法，较大的主题通常被分解成独立的学习经验或概念。随着开发人员的进步，更高级的概念被分层在那些已经掌握的概念之上，就像物理脚手架随着建筑物的升高而被建造。这使得像网络安全这样困难且不断发展的主题的教学成为一种行之有效的方法，首先将其分解成较小的、不那么复杂的块状，然后在此基础上建立更多的复杂性。

无论你决定如何处理你的开发人员安全技能计划，将其与合规性练习分开将是关键。合规性和安全培训都很重要，但两者都需要不同的方法来获得成功。

进一步阅读

白皮书。改善软件安全的挑战（和机遇）。

白皮书。软件安全的预防性开发者方法。

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

在过去的20多年里，同样的10个软件漏洞造成的安全漏洞比其他任何漏洞都多。然而，许多企业仍然选择在漏洞发生后进行补救；在这一切的人为和商业影响中浑浑噩噩。但现在，一项新的研究指出了一个新的、由人主导的方向。

以下讨论的是由Secure Code Warrior 与Evans Data Corp进行的一项研究得出的见解，该研究题为 "从反应到预防。应用安全的变化"（2021年），探索开发人员对安全编码、安全代码实践和安全操作的态度。下载白皮书 这里.

在即将发布的研究中，开发人员和开发经理被问及他们与安全编码相关的活动。排名前三的回答是。

• 在已部署的应用程序上使用扫描工具。
• 手动审查代码中的漏洞。
• 
  ，积极和持续地编写受保护的软件，以防止漏洞。

那么这告诉我们什么呢？在前三个回答中，有两个仍然集中在反应式方法上，第一个依赖于工具（扫描器），第二个依赖于开发人员（即人类）进行手动检查--在这两种情况下，都是在代码编写之后。使用这些方法检测到的漏洞必须被踢回给开发团队进行返工，这对项目的时间表和项目成本都有影响。

同时，在被提名的三项活动中，有两项依赖于人的因素--这表明人们越来越认为安全是一个人的问题。但在所有被提名的活动中，最能说明问题的是第3项，它确定了在编写软件时的人为因素，首先要保护其不受漏洞的影响。 这突出了一个向左开始的转变--一种主动的和预防性的方法，从软件开发生命周期的一开始就将安全纳入软件。 

反应性可能等于昂贵的

根据IBM的一项研究*，修复发布后的代码中的漏洞要比在一开始就发现和修复这些漏洞的成本高30倍。这是一个强大的激励机制，促使我们采取新的积极主动和更人性化的方法来捍卫软件安全，使开发人员从一开始就能更安全地编码。 

这就是你可以称之为人类主导的防御。但要让开发人员开始关心安全问题，它必须成为他们每天思考和编码方式的一部分。这就要求采取新的培训方法，与开发人员的日常工作高度相关，并激发他们的学习欲望--目前的培训模式无法做到这一点。

为了创造一种积极主动的安全文化，需要新的培训，即。

• 使安全编码成为开发人员提高软件安全技能的一种积极和参与性的体验。 
• 鼓励开发者以安全的思维方式看待他们的日常编码任务 
• 使安全编码成为他们日常工作流程的内在要求
  

当这些线索结合在一起时，就能从一开始就防止漏洞的发生，使团队能够更快、更有信心地交付高质量的代码。好消息是，在软件开发过程中，已经有一个Learning Platform ，'从左边开始'--它已经赋予开发人员技能和工具，从一开始就创建高质量的代码。

‍

*IBM软件集团；尽量减少代码缺陷以提高软件质量和降低开发成本
https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

这篇文章的一个版本出现在 黑暗阅读.它已被更新并在此转发。

当与开发人员谈论安全问题时，我的一个口号是："唯一优质的代码是安全的代码"。这仍然是事实；当90年代有漏洞的软件在野外出现时，我们可能躲过了灾难，但今天不值得冒险。多年来，许多人努力向开发人员灌输安全意识的心态，在这样做的过程中，希望在涉及到他们的代码的自我assessment ，使安全成为质量的同义词。

经过思考（以及我的同行之间的一些辩论），然而，这也许是过度简化了这个概念。我们完全有可能创造出确实安全的代码，但却显示出新手开发技术的迹象，或其他使其不太理想的问题领域。

我们的行业详细地讨论了 "向左转移 "的概念。在我看来，这都是关于 "开始 "向左移动，使工程组群能够分担安全责任（作为质量的一个方面），并给予他们权力来消除他们（字面上）指尖上的常见漏洞。不过，鉴于目前的这个难题，似乎必须把信封推得更远一点。

具有一定质量水平的代码根据其定义也是安全的，但所有安全的代码不一定是好的质量。从 "左边的左边 "开始，是确保纯安全编码标准的公式吗？

质量差 "的安全代码是什么样子的？

让我们把放大镜放在这个代码片段上。

如果我们从安全的角度来分析这段代码，这段代码确实是安全的，而不是攻击者利用SQL注入漏洞的入口。  

这是一个高质量代码的例子吗？很不幸，不是。简单地将参数从int(eger)改为String值，就可以让用户自由输入来操作查询，而数字则不能。这种改变--或者从其他地方胡乱复制和粘贴String sql--立即创造了一个可能存在SQL注入漏洞的环境，以及与之相关的所有风险。

安全措施在这里的范围非常有限，而一个更彻底的（或者，有经验的）开发者可能会采取不同的方法，并考虑低效参数结构的影响。运送这样的代码不仅是糟糕的做法，而且为开发组中的其他人树立了一个坏榜样。

软件的 "三重威胁"。形式、功能、堡垒般的？

娱乐业中的 "三重威胁 "是指能够以同样高的技术水平表演、跳舞和唱歌的人。他们是每次试镜时令人恐惧和羡慕的人，是已经竞争激烈的领域中的独角兽。每个行业都有自己版本的顶级、特殊的产品和服务的例子，软件也不例外。

如果我们想一想应用程序中很难与同等（高）质量相平衡的三个关键因素，它们可能是功能/优雅，加上铁一般的安全，再加上考虑所需的交付速度时的成本效益。现在，最后一个属性无疑是其他两个选项应用得好坏的决定性因素，它可以成为整体质量随着时间推移而下滑的催化剂。

然而，是否所有的软件都需要像休-杰克曼那样表现，或者我们可以用尼古拉斯-凯奇来逃避？这样说吧：如果你能让金刚狼加入你的团队，那么你就给它最好的机会。

马丁-福勒（Martin Fowler）在软件开发中提出了 "高质量是否值得"的问题，他的结论是，不仅 "值得"，而且随着时间的推移，它实际上更便宜。大多数用户不会去看引擎盖下的代码是否一团糟，也不会去看安全是否和其他东西一样重要。然而，那些工具上的人将浪费宝贵的时间重做马虎的代码，以增加更新的功能，或遍历项目的主要部分，以了解发生了什么，或者，最糟糕的情况是：修复一个从AppSec团队反弹回来的漏洞，推迟生产。现在花时间使代码既安全又优质，可以节省很多未来的心痛，更不用说解开执行不力的工作的成本。

熟练的有安全意识的开发人员编写的代码，在功能交付中保留了他们创造性的、解决问题的视野，并考虑消除工程师在其阶段可以控制的常见安全隐患。安全代码在孤立的情况下并不十分有效，这就是为什么 "从左到右 "的概念将有助于支持安全文化成为开发人员的第二天性，建立在他们提供惊人的功能并降低风险的能力中。

从 "左边的左边 "开始是安全用户体验的关键。

长期以来，安全问题一直是软件用户体验中的一个考虑因素，但显然结果是好坏参半。在过去的一年中，安全配置错误占了基于云计算的数据泄露的21%，业余时间的错误，如以明文存储密码，给受影响的公司带来了一些生产力、收入和客户信任的严重损失。

而且，在保护自己的数据方面，用户自己可能是他们自己最大的敌人。太多的人仍在使用 "密码 "作为他们的密码，或在多个敏感账户中使用相同的组合。

我不知道有哪个开发者在被告知他们必须在登录屏幕上工作的时候会拍手叫好，这也难怪：设计一个安全流程是一个微妙的平衡，既要稳健、实用，又要让用户能够以一种对他们有意义的方式来浏览，而且干扰最小。

放置太多复杂的步骤和限制，用户可能会关闭，再也不会回来（这对一个新的应用程序来说是一场灾难），让它变得太混乱，你可能会让支持团队在处理用户试图访问他们的账户的询问时集体偏头痛。如果把它弄得太简单，那么你在安全方面就有点失败了。

一个成功的安全用户体验需要将严密的安全编织到一个有意义的流程中，并以一种不影响软件其他引人注意的方式呈现。你当然可以满足编码安全登录功能的目标，放入各种复杂的密码要求、验证码、小老板和四波僵尸，但如果它是一个完全混乱的、令用户厌恶的东西，它就没有达到目标。

为卓越的软件奠定基础。

作为一名开发人员，我知道我们绝大多数人都对自己的工作感到自豪，并希望做正确的事情。讨厌的曲线球，如时间限制，当前目标的突然变化，或紧急的热修复，会扰乱流程并导致错误，但残酷的事实是，许多软件工程师没有为成功做好准备。

从 "左边开始 "是一个开发者优先的概念，需要企业认真对待提高他们的工程队列的问题。有安全意识的开发人员是物有所值的，以培训的形式提供支持，提供正确的工具，并提供机会让更多有经验的开发人员对其进行指导，这将培养一种环境，使代码以安全第一的心态制作，并以精确和注重细节的方式将软件推向新的水平。

准备好点燃自己身上的安全编码之火了吗？ 迎接挑战.

‍

这是一年中的一个特殊时刻（无论如何，对我们来说），我在这里反思我们最近围绕太阳的一圈，以及在过去的三百六十五天里所做的事情，使我们为新一年的成长、教训和不可避免的不可预知性做好准备。

虽然我认为没有人能够预见到去年的曲折--毕竟，我认为我们大多数人面临的曲线球比洛杉矶道奇队还要多--但我们仍然在这里。日历的翻转并没有让 "无法命名的一年 "的痛苦点突然停止，但在我周围，我看到个人、企业和我们行业坚定不移的复原力。

那么，我们在确保整个银河系代码安全的目标上取得了哪些进展？

我们加强了我们的产品套件。

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

我们希望激励开发人员接受一种预防性的安全编码方法，使每个团队都能自信地交付高质量的软件。

我非常自豪地详细介绍我们的产品团队如此努力地推出的产品；他们在整个一年中踢出了不可思议的目标。

• 我们收购了Adversary.io，并在不到9个月的时间里整合了他们的技术、他们惊人的技术团队和企业客户。
• 我们达到了一个令人难以置信的里程碑，即支持超过50种编程语言，包括Docker、Ansible、Terraform、Kubernetes、Powershell和CloudFormation等基础设施即代码的主流语言，以及Rust和Go等新的孩子。
• 除了Atlassian JIRA Cloud & Server之外，还为GitHub Actions和Issues发布了全新的扩展程序，为开发者带来安全知识，在开发者玩耍的地方提供上下文学习，无需在任务之间切换。
• 在IDE中的实时质量代码指导 Sensei现在可以在JetBrains市场上为每个开发人员提供检测安全漏洞、执行最佳实践、分享知识以及防止性能问题和技术故障的指导。
• 通过发布以下内容，使企业更容易与开发人员接触并扩大安全编码的规模 Courses一个全新的功能，允许为与企业及其安全目标最相关的目标策划学习途径。我们还增加了 Missions我们还为旗舰平台增加了一个令人兴奋的增强功能，使开发人员能够成为漏洞的驾驶员。这是支架式学习方法的下一步，为开发者提供了一个可行的、终身的成功基础。

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

我们登陆了，我们扩大了，我们影响了。

我们喜欢用一些不同的方式来处理安全编码，自然，我们也希望这种精神能在整个行业中得到普及。重要的是，开发人员要认识到他们在与网络攻击者的斗争中的力量，让他们真正喜欢学习安全知识是一个首要目标。

数千名来自世界各地的开发者加入了我们的虚拟Tournaments，仅在2020年就举办了80多场。我们很高兴能让人们作为GitHub Universe、全球思科活动和DevSecCon的一部分进行比赛。

我们挖掘了我们的数据，看到2020年有数十万独立用户在我们的平台上玩耍，当我想到我们六年前开始的时候，这真是令人震惊。

我非常高兴地看到，我们在财富1000强企业中的影响力大大增加，他们每个人都愿意尝试新的东西作为其安全计划的一部分。我们特别发现了与科技公司的协同作用，其中许多公司转向了远程工作，并看到了远程培训选项的价值。

令人敬畏的团队变得更大，更强大，一起。

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

我们还欢迎约翰-威尔逊担任全球销售高级副总裁，这得益于他25年来在推动增长和将云技术和网络安全公司建设成市场领导者方面的广泛记录。他广泛的技术技能已经成为赛门铁克、Qualys、黑莓和Verizon等公司的创新力量，我们非常高兴他能与我们一起施展魔法。

缺乏实体办公室并没有阻止我们在五个国家为60名新员工办理入职手续，并确保他们能够通过虚拟支持、介绍，当然还有令人羡慕的员工礼品包送上门来。

我们在每个部门都持续增长，在实现我们的全球使命，即快速实现高质量的代码方面都具有同等重要性。然而，我们仍然感觉到我们才刚刚开始。

2021年，是改变对话的一年。

长期以来，我一直认为社会对网络安全关心不够，只有当一些令人难以置信的重大事件发生时，我们才可能看到行动和意识的指针在移动。

随着去年年底SolarWinds的巨大漏洞被打破，更多的细节正在浮出水面。损失的全部程度仍不为人所知，但这一事件可能成为广泛变革的催化剂。美国政府部门已经在全面改革他们的安全计划，而网络间谍在那些有很大损失的人中是一个非常热门的话题。

我们仍然可以在我们所做的一切中加入一点乐趣，但现在是时候卷起袖子，开始工作，真正改变对话。

每一个有安全意识的开发者都会使我们的世界更安全一些，不受网络攻击的影响，而给他们提供成功的知识--甚至可能是爱上它--将永远是我们的目标。我们每天都在努力工作，创造出开发者在学习安全知识时选择使用的工具，并创建最高质量的代码。安全代码应该是标准，而我们都可以为实现这一目标而伸出援手。

感觉上，"网络安全合规 "已经流行了很多年，有无尽的文章、倡议和委员会在讨论世界应该如何最好地解决网络犯罪这个巨大的、多威胁的野兽。

问题是，我们似乎并没有取得那么 大的进展。在全球范围内，数据泄露的成本一直在稳步上升，在五年内增长了12%，到2019年，每个泄露事件的成本约为392万美元。随着我们对互联网的使用在短短几十年内爆炸式增长，许多公司只能在没有盔甲的情况下战斗，因为他们迅速上网、开店并处理不安全的软件、有限的AppSec资源以及在某些情况下滥用客户信任的后果。

这些天，我们无可辩驳地更加成熟了。我们了解并详细讨论了威胁的范围，公司很清楚网络攻击会对客户的情绪、他们的声誉和他们的底线产生影响，许多地方正在积极寻求通过合规培训、熟练的招聘和越来越多的DevSecOps举措来提高软件安全。尽管有了这些巨大的飞跃，我们并没有赢得这场战斗--甚至没有。仅在2019年，就有至少40亿条记录在数据泄露事件中被盗。

在网络安全标准、预期和违规后果方面，缺少的一个因素是（在政府层面）缓慢的涓涓细流。至少在欧洲，GDPR 的出现让一些人开始行动起来，但许多政府机构现在才追赶上来，而突然需要迅速遵守新出现的合规举措可能会在未来产生一些不必要的影响。

愚人冲进（错误的训练）中

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

不幸的是，在这个阶段，一些最重要的内容有点太容易被解释。例如，英国网络安全委员会的立法中的一项任务是。

"在已经开展的职业道路工作的基础上，创建一个明确的认证清单和一个易于理解的框架，说明它们之间的联系以及它们所传达的能力"。

虽然他们的举措无疑会随着时间的推移而得到改善和发展，但如果企业现在已经按下了恐慌按钮并跃跃欲试地进行培训，他们可能会发现自己对未来准备不足。

一个组织的网络安全需求变化很快，静态的培训方案不太可能以所需的速度阻止不安全软件的流动。情况的变化比传统课程的更新速度更快，这可能会使一些地方陷入 "打勾 "的合规性练习陷阱；开发人员、承包商和其他安全专业人员没有接受足够的培训，我们又回到了坐以待毙的状态。

静态训练和静态工具存在同样的问题

静态分析工具是SDLC的一个组成部分，为大多数大型组织中稀缺且工作过度的AppSec专家提供扫描工作。它们做得很好，但有一个缺陷：没有一个工具可以扫描每一个漏洞，支持现有的大量编程框架。这也是一个缓慢的过程，只要有一个安全漏洞通过缝隙，就会给攻击者留下一个门。

对于静态培训，也有一个类似的问题。如果开发人员接受的安全培训是僵化的、"一劳永逸 "的课程，那么它就很难跟上那段时间内最普遍的安全问题的步伐。它只是写的时候的一个快照，而且很少有足够的重温，用学生喜欢的语言和框架来提供，也没有与他们在日常工作中可能面临的漏洞相联系。想象一下，当你试图从几个月前看的视频中回忆起一个相关的信息，同时又想在交付期限前完成代码......这是不可能的。

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

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

动态训练：黄金标准

通过为开发人员提供一个动态的培训解决方案，一个可以根据业务、个人技能水平和一般行业动态迅速形成的解决方案，你将为他们提供安全编码的最佳基础，保持安全领先，并以安全意识的心态行事。

那些一刀切的、从未被重新审视过的、一开始就没有吸引力的培训将完全是浪费时间，不幸的是，这意味着你最终可能为了遵守规定而冲动地购买一个无效的项目。它可能在你推出之前就已经过时了，或者与他们日常工作的需要几乎没有关系。

动态培训是一个活生生的工具，它不断更新，与日常需求相联系，让用户参与批判性思维，并实际赋予他们学习技能和解决问题的能力。

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

这将是。

• 一点一滴。开发人员可以在可管理的小块中学习技能，这比冗长的培训手册和视频更容易记住（更重要的是，应用）。
• 相关的。 当开发人员主要用Java编程时，通用安全培训的例子是C#，那有什么用呢？任何培训都应该直接适用于他们的角色，让他们在编码时看到应该发现和解决的问题（最好是在第一时间避免）。
• 当前： 这似乎很明显，但往往不是。网络安全环境一直在变化，而更多的代码带来了更多的责任。为了让开发人员成为你的第一道防线，他们需要接受与现代安全最佳实践保持同步的培训。
• 吸引人。 开发人员认为 "安全 "是件苦差事，这已经不是什么秘密了，尤其是当它干扰了他们的创作流程。正确的培训将向他们展示他们在解决可能演变成巨大风险的日常安全问题方面所拥有的力量，建立一种责任和安全意识的文化。
• 乐趣。 动态培训很少是枯燥的；从设计上来说，它至少应该是有点刺激的。想一想开发人员喜欢什么：解决问题，与同行竞争，以及像我们许多人一样在工作中获得奖励和认可。发挥他们的长处，专注于获得最佳结果。

作为一名软件工程师，这是一个令人兴奋的时代；他们在数字创新中扮演着不可或缺的角色，帮助创建令人惊奇的公司，甚至用自己的创造掀起世界风暴。然而，随着政府机构和大型企业意识到他们在制定软件安全标准方面需要发挥的作用，重要的是要通过有效的、动态的培训解决方案来支持他们，培养他们对安全编码的热爱，而不是官僚主义的打勾做法。

根据IBM的一项研究，与最初发现和修复漏洞相比，在发布后修复漏洞的成本要高出30倍。考虑到这一点，具有前瞻性的首席信息官正在实施安全编码实践就不足为奇了。这意味着培训和装备开发人员从一开始就编写更安全的代码，使他们成为组织的 "第一道防线"。为了衡量这一趋势的实际影响，Secure Code Warrior ，与埃文斯数据公司*合作，委托进行一项关于开发人员对安全编码、安全代码实践和安全操作的态度的最新研究。这项研究显示，实施安全代码实践对公司在几个不同方面都有影响。下载该白皮书的副本 这里.

以更大的信心和心态安全地进行编码

毫无疑问，实施安全编码实践提高了开发人员的安全意识，使其雇主受益。我们的研究显示，55%的开发人员说，良好的培训增加了他们对自己编码技术的信心，53%的人说，良好的培训让他们在调试和测试自己的代码时更加谨慎。同样有53%的人认为他们在编写代码时更加注意安全问题。

这告诉我们什么呢？它告诉我们，只要稍微提高一下技能，开发人员就可以转变为你的第一道防线。

更智能的工具选择+更高的发布速度

当我们问及管理人员关于安全代码培训的影响时，他们的观点反映了他们的管理职责。43%的经理同意安全代码培训帮助他们的组织在调试和测试代码时变得更加谨慎。47%的人透露，良好的培训使他们能够更有选择地选择提供更多安全性的工具。但也许最重要的是，44%的人表示，安全代码培训和技术帮助节省了时间，加快了软件发布的速度--当市场速度决定一切时，这是一个实质性的优势。

全面提高生产力

当我们询问开发者安全编码对生产力有什么帮助时，超过一半的人认为它有助于提高编码和应用程序的设计质量。  

63%的人说它通过防止反复出现的漏洞减少了返工。70%的人说它有助于消除导致返工或修补的错误。56%的人称，它提高了调试和测试的生产力。我们可以看到在软件开发生命周期的多个阶段都在进行转变。

团队动态和代码质量

安全的代码实践也会对团队的动态产生影响。虽然单个开发人员学会了更安全的编码，但他们的代码并不存在于真空中。他们的代码往往取决于其他人的工作，反之亦然。实施安全编码实践会使开发人员分享和寻求安全编码知识，推动开发人员之间、开发人员和管理层之间以及开发团队和他们的利益相关者之间更好的沟通。

• 60%的受访开发者认为，采用安全代码的做法增加了他们与其他开发者的沟通。
• 45%的人说，与管理层的接触增加了。

这些观点得到了管理人员的响应，尽管是从不同的角度。62%的受访经理人声称，安全代码实践需要他们花更多的时间来管理人员，并帮助提高代码发布的速度。

对于实施安全代码实践的组织来说，沟通的增加对团队的动态产生了过渡性的影响，对代码质量和上市速度产生了积极的影响。

从反应性转变为预防性

最后，安全代码会影响到开发人员和开发经理应用安全措施的方式及其附带的衡量标准。

今天，81%的组织仍然依靠缺陷计数和扫描器指标等反应性指标来确定安全质量。

但这些被动的活动正越来越多地被主动或预防的指标所补充或让位于主动或预防的指标。67%的组织现在将开发人员对OWASP Top 10的认识作为安全准备度的衡量标准。其他越来越多的主动性指标包括。

• 围绕应用安全衡量开发人员的能力
• 使用预先批准的代码
• 遵守监管要求。

90%的开发人员现在注意到了这些预防措施。但是，虽然对安全编码实践的认识和实施正在增长，但要实现其全部潜力还有一段路要走。

今后该何去何从？

作为安全编码变革的推行者，Secure Code Warrior 采取以人为本的方法，帮助您将您的开发人员转变为您的第一道防线--以及您的整体安全方法从被动到主动。我们经过验证的learning platform ，在52种语言：框架特定的类别中提供上下文的实践教育，其挑战是模仿开发人员在现实世界中所面临的。我们从深刻的经验中知道，与基于理论的静态学习的挣扎相比，开发者更喜欢在实践中学习的方法。如果你想看看这对你的团队和他们有信心地发送高质量代码的能力所产生的变革性影响，现在就预订一个演示。

‍

从反应到预防的转变。应用安全的变化。Secure Code Warrior 和 Evans Data Corp. 2020年
1.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는 지식 공유에 대한 협업을 증진하는 데 사용할 수 있는 접근 방식을 하나 이상 갖게 되기를 바랍니다.

---

IntelliJ 내에서 “환경설정\ 플러그인” (Mac) 또는 “설정\ 플러그인” (Windows) 을 사용하여 Sensei를 설치한 다음 “센세이 보안 코드”를 검색하기만 하면 됩니다.

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

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