Secure Code insights

Software development & Cybersecurity are undergoing the most profound shift in their history, and we’re facing an immediate future in which many security leaders may be caught unprepared. We are rapidly transitioning from human-written code assisted by AI, to AI-native workflows, and ultimately toward fully agentic systems where AI builds code with human accountability. In fact, recent data shows that 72% of developers are already using some form of AI in their daily workflows.

While this incredible acceleration in development velocity is exciting, it brings to the table a risk profile that is often hidden. In this new era of AI adoption, theoretically, every employee will become a "builder" of applications and AI agents. However, as the barriers to software creation fall, we face the dangerous reality that many of these new builders are skipping fundamental security principles in software design, architecture, and execution. When AI copilots generate code, organizations must ensure that this software remains secure, compliant, and rigorously governed.

That is why I am thrilled to announce today an upcoming strategic partnership between Secure Code Warrior and KnowBe4. KnowBe4 is a world-renowned leader in comprehensively managing human and agentic AI risk, making them the perfect partner to help us distribute foundational security awareness to organizations across the globe.

Despite the rapid adoption of AI coding tools, a massive governance gap has emerged. Security leaders often struggle to answer basic questions, such as which AI models contributed to specific commits or whether AI-generated code meets secure coding standards. Traditional security tools that merely detect vulnerabilities after code is written are no longer enough. As we move to fully agentic workflows, organizations need a security-first mindset from every team member, in every role.

Through this partnership, we are bridging this gap by bringing 31 interactive learning activities to KnowBe4’s Diamond customers. This content covers critical topics like:

• Coding with AI
• The OWASP Top 10 for Large Language Model Applications
• Threat Modeling
• Data Protection 
  ‍

Crucially, this training supports 10 programming languages across 8 spoken languages, meaning developers can learn to spot vulnerabilities in the exact context of the frameworks they use every day, in their native language.

Secure Code Warrior’s existing customers will continue to benefit from our premium, cutting-edge content covering 10,000+ interactive learning activities (including 1000+ on AI topics), in 75+ coding languages, targeting 650+ real-world vulnerabilities. And don’t forget our award-winning SCW Trust Agent capability.

To operate agentic AI safely, we must first build human capability. We need to empower developers with the skills they need to review and improve code, regardless of whether it was written by a human colleague or generated by any number of AI models (all of which vary in their security proficiency, just like humans). Our goal is to provide the foundational capability that transforms developers into confident orchestrators of AI agents, equipping them to govern exactly what AI can and cannot touch within their codebases.

Secure Code Warrior defines and leads the AI Software Governance category. Our mission has always been to help organizations take control of AI-driven software development by improving code quality and scaling AI adoption with confidence. By joining forces with KnowBe4, we are enabling teams to embrace the incredible productivity gains of disruptive AI technologies without compromising on safety or security. 

Together, we will ensure that as the world transitions to AI-driven development, security remains the unshakeable foundation of every application built.

Today’s encryption will not survive quantum computing. It was never designed to.

When large-scale quantum systems become viable, widely used algorithms like RSA and elliptic-curve cryptography will fail—not gradually, but all at once.

The risk is already in motion. Attackers can capture encrypted data today and decrypt it later when quantum capabilities catch up. It has a name: harvest now, decrypt later. Encryption that cannot be broken today is increasingly likely to be broken within the next decade, and much of the encrypted data being collected now will still be sensitive when that happens.

Why post-quantum cryptography matters now

Post-Quantum Cryptography (PQC) requires organizations to move to new, quantum-resistant algorithms. These are not simple or quick changes for most businesses. Cryptography is embedded into every layer of the software stack—from applications to infrastructure to core dependencies—and is often hard-coded into legacy systems that are difficult and costly to change. Updates can also have downstream impacts on performance and load calculations.

To prepare, organizations need to build a clear picture of where cryptography exists across their environments. That means creating a new kind of bill of materials to inventory and track cryptographic implementations, and becoming more crypto-agile so updates can happen more routinely as standards evolve.

Auditing where cryptography exists—and understanding the shelf lives of sensitive data—helps organizations prioritize their early efforts. Data that needs to remain secure for years is already exposed to harvest now, decrypt later attacks. In many cases, the algorithms protecting that data today will take time to replace, especially as changes need to propagate through complex systems and supply chains.

Regulatory pressure is accelerating the timeline

Regulators are setting concrete timelines that make post-quantum cryptography a near-term engineering concern—not a theoretical one.

