Behind the software that powers our world and economies are software developers who design, develop, and deploy code. Software developers exert a significant influence on the quality, reliability, and security of the software produced. Alternatively, attackers are merely searching for an innocent coding mistake, a vulnerable dependency, a leaked secret, an overprivileged function, or a misconfigured storage bucket that can be exploited to infiltrate an enterprise. This elevates application security to the most crucial role on your development team.
We should be better at this by now
The concept of DevSecOps — which integrates people, processes, and technology with the aim of embedding security throughout an application’s lifecycle — is not new. Forrester introduced The Seven Habits of Rugged DevOps, an early iteration of DevSecOps, back in 2015. However, transformation takes time, and numerous factors such as industry regulations, risk tolerance, legacy code, and company culture can either facilitate or impede adoption by an organization or individual teams. Thanks to developer coding assistants, cloud deployments, and automated continuous integration and continuous deployment pipelines, code is being released at ludicrous speed, but without app sec, that code has the potential to introduce significant downside risk to the organization.
Let’s look at where we are this year when it comes to application security.
- Web application exploits continue to persist. Twenty-two percent of security decision-makers who reported breaches via external attacks identified web application exploits as the entry point. We’re referring to common security flaws such as cross-site scripting (XSS) and SQL Injection (SQLi), which attackers exploit to compromise organizations. Tools designed to identify these types of flaws, such as static application security testing (SAST) and dynamic application security testing (DAST), have been available for decades. So, why are these issues still prevalent? Firstly, for these tools to be effective teams need to use them early in the development lifecycle but often don’t. Secondly, attacks targeting application programming interfaces (APIs) have surged in the last few years, and organizations are struggling to successfully inventory APIs let alone apply application security best practices to them.
- Software supply chain attacks are escalating. A particularly insidious form of these attacks involves bad actors compromising open-source libraries. Organizations unknowingly download and incorporate these compromised libraries into customer applications. Twenty-seven percent of security decision-makers who reported breaches via external attacks identified software vulnerability exploits as the vector. Another basic hygiene tip: keep your open-source and third-party libraries up-to-date. When new critical vulnerabilities are disclosed and patched, obtaining a fix often requires updating to the latest versions. If your application is several versions behind, this could necessitate painful upgrades just to apply a security fix, thereby delaying your response capability.
- Security debt won’t magically disappear. In the software security world, this is akin to technical debt, which accumulates when corners are cut, testing is skipped, or code reviews are superficially conducted to expedite product releases. Every software development team has experienced the burden of technical debt. Symptoms include customer complaints about a slow user interface, fixing a defect in one area of the code leading to unintended consequences in another, or an ever-growing defect backlog. Security debt is similar.
But it’s not all dire warnings and missed opportunities to keep up with the basics. We’ve observed some promising trends with teams transitioning to DevSecOps, which represents a more preventative approach to security. Interested in discovering more? Dive into our comprehensive report, The State of Application Security, 2024, to see how your program stacks up.
