Close Menu
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Facebook X (Twitter) LinkedIn
Facebook X (Twitter) LinkedIn
Information Security BuzzInformation Security Buzz
  • Home
  • Articles
    • Attacks
      • BEC
      • Data Breach
      • DDoS
      • Evasion Attacks
      • Injection
      • Malware
      • MITM
      • Phishing
      • Ransomware
      • RCE
      • Social Engineering
      • Spoofing
      • Spyware
    • Business and Policy
      • BCP and DRP
      • GRC
      • Regulations
    • Data Protection
      • DLP
      • DRM
      • Encryption
      • IAM
    • Future, Trends and Insight
      • AI
      • Events & Community
      • Emerging Tech
      • Expert Panel
      • Interviews With Experts
      • Insights
      • Study & Research
    • Resources
      • Guides
      • Tools
      • Training & Education
    • Security
      • API
      • Apps
      • Cloud
      • Critical Infrastructure
      • Endpoint
      • Hardware
      • IoT
      • Mobile
      • Network
      • OT
      • Port Security
      • Security Architecture
      • Software Development
      • Supply Chain
      • Zero Trust
    • Threats and Vulnerabilities
      • Emerging Threats
      • Insider Threats
      • Risk Management
      • Threat Intelligence
      • Zero Day
  • News and Exclusives
    • Latest News
    • ISB Exclusive
    • Positive News
  • Who We Are
    • About Us
    • Information Security Buzz Expert Panel​
    • Write for Us
    • Media Pack
  • Contact Us
  • Newsletter
Subscribe
Information Security BuzzInformation Security Buzz
Home - Articles - Why SQL Injections Are The Cockroaches Of The Appsec World (and how CISOs can eradicate them once and for all)
Articles

Why SQL Injections Are The Cockroaches Of The Appsec World (and how CISOs can eradicate them once and for all)

Matias MadouBy Matias MadouOctober 24, 2018Updated:December 30, 20216 Mins Read
Share LinkedIn Twitter Facebook Copy Link Email
Share
Facebook Twitter LinkedIn Email Copy Link
Quick AI Summary
ChatGPTClaudeGeminiGrokPerplexityDeepSeekCopilot

When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.

There’s a well-known theory that cockroaches can survive basically anything – even a nuclear explosion. While that theory only rings true to a point, their simple body composition makes them extremely hardy for their size, and difficult to eradicate under most conditions.

I’ve been thinking… if cockroaches had an equivalent in the digital world, it would have to be SQL injection (SQLi) vulnerabilities in code. This has been a known vulnerability for more than twenty years, yet organizations fall victim to them time and time again. The widespread, costly attack on Target was the result of SQL injection, as was an instance of election hacking in Illinois in which 200,000 voter records were exposed, prompting the FBI to recommend all IT admins work quickly to strengthen their security practices.

Imperva’s Hacker Intelligence Initiative Report revealed that between 2005 and 2011, SQLi attacks were used in 83% of all reported data breaches. Today, injection vulnerabilities remain the number-one threat in the OWASP Top 10. They are relatively simple, yet they just won’t die.

It seems ridiculous that this same vulnerability is still appearing in a significant number of application security scans. We know how it operates, and we know how to stop it. How is this possible? The truth is, our software security has a vast amount of room for improvement.

Veracode’s State of Software Security Report – based on 400,000 application scans in 2017 – revealed an alarming statistic: just 30% of applications passed OWASP Top 10 policy. This has been a consistent theme over the past five years, with SQL injections appearing in almost 1 in 3 newly scanned applications. This is evidence of an endemic issue; we are not learning from our mistakes, and CISOs seem to face an uphill battle in being able to procure enough security talent. Typically, the ratio of AppSec specialists to developers is an inadequate 1:100.

Why is software security on life support? It’s no secret that specialist security talent is scarce, but we must also pay attention to the fact that developers are not fixing issues as they arise, and are quite clearly ill-equipped to not introduce vulnerabilities in the first place. In the same Veracode report, it was divulged that there were documented mitigations for just 14.4% of all development vulnerabilities. In other words, most vulnerabilities were submitted without development mitigation. Fewer than one-third of vulnerabilities were closed in the first 90 days, and 42% of vulnerabilities were never closed within the development period.