In the U.S., the CNSA 2.0 program from the National Security Agency (NSA) mandates a phased transition to post-quantum cryptography, with key deadlines beginning in 2027 and major migration milestones by 2030.

In Europe, frameworks such as the NIS2 Directive and the Digital Operational Resilience Act (DORA) require organizations to assess cryptographic risk, enforce stronger cryptographic controls, and demonstrate readiness to evolve toward quantum-resistant approaches.

PQC is no longer a distant concern. It is already on compliance roadmaps.

Securing the transition to post-quantum cryptography

The shift to post-quantum cryptography goes beyond a technology upgrade, and introduces a fundamental change in how software is built, validated, and governed.

As AI-assisted development accelerates, development teams need confidence that cryptographic patterns are applied correctly and consistently. This depends on visibility into how code is created and clear validation that secure practices are followed across workflows.

AI can assist in generating and reviewing code, but it does not guarantee secure outcomes. Validating implementations and reinforcing secure patterns still needs to be part of everyday development.

AI Software Governance connects visibility, risk correlation, and developer capability. Secure Code Warrior provides visibility into AI-generated code, correlates risk at commit, and strengthens developer capability through hands-on secure coding learning. Together, this enables organizations to adopt post-quantum cryptography while maintaining control as development becomes increasingly AI-assisted.

New post-quantum cryptography learning in Secure Code Warrior

To support this transition, Secure Code Warrior has introduced a new vulnerability category: Improper Post-Quantum Cryptography (PQC).

New learning topics are available across ten languages and frameworks, including Terraform (AWS and GCP), Python, Java, Java Spring, C# (.NET Core and Basic), JavaScript and TypeScript (Node.js Express), and Go. Cloud and backend infrastructure are where early PQC efforts are most urgent, and where most organizations will find their most critical cryptography components.

Each topic includes language-specific guidance, hands-on AI Challenges, and real-world scenarios that simulate PQC implementation risks. This gives developers practical experience with how quantum-safe cryptography is implemented and where it can fail.

Post-quantum readiness requires teams to understand where cryptography exists in their code, how PQC impacts implementation, and how to apply secure patterns consistently across development. As quantum-resistant approaches begin to appear in modern standards, teams must also validate how they are applied in real code. Clear visibility into development workflows, combined with reinforcement of secure practices, helps reduce software risk at the source and maintain control as development becomes increasingly AI-assisted.

You can find the new PQC topics in Secure Code Warrior across Quests, Learn, and Explore. Start building the developer capability required to secure what comes next.

‍

While the first two enablers focus on building the foundational aspects of your secure coding program (by establishing goals and gaining leadership buy-in), Enabler 3 is one of the first steps to implementing your program for teams across your organization.

Your Developer Communications Plan establishes an ongoing strategy designed to keep the developer community excited and engaged with your program.

A successful communications plan maintains an informative communication stream throughout the year, covering events, new assignments, developer recognition, and more. Messages should be clear, concise, and delivered across developers’ preferred channels (email, intranet, Slack, Teams, etc.).

Your Developer Communications Plan establishes an ongoing strategy designed to keep the developer community excited and engaged with your program. 

A successful communications plan maintains an informative communication stream throughout the year, covering events, new assignments, developer recognition, and more. Messages should be clear, concise, and delivered across developers’ preferred channels (email, intranet, Slack, Teams, etc.).

Addressing the Developer Perspective

In addition to logistical information like platform login details and assignment due dates, communications must explicitly address the questions, "What’s in it for me?" and "Why should I care?”. Speaking specifically to the developer perspective shows that you understand the time investment made by developers to participate in your secure coding program, whether it is mandated or not.

Initial program launch communications should clearly link your organization’s secure coding program to critical business outcomes (established in Enabler 1) and to developer benefits. For developers, team leads, and engineering managers, these benefits include:

Reward and recognition

Reducing friction during release cycles

Saving time and frustration resulting from rework

Opportunities for skill development and career advancement

Internal support from Engineering and AppSec leadership

‍

‍Execution and Strategy

A secure coding program cannot rely on a "one-and-done" communication approach. A comprehensive communications plan requires a well distinguished Timeline outlining when launch, follow-up, and reinforcement messages will be sent.

Executive Participation in Program Announcement

Having initial program announcements delivered by executive leadership can help gain developer buy-in. This will help showcase that leaders have visibility into the program and allow them to communicate the why of the program from the start.

When formulating communications, essential elements to consider include content, clarity, consistency, and the credibility of the sender. Also, consider the following:

Tone: The communication tone should be positive and encouraging, prioritizing "More 'carrot' than 'stick'". It is crucial to avoid language that is browbeating or uses finger-pointing, and instead highlights the benefits to gain traction.

Channels: While formal email communications can serve as a backup, more informal channels (such as internal developer communication platforms) should also be utilized. Consider building channels exclusively for program communications, announcements, and developer recognition.

Frequency: It is essential to strike the right frequency for program communications, so that developers stay informed, but not overwhelmed. During the initial rollout and other higher-intensity phases (when training deadlines approach), consider daily communications that count down to your program. However, during routine maintenance periods, veer towards monthly communications. The last thing you want is for developers to check out because there is too much white noise.

Evangelists: Look for credible evangelists within the developer community to help amplify the messaging and promote the program. These champions lead by example and continue to amplify key messages from within the community.

Measuring and Recognizing Success

Developer communications are often the perfect place to showcase rewards and recognition for developer achievements in your program. In addition to celebrating their wins, it is essential  that developers know what targets they are trying to attain as well as their progress on the way to those targets. 

A monthly newsletter or program recap may be the perfect place to showcase:

• Completion Rates - For organizational targets, consider creating team incentives for those who finish fastest!
• Certificates / Badges Earned - Celebrate those who have completed secure code training to promote the achievements to other developers.
• Developers with the Highest Skill - Highlight those developers with special security skills. Not only does it acknowledge their achievements, but it also helps others identify 'go-to' experts for secure coding expertise.
• Competition Winners - Secure coding competitions are not only a great way to engage developers, but also an opportunity to showcase winners and the prizes they’ve won. This can help build a following for annual competitions and to help further motivate the rest of your developer community.
• And More!
  ‍

We’ll dive deeper into Developer Recognition later in the series when we explore Enabler 7.

With our Developer Communications plan now established, our next post will focus on further program implementation, with Enabler 4: Low Barrier to User Access.

Have additional questions?  Customers can reach out to account team members or to support@securecodewarrior.com. Prospective customers can speak to someone on our sales team by contacting us here.

While these seismic shifts in software development and security seem to be regular occurrences in 2026, the arrival of Anthropic's latest, reportedly "most dangerous" AI coding model yet, Claude Mythos, represents a permanent, fundamental shift in how every security leader must approach their security program, especially with patch management of legacy systems.

Most enterprises are still navigating the shift from human-written code to AI-assisted development, ushering in new processes, learning to review what their AI co-pilots generate, building new skills, and establishing new guardrails around appropriate enterprise use.

But, the next phase of AI-driven software creation didn't wait.

This week, Anthropic published a detailed technical assessment of Claude Mythos Preview, a new frontier AI model with a capability that should stop every security and engineering leader in their tracks. It can autonomously identify and exploit zero-day vulnerabilities across all major operating systems and browsers, without human intervention after an initial prompt. Engineers with no formal security training directed the model overnight and woke up to complete, working exploits.

These findings are startling and not theoretical. Mythos Preview found a 27-year-old vulnerability in OpenBSD, one of the most security-hardened operating systems in the world, that allowed an attacker to remotely crash any machine just by connecting to it. It discovered a 16-year-old flaw in FFmpeg that automated testing tools had hit five million times without catching. It chained together multiple Linux kernel vulnerabilities autonomously to achieve full machine control. These weren't human-assisted discoveries; no real-world practitioner guided the process after the initial prompt.

In response, Anthropic announced Project Glasswing, a cross-industry coalition that brings together AWS, Microsoft, Google, Cisco, CrowdStrike, Palo Alto Networks, JPMorgan Chase, NVIDIA, Apple, Broadcom, and the Linux Foundation. The shared conclusion across all of them: the old approaches to securing software are no longer sufficient, and the time to act is now. As CrowdStrike's CTO put it, the window between a vulnerability being discovered and exploited has collapsed; what once took months now happens in minutes.

The three problems just got harder

At every stage of the AI development transition, enterprises face the same three challenges. Mythos Preview sharpens all three at once, at a speed never previously possible.

Learning to build securely gets harder when AI can generate and modify code faster than teams can review it. The skills required to govern AI-generated code differ from those needed to write code manually, and those skills must keep pace with the tooling.

Governing what AI can and can't touch becomes critical when autonomous agents write and revise code without a human in the loop. Generally, we are still asking the wrong question. It’s less "what did our developers build?" and more "what did our AI build, and was it allowed to?"

Tracing which AI did what, where, and for whom is now a compliance and incident response imperative. When something goes wrong in an agentic pipeline, organizations need to answer that question immediately. Most can't.

