Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

For the first time in this research series, the numbers moved. Since we began tracking AI-generated code security, the average pass rate has barely budged from 55–56%. Four snapshots, over 100 models, massive advances in capability… and the average stayed flat. Last quarter, we noted that the ceiling had actually dropped, from 72% (GPT-5 Mini, October 2025) to 68% (GPT-5.5, Summer 2026). The headline was “the ceiling won’t break.”

Seven years after the General Data Protection Regulation came into force, organizations are still learning a hard lesson: GDPR compliance is a technical lesson as much as it is a legal one. Application security for GDPR compliance sits at the center of that reality, because the personal data GDPR protects lives in your software: your web applications, your APIs, your cloud-native services, your third-party integrations.

In the span of a few days, we saw PHP2Shell, a set of critical remote code execution vulnerabilities in core PHP itself. That’s not in an application built on PHP, but in the engine that powers roughly 70% of the websites on the internet. Every PHP version released in the last decade was affected.

This briefing covers material developments for the seven-day period of 14–21 October 2026 and the thirty-day period of 21 September–21 October 2026. It is written for board risk committees, peer CISOs, and security leadership. The focus is residual risk, control effectiveness, and business enablement across application security, software supply chain, cloud and infrastructure, identity, third-party exposure, and AI-assisted development.

If you lead security at an EU financial institution or ICT service provider, the Digital Operational Resilience Act (DORA) is already reshaping your calendar, your budget, and the questions your board is asking. What it should also be reshaping is how you think about your software. Application security for DORA compliance isn’t a discrete project you hand to your development team.

AI tools can scan an entire application in minutes. They flag known vulnerabilities, map attack surfaces, and generate reports that look thorough. So, it’s fair to ask whether human penetration testers are still necessary. They are.

This briefing examines material developments across the most recent seven-day period and the preceding thirty days. It is written for executive and board consumption and focuses on residual risk, control effectiveness, material exposure, and the practical implications for application security programs, software supply chain integrity, edge and identity systems, and the accelerating role of AI in both attack and defense.

If you build, own, or secure software that touches protected health information (PHI), you already know that HIPAA compliance for healthcare applications is not a box you check before a release and forget until the next audit. It’s a continuous operating requirement, and the gap between what most teams actually do and what HIPAA demands is widening fast.

If your organization stores, processes, or transmits cardholder data, then application security for the Payment Card Industry Data Security Standard (PCI DSS) is a discipline you sustain. And with PCI DSS v4.0.1 now in effect, the standard has stopped accepting passive, point-in-time testing as evidence of a mature security posture. It wants continuous proof.

Application security testing (AST) is the practice of scanning software for vulnerabilities using static, dynamic, and component-level analysis – then managing those flaws through remediation, validation, and certification. A new independent report from FOURCASTERS and Lionfish Tech Advisors confirms that AST is not becoming obsolete. AI and cloud platforms are changing how testing gets delivered, but the need for independent testing, flaw lifecycle management, and validation has only grown.