The last few years have seen the Application Security (AppSec) industry undergo some dramatic changes, with new types of attacks materializing and new types of security companies forming in response. The classic security industry game of whack-a-mole is now in full swing, with enterprises, security vendors, and AppSec teams alike collectively figuring out what it means to run a modern, secure engineering org.
To figure out where and how to go forward, it’s worth tracing how the landscape has changed over the years, and how we got here to begin with.
How Did We Get Here?
Application Security has been around for about as long as businesses have been building, hosting, and selling software as a primary revenue stream — so, for the better part of 30 years. A good marker for the start of this industry would be around the time of the dotcom boom, when the first public-scale SaaS companies started to form. As hosted apps grew in importance as the primary revenue drivers for public-scale companies, so too did securing them.
While the AppSec industry has produced some massive outcomes over the years — with companies like Snyk, Checkmarx, and Veracode collectively scaling to hundreds of millions of dollars in revenue — a few recent trends have shaken up the market, creating the perfect storm for new types of companies to emerge:
-
- Every company now looks like a tech company. While Silicon Valley continues to be a hub for companies that hire software engineers and ship code, the big macro trend over the years has been that software delivery has become an integral part of every major industry. It is now common practice for sectors like banking, insurance, travel, manufacturing, big pharma, and more to hire software engineers and develop critical, revenue-generating apps. The Bureau of Labor Statistics consistently places software engineering as one of the fastest growing jobs in America.
- Open source has exploded. Developers increasingly want to focus their efforts on writing code that adds unique and differentiating value. A side effect of this is that open source has become a massive part of developer productivity; any non-differentiating task can easily be picked up off-the-shelf and popularized amongst developers. A recent GitHub analysis reports that there are now 284m public repositories, growing 22% year over year; 90% of companies on GitHub are leveraging open source software (OSS) in their applications; 60% of Snyk survey respondents report having a developer tool stack built on 50% OSS or more. The data shows that open source tooling is growing, companies are using it, and not just sparingly – it has become a critical part of the software ecosystem.
- Cloud-native development became mainstream. As testing, building, and production environments move to third-party platforms like AWS, the attack surface for applications has become increasingly disjointed, exposed, and complicated. Gone are the days of having clear visibility and control over the surface area within the four walls of your data center.
- AI has forced new incentives around data accumulation. Companies evaluating their “AI strategy” quickly realize the value of their proprietary data: it is the central means of building a moat in a world where model training and personalization play a bigger role in customer experience. As the primary driver for data accumulation, applications stand to become an increasingly sensitive attack surface in the enterprise.
The sum of all of this is that attackers have taken notice, engineering new and ingenious ways of compromising apps. We see this in the explosive growth in software supply chain attacks since the start of COVID in 2020.
Considering that AppSec tools have been well-adopted in the enterprise for years, the growth in attacks can only be explained by adversaries finding new and unprotected surface areas to go after. As a result, the industry has had to evolve over the last 3-4 years to meet these shifting attack patterns. This has created the whack-a-mole like dynamic that has defined so much of the innovation in the broader security industry: adversaries discover new attack vectors, new companies counter with evolved software, rinse, repeat.
Historically, AppSec tools fit under the umbrella of Application Security Testing (AST), which is comprised of three well-established subcategories:
- Software Composition Analysis (SCA): SCA tools check your third-party dependencies against known vulnerabilities or suspicious behavior. For example, they can flag if your application leverages the Log4j package, or if any of your libraries are no longer being maintained.
- Static Application Security Testing (SAST): SAST tools scan first-party code written by your in-house engineering team. They can check for exposure to vulnerabilities like buffer overflows and SQL injection attacks.
- Dynamic Application Security Testing (DAST): DAST tools scan all of the paths that your application can take during runtime, and attempt to inject malicious payloads to see how the app would respond in production.
These three methods have long been considered sufficient for running a comprehensive AppSec program. However, in light of the recent attack growth, CISOs have looked for evolved tooling to help protect them from these new exploits.
Community Response
In recent years, there has been tremendous community effort towards understanding and securing these new blindspots. In 2021, founding members Red Hat, Google, Purdue University, the Linux Foundation, and other security leaders collaborated to create Sigstore: an open source project that helps engineering teams more securely sign and verify their software artifacts.
More recently, in 2023, Ox Security published PBOM.dev, a framework for understanding some of the newer and more innovative attack patterns that AppSec leaders are grappling with.
Perhaps most notably, in 2021 Google partnered with the Open Source Security Foundation to create SLSA (Supply-Chain Levels for Software Artifacts): an open standard for defining and improving application security posture. In the three years since its release, practitioners and vendors alike have aligned to this highly-structured view of software supply chain attack vectors. Each of the attack paths outlined in SLSA has a recent, real-world example to draw from: e.g. SolarWinds, which compromised the build platform to inject malicious behavior, or CodeCov, where attackers used leaked credentials to upload a modified package. We’ve found their perspective to be helpful in understanding the threat landscape and where the opportunities lie for emerging AppSec companies.
| Attack Vector | Real-world Example | How SLSA Would Help | |
| A | Submit Unauthorized Change | SushiSwap: Contractor with repository access pushed a malicious commit redirecting cryptocurrency to themself. | Two-person review could have caught the unauthorized change. |
| B | Compromise source repo | PHP: Attacker compromised PHP’s self-hosted git server and injected two malicious commits. | A better-protected source code platform would have been a much harder target for the attackers. |
| C | Build from modified source | Webmin: Attacker modified the build infrastructure to use source files not matching source control. | A SLSA-compliant build server would have produced provenance identifying the actual sources used, allowing consumers to detect such tampering. |
| D | Use compromised dependency | event-stream: Attacker added an innocuous dependency and then later updated the dependency to add malicious behavior. The update did not match the code submitted to GitHub (i.e. attack F). | Applying SLSA recursively to all dependencies would have prevented this particular vector, because the provenance would have indicated that it either wasn’t built from a proper builder or that the source did not come from GitHub. |
| E | Compromise build process | SolarWinds: Attacker compromised the build platform and installed an implant that injected malicious behavior during each build. | Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence. |
| F | Upload modified package | CodeCov: Attacker used leaked credentials to upload a malicious artifact to a GCS bucket, from which users download directly. | Provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo. |
| G | Compromise package registry | Attacks on Package Mirrors: Researcher ran mirrors for several popular package registries, which could have been used to serve malicious packages. | Similar to above (F), provenance of the malicious artifacts would have shown that they were not built as expected or from the expected source repo. |
| H | Use compromised package | Browserify typosquatting: Attacker uploaded a malicious package with a similar name as the original. | SLSA does not directly address this threat, but provenance linking back to source control can enable and enhance other solutions. |
Source: SLSA Supply Chain Threats, Real World Examples
Given the above, CISOs have raised the bar for their purchasing requirements, and founders have certainly responded. In recent years, we’ve seen established methods of code scanning expand to cover new surface areas, improve developer experience, and reduce alert fatigue. We’ve also seen some entirely new types of security companies emerge, rethinking what it means to have an AppSec program altogether.
Software Composition Analysis (SCA)
Managing open source dependencies remains the linchpin of any AppSec program. In fact, SCA is the one category that best fits the name for “software supply chain security.” As software producers expand their use of open source, and software buyers increasingly demand things like SBOMs (software bill of materials), SCA stands to become an increasingly important category over time.
Some of the main challenges in this category today are around prioritizing alerts and finding signal in the noise – legacy SCA tools can easily produce on the order of thousands of alerts per day, increasing the risk that security teams miss the few vulnerabilities that actually matter most.
Kodem has a unique approach here in prioritizing packages that are reached in runtime environments, thus “shifting right” to highlight the most actionable vulnerabilities. Stacklok has taken an alternative approach by helping both sides of the open source ecosystem: end-users and maintainers. Their Trusty offering helps developers understand which packages are safest for use, while their Minder platform helps maintainers build packages that are more secure to begin with.
Container Security
As containers have become an increasingly important part of application architecture, so too have container-specific security measures. Containers often stem from base images, which are designed to store all of the dependencies required for developers to work on their services. Similar to SCA, these images and dependencies must be scanned for known vulnerabilities.
Chainguard is one of the many exciting breakout players here, having taken the approach of offering their own base image registry with dramatically fewer dependencies. The idea is that if you use fewer packages, there’s less that could go wrong to begin with. Slim.ai has taken a similar approach of “slimming” customers’ existing containers to only include what is needed.
Application Security Posture Management (ASPM)
ASPM is a categorically new type of platform that aims to deliver everything needed for an AppSec program in one place.
Increasingly, these products will offer their own proprietary AST-based scanners, or offer the flexibility of integrating with other SAST, SCA, and DAST tools. However, they expand on traditional code scanning techniques by also connecting to every part of the SDLC, from code to cloud: e.g. source repos (GitHub, Gitlab), build servers (Jenkins, CircleCI), artifact repositories (JFrog), and runtime environments (e.g. EKS). Given the full visibility of the application delivery process, these platforms can do things like measure SLSA compliance levels or trace vulnerabilities from runtime back to the source repo from which they came.
This market has seen explosive growth in terms of new company formation, buyer mindshare, and adoption. Companies like Ox Security, Cycode, Legit Security, Apiiro, and more have solidified this category in recent years as the primary response to the uptick in supply chain attacks.
Autonomous Product Security Engineering (APSE)
A bleeding edge trend in this market is the creation of AI-based agents that autonomously act as Product Security Engineers, essentially adding to the headcount of your team.
While ASPM envisions a world where Product Security teams interface with dashboards and alerts to make security decisions, new companies like Nullify and Amplify aim to make decisions and perform remediations autonomously. These AI agents gain context from your source repos and ticketing systems, allowing them to prioritize, select, and fix vulnerabilities on their own, just as any Product Security Engineer would.
What’s Next?
The market is certainly moving quickly, with adversaries and founders racing to see who can outpace and outwit the other. While this has accelerated the creation of new product types and categories, we believe that there are opportunities to build massive companies in all corners of the AppSec market – from iterating on established methods like SCA and SAST, to new ideas on what AppSec could be altogether. As more industries become software-driven, move to the cloud, and accumulate data for AI, we believe that AppSec will only grow in importance.
If you’re a founder building in this space, we’d love to chat. Feel free to drop me a note at shayan@scalevp.com.