As practitioners, we predicted long ago that this technology could eventually be leveraged by threat actors, effectively supercharging their attack capabilities. We already know that cybercriminals have a distinct offensive advantage over most enterprise security teams, and a tool like Mythos streamlines their nefarious processes even further. 

We're in the age of democratized cyberattacks, where the level of destruction once achievable only by elite threat actors can be carried out by a relative novice. We shouldn't be shocked, but many remain vastly underprepared. Swift, prioritized patching is a must, but this management is only ever as good as the traceability of every tool and dependency in use.

This is an industry-level problem

What makes Project Glasswing significant isn't solely determined by the capabilities Mythos Preview revealed; it is the scale and potency of the response. A coalition spanning hyperscalers, security vendors, financial institutions, and open-source foundations is all aligned on the same conclusion, and it’s a familiar narrative that speaks directly to the ethos of SCW. AI Software Governance has never been a “nice-to-have”, optional feature. This is the missing layer that every organization scaling AI-driven development needs in place before the next incident. Those who stick to an oft-used, reactive playbook are going to be swept off their feet in the worst possible way.

Enablement, not restriction

The temptation when reading findings like these is to reach for the brakes, to slow AI adoption, restrict tooling, and tighten controls. That's the wrong response, and it's not what the Glasswing partners are recommending either.

The organizations that will navigate this transition well are the ones that adopt AI-driven development with governance in place from the start. That means training developers as the tooling evolves, setting guardrails for what AI agents can access in your repositories, and, fundamentally, building the traceability that your compliance and incident response teams will demand without burning millions of tokens to facilitate it.

The moment to act is now

Anthropic's own advice to defenders: start with the tools available today. Don't wait for the next model. The value of getting your processes, scaffolds, and governance frameworks in place compounds quickly.

Secure Code Warrior sits at the center of all three enterprise problems the agentic era creates. If your organization is scaling AI-driven development, the question isn't whether you need AI Software Governance. It's whether you have it yet.

What this means for you

For CISOs

Your vulnerability disclosure policies, patch cycles, and incident response playbooks were built for a world where exploit development took weeks. That world is gone. Now is the time to establish AI governance visibility across your development environment, while contextually understanding which AI agents are touching your codebase, what they're producing, and whether it meets your risk threshold. If you can't answer those questions today, that's the gap to close first. 

For CTOs

Your engineering teams are already using AI to ship faster. The question is now whether you have the guardrails in place to do it safely at scale. Governing what AI agents can and can't touch in your repositories, and maintaining traceability of AI contributions, is now a technical architecture decision, rather than an isolated security consideration. The organizations building this foundation now will be the ones who scale AI development with confidence. 

For Engineering Leaders

Your developers are being asked to move faster with AI tools they didn't design and can't fully predict. The skills required to review AI-generated code are genuinely different from those required to write code manually, and most teams haven't had the chance to develop them yet. Closing that capability gap is what makes AI adoption safer and more sustainable. 

For CEOs and Boards

Project Glasswing might be headline news, but it’s also a signal we cannot ignore. When AWS, Microsoft, Google, Cisco, CrowdStrike, and JPMorganChase align on an urgent, coordinated response to an AI-driven security risk, and Anthropic commits $100M to address it, that's the market telling you something. AI-driven software development is accelerating the rate at which vulnerabilities can be found and exploited. Governance over that process is now a board-level risk question. The organizations that treat it as one early will be better positioned to scale AI development — and to demonstrate to regulators, customers, and investors that they're doing it responsibly.

In our last post, we established that a truly successful secure coding program must define its goals by linking them directly to critical business outcomes (Enabler 1: Defined & Measurable Success Criteria). But a successful program needs more than just goals and metrics; it needs power, visibility, and credibility derived from the top ranks of the organization.

This brings us to Enabler 2: Senior Leadership Sponsorship, a critical factor in ensuring widespread buy-in and adoption for your program. Securing C-Suite/Executive buy-in is essential for driving a smooth program rollout and helping drive sustained interdepartmental support.

Active Buy-In, Not Passive Awareness

For secure coding to thrive, the C-suite must be fully on board with the program. This means it is wholly necessary for leadership to be actively supportive, rather than passively aware. Leaders must fully back the “What & Why” of the program.

Crucially, the senior leaders’ names should be associated with the program and the desired business outcomes. They must believe in the fundamental link between effective secure coding practices and company-wide risk reduction.

In practice, this may look like:

Executive Participation in Program Launch - This may come in the form of email communications, company-wide kickoffs, departmental meetings, and more. They can communicate the program's rationale from the start to help build buy-in from the developer organization.

