Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Last Tuesday, your SCA tool flagged 3,847 CVEs across your Kubernetes clusters. Your SAST scanner added another 1,200 findings from the overnight build. The container scanning pipeline blocked 47 images. And somewhere in Slack, someone from the SOC is asking why you haven’t patched the Log4j variant they read about on Twitter. You’ve done everything the security vendors told you to do. You shifted left. You scan everything. You gate deployments. You have dashboards.

With my youthful good looks, it’s hard to believe that I’ve been in cybersecurity for almost two decades. : ) I’ve seen the industry go through some massive transformations. Each change brought its own set of challenges, failures (I’m looking at you XDR) and, more importantly, opportunities. As I am now entrenched in application security, I’m learning that we’re in the middle of another one of those moments, and it’s just as exciting.

Every financial entity operating in the European Union must comply with the Digital Operational Resilience Act (DORA). DORA focuses on whether systems can withstand, respond to, and recover from ICT-related disruptions and whether this can be demonstrated with evidence. For engineering, security, and risk teams, this introduces a practical requirement. Operational resilience must be observable in live systems, continuously tested, and traceable over time.

Compliance once lived on a calendar. Teams prepared for it in advance, reviewed it periodically, and treated it as a milestone separate from engineering work. That model no longer holds. Mobile applications now ship continuously. Features move weekly. Fixes land daily. Every change, no matter how small, alters the security and privacy posture of the organization. In this environment, compliance cannot trail development. It has to move with it, embedded into how software is built, tested, and released.

Compliance once followed a schedule. Teams prepared evidence near audit windows, ran tests in batches, and treated documentation as something assembled outside the development lifecycle. That approach no longer holds when releases ship continuously. Every commit, dependency update, and configuration change reshapes exposure and alters what evidence must exist.

Insecure Direct Object References, commonly referred to as IDORs, remain one of the most common and damaging classes of application vulnerabilities. Despite being well documented and widely understood at a conceptual level, they continue to appear in real production systems, particularly in modern, API-driven applications.

Effectively protecting your software supply chain has reached a critical turning point where the traditional strategy of patching together “best of breed” or point AppSec solutions is no longer sustainable.