Application security is changing in dramatic ways. Change is accelerating so quickly that the current state is almost unrecognizable to someone who started developing software just a decade ago.
Rapid change can be a tough pill to swallow for developers. Anyone who writes code continuously faces change on multiple fronts: new technologies and frameworks, programming languages, tools, processes, and more. It’s hard to keep up with core software development topics, let alone (arguably) adjacent topics like application security.
When looking at major trends in application security, one thing is clear to me: there is a lot more good news than bad news. That’s not to understate the bad news — there is a lot of it. You know that. But there’s another side to the story.
Challenges create opportunities. That’s exactly what is happening in application security if we zoom out and look big picture. Strategy-minded software developers are exceptional at solving problems and taking advantage of opportunities. We’re going to discuss a bunch of them today.
In this article, a few trends we’ll cover include:
- DevSecOps and the convergence of application security responsibilities on development teams
- Changes in attack patterns inside and outside of your code
- Developer-friendly application security testing
- The rise of software supply chain security into the spotlight
- The biggest risk people don’t talk about: secrets management
- The importance of securing data, not just code
- Transformative progress in authentication and authorization
- Reliance and impact of third parties on security
- Changing user expectations around security
This is a wide-ranging article that covers nearly every area of the application security landscape. Since we’re going wide here, this article is structured a bit differently than a typical company-focused analysis. Our goal for today is to cover a lot of ground while offering some practical ideas to explore.
Let’s get to it.
Convergence is making developers responsible for more than development.
Impact
The convergence of development, security, and operations are shifting everything straight onto the plate of developers. Traditionally, software development has been all about writing, testing, and deploying code. Now, DevSecOps (and more importantly, the processes and tools behind it) are shifting more responsibilities and control to developers. Developers are still in charge of code, but now get to claim responsibility for infrastructure, security, and more.
On the surface, an increase in responsibilities sounds like a bad thing. It can be, but the reason why it’s happen matters. When you look at the trend more closely, it’s happening because improvements in tools enabled the shift.
Tools are getting better to help make this burden manageable — perhaps even advantageous. In the case of security, many new products are composable. They give developers a set of primitives and workflows to build security experiences instead of implementing one-size-fits-all products.
One good example is Persona, a set of building blocks that lets developers build specific identity verification workflows for customers. Another is Panther, which lets developers build a highly customized SIEM based on a set of log management and alerting primitives.
Forward-thinking security companies are going to continue building tools that are developer-friendly. Expect more of this in the future.
Ideas
The convergence of development and security is going to continue. Embrace it. The trend will accelerate as new paradigms (and products) gain adoption.
As the famous Eleanor Roosevelt quote goes, “with freedom comes responsibility.” The traditional mindset for security has often been to buy a product that (theoretically) solves a set of security problems. Convergence and composability turns that around.
Now, we get a nice set of tools that we are responsible for using to build solutions for our unique security problems. That’s a good shift, but a big shift that many people aren’t ready for.
Finally, be development teams should be intentional about adoption and use of processes and tools. Don’t let them be imposed by security teams. Instead, work together on objectives everyone agrees on. This trend brings a window of opportunity to redefine the relationship between development and security (and to pick world-class tools), so make the most of it.
Attacks are happening outside of your applications…
Impact
Attackers are after your customers and money. Exploiting applications is only one of many ways to get there. Unfortunately, attackers are always on the lookout for new and creative ways to carry out their nefarious motives. Attacking your applications is a tried-and-true approach, but recent high profile breaches have involved adjacent areas of software engineering.
For example, attacks on the DevOps pipeline have caused major breaches, including SolarWinds. The InfoSec community has rightfully placed a lot of emphasis on securing code. However, examples like SolarWinds have shown us that other parts of our engineering processes are also targets.
Attacks coming from all angles also have an operational impact, even if a breach is avoided. According to data from Verizon’s 2021 Data Breach Investigation Report (DBIR), Denial of Service (DoS) attacks cause a disproportionate amount of incidents (but not many breaches). Unfortunately, we now need to anticipate a steady stream (and sometimes a huge spikes) of attacks that follow this pattern.
Ideas
Broaden your mental model of security beyond code. Attackers are looking for any ways to exploit your company that they can find. We have to adjust our own mindset and include areas outside of code in our threat models.
Use services like DoS mitigation and bot management. These attacks can’t be eliminated, but their impact can be reduced. Services like Cloudflare routinely mitigate large attacks. The nominal cost of adding this layer of protection to our apps is well worth the investment.
Include your DevOps pipeline in threat modeling activities. Tools like CI/CD, artifact repositories, and other parts of the pipeline are now targets that need to be secured just like our code and infrastructure.
…but basic web application attacks still cause 26.1% of breaches.
Impact
Web application attacks are the second most frequent attack pattern identified in the Verizon DBIR report (social engineering was first, causing a full 33.6% of breaches). Attackers are looking beyond applications, but our applications are still under attack. And they’re still causing breaches at an alarmingly high rate.
An upward trend in credential stuffing is a newer development for specific types of attack patterns. According to the Verizon DBIR, credential stuffing (~80%) causes far more incidents than vulnerability exploitation (~20%). Many people don’t expect that ratio — especially given how much visibility and education there is around vulnerability exploitation.
From a process and governance standpoint, vulnerability management programs are converging with application security and risk management. These domains used to be viewed separately, with vulnerability management focusing on patching and risk management focusing on audits and compliance. Companies are now taking a risk-based approach to vulnerability management and managing application security vulnerabilities within their overall programs.
Ideas
Move beyond manual testing and one-off static code scanning. In today’s iterative, fast-moving style of software development, a point-in-time scan or manual review isn’t able to keep up with how fast an application’s code is changing. Ideally, secure your code as it’s written. As we’ll discuss next, major improvements in tools have made an iterative and developer-friendly approach possible.
Use services to detect and defend against credential stuffing attacks. This attack pattern is still an attack on our application, even if it’s a different approach than more traditional vulnerability exploitation. We have to expect a constant flow of credential stuffing attacks on production applications, including the occasional spike in attempts when a fresh batch of credentials gets exposed in a breach.
Take a prioritized and risk-based approach to remediating vulnerabilities. As much as we’d like to close all vulnerabilities, it’s currently impractical for most companies to do this in practice. A risk-based approach makes remediation more manageable.
Application security testing is (finally) becoming developer-friendly.
Impact
Organizations (and products) are finally starting to cater security to developers’ needs. For any experienced software developer, this has been a long, long time in the making. The painful memories of application security intake forms, delayed releases, and last-minute vulnerability remediation haven’t faded away quite yet, but a lot of progress has been made.
The big idea is to move application security testing forward in the development process and iteratively run scans as code is developed and committed. The term “shift left” gets overused, but the foundational idea is nice. Just like you’d write automated tests and get real-time feedback, you can run automated security tests.
Companies like Veracode and Snyk have been leading the way, and both companies are likely to be rewarded with IPOs in the next five years. Their success (and huge developer fan base) validates the idea that software development can increase speed and security at the same time — these objectives are not diametrically opposed.