Celebrating Wins - Leadership actively celebrating developer wins can go a long way in incentivizing program participation. Whether it’s presenting awards to developers in meetings, shout-outs or kudos in company communications, or even having an executive signature on certificates of completion, it often helps developers to know that leadership is watching and appreciates their efforts.

Reviewing Value and ROI - A regular cadence of reviewing the Joint Success Plan with leadership helps ensure the program's value and return on investment (ROI) are realized. When necessary, leadership can help pull in necessary resources to help continue gaining buy-in for a program.

‍

The Critical C-Suite Lineup

For a Secure Coding program to gain traction and strategic importance, involvement should ideally extend beyond a single leader. The essential C-level sponsors should include the CIO(s), CDO/CTO, and CISO. For larger organizations, having all three of these roles onboard is necessary.

jThese roles provide distinct areas of influence crucial for program success:‍

• ‍CIO (Chief Information Officer): This person decides what the developers build in order to support and drive the business forward. In large organizations, there may be multiple business units with their own CIOs, potentially led by a Global CIO overseeing the entire IT structure.
• ‍CDO/CTO (Chief Development Officer / Chief Technology Officer): This individual decides how the developers build. This includes establishing design standards and patterns, development tooling, application architecture, and build pipelining. It is essential that this leader buys into security so that your program can be incorporated into the engineering strategy.
• ‍CISO (Chief Information Security Officer): This leader is charged with ensuring the developers build in a secure way. Their role is to ensure applications used by the business are secure, preventing data breaches or exposure to excessive risk.
  ‍

Why the CISO Alone is Not Enough

While the CISO plays a fundamental role in driving risk management and compliance, relying solely on them can be a challenge. It is a harsh reality that developers may not be incentivized by, or necessarily respond to, the CISO alone.

Therefore, at least one of the ‘voices from the top’ communicating the ‘why’ of the program to the development community needs to be credible and respected by the majority of those developers.

With the clear objectives defined (Enabler 1) and the political capital secured (Enabler 2), the program is ready to build momentum, moving next to Enabler 3: Developer Communications Plan.

Have additional questions? 

Customers can contact the account team or support@securecodewarrior.com. Prospective customers can speak with a member of our sales team by contacting us here.

Check our last enabler for success on defined measureable success criteria.

If you’ve been paying attention to the rapidly shifting landscape of our industry, you already know the reality we are facing: the question isn’t whether Generative AI should be used to create software code, or whether the percentage of code generated by GenAI will increase in the near future. We’re well beyond the contemplation stage, at this point. The real question we must answer is how to maintain security and compliance while GenAI and artificial intelligence agents generate code and commit changes. The Software Development Life Cycle (SDLC) has transformed into the Agentic Development Lifecycle (ADLC) right before our eyes, and to be honest, we’re lagging behind best practices to keep it secure.

While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.

The Risks of AI-Generated Code That We Cannot Ignore

Ever since GenAI became an easily accessible tool, sparked by the release of ChatGPT in November 2022 and followed quickly by other large language models (LLMs), its application in code generation has been one of the hottest topics in tech. The productivity boost has been massive, but the double-edged sword of AI quickly became apparent. Even though some studies suggest AI-generated code can be as secure as human-generated code, the real risk lies in how often and how quickly AI-generated errors can propagate into the wider software ecosystem.

With Gartner finding that 52% of IT leaders expect GenAI will be used to generate software for their organizations soon, we cannot afford to pace ourselves too slowly, or wait for a more precise legislative landscape.

The Building Blocks for More Secure AI Code

Here at Secure Code Warrior, we view our framework for the secure use of AI coding tools not as a final destination, but as a crucial starting point that organizations can adopt immediately:

1. Where’s Your Ruleset? First and foremost, developers need clear guidance for making use of AI coding tools. For instance, our SCW AI Security Rules, which we made available as a free resource on GitHub, provide structured guidance for developers working with popular tools like GitHub Copilot, Cline, Roo, Cursor, Aider, and Windsurf. These rules are lightweight by design, acting as a practical starting point rather than an exhaustive rulebook. They are organized by domain (such as web frontend, backend, and mobile) and are heavily security-focused, covering recurring issues like injection flaws, unsafe handling, weak authentication flows, and cross-site request forgery (CSRF) protection.
2. Do You Have the Right AI Tech Stack? It's not just about using AI; it's about using the correct tool for the job. Organizations need to focus on the security efficacy of the AI tools they use, ensuring they are specifically built to meet the demands of a secure environment. You should be able to leverage AI tools for proactive, developer-led threat modeling, not just for code output. When the right AI tools are used the right way, they actually enhance security and prevent many errors from slipping into the pipeline.
3. Precision AI Governance: A lack of visibility and governance is the fastest way to breed "shadow AI" and spread insecure code throughout your organization. We need tools that provide deep observability to enable organizations to effectively manage A tooI adoption, MCPs in use, and the commits being made by agentic technology. For example, by correlating AI tool usage directly with developer secure coding skills, leaders can maintain oversight. Upskilling developers through an ongoing learning program ensures the safe use of AI early in the software development lifecycle (SDLC), allowing your organization to innovate faster without sacrificing security. You can do that right now with SCW Trust Agent: AI. Awesome!
4. Adaptive Learning Pathways: CISOs must empower their developers via educational programs that provide hands-on, real-world upskilling in secure coding. It is vital to measure their progress in acquiring new skills and to observe developers’ commits to see how well they apply those skills daily—especially their ability to double-check the work of AI tools. By using benchmarks to establish required skills and measure educational progress, organizations can effectively manage their use of AI in software development.

Want to see Learning Pathways and AI Governance in action? Book a demo.

The Bottom Line

As any developer knows, AI coding tools are extremely powerful, but how they are used determines how well they support security and compliance. Security-proficient developers and their managers who follow this framework to safely leverage AI coding tools from the start of the development cycle can increase the quality and security of their code tenfold. 

And those who don’t? Well, sadly, the risk profile will only continue to grow, and security leaders will continue to contend with a cyber skills gap expanding at a similar pace.

AI-driven development has introduced an entirely new classes of software risk. Prompt injection, RAG manipulation, and excessive agent permissions are no longer theoretical concerns – they are active realities in modern applications.

Developers need hands-on exposure to these emerging threat patterns in environments that reflect real-world complexity. That is why we have transformed the Cybermon 2025 AI/LLM Boss Missions from a limited event experience into a deployable Quest topic collection within Secure Code Warrior. You’ll find the Cybermon 2025: Beat the Boss collection within the Specific Concepts section under Security Concepts when creating a new Quest.

Cybermon 2025: Beat the Boss allows organizations to integrate these high-difficulty AI security challenges into their secure coding programs at any time.

What Is Beat the Boss?

Beat the Boss brings together four advanced AI/LLM challenges designed to test real-world secure AI development capability.

Each topic includes a short intro video and guideline, a guided walkthrough warm-up, and the original high-difficulty Boss Mission from Cybermon 2025. These immersive scenarios focus on practical AI vulnerability classes that developers must understand as AI-enabled applications evolve.

The four Boss Missions each target a distinct AI risk area, simulating real-world threat patterns in AI-powered systems:

• Bypassaur – Direct Prompt Injection
• Keykraken – Indirect Prompt Injection
• Promptgeist – Vector and Embedding Weaknesses
• Proxysurfa – Excessive Agency

‍Run It Your Way

We recommend spotlighting one Boss at a time to give each vulnerability the focus it deserves. Many organizations choose to run:

• One Boss per week as a focused AI security sprint
• Or one per month as a “Vulnerability of the Month” initiative

Structured rollout guidance and downloadable branding assets are available in the Knowledge Base for administrators configuring internal events:
Cybermon 2025: Run your own Beat the Boss event

Operationalizing AI Security Readiness

AI-accelerated development is reshaping the software risk landscape. Emerging vulnerability classes demand more than awareness – they require applied experience.

Beat the Boss enables organizations to translate evolving AI threat patterns into practical developer capability.

Developers can attempt each challenge independently, then review the guided walkthrough solutions to reinforce attacker-mindset thinking and defensive strategies. Full solution walkthrough videos are available for post-challenge learning:
‍

Many teams extend the experience through internal knowledge-sharing sessions – shifting event-based learning from competitive to collaborative. Security and development are team sports. Organizations are best protected when developers, security leaders, and engineering teams work together to understand and mitigate the expanding AI attack surface. Facilitated debriefs, shared solution reviews, and cross-team discussions help turn individual challenge completion into collective capability.

By integrating Beat the Boss into your secure coding initiatives, you reinforce safe AI adoption while building measurable AI security maturity across your development teams.

Get Started

You’ll find the Cybermon 2025: Beat the Boss collection within the Specific Concepts section under Security Concepts when creating a new Quest. Log in to your Secure Code Warrior account to configure your rollout and strengthen secure AI development across your teams.

