Secure Code insights

We begin our deep dive into the 10 Enablers of Success with the foundational step of Enabler 1: Defined & Measurable Success Criteria. If a secure coding program is a journey, the first and most critical step is knowing exactly where you are going. That is the essence of the first enabler.

Linking Success Criteria to Business Outcomes

Building a successful secure coding program requires the existence of clear objectives tightly linked to business outcomes. Enabler 1 answers the core questions: "What, in very specific and measurable terms, is the problem or pain point we are trying to solve with our secure coding program?” 

Perhaps your organization is looking to meet compliance requirements, or avoid security breaches and cyberattacks. Or maybe you are looking to start left as an organization, reducing costs and time on rework by training developers to code securely from the start.

Regardless of your motivations, your organization’s current state, or even the security training platform you choose, the long-term success of your program is highly dependent on having clearly defined goals tied to business objectives in order to gain buy-in and ensure lasting success..

Consider key stakeholders of your program when determining Success Criteria. Knowing your executive sponsors and their business objectives will help drive wider adoption across departments.

‍Making Success Tangible and Measurable

These objectives must, by their very nature, be spejcific to your organization. That said, review these typical business objectives and consider how they might inspire additional ideas for you:

Risk Reduction: Mitigate developer risk and reduce vulnerabilities introduced by coding flaws. This includes risk identification and reducing the application attack surface.

Programs often target metrics like Vulnerability Density or Vulnerability Injection Rate reduction and avoidance.

Operational Velocity: Maximize product delivery velocity, reducing developer frustration and attrition, and decreasing the amount of time spent on rework. Secure code training acts as a significant incentive for developers by helping them avoid time-consuming rework of buggy code identified later in the software development lifecycle.

Programs often target a reduction in developers' Mean Time to Remediate (MTTR) vulnerabilities.

Regulatory Compliance: Achieve external compliance, such as adhering to standards like PCI-DSS (which mandates training for all developers working on payment systems).

Talent and Trust: Raise engagement and awareness of Security & Vulnerabilities within the developer organization, while maintaining and building customer trust. For some businesses, security-enabled developers help establish market differentiation.

Programs often establish minimum skill requirements for developers or even create specialized Security Champion programs.

‍Documenting Success in a Joint Success Plan

‍Once you have defined your success criteria, the next step is documenting them within a Joint Success Plan. This plan is a shared blueprint cross-functionally, with any key stakeholders of your program, including external support such as your training platform CSM. 

The Success Plan contains:

1. Value Driver(s): These include the high-level business goals related to improving code security and answering "The Why" for your program.
2. Current State: This establishes the "Where are we now?" (e.g., current secure coding skills or existing training programs).
3. Future (Desired) State: Next you document  "Where do we want to be?" and establish how the secure coding skills gap will be closed.
4. KPIs / Measures: These are the metrics that show success and demonstrate that the gap between the Current and Future States is closing as the program rolls out.

We recommend starting with 1 or 2 specific metrics and expanding later if necessary. These KPIs/Measures must adhere to the S.M.A.R.T. principle (Specific, Measurable, Achievable, Relevant, Time-bound). They should be easy to track and not open to loose interpretation. Accountability on all sides is required to put the plan into action, with a regular, agreed cadence to review the value and ROI with leadership.

By defining and measuring these criteria explicitly, your secure coding program moves from a simple cost center to a verifiable driver of crucial business outcomes—a necessary first step toward achieving program maturity.

Next, we will dive into Enabler 2: Senior Leadership Sponsorship to discuss the key role that leadership plays in the successful rollout of a secure coding program.

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.

An individual who decides to plunge headfirst into a startup venture is called many things, from the aspirational moniker “entrepreneur” to the decidedly less glamorous “freaking crazy.” After eleven years at the helm of Secure Code Warrior, I’m happily somewhere in the middle. 

The past five years have been a lesson in resilience for many, with curveballs thrown, economic and otherwise, in ways that some of the smartest people on the planet failed to predict. “Survival of the fittest” may come to mind here, but I prefer this quote:

"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change."

