[0:00] Good afternoon or morning, everyone. My name is Melissa Goldberger, I’m the CMO here at OX Security, and I’m excited to introduce a new series called Espressos and Endurance. Today we have an amazing guest speaker, James Berthoty, from PagerDuty, for an informal chat about the realities of ASPM. No slides today, just James...
[0:00] Good afternoon or morning, everyone. My name is Melissa Goldberger, I’m the CMO here at OX Security, and I’m excited to introduce a new series called Espressos and Endurance. Today we have an amazing guest speaker, James Berthoty, from PagerDuty, for an informal chat about the realities of ASPM. No slides today, just James and me talking, and we want the audience to ask questions. James, give us a bit of background about yourself.
[1:07] Thank you, I appreciate being here. I love talking about ASPM because I disagree with Gartner and the prevailing definition, so it gives me an amazing starting place to drop hot takes all day. My background is more DevOps and systems into security, primarily startups to SMB with some light enterprise. I don’t come at this from the traditional “I am an AppSec engineer at Microsoft” lens; I’m very much focused on getting results done with small teams, in the midst of DevOps chaos, and turning all these buzzwords, acronyms, and features into actual more security, which is the missing piece of most of this.
[2:09] So more buzzwords doesn’t equal better security. It’s more fun, at least. My favorite of these acronyms is X, because you’ve got the X-bomb, you’ve got XDR, and it goes back to the 90s “extreme” days when everything got cooler with an X in front of it.
[2:52] Before we dive in, I noticed there’s no coffee, what’s your drink of choice?
[3:03] I turned on my tea brewer; I’m a bit of a tea person lately, and I bought a banana-nut-muffin tea that’s been fun. Mine is busted coffee in a Dollar Tree cup with ice, from Costco this week. Let’s dive in. We talked a lot about acronyms; how do you define ASPM?
[3:46] My first exposure to ASPM was at one of the OWASP conferences, seeing vendors I knew as SCA vendors or SAST scanners suddenly marketing as ASPM. Then talking to older AppSec players like ArmorCode or Phoenix Security, who’ve been focused on ASOC, the original Gartner acronym I didn’t know existed, a specifically enterprise problem of “we have too many application security tools, how do we orchestrate them into a dashboard.” In my career I never came across that, because I was never at an enterprise where half a business unit used one SCA tool and others used another. The goal I’ve always had is, what can I do to actually make my application more secure with a single tool? As that enterprise market moves downstream, that’s a lot of what’s happening, but also this all-in-one idea didn’t exist before; there were point vendors, Snyk being the first in my mind to branch into multiple tools, that started the ball rolling on the all-in-one scanner. ASPM in my mind is a continuation: not just orchestrating tools into a dashboard, because to me that’s just vulnerability management. What makes ASPM stand out is it’s directly allegorical to CSPM, where the best CSPM players didn’t just orchestrate open-source scanners into a dashboard; they added their own value to make the results meaningful with their own data. So an ASPM tool, to me, is one where I can say I bought this one tool and therefore my application is more secure, as opposed to the point solution where I want the best SCA scanner, the best SAST scanner, the best container scanner; it’s an attempt to put all of those into one place.
[6:57] What’s working in the ASPM market right now, what’s not, and are there more posture-management categories coming, like supply chain security?
[7:26] Everyone has the same problem: too many meaningless vulnerabilities, and there are a million approaches to that, which is why there are so many solutions. It’s hard to decide whether to buy the best internet-reachability tool, the best function-reachability tool, or the best runtime-reachability tool; it’s hard to tell what takes out the most noise by itself. What’s working on the prioritization side is incorporating multiple of those ideas into a single platform, and OX is a good example: when I met OX I tried to grill them on what they don’t do, and the answer was that every piece is technically in there, function-level reachability, code fixes, runtime context, code-to-cloud context, and all of that data together creates the actual prioritization. But more importantly, your actual time as a developer isn’t spent prioritizing alerts, it’s trying to fix the alert, and that’s where you need the most context in the tool. Whoever is focusing on that problem, whether they market as vuln-remediation, ASPM, or code fixers, is being the most successful, whereas everything chasing the prioritization game gets lost in the haziness of “is this prioritization filter better than that one.”
[9:41] It’s funny, I came from the other side, MAST and SAST, and we touted prioritization too, but it’s the why, it’s about context. Where do you see current use cases and where is ASPM heading, and why would I use one?
[10:20] The ultimate use case is you’re tired of not making progress getting things fixed with application security scanners. In the early days, when we started putting them into pipelines instead of waterfall quarterly scans, people had this idea of “stop the bleeding.” But most vulnerabilities don’t arise from stop-the-bleeding approaches; that’s true within SAST, but within SCA and container vulnerabilities, those come up over time. No developer intentionally picks a ten-year-old unsupported library; things get old, and vulnerabilities are discovered over time. So the reality of alerts only going up is because your older packages get more vulnerabilities discovered, and you never go back to fix them, as tech debt. The ASPM goal is to create workflows that get findings to developers in a way they’ll actually fix, and right now people are experimenting with a lot of ways: no-code drag-and-drop workflows, GitHub-based workflows, Slack-bot workflows.
[12:16] There’s a lot of talk about automated remediation. Do you think users will get comfortable with it?
[12:33] Automated remediation, in the way we’ve been talking about it, with any existing provider, is never going to work, because it’s of zero help. A lot of tools that do auto-PRs are just raising a pull request that changes a version number from one to two, and if you push that through you’ll guaranteed break your application, because you have to read the changelog, figure out what changed, and then do the updating. That’s why the code-fixers all focus on SAST, because you can really only have an automated PR work with SAST alerts, like fixing a SQL injection by parameterizing the query. The second you talk about major framework updates, the number of providers that can even theoretically do it shrinks. There are promising approaches, Chainguard with container vulnerabilities, Seal Security just came out of stealth for SCA, where you change your version from the open-source version to their version, but even these have difficulties, because you’re breaking the dependency chain in a different way and trading one complexity for another. You’re trusting Chainguard to keep their images as updated as the open-source community and to be functionally the same. There are also providers like Grit that take a more holistic migration approach, “we’ll help you migrate from version one to two and change all your functions,” but that has its own complexity. So “we’re going to fix these vulnerabilities with a pull request” is not what’s going to happen.
[15:28] One nice thing, going back to context: some automation is at least automating the prioritization and where to focus. So maybe light automation in some areas.
[15:47] Workflow automation is totally possible, getting the right alerts to the right people at the right time, whether it’s OX’s workflow building or Slack workflows. I was explicitly talking about relying on a system to automatically remediate the thing.
[16:26] Exactly, I was keeping it bigger and bringing it back down. Let’s talk about your vendor-neutral site, Latio, and what users should look for when choosing an ASPM vendor.
[17:14] Let me share my screen. The reason I split things up this way: ASPM providers all hit vaguely similar checkboxes, and where it gets weird is, you’d assume everyone does container vulnerability scanning, but that’s where some of this splits apart. OX is one of the only ones, OX and Aikido, off the top of my head, that include CSPM scanning as part of the ASPM solution, whereas some others don’t. So first, get a clear vision of which pieces of application security you really care about, because some ASPM provider might just not have a solution for it. The other big decision is whether you want someone like OX, or more like the remediation platforms that don’t have any of their own scanning; they purely orchestrate other people’s stuff. The visual I usually show that people are trying to get toward is from OX, where it shows this application is deployed using this GitHub Action to this registry, deployed by this YAML file, and these resources are running in Kubernetes as a result. Not many tools that also provide their own scanners do this; it’s the hardest technical challenge but the most essential information for showing the application’s context. When I get an alert like “this Kubernetes container should not explicitly allow elevation of privileges,” I can’t know the actual risk unless I know where it’s running, if it’s running at all, what repo to change, and whether anything upstream is altering the deployment. So at a high level, understanding the capabilities of building that graph is one half of what I look for, and the other half is understanding what the capabilities are if I use, say, OX’s SAST tool by itself, going through each category to understand where I’m gapped from a visibility perspective and a functionality perspective.
[22:07] I’ve got you on the record, so, vendor neutrality aside, what else do you like about OX?
[22:26] The two vendors I love putting head-to-head are OX and Arnica, and I don’t know which approach I appreciate more. Arnica’s approach is “we’re going to give you the best SCA, SAST, and IaC scanning workflow, and that’s it.” I appreciate that vision, but OX has the smooth pitch of “I can integrate with anyone I want, and if I don’t have something, I can just use OX’s, and OX’s is probably as good if not better.” Either you provide the best point solutions in each category and end up alienating people who need to integrate something, or with OX there’s no compromise: workflow building, all the kinds of reachability, prioritization. On a feature sheet, there’s no other even-close competition; people compete on different pieces, but holistically, the all-in-one scanners don’t have function-level reachability, attack-path visualization, asset inventory, and no-code workflows; you’d go to different vendors for each. That vision is what makes OX stand out, the same way Wiz stands out in CSPM, a no-compromise, flexible platform that does as much as humanly possible with the visibility it has.
[25:14] You just wrote my website copy. Say you’ve selected OX or another vendor, what are some tips to endure an ASPM implementation?
[25:53] I love this question because I forget about it, since I talk to cool startups all day and forget the misery people are going through on legacy providers. The single biggest thing to consider is what you call “pipeline-less,” which is a bit of a misnomer because it still runs in a pipeline, but you don’t have to host and maintain your own Docker image; it’s web-hook-based scanning. If you don’t use that, you’re going to dedicate at least one person’s job to maintaining the agent you run in your pipeline, its own patches, its own vulnerability scanning. Web-hook-based scanning is the line for me on whether I’d even consider a tool. Beyond that, a lot of AppSec tools have turned into a Frankenstein monster; download the CLI and see how painful it is to use. The example I think of is SCA scanning the manifest files versus the compiled binary; manifest scanning is faster, surfaces results more cleanly, and builds the dependency tree better, while binary scanning catches more context and fewer false negatives. So think about which you want for different audiences. I think it’s important to have both: security people need the in-depth reporting to query across the whole codebase when a specific package demands an immediate response, while manifest-based scanning is good for quick PRs for developers. So have a layer of flexibility, where the scanner isn’t built on some weird technology that requires very specific implementations.
[29:19] We’re seeing a lot around compliance. How does ASPM address different business sizes and their compliance needs?
[29:58] It’s a deep question. A bit of my background is in the SOC 2 automation space, so I know what you need from an AppSec perspective to get through a SOC 2, where you define your own controls aligned to the trust criteria, so you can be vague, “we require reviews” can be enough, doing branch-protection and SDLC configuration. But as you scale into more serious frameworks, you need to show dedicated scanning. A lot of compliance frameworks are lagging on application security; many requirements are still around DAST as the primary report, though that’s changing quickly. The main thing is to be flexible as the need comes up, otherwise you end up buying the best point-solution container scanner, then the best SCA scanner, then the best SAST scanner, reactively chasing compliance requirements, as opposed to moving to a holistic ASPM where you can tell the auditor “we use OX for all our scanning,” without bringing up that this pipeline runs Semgrep and that one runs another tool, because OX is the orchestration and fallback layer. And on the ASPM front, the vuln-management ASPMs that don’t provide their own scanner only work for enterprises; if you don’t have other tools, the tool has zero value. So scaling with a flexible platform that has its own scanning makes more sense from a compliance perspective.
[33:08] We have questions. First: can you share a real-world example of using a security tool to save the day and get kudos from devs and execs?
[33:35] I have a blog post with Sysdig called “runtime is the way” because of this. A lot of hype is around static scanning, but a critical SAST finding in pipeline isn’t going to save you after the fact, because you’ve already deployed and you’re trusting whether it’s exploited, which you only know from your SIEM logic or RASP-type rules. I hate using this example because it’s so common, but Log4j was when SCA scanners got to shine, one of the few moments where you need to quickly do a comprehensive scan across your environment for a particular package, see how it’s used, and prioritize patching. The other soapbox: it’s popular to say DAST is dead, but every actual vulnerability I’ve found from a security scanner has been from a DAST scanner, because it shows the runtime. If you don’t do cookie validation, that’s a theoretical finding in a lot of tools, and a lot of SAST providers aren’t crossing from service to service to check the validation token; your auth provider is probably a different service, so how are you doing your JWT validation or checking permissions? Those business-logic outcomes are what static testers don’t look for because they’re not pretending to be users. DAST finds really obvious things, non-public endpoints, things with no authentication, those save-your-day stories, combined with the network-runtime side, traffic from a pod to a known threat-actor IP, a web process opening a shell process. Those runtime alerts I associate with security alerting, because runtime exists for security, but in ASPM the end user is the developer, and security exists to facilitate that with secure design, implementation, and testing, not to get an alert and spend a quarter figuring out a service you’ve never seen, instead of sending the alert to the developer.
[37:08] I love the soapbox, that’s why we asked you here. Next question: what aspect of tooling do you think ASPM providers will build next and where do you see the most innovation?
[38:40] Everyone’s working on the wrong stuff, because they talk to too many security people. If you listen to me complain about vuln management, I’ll say I want better prioritization, better false-positive detection, better dashboarding for executive buy-in, ancillary things. But there are only so many vulnerabilities, because fixing them is so hard and time-consuming, so the focus needs to be on auto-patching (what people are hyped about with GenAI, 50/50 hype versus reality) or the quality of the actual alert and what it tells the developer about how to fix it. I’ve told vendors, if you do this you’ll win the market and I’ll buy your tool instantly, and they still don’t, because it’s hard: I want a map of the transitive dependency tree that tells me, is this a vendor dependency (I’m using this version of the Datadog agent and need to bump it) or am I directly using it some other way, mostly on the container side, and people don’t want to build that complicated logic. That’s where the actual opportunity is: making it easier to fix things, not just squishing the priority box. The problem is they’re all doing SAST right now, “this company uses LLMs to autofix your SAST findings,” with no real differentiator. The differentiation will be people like Seal bringing it into other areas, using GenAI to auto-patch Terraform, containers, and so on, and theoretically, way in the future, one tool that auto-remediates all these findings, but that’s a pipe dream at the moment.
[41:21] Another question: would it ever be possible to combine auto-remediation with blue-green deployments to automatically test if a fix would work?
[41:47] Theoretically possible, but most companies don’t have good enough blue-green deployments to test their own changes, never mind another company’s pull request. And the major framework updates, how do you blue-green test migrating from Spring 4 to Spring 5, which fundamentally changes so much of your app, especially across multiple services? There’s a reason people generally haven’t done it; it’s too complex for big framework updates. That’s why what Seal and Chainguard do, back-porting the patches for you, is a more sensible approach, because you don’t have to blue-green test, they’re theoretically doing that for you, with a big asterisk on “theoretically.”
[43:12] I love when the time flies. Any final words on ASPM?
[43:39] I’m curious, and you can message me on LinkedIn: the quote that goes around about hesitancy to switch vendors is “you never get fired for choosing IBM,” but cyber security might be different, because the field moves so quickly that you’re actually less secure sticking with some of the older, bigger providers. So I’m curious how people deal with risk acceptance around vendor switching, because I’d love a world where I don’t care which modern ASPM you pick, I just want everyone using one, because it’s so much better than the alternatives. People are hesitant to switch, but once you make the cut to pipeline-less scanning, it’s pretty easy to swap vendors in and out without much pain.
[44:53] If anyone wants to share thoughts in the chat, great, or connect with James on LinkedIn. I can relate, even in marketing: every time I’ve switched products it’s been an improvement, even when I’d chosen a bad product, we switched off it the next year and it was better than before. James, I so appreciate you joining us. For listeners, we hope you can join us March 7th for OX Unfiltered, “Bridging the Gap: Uniting Development and Security,” more of a panel. Thank you so much, James, and I’ll find you the best tea possible to send. Thanks everyone for joining, have a great day.
[47:00] Thanks, bye.