Anthropic’s launch of Claude Code Security marks a defining collision point between AI-assisted software development, and the rapid augmentation of how we approach modern cybersecurity. While this new Claude capability can identify vulnerabilities in AI-generated code, this creates a single point of both trust and failure, and a skilled human must still evaluate those findings and determine the appropriate remediation path. This approach is supported by the likes of Justin Greis, CEO of consulting firm Acceligence, who told CSO Online, “For those who blindly rely on any code scanning tool, AI or otherwise, to replace the fundamentals of good security practices and secure coding, this is your red blinking light to not outsource the very expertise that protects the value proposition of the product or service you’re developing.” 

In that respect, the model is not fundamentally different from traditional SAST tools. It is more advanced in its reasoning, but a risk-sensitive use case still relies on a human-in-the-loop to interpret, validate and remediate the issues it surfaces safely.

The threat for organizations is not AI capability, it is unchecked AI autonomy and low oversight within the software development lifecycle. When AI both generates and evaluates code, strong, precision governance becomes a critical control. 

The Expanding Definition of the “Developer”

AI has lowered the barrier to entry for creating apps and software. But, just because something can be done quickly using AI, doesn’t mean that you are doing it in the most secure or resilient way, nor that the project itself is user-ready. The entire premise of vibe coding is to get into the “flow state” and deal with enterprise-level development formalities, like security, later. 

Today’s “developer” may be:

• A traditional engineer using AI to speed up coding tasks
• A product manager prototyping features via prompts
• A data analyst automating scripts through AI
• A QA engineer leveraging AI to generate test cases

From an organizational security perspective, who writes the code matters far less than the code's impact once it reaches production. From a compliance and risk standpoint, if an individual’s interaction with AI results in code entering the software development lifecycle (SDLC) without proper, company-specific security oversight, it introduces organizational risk — risk that must be understood, measured, and mitigated.

Why Human Judgment Still Matters

As more individuals gain the ability to generate code that could impact production or sensitive codebases, an organization’s risk profile expands. Governance must evolve to enable AI-driven development at scale while ensuring the controls required to protect the enterprise remain firmly in place.

AI can, fairly reliably, generate code and flag potential vulnerabilities. What it cannot do is validate whether that code is appropriate within the context of your architecture, data flows, identity model, regulatory obligations, or risk tolerance, and this is fundamental intel that impacts the potency of any security program. Additionally, implementing a tool like Claude Code into the SDLC is one thing, but tools like BaxBench demonstrate via vast data analysis that different models (for example, Opus vs Sonnet 4.5 vs Sonnet 3) are returning different outputs in terms of security and accuracy, resulting in an enormous difference in the real dollars a company will ultimately pay for usage as they push for working, secure code.

Secure software is not simply code that passes a scan. It must follow good, safe patterns that align seamlessly with system design, business intent, and enterprise policy. That requires judgment. When developers rely heavily on AI to generate or even review code, there is a real risk that their understanding of the codebase erodes. If an engineer cannot fully explain why a piece of code works or is secure, the organization has already lost a layer of control.

Validation is not the same as detection. Accountability is not the same as automation. AI can assist, but it cannot assume responsibility (and no legislation to date absolves humans from consequences of rogue AI actions).

Human-in-the-loop oversight is not a legacy concept. In an AI-driven development environment, it is the primary safeguard that ensures code entering the software development lifecycle has been consciously reviewed, understood, and approved. Without that layer of judgment, speed becomes exposure.

Education Must Be the Foundation of Safe AI Adoption

In this context, secure coding training evolves from a nice-to-have to a core enterprise control. “Developers” will evolve from operators to orchestrators, shifting education from developing secure code to evaluating the security of AI-generated code.

The skills required to validate AI-generated code, anticipate emergent AI vulnerability classes such as prompt injection, and understand how AI patterns interact with your architecture cannot be learned through episodic compliance modules. They must be continuous, practical, integrated into existing workflows, and measurable against real risk outcomes. 

AI Software Governance: The Control Layer We’re Missing

Many security programs still treat application security as a downstream function. In an AI-driven environment, that model ceases to have the same impact on risk reduction. What’s required is AI Software Governance: a true enterprise control plane for an AI-driven software development lifecycle. This discipline spans the AI-driven software development lifecycle and establishes structured oversight of code creation, review, and approval.

That includes:

• Visibility into AI tool usage across teams
• Clear attribution of AI-generated code within the SDLC
• Correlation of code changes to risk signals and policy requirements
• Enforcement of secure coding standards inside developer workflows
• Continuous upskilling and measurable secure coding capability
• Demonstrable reduction in security risk before code reaches production