(This is often misattributed to Charles Darwin, but it was actually said by Professor Leon C. Megginson, who was summarizing Darwin's work, Origin of Species. Hopefully, that will win you a great pub quiz prize sometime in the future.)

Now, what better example of change and adaptability is there, in our world, than artificial intelligence? More than three years since the LLM bomb dropped, and we’re still scrambling to understand what this iteration is, what it can do, and how it can best serve us in virtually every role that exists today. Regardless, it is here to stay, and as cybersecurity practitioners in particular, we need to stay one step ahead to safeguard it, even in the absence of official guardrails and regulations.

2025 was a big year for AI, for cybersecurity, and for SCW. I’m approaching 2026 with quiet confidence, and the optimism that only hard work paying off can bring. 

We hit some major milestones, including our foray into safeguarding AI-powered software development. We:

• Released Trust Agent: AI into beta testing: With new research from the CCIA confirming that generative AI is the fastest-adopted technology in history, it’s no great shock to see the huge uptake of AI coding agents and assistants among developers, including hasty enterprise-level rollouts that are moving faster than their security programs.
  
  Our latest technology, Trust Agent: AI, provides the missing ingredient of visibility and governance over AI-generated code. It affords enterprise security leaders the deep observability and control they need to confidently manage AI adoption in their software development lifecycle (SDLC) without sacrificing security.
• Surpassed our latest major revenue milestone: Exceeding our revenue goal is a testament to the tenacity and innovation of the entire Secure Code Warrior team. When we started this journey, our mission was to move beyond the "checkbox" approach to security and actually empower developers to write secure code from the very first line.
  
  Seeing that vision resonate with so many global enterprises proves that the industry is finally shifting its focus toward developer-centered security, and I couldn’t be prouder of how our Warriors have leaned in to make software safer for everyone.
• Expert integrations with strategic partners: Our partnerships with great companies like Aikido, OpenText and Black Duck, represent a significant step forward in our mission to create a seamless, developer-centric security ecosystem. By bridging the gap between identifying vulnerabilities and providing the specific skills needed to fix them, we are effectively closing the loop on developer-oriented software risk.
  
  I am incredibly proud of this partnership, which signifies a strategic shift away from fragmented tooling toward a unified experience where security is a natural extension of the development workflow.

As we dive into another big year, I’d like to thank our growing swell of supporters, especially those in the wider cyber community, who continue to take charge in the fight against recurring vulnerabilities, low security awareness, and poor-quality code output. By adopting a new, safer standard, we can start to see real improvements in the security of our software, services, and technology. 

We’re surging ahead with full investment in a future where AI writes the majority of the code, under the watchful eye of skilled humans. Our SCW Learning is evolving quickly to meet the requirements of this new world, and our SCW Trust Agent: AI will be made available in the next three months to support the safe operation of LLMs, MCPs, and more in the SDLC. We’re also poised to announce an exciting new partnership with a major market player very soon.

Stay tuned!

People and Processes

Anyone can build a secure coding program, but achieving lasting success is a more complex endeavor. The challenge lies not just in choosing a platform or launching the program, but also in effectively integrating it within an organization that often has diverse teams with competing interests. 

Whether the program’s driving force is AppSec, L&D, DevOps, or Engineering itself, both the people and processes play a part in creating a successful program. 

This is where the 10 Enablers of Success come in. This 12-part blog series will unveil our proven operational blueprint for any organization to build, sustain, and scale a highly effective secure coding program.

Drawing on more than ten years of experience with leading organizations, Secure Code Warrior’s Customer Success team–with key contributor Jim Loughran–has identified these 10 factors as crucial elements to drive adoption, usage, and developer "stickiness" and therefore value over time.

The 10 Enablers of Success

Over the next ten blog posts, we will dive deeply into each of these enablers. Successfully implementing these steps helps a program through critical maturity stages, transforming developers into the "first line of defense" for your organization.

The Enablers include the following:

1. Defined & Measurable Success Criteria: Establish program objectives that are directly linked to business outcomes to increase relevance and trace return on investment.
2. Senior Leadership Sponsorship: Ensure C-Suite/Executive buy-in to help drive a smooth program rollout and secure interdepartmental support.
3. Developer Communications Plan: Maintain an ongoing, exciting, and informative communication stream to keep developers engaged throughout the program.
4. Low Barrier to User Access: Enable quick and easy developer access to relevant platforms, utilizing tools like SSO.
5. Certification Programs: Implement multi-level programs to manage developer progression and provide meaningful achievements through continuous learning.
6. Regular Reporting to Leadership: Provide consistent, relevant updates to share progress, celebrate wins, and showcase impact for continued executive buy-in.
7. Developer Recognition: Share wins, tournament results, and call out successes loudly to celebrate and encourage developer achievement.
8. Branding Your Program: Embed a recognizable brand, name, or acronym (like ASC for Application Security Champion) within the developer community for continued program socialization.
9. Developer Ecosystem Integration: Use APIs and integrations to enrich data and embed secure code training into existing development workflows (e.g., JIRA or LMS integrations).
10. Training Linked  to Career Progression: Partner with HR/People teams to embed training (like certifications) into developer performance goals, reviews, or annual bonuses.

The Path to Program Maturity

Regardless of where you are in the building of your secure coding program, the implementation of these enablers directly correlates with the maturity level of your program. Program Maturity can be measured based on how many enablers are in play. 

Having 1-3 enablers implemented indicates an organization is still defining its secure coding program. It is likely that the program is still in its infancy or even still being rolled out. There are opportunities for maturing as the program grows.

Having 4-6 enablers implemented means a program is in its adopting stage. The program is continually being integrated into the organization’s security culture and is maturing or optimizing “on the way” to full adoption.

Finally, having 7-10 enablers implemented means a program is scaling.
At this stage, security is deeply ingrained into the organization’s culture and training is linked not only to developers’ ecosystem of tools, but also to their sense of accomplishment and career progression.

Whatever stage you are at, follow along as we continue to explore each of the enablers in depth, starting with Enabler 1: Defined & Measurable Success Criteria. 

‍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.

With OWASP’s release of its 2025 Top Ten, enterprises have a couple of new risk categories to pay special attention to, including a brand-new category that proves, once and for all, that what you don’t know can indeed hurt you.

The new category, Mishandling of Exceptional Conditions, outlines what can go wrong when organizations aren’t prepared to prevent, detect and respond to unusual or unpredictable situations. According to OWASP, this vulnerability can trigger when an application doesn’t prevent something unusual from occurring, fails to identify a problem when it crops up and/or responds poorly or not at all when an unexpected situation rears its head. 

The idea that enterprises need to be ready for what they didn’t see coming reflects the reality of today’s highly distributed, interconnected systems. And it’s not like OWASP is talking about problems that are unheard of—the Mishandling of Exceptional Circumstances contains 24 Common Weakness Enumerations (CWEs). It’s just that those CWEs, which involve improper error handling, failure to open events, logical errors and other scenarios, can occur under abnormal conditions. This can result, for instance, from inadequate input validation, high-level errors in handling functions and the inconsistent (or non-existent) handling of exceptions. As OWASP states, “Any time an application is unsure of its next instruction, an exceptional condition has been mishandled.”

Those exceptional circumstances can cause systems to fall into an unpredictable state, resulting in system crashes, unexpected behavior and long-lasting security vulnerabilities. The key to preventing this kind of disruption is to, essentially, expect the worst and plan to be prepared for whenever the unexpected happens.

[WATCH VIDEO]

Exceptional Circumstances and the Evolution of the Top Ten

The makeup of the quadrennial Top Ten list of the most serious risks to web application security has been fairly stable through the years, with some categories moving around the list and maybe one or two additions every four years. The 2025 iteration has two new entries, including Mishandling of Exceptional Conditions coming in at No. 10. The other, Software Supply Chain Failures, which sits at No. 3, is an expansion of an earlier category, Vulnerable and Outdated Components (No. 6 in 2021), that now includes a broad range software compromises. (For those keeping score, Broken Access Control still rules the roost as the No. 1 risk). 

The exceptional conditions that constitute the newest category can create a host of vulnerabilities, from logic bugs to overflows, and fraudulent transactions to issues with memory, timing, authentication, authorization and other factors. These types of vulnerabilities can impact the confidentiality, availability and integrity of a system or its data. They allow an attacker to manipulate an application's flawed error handling, for example, to exploit the vulnerability, OWASP said. 

One example of failing to handle unexpected conditions is when an application identifies exceptions while files are being uploaded during a denial-of-service attack, but then fails to release resources afterward. When that happens, resources remain locked or unavailable, resulting in resource exhaustion. If an attacker intrudes on a multi-step financial transaction, a system that doesn’t roll back the transaction once an error is detected could allow the attacker to drain the user’s account. If an error is detected part of the way through a transaction, it’s very important to “fail closed”—that is, roll back the entire transaction and start over. Trying to recover a transaction in midstream can create unrecoverable mistakes.

Fail Closed vs. Fail Open

So, what’s the difference between these two actions? Let’s clarify:

Fail Open: If a system “fails open,” it continues to operate, or remains “open” when something goes wrong. This is useful when keeping things running is very important, but it can be risky for security.

Fail Closed: If a system “fails closed,” it automatically shuts down or becomes secure when there’s a problem. This is safer from a security perspective because it helps prevent unauthorized access.

Handling Unforeseen Errors

Preventing this kind of risk starts with planning for the unknown. And that involves being able to detect any possible system error when it occurs and taking steps to solve the problem. You need to be able to properly inform the user (without revealing critical information to the attacker), log the event and, if necessary, issue an alert. 

Here’s an example of the disclosure of a SQL query error, along with the site installation path, that can be used to identify an injection point:

Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:\app\index_new.php on line 188

A system ideally would have a global exception handler in place to catch overlooked errors, along with features such as monitoring or observability tooling, or a feature that detects repeated errors or patterns that could flag an ongoing attack. This can help defend against attacks that are intended to take advantage of any weaknesses the enterprise may have in handling errors.

For a standard Java web application, for instance, a global error handler can be configured at the web.xml deployment descriptor level—in this case, a configuration used from Servlet specification version 2.5 and above.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

This little block of code tells a Java web application what to do when something goes wrong behind the scenes. Instead of showing users a confusing error message or a blank screen, it quietly catches the problem and sends them to a custom error page. In this case, that page would be error.jsp.

Because it’s set to handle the general java.lang.Exception types, it acts as a master error handler for the whole app. That means no matter where an error happens, users will be redirected to the same friendly, consistent error page instead of seeing raw technical details.

Preventing the Unexpected

Ideally, organizations should work to prevent—as much as possible—exceptional conditions from even occurring. Implementing rate limiting, resource quotas, throttling and other limits can help against denial-of-service and brute force attacks, for example. You may want to identify identical repeated errors and include them only as statistics, so they don’t interfere with automated logging and monitoring. A system should also include:

Strict input validation, to ensure that only properly formed and sanitized data is entering the workflow. It should be early in the data flow, ideally as soon as any data is received.

Error handling best practices, to catch errors right where they happen. They should be dealt with efficiently: Tell users clearly that they must keep a log and send alerts if needed. A global error handler is also ideal to catch anything that was missed. 

General transaction safety, is also a must. Always “fail closed”: if something goes wrong, roll back the entire transaction. And don’t try to fix a transaction halfway—it can cause bigger problems.

Centralized logging, monitoring and alerting, along with a global exception handler, which allows for quick investigation of incidents and a uniform process of handling events, while also making it easier to meet compliance requirements.

Threat modeling and/or secure design review, performed in the design phase of projects.

Code review or static analysis, as well as stress, performance and penetration testing performed on the final system.

Mishandling of Exceptional Conditions may be a new category, but it involves some basic principles of cybersecurity and emphasizes why enterprises need to be prepared for what they aren’t necessarily anticipating. You may not know what form exceptional conditions will take, but you know they will happen. The key is in being prepared to handle all of them in the same way, which will make it easier to detect and respond to those conditions when the inevitable crops up. 

Note to SCW Trust Score™ Users:

As we update our Learning Platform content to align with the OWASP Top 10 2025 standard, you may observe minor adjustments in the Trust Score for your Full Stack developers. Please reach out to your Customer Success representative if you have any questions or require support.

With the much-anticipated arrival of the 2025 OWASP Top Ten, enterprises have a couple of new threats to be extra wary of, including one that lurks near the top of the list. Software Supply Chain Failures, which debuts as a new category but isn’t entirely new, sits at No. 3 on the Open Web Application Security Project’s quadrennial list of the most serious risks to web application security. It’s a risk that enterprises need to take very seriously, if they aren’t already. 

Software Supply Chain Failures grew out of a category in the previous list from 2021, Vulnerable and Outdated Components, and now it includes a broader range of compromises across the software ecosystem of dependencies, build systems and distribution infrastructure. And its appearance on the list should come as no particular surprise, given the damage caused by high-profile supply chain attacks such as SolarWinds in 2019, the Bybit hack earlier this year, and the ongoing Shai-Hulud campaign, a particularly nasty, self-replicating npm worm wreaking havoc on exposed developer environments.

The OWASP Top Ten has generally been consistent, which befits a list that appears every four years, albeit with updates in between. There usually is some shuffling within the list—Injection, a longtime resident, drops from No. 3 to No. 5, for instance, and Insecure Design drops two places to No. 6, while Security Misconfiguration jumps from No. 5 to No. 2. Broken Access Control continues to stake out the top position. The 2025 edition has two new entries, the aforementioned Software Supply Chain Failures and Mishandling of Exceptional Conditions, which enters the list at No. 10. Here, we take a close look at the new supply chain vulnerabilities entry.

[WATCH VIDEO]

Vulnerabilities Can Crop Up Almost Anywhere

Software Supply Chain Failures is a somewhat unusual category on the list in that, among the 10 entries, it has the fewest occurrences in OWASP’s research data, but it also had the highest average exploit and impact scores resulting from the five Common Weakness Enumerations (CWEs) in the category. OWASP said it suspects the category’s limited presence is due to current challenges in testing for it, which could eventually improve. Regardless, survey respondents overwhelmingly named Software Supply Chain Failures as a top concern.

Most supply chain vulnerabilities grow out of the interconnected nature of doing business, involving upstream and downstream partners and third parties. Every interaction involves software whose components (aka dependencies or libraries) could be unprotected. An enterprise can be vulnerable if it doesn’t track all versions of its own components (client side, server side or nested), as well as transitive dependencies (from other libraries) ensuring that they are not vulnerable, unsupported or out of date. Components typically have the same privileges as the application, so compromised components, including those that come from third parties or open-source repositories, can have a far-reaching impact. Timely patching and updates are essential—even regular monthly or quarterly patch schedules can leave an enterprise exposed for days or months. 

Likewise, the lack of a change management process with your supply chain can create vulnerabilities if you are not tracking Integrated Development Environments (IDEs) or changes to your code repository, image and library repositories, or other parts of the supply chain. An organization needs to harden the supply chain by applying access control and least-privilege policies, ensuring that no individual can create code and deploy it to production without supervision, and that no one can download components from untrusted sources. 

Supply chain attacks can take many forms. The notorious SolarWinds attack began when Russian attackers injected malware into an update to the company’s popular network management software. It affected about 18,000 customers. Although the number of enterprises actually impacted was closer to 100, that list included major corporations and government agencies. The $1.5 billion Bybit hack, traced to North Korea, involved compromised cryptocurrency apps. The recent Glass Worm supply chain attack involved an invisible, self-replicating code that infected the Open VSX Marketplace. 

Preventing Supply Chain Exploits

Because supply chain attacks involve the interdependency of systems, defending against them involves an all-encompassing approach. OWASP offers tips for preventing attacks, including having patch management processes in place to:

• Know your Software Bill of Materials (SBOM) for all software and manage the SBOM centrally. It’s best to generate SBOMs during the build, rather than later, using standard formats, such as SPDX or CycloneDX, and to publish at least one machine-readable SBOM per release.
• Track all of your dependencies, including transitive dependencies, removing unused dependencies, as well as unnecessary features, components, files and documentation. 
• Continuously inventory both client-side and server-side components and their dependencies using tools, such as OWASP Dependency Check or retire.js.
• Stay up to date on vulnerabilities, continuously monitoring sources such as the Common Vulnerabilities and Exposures (CVE) website and the National Vulnerability Database (NVD) and subscribe to email alerts for security vulnerabilities related to the components you use.
• Use components obtained only from trusted sources over secure links. A trustworthy provider, for instance, would be willing to work with a researcher to disclose a CVE the researcher discovered in a component.
• Deliberately choose which version of a dependency you will use and upgrade only when you need to. Work with third-party libraries that have had their vulnerabilities published in a well-known source such as NVD. 
• Monitor for unmaintained or unsupported libraries and components. If patching is not possible, consider deploying a virtual patch to monitor, detect or protect against the discovered issue.
• Regularly update developer tooling.
• Treat components in your CI/CD pipeline as part of this process, hardening and monitoring them while documenting changes.

Change management or a tracking process should also apply to your CI/CD settings, code repositories, sandboxes, integrated developer environments (IDEs), SBOM tooling, created artifacts, logging systems and logs, third-party integrations such as SaaS, artifact repository and your container registry. You also need to harden systems, from developer workstations to the CI/CD pipeline. Be sure to also enable multi-factor authentication while enforcing strong identity and access management policies. 

Protecting against software supply chain failures is a multi-faceted, ongoing endeavor in the face of our highly interconnected world. Organizations must employ strong defensive measures for the entire lifecycle of their applications and components in order to defend against this rapidly evolving, modern threat.

Note to SCW Trust Score™ Users:

As we update our Learning Platform content to align with the OWASP Top 10 2025 standard, you may observe minor adjustments in the Trust Score for your Full Stack developers. Please reach out to your Customer Success representative if you have any questions or require support.

Every few years, the security world gets a moment that resets the conversation. The release of the OWASP Top 10: 2025 Edition is one of those moments. It is the first major update since 2021, and while many of the usual suspects are still on the list, the new structure shines a spotlight on the risks that modern software teams are struggling with today. Think dependency chaos, complex distributed systems, and the increasing role AI plays in how code is written and deployed.

Two areas in particular stand out in the 2025 list: Software Supply Chain Failures and Mishandling of Exceptional Conditions. Both reflect the reality that developers are no longer building applications in neat, isolated environments. They work with third party libraries, package managers, APIs, distributed services, and AI tools that generate code for them. Development teams have long recognized that when upstream issues or unexpected error states occur, the impact can rapidly cascade. OWASP's acknowledgment of this reality confirms what teams have experienced for years.

Secure Code Warrior has fully aligned the platform to OWASP Top 10 2025, and we want to make this transition as smooth and practical as possible. Below is a look at what we updated, why it matters, and how teams can start using the new material today.

Why This Update Matters

OWASP’s Top 10 2025 revision is more than a category shuffle. It recognizes the realities of today’s development landscape, including modern authentication patterns, dependency chains, distributed architectures, and the growing influence of AI-generated code. These changes reinforce the need for developers to build practical, real-world skills to identify and prevent issues early. 

This is where Secure Code Warrior’s updated OWASP content becomes essential. Topics like supply chain exposure, secure error handling, and automation risk require hands-on practice, not theory. SCW’s updated Quests, Vulnerability Topics, self-paced content in Learn, and Courses make that knowledge accessible and actionable, giving developers the chance to build real capability in the languages and frameworks they use every day.

Secure Code Warrior Makes it Easy

The OWASP Top 10 2025 structure is now woven throughout the entire SCW learning experience, this includes updates across Quests, Vulnerability Topics, self-paced content in Learn, Courses, and the SCW Trust Score^® framework. Developers now learn OWASP Top 10 2025 skills naturally in the context of their web language, and leaders can measure capability using the most current standard.

Quests and Vulnerability Topics 

One of the biggest advantages of SCW is that OWASP is already built into the core of our vulnerability-based Quests. The new OWASP Top 10 is now baked directly into the standards that shape all Quest objectives. This means:

• Every web-language Quest that used the OWASP Top 10 2021 standard now uses the updated OWASP Top 10 2025 in its structure
• The Top 3, Top 5, and Top 10 Vulnerability Quest objectives will automatically draw from the 2025 OWASP Web Top 10 for all relevant web languages
• We use OWASP's Top 10 standards and other key industry standards like CERT-C to ensure Developer training contains the most relevant and important topics for the languages and frameworks they use

Courses and More 

All OWASP-related Quests and Courses have been refreshed and re-organized to match the new structure. Self-paced content in Learn has also been updated. Module order, terminology, and category mapping have been updated so developers receive clear and accurate guidance that aligns with the 2025 standard. 

SCW Trust Score^® 

SCW Trust Score now reflects developer capability and progress within the updated OWASP Top 10 2025 category structure. Customers may see small adjustments in Full Stack developer scores as part of this alignment. This is expected and ensures that Trust Score remains accurate, current, and aligned with the OWASP Top 10 2025 taxonomy.

Moving Forward with OWASP Top 10 2025

The OWASP Top 10 2025 update is an important milestone for the industry. OWASP has created a structure that better reflects how software is built today, and Secure Code Warrior is proud to support teams in adopting it quickly and confidently. All updates to Quests, Vulnerability Topics, Courses, and Trust Score are already applied in the platform. Your developers now have the content, guidance, and structure needed to build more secure software, and your leadership teams have the insights needed to track capability against the latest global standard.

If you’d like guidance on how to roll these updates into your existing programs, your Secure Code Warrior representative or Customer Success Manager is ready to help. They can walk you through what’s changed, how it impacts your teams, and the best ways to make the most of the new OWASP Top 10 2025 content.

Do you ever get the feeling as a cybersecurity professional that right now, everyone is entering hyperdrive on agentic AI, when maybe it’s time to go slow and reflect? Well, what many of us have been seeing in our AI security crystal balls is now suddenly reality. 

On Friday, the 14th of November, Anthropic (one of the world's most well-known vendors for LLMs, thanks to its popular Claude Code tool) released a groundbreaking paper on a cyber incident they observed in September 2025, that targeted everyone from large tech companies, financial institutions, and chemical manufacturing companies, to government agencies.

So, what’s all the fuss about, and what makes this so concerning? In layman's terms, a highly advanced threat actor (allegedly a nation-state) used Claude Code and a range of tools in the developer environment, leveraging Model Context Protocol (MCP) systems, to almost autonomously, at scale, use benign open-source hacking tools to target carefully selected companies. There were over 30 attempted attacks; several were successful, proving that AI agents could indeed execute devastating breaches with very little human intervention.

Last month, GlassWorm, a first self-propagating worm targeting VS Code extensions, was identified by Koi Security. While the latter is not a new attack vector, there is a new wave of coding extensions (including MCP servers) that, at first glance, have benign functionality, but under the hood host a range of malicious activities that could compromise a developer’s endpoint quickly.

Maybe it’s time we slowed down, took a deep breath, and put our heads together to work out how best to defend against this new threat profile.

Securing systems against high-velocity AI agents

The recent paper by Anthropic highlights a potent new threat, one that confirms the long-held fears of many in the security community, by showing how AI can dramatically accelerate and amplify distributed risk. This development gives malicious actors further advantage, which is maddening considering the head start they already have over burnt-out, stretched security personnel managing the tech sprawl in the average enterprise.

In essence, state-sponsored attackers managed to "jailbreak" the Claude Code model. They successfully tricked the AI into circumventing its sophisticated security protocols to execute hostile operations. Once compromised, the rogue AI agent, utilizing its MCP access, rapidly infiltrated various corporate systems and tools. It located and pinpointed highly sensitive databases within the target organizations in a timeframe that would be impossible for even the most advanced human hacking collectives.

This breach unleashed a terrifying cascade of actions: comprehensive vulnerability testing, the automated generation of malicious code, and even the self-documentation of the attack, complete with system scan logs and the Personally Identifiable Information (PII) it successfully nabbed.

For security veterans, this is a genuine nightmare scenario. How can human teams possibly match the sheer speed and destructive capability of an attack vector powered by this kind of AI?

A developer’s endpoint and this new AI ecosystem offer new attack vectors

Every developer prefers their own IDE, whether it's the classic VSCode, JetBrains’ IntelliJ or Eclipse, or the newer Cline, Windsurf or Cursor, and most of these have App marketplaces offering extensions to download and install. These extensions are rarely scrutinized for malicious activity, typically ship over-permissioned and have access to a sandboxed environment where they can access files. 

These environments are now all integrating AI capabilities, AI agents and a range of new tools these agents can use (MCP servers, for example). Often, these are all published through marketplaces where any developer can release their new tools. And yes, you guessed it, these MCP servers can often read, write and execute commands on a system all through an AI environment that is most likely vulnerable to prompt injections. What possibly could go wrong?

The non-negotiable need for AI tool traceability and observability

It’s all at once complex yet simple: If a CISO has no idea which developers are using which AI tools, what code is being committed, or which repositories are augmented by human-AI collaboration, then a huge dataset is missing, and observability needs to improve yesterday. 

The rapid integration of AI coding assistants and MCP servers, now leveraged by a vast majority of developers, has created a critical security blind spot within the SDLC. The data is alarming: up to 50% of functionally correct LLM-generated code has been found to contain security bugs, yet without proper observability, CISOs and AppSec teams lack actionable insight into the sheer volume and sources of this high-risk code being introduced. This critical lack of traceability renders effective AI governance in the form of policy enforcement and risk mitigation functionally impossible.

To safely maximize the immense productivity gains offered by AI, organizations must mandate solutions that provide complete, deep visibility into the AI attack surface. Secure Code Warrior has SCW Trust Agent: AI in closed beta with a select number of our customers. This capability provides deep observability by actively monitoring AI-generated code traffic (including MCP servers) in real-time on the developer’s local machine, and IDE tracking it through pull requests and commits to actual software repositories. Accurate security traceability is achieved only by correlating three vital signals: the specific AI coding tool and LLM model used, the targeted code repository, and, most critically, the contributing developer's measured secure coding proficiency.

Only by establishing this verifiable chain of correlation can an organization accurately benchmark the actual security risk being introduced, automate robust policy enforcement, and ensure that AI-enabled developers meet mandatory secure coding standards before their contributions successfully bypass existing guardrails. 

Get in touch with us if you’d like to know more or see a demo of supercharged AI governance in action, or just send a message to join the beta program.

A version of this article appeared in Cybersecurity Insiders. It has been updated and syndicated here.

‍

The adoption of artificial intelligence assistants, ranging from Large Language Model (LLM) code creators to sophisticated agentic AI agents, provides software developers with a wealth of benefits. Yet recent findings, underscored by a new MIT study, issue a warning: heavy reliance on AI might lead users to lose critical thinking skills.

Given a software landscape where AI-related security risks have grown in step with AI adoption, this loss of cognitive fitness could indeed lead to catastrophic outcomes. It is an ethical imperative for developers and organizations to proactively identify, understand, and mitigate security vulnerabilities early within the Software Development Lifecycle (SDLC). Those who neglect this duty, which, alarmingly, describes many organizations today, face an equally sharp rise in potential security threats, some of which are directly attributable to AI.

The debate is not whether to use AI, since the productivity and efficiency benefits are too great to dismiss. Instead, the real question is how to apply it most effectively: safeguarding security while maximizing output growth. And this is best done by security-proficient developers who deeply understand their code, no matter where it originated.

Over-reliance on AI risks cognitive decline

The study by MIT’s Media Lab, released in early June, tested the cognitive functions of 54 students from five Boston-area universities while they wrote an essay. The students were divided into three groups: those using a Large Language Model (LLM), those using search engines, and those going old school with no outside assistance. The research team used electroencephalography (EEG) to record the participants' brain activity and assess cognitive engagement and cognitive load. The team found that the old school, “brain-only” group exhibited the strongest, most wide-ranging neural activity, while those using search engines showed moderate activity, and those using an LLM (in this case, OpenAI’s ChatGPT-4) exhibited the least amount of brain activity.

This may not be particularly surprising—after all, when you enlist a tool to do your thinking for you, you are going to do less thinking. However, the study also revealed that LLM users had a weaker connection to their papers: 83% of students struggled to recall the content of their essays even just minutes after completion, and none of the participants could provide accurate quotes. A sense of author ownership was missing compared with the other groups. Brain-only participants not only had the highest sense of ownership and showed the broadest range of brain activity, but they also produced the most original papers. The LLM group’s results were more homogenous—and, in fact, were easily identified by judges as the work of AI.

From the developers' point of view, the key outcome is diminished critical thinking stemming from AI use. A single instance of relying on AI might not cause a loss of essential thinking skills, of course, but constant use over time can cause those skills to atrophy. The study suggests a way to help keep critical thinking alive while using AI—by having AI help the user rather than the user help AI—but the real emphasis must be on ensuring that developers have the security skills they need to build safe software and that they use those skills as a routine, essential part of their jobs.

Developer education: Essential for the AI-driven ecosystem

A study like MIT’s isn’t going to stop AI adoption, which is pushing forward across every sector. Stanford University’s 2025 AI Index Report found that 78% of organizations reported using AI in 2024, compared with 55% in 2023. That kind of growth is expected to continue. But increased use is mirrored by increased risk: The report found that AI-related cybersecurity incidents grew by 56% over the same time. 

Stanford’s report underscores the vital need for improved AI governance, as it also found that organizations are lax in implementing security safeguards. Although practically all organizations recognize the risks of AI, fewer than two-thirds are doing anything about it, leaving them vulnerable to a host of cybersecurity threats and potentially in violation of increasingly strict regulatory compliance requirements.

If the answer isn’t to stop using AI (which no one will do), it must be to use AI more safely and securely. The MIT study offers one helpful clue on how to go about that. In a fourth session of the study, researchers broke the LLM users into two groups: those who started the essay on their own before turning to ChatGPT for help, known in the study as the Brain-to-LLM group, and those who had ChatGPT work up a first draft before giving it their personal attention, known as the LLM-to-Brain group. The Brain-to-LLM group, which used AI tools to help rewrite an essay they had already drafted, showed higher recall and brain activity, with some areas similar to those of the search engine users. The LLM-to-Brain group, which allowed AI to initiate the essay, exhibited less coordinated neural activity and a bias toward using LLM vocabulary.

A Brain-to-LLM approach may help keep users’ brains a bit sharper, but developers also need the specific knowledge to write software securely and to critically evaluate AI-generated code for errors and security risks. They need to understand AI’s limitations, including its propensity to introduce security flaws such as vulnerabilities to prompt injection attacks.

This requires overhauling enterprise security programs to ensure a human-centric SDLC, in which developers receive effective, flexible, hands-on, and ongoing upskilling as part of an enterprise-wide security-first culture. Developers need to continuously sharpen their skills to stay abreast of rapidly evolving, sophisticated threats, particularly those driven by AI’s prominent role in software development. This protects against, for example, increasingly common prompt injection attacks. But for that protection to work, organizations need a developer-driven initiative to focus on secure design patterns and threat modeling.

Conclusion

When LLMs or agentic agents do the heavy lifting, users become passive bystanders. This can lead, the study’s authors said, to “weakened critical thinking skills, less deep understanding of the materials and less long-term memory formation.” A lower level of cognitive engagement can also lead to reduced decision-making skills. 

Organizations cannot afford a lack of critical thinking when it comes to cybersecurity. And because software flaws in highly distributed, cloud-based environments have become the top target of cyberattackers, cybersecurity starts with ensuring secure code, whether it is created by developers, AI assistants or agentic agents. For all of AI’s power, organizations more than ever need highly honed problem-solving and critical thinking skills. And that can’t be outsourced to AI.

The new AI capabilities of SCW Trust Agent provide the deep observability and control you need to confidently manage AI adoption in your SDLC without sacrificing security. Find out more.

For years, security leaders have invested heavily in secure coding programs, yet a fundamental question remains unanswered: Do we truly know who is committing code, and do they possess the skills required to write, review, and ultimately deliver secure code?

Traditional "shift-left" approaches leave enterprises struggling with massive blind spots when it comes to discovering and onboarding developers for secure coding programs. As program administrators rely on manual checks, spreadsheets and HR org structures to track developer secure coding skills, "shadow developers" who contribute code across critical code bases but lack security proficiency often emerge. This reality severely undermines secure SDLC goals and complicates governance, making it difficult to prove security competency when faced with internal or external reviews.

Secure Code Warrior’s Trust Agent eliminates this risk, transforming your secure coding program into a continuously monitored, verifiable defense that gives CISOs and AppSec leaders the confidence to prove their developers possess the necessary security proficiency required, on every commit.

Continuous Oversight and Assurance with Trust Agent

Without continuous oversight, developer risk remains hidden. Trust Agent delivers ongoing visibility by operationalizing security at the code commit level.

Continuous Developer Discovery: Knowing Your Scope

Before you can secure your codebase, you must know who is touching it.

Trust Agent automatically scans your integrated repositories to discover all active code contributors across your entire codebase. This helps address a critical challenge of onboarding - a continuous process - and answers the question: do you know when new engineers or contractors join, and whether they are receiving immediate, relevant secure coding education? By continuously monitoring commits, we ensure every developer is immediately identified and their secure coding journey can begin, eliminating the typical onboarding delays and ensuring comprehensive program scope.

‍

Verified Competency: Monitoring Code, Not Just Learning Completion

In addition to discovering all code contributors, Trust Agent transforms learning data into hard evidence by continuously monitoring secure coding skills applied in real-time. It provides deep observability by correlating every code commit with the developer's verified language-specific secure coding proficiency.

This is crucial for mandates like PCI DSS 4.0 (Requirement 6.2.2), which specifically calls for secure code training every 12 months in the language or framework developers commits code in. Trust Agent gives you the auditable evidence needed to prove that security competency is aligned with the languages and frameworks used in your critical applications.

In addition, Trust Agent provides immediate insights into your risk posture by pinpointing which teams or code repositories have high volumes of commits from developers without adequate security skills. This visibility enables program administrators to easily assign the right education to the right developers based on the most relevant, real-time data.

Integrated Governance and Policy Control

Ultimately, governance must be applied to truly lower developer security risk. Trust Agent offers the ability to make security proficiency mandatory by moving controls directly into existing dev workflows, with the ability to define commit policies based on your organization's risk tolerance. Trust Agent automates governance directly in the commit workflow, with policy gates that can be configured to log, warn, or block pull requests if a developer's secure coding skill level is insufficient. This integrated governance is the key to truly ensuring security is a requirement and not an optional suggestion.
‍

Securing the Future of Development

The move to verifiable secure coding proficiency is not just about passing audits- at the end of the day, it’s about shipping innovative, secure code. Even or especially with the rise of AI-assisted development, the fundamental principle remains: developers must be security-proficient to truly lower risk.  By making developer secure coding competency a measurable requirement, SCW Trust Agent is the critical piece that ensures your organization not only meets compliance and regulatory obligations, but fundamentally strengthens its security posture from within.

To learn more, book a demo or reach out to your Customer Success Manager today!

‍