TL;DR
Traditional application security programmes focus heavily on vulnerability remediation and developer education, yet breaches continue to occur. This essay proposes a paradigm shift: implementing robust validation controls at the API layer whilst accepting that perfect remediation is neither practical nor necessary. The approach acknowledges development realities whilst establishing stronger foundational security controls.
Context
Applications form the backbone of modern business operations, customer interactions, and data processing.
Despite advancements in security practices, the scale of the challenge to protect apps remains stark: Verizon’s 2024 Data Breach Investigations Report reveals that vulnerability exploitation as an attack vector has nearly tripled year-over-year, with web applications remaining the primary entry point for breaches. Industry analysis further indicates that insecure APIs and broken authentication, at 33% and 27%, respectively, represent the most prevalent attack vectors.
Traditional approaches focusing on vulnerability scanning, penetration testing, and remediation programs often struggle to keep pace with modern development speeds and evolving threats. Organisations find themselves caught between the pressure to deliver features quickly and the need to maintain robust security practices, often resulting in growing backlogs of security issues and increasing technical debt.
Security teams and developers frequently operate in separate worlds, with different priorities, languages, and success metrics. While security teams focus on reducing vulnerabilities and maintaining robust controls, development teams are driven by feature delivery timelines and business imperatives.
The impact of this disconnect is profound: the average cost per data breach has reached $4.8M, with only 12% of organisations reporting full recovery from their breaches. This combination of misaligned priorities and substantial business risk creates an urgent need for a new perspective.
This collaborative essay brings together insights from Chris Lindsey, a cyber security veteran with three decades of software development experience, and Dan Haagman, CEO of Chaleit, who together propose a shift in the application security approach.
Through their complementary perspectives on development, security, and system safety, they challenge conventional wisdom and offer practical solutions to bridge the gap between security requirements and development realities.
Challenges
The following challenges stem from the complex interplay of business pressures, technical constraints, and human factors. Understanding them is crucial for appreciating why traditional approaches often fall short and why a new paradigm is needed.
Let's examine each challenge in detail, starting with the fundamental pressure that shapes development decisions.
The pressure of delivery
Development teams operate under intense pressure to deliver features quickly. Dan uses an aviation metaphor to describe this situation: “Developers are flying blind, relying solely on their instruments because they lack visibility.” This tunnel vision, combined with business imperatives around feature deployment and roadmap completion, creates an environment where security becomes an impediment rather than an enabler.
“If you’re not getting product out the door, you’re spending money without making any,” Chris explains. This financial pressure drives teams toward quick solutions rather than secure ones. The speed of development, particularly in VC-funded companies, creates what Dan describes as a “blinkered effect” where developers focus solely on the next feature delivery.
A concerning practice Chris identifies is what he calls “notepad inheritance”: “Developers often reuse existing code by copying and pasting, a practice I call ‘notepad inheritance.’ This can propagate security vulnerabilities if the original code wasn’t secure.”
The problem compounds as applications grow. Chris explains: “We scaled quickly, hitting 100, 200, and then even 500 customers. But with that growth came slowdowns and problems.” This scaling challenge often reveals security shortcuts taken during initial development phases.
While delivery pressure creates one set of challenges, the disconnect between teams amplifies the problem further.
The communication gap
The disconnect between security teams and developers creates significant obstacles. “When you tell a developer you have an SSRF or cross-site scripting or stored cross-site scripting, you might as well be speaking a foreign language to most of them,” Chris observes. This communication barrier creates friction between security teams and developers, leading to delayed remediation and misunderstood priorities.
The problem extends beyond individual vulnerabilities to fundamental architectural decisions.
As Chris points out, “Out of my entire career, I’ve only had two software architects that knew anything about security.” This lack of security awareness at the architectural level leads to systemic vulnerabilities that become increasingly difficult to address as applications scale.
These communication challenges directly impact how organisations approach security fixes, leading to inefficient remediation cycles.
The remediation cycle
Traditional vulnerability remediation approaches often lead to an endless cycle of fixing issues without addressing root causes. The focus on individual vulnerabilities rather than systemic problems creates a never-ending game of whack-a-mole, consuming resources while failing to improve overall security posture.
Chris shares an example of the challenges with traditional security tooling: “My SAST tool flagged a cross-site scripting issue that wasn’t a real problem. The application’s encoding was correct, so there was no security risk. Even so, we had to spend time addressing it.”
Adding to these traditional challenges, the increasing adoption of AI in development introduces new complexities to cyber security.
AI and automation risks
The communication challenges between security and development teams are further complicated by the increasing reliance on automated tools and AI. While these technologies promise to bridge the gap, they often introduce new risks.
As Chris points out, AI’s knowledge is limited to its training data. When that data comes from GitHub, for example, it includes everything from best practices to code written by beginners. This variance in quality creates significant risks when using AI-generated solutions without proper oversight.
The problem is evident in real-world situations. Chris shares an example of Tesla’s autopilot system attempting unnecessary highway exits, illustrating how automation without context and human oversight can create new risks rather than mitigate existing ones.
These challenges show why traditional security approaches often fail. Rather than trying to fix each problem separately, we need a new approach that addresses the root causes.
A new approach to application security
Instead of continuing with traditional remediation-focused approaches, Chris and Dan propose a shift in how organisations approach application security.
Their research and experience suggest that robust API validation can prevent the vast majority of potential security issues before they occur.
A preventative approach, focusing on comprehensive API-level controls, represents a more efficient and effective foundation for application security than traditional remediation-focused methods.
Let’s explore it in more detail.
The API-first security framework
The proposed approach centres on treating the API layer as the primary security control point.
“Everything coming into an API is dirty. It’s wrong until it’s validated right,” Chris emphasises.
His proposed mindset shift leads to a more effective security posture.
Core elements of this approach include:
Comprehensive input validation at all API endpoints
Robust database security through stored procedures
Behavioural analytics integration at the application layer
Sophisticated logging and monitoring systems
“I’m now convinced that stored procedures are essential for application development, and I won’t develop another application without them,” Chris states, highlighting the importance of secure database interactions through stored procedures.
Implementation strategy
The implementation of this security framework requires a systematic approach.
First, establish robust input validation. As Chris explains, “If a value that’s supposed to be no more than 15 characters is longer, it’s a red flag for a potential man-in-the-middle attack or malicious intervention.” Strict validation prevents many common attack vectors.
Second, implement comprehensive logging and monitoring. “I log every inbound request coming into an API. If I know the data is critical, I actually encrypt it and save it encrypted,” Chris describes. This methodology enables both security monitoring and forensic analysis when needed.
Third, behavioural analytics should be integrated directly into the application layer. By monitoring patterns of usage and access, the system can identify and respond to suspicious behaviour in real time. “Tracking customer login IP addresses establishes a baseline for normal activity,” Chris notes.
Finally, scalability is key. Chris explains that Kubernetes clusters, pods, and load balancers offer the flexibility to scale. Modern architectures ensure security controls can keep pace with application growth.
Key takeaways
The insights shared by Chris and Dan suggest several crucial principles for application security:
Validation over remediation. API-level validation can prevent the majority of security issues before they occur. As Chris demonstrates through his 18+ years of uncompromised APIs, robust validation at the entry point is more effective than continuous vulnerability remediation.
Security at the architecture level. Rather than treating security as a post-development concern, build it into the architectural foundations. This includes proper API design, database security through stored procedures, and scalable security controls.
Behavioural analytics in the application layer. Move traditional SOC capabilities into the application layer. By integrating behavioural analysis at the API level, organisations can detect and respond to threats more effectively and efficiently.
Accept development realities. Instead of fighting against development pressures and timelines, adapt security approaches to work within these constraints. Focus on controls that don’t impede development velocity.
Human expertise remains critical. While embracing automation and AI, maintain human oversight and expertise.
Scale security with growth. Design security controls that can scale with application growth. Using modern architectures like Kubernetes ensures security measures remain effective as applications evolve.
The future of application security requires a delicate balance between automation and human expertise.
“We’re the last generation who really understands how things truly work,” Chris cautions, emphasising the importance of maintaining fundamental security knowledge while embracing new technologies.
The key is not perfect vulnerability remediation but robust foundational controls. Dan shares his experience at Chaleit: “We prioritised building a solid foundation, which takes time and effort. We focused on hiring senior staff, establishing compliance and governance, and developing a deep understanding of our services.” This upfront investment, while slower initially, pays off in the long run.
As Dan concludes, we need to “stop vulnerability scanning your application around the API per se, replace thinking with a look at the way validation is executed.” By focusing on API-level validation and controls while acknowledging the realities of modern software development, organisations can achieve better security outcomes with fewer resources.
At Chaleit, we apply these principles in our client engagements by first understanding the fundamental architecture and development realities before diving into security assessments.
Rather than focusing solely on vulnerability scanning, our approach works within our clients’ business constraints and context. We help organisations build security foundations that scale with their growth while maintaining development velocity. Let’s talk security.
About the authors
Chris Lindsey
Chris Lindsey is a seasoned speaker who has appeared at conferences, webinars, and private events. Currently building an online community and creating a podcast series (Secrets of AppSec Champions Podcast), Chris draws on expertise from more than 15 years of direct security experience and over 35 years of experience leading teams in programming and software, solutions, and security architecture.
For three years, Chris built and led an entire application security program that includes the implementation of mature AppSec programs, including oversight of security processes and procedures, SAST, DAST, CSA/OSA, compliance, training, developer communication, code reviews, application inventory gathering, and risk analysis.
Dan Haagman
Dedicated to strategic cyber security thinking and research, Dan Haagman is the CEO and founder of Chaleit, a seasoned leader in global cyber security consulting, and an Honorary Professor of Practice at Murdoch University in Perth, Australia.
With nearly 30 years of experience, he began his journey at The London Stock Exchange, where he pioneered the development of their first modern SOC and defensive team. As a co-founder of NotSoSecure and 7Safe, both acquired by reputable firms, Dan has left a lasting impact on the industry.
Today, Dan leads a team of brilliant minds in seven countries, all focused on delivering world-class cyber security consulting. Chaleit reflects Dan’s vision for the industry’s future. Built on the core principles of longevity and transparency, the company is poised for a public offering within the next few years.
Dan has a passion for learning. With a pen and paper at hand, he dedicates significant time to reading, researching, designing systems, and learning with clients and peers with the goal of being a leading thinker and collaborator in the cyber industry.
Disclaimer
The views expressed in this article represent the personal insights and opinions of Dan Haagman and Chris Lindsey. Dan Haagman’s views also reflect the official stance of Chaleit, while Chris Lindsey’s views are his own and do not necessarily represent the official position of his organisation. Both authors share their perspectives to foster learning and promote open dialogue.