Governance is what bridges detection and decision, ensuring that productivity gains do not come at the expense of accountability.

AI will continue transforming how software is built, and abandoning it is neither realistic nor desirable. The productivity and innovation gains are, after all, too significant. But, working to extract value safely requires disciplined oversight and intentional human validation, and this infrastructure equally cannot be rushed or ignored.

The Cyber Resilience Act is rapidly becoming a strategic priority – not just for EU-based companies, but for any business selling digital products into the European market. While compliance deadlines extend into 2027, engineering and security teams are already asking hard questions about secure by design practices, vulnerability handling, and development capability.

Unlike many regulations that focus on documentation and audits, the CRA places secure software design and development at the heart of compliance. Organizations that invest early in secure by design capabilities will move into compliance faster – and stand out in a market where product security is becoming a purchasing decision.

What the Cyber Resilience Act Requires

The Cyber Resilience Act (CRA) introduces baseline cybersecurity requirements for most products with a digital component placed on the EU market – including software, operating systems, connected devices, and embedded systems.

More importantly, it shifts where responsibility sits.

Security is no longer only a runtime or operational concern. Under the CRA, it becomes a design and development obligation spanning architecture, implementation, maintenance, and vulnerability handling.

For engineering and security leaders, this means:

• Products must be built according to secure by design principles
• Known vulnerabilities must be prevented where possible and handled effectively
• Organizations must demonstrate that secure development practices are in place

In short: compliance is inseparable from how developers write and maintain code.

Who the CRA Applies To

Although introduced by the EU, the CRA applies to any organization worldwide that places in-scope digital products on the EU market, including:

• Software vendors and SaaS providers whose services function as remote data processing components of covered products
• Manufacturers of digital or connected products
• Importers, distributors, and retailers
• Organizations embedding third-party digital components

For global enterprises, CRA readiness is a cross-border development requirement, not a regional compliance exercise.

Why Organizations Are Starting Now

Key milestones:

• September 2026 – Vulnerability reporting obligations begin
• December 2027 – Full compliance required

On paper, that timeline can look comfortable. In reality, development transformation does not happen in quarters – it happens over years.

Secure by design is not a policy update. It requires:

• Upskilling thousands of development across languages and teams
• Embedding secure by design expectations into day-to-day workflows
• Shifting from reactive vulnerability remediation to prevention
• Creating measurable evidence that secure development practices are consistently applied

These changes affect hiring, onboarding, architecture decisions, SDLC processes, and engineering culture. Organizations that delay until late 2026 will be attempting to retrofit capability under regulatory pressure – a far more expensive and disruptive path.

Enforcement also carries significant financial risk. Under Article 64 of the CRA, penalties can reach €15 million or 2.5% of global annual turnover for violations of essential cybersecurity requirements.

Waiting until late 2026 is simply too late.

CRA Is Ultimately a Developer Capability Challenge

Many regulations focus on policies and documentation. The CRA goes further by linking compliance to the actual practices used to design and build software. It raises expectations around secure development as an operational discipline, not just a governance requirement.

For engineering leaders, this means compliance depends on whether development teams consistently apply secure practices, including:

• Understanding common vulnerability classes
• Applying secure design and architecture principles
• Avoiding insecure implementation patterns
• Handling third-party and open-source components responsibly

Security tooling plays an important role in detecting issues. But tools surface weaknesses after code is written. Secure by design requires developers to prevent vulnerabilities in the first place – and to do so consistently across teams, languages, and products.

Tools alone cannot achieve this. Secure by design outcomes depend on human capability.

How Secure Code Warrior Supports CRA Readiness

Secure Code Warrior provides CRA-aligned learning pathways that combine:

• A CRA Standard Quest mapped to Annex I, Part I technical vulnerability requirements
• A Secure by Design Conceptual Collection
• Hands-on, language-specific vulnerability learning

Check out our onesheet guide on all of the CRA-Aligned learning content in SCW. SCW does not certify compliance. We support CRA readiness through structured learning and measurable capability improvement aligned to the regulation’s secure development principles. 

Start Building CRA Readiness Now

The CRA reflects where the industry is headed: secure by design engineering as the default expectation. Organizations that invest in developer capability now will be better positioned for compliance – and for building more resilient, lower-risk software long term.

For additional details on how Secure Code Warrior can assist you in achieving compliance, check out our knowledge base: How Secure Code Warrior can assist you in achieving compliance