I speak to security professionals, CISOs and CEOs all the time, and anecdotally, I’ve become aware that many companies become so frustrated with the number of vulnerabilities found that can’t be mitigated (in addition to the scourge known as false positives), that they stop scanning for them altogether, cross their fingers and hoping for the best.

Why do AppSec professionals let this happen? Make no mistake: AppSec people are painfully aware of problems in code. After all, that’s one of their core skills that makes them such a valuable team resource. However, they are often hamstrung by several factors.

For instance, an AppSec manager will find an issue and ask the developer, “can you fix the code?”. The answer to this important question differs from organization to organization, but in general, the developer is so stretched meeting strict feature delivery sprints that they simply don’t have the time to fix these problems, nor decent tools to help them. AppSec professionals themselves might be able to identify vulnerabilities, but they often don’t have the skills and/or access to remediate them on the spot.

We must also realize that for every problem, there is a process of needing to find a solution, implement it, and then test it. For even the slightest issue found in the code, the time it can take to fix, not mention the resources required, is immense. There are over 700 vulnerabilities that can be introduced into software, and it’s simply impossible for any one person to be able to defend against them all. It is for this reason that most companies stick to following the OWASP Top 10 only. All the while, developers keep building features and in turn, they keep introducing vulnerabilities into the code they write.

What is the solution? The simple fact is, we don’t give our developers the tools and training to foster secure coding success. There are no regulations that force organizations to ensure developers possess adequate security skills, and it’s a sad reality that most universities and internships don’t prepare junior developers to code securely, either.

When someone wants to fly a plane, there is a very rigorous process that ensures training, practical experience, medical checks, safety knowledge and exams before they are able to fly. No-one would dare imagine that they would be let loose in the sky without this extensive preparation and validation of skills, yet this is what happens on a day-to-day basis with code writing.

We need to spend the time to educate developers on writing secure code. However, in today’s world, where software development is fast-paced as well as good developers and security professionals existing in short supply, it never seems to be a priority. It’s time we changed the conversation.

A recent headline from the World Economic Forum screamed: “There can be no digital economy without security”, with the accompanying content arguing the need for security to be a core part of any digital transformation strategy. “Security is what protects businesses, allowing them to innovate, build new products and services. Beyond a defensive role, security provides businesses with a strategic growth advantage.” Improving secure coding skills and outcomes will add a powerful layer of cyber protection for organizations, assisting them in creating better, faster code.

Developers don’t need to become security experts, but they must be empowered positively and practically to be the first line of defense against cyberattacks. Developers can be the next security and innovation heroes. They are very clever people, they are creative problem-solvers, and generally keen to build their skills. Play to their strengths with the specialized training they deserve, and commit to a higher software security standard.

Matias Madou

Co-founder and CTO

  • Matias Madou
    Adding A Human Firewall: The Role Of Developers In Protecting The Supply Chain
  • Matias Madou
    How Can Organisations Protect Themselves From Cyberattacks In An Increasingly Virtual World?
  • Matias Madou
    How To Become A Kick-Ass DevSecOps Engineer

The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.

Share. Facebook Twitter LinkedIn Email Copy Link

Related Posts

AppSec is dead, long live AI security

April 29, 20265 Mins Read

Managing App Access on Frontline Devices in an Always-On World

March 9, 20264 Mins Read

OWASP Top 10 2025: New Enemies, Old Foes, and an Approach to Vulnerability Remediation That Must Evolve

January 22, 20265 Mins Read
ISB-Bora-Side-Bar

No se ha podido establecer conexión. Error 429

 
ISB-Bora-Side-Bar
Black ISB Logo

Information Security Buzz is an independent resource that provides the experts’ comments, analysis, and opinion on the latest Cybersecurity news and topics

X (Twitter) LinkedIn Facebook RSS

Working With Us

  • About Us
  • Advertise With Us
  • Contact Us

Write For Us

  • How To Contribute

The Pages

  • Privacy Policy
  • Cookie Policy
  • AI Policy
  • Terms & Conditions
  • Copyright Notice

Information Security Buzz and all its contents are copyright © 2014-2025. All rights reserved. All third-party trademarks are recognized.

Type above and press Enter to search. Press Esc to cancel.

Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
View preferences
  • {title}
  • {title}
  • {title}