[0:00] Welcome to our next edition of Espressos and Endurance. My name is Melissa Goldberger, I’m the CMO here at OX Security, and I’m delighted to be sitting with Aaron Miller, our Solutions Engineer who handles our west coast region. Aaron, can you tell us a little about yourself? [0:33] Of course. I come to...
[0:00] Welcome to our next edition of Espressos and Endurance. My name is Melissa Goldberger, I’m the CMO here at OX Security, and I’m delighted to be sitting with Aaron Miller, our Solutions Engineer who handles our west coast region. Aaron, can you tell us a little about yourself?
[0:33] Of course. I come to OX via another API security provider named Salt, and prior to that I was at an open-source gateway called Kong, which is based on nginx. Before that I was running API programs as a director of API. So I know the space pretty well. I was mainly attracted to OX by the breadth and depth of the platform, and I really love working here.
[1:17] Let’s start with that, what are you drinking today?
[1:24] I’m kind of a coffee snob. My drink today is called Ethiopian Supernatural; it only comes out once a year, and this is the last of the run, so it’s pretty special.
[1:42] Unlike my Costco dark roast that I dilute with tons of ice. We have to get OX cups for these. Let’s dive in. Being newer to OX, what are you finding unique and special about the platform?
[2:24] It’s going really well. I ask this of prospects daily, and the consistent answer is the orchestration of all the security tools. What really drives that, I think, is the idea behind the PBOM. Let me show the product. PBOM is one of these frameworks; it’s obviously MITRE-like, that’s where the ampersand comes from, but it’s focused on the software supply chain. If you think about how an attacker might breach your defenses, they’re going to have to use one of these methods, and as you can see it’s very broad and also goes very deep, so a product built on this framework is naturally both. That’s what I hear from people: how can OX do it all? It’s not easy, but it’s what people need; they’re tired of point solutions.
[3:49] It’s funny, I was on the phone with one of our customers this morning, and he was so impressed by the breadth and depth, and how much polish there is for a younger solution. Over the last year OX has really enhanced its SCA tool as part of that ongoing Active ASPM platform. For us it’s part of that platform. How does it streamline the vulnerability management process, specifically compared to standalone tools that sometimes struggle linking the CVEs within a single package?
[4:47] I’ll share my screen. In OX, SCA is labeled open-source security, because to do software composition analysis you have to have access to the source code. I’ll dive straight into issues; you’ll notice a lot of issues here, and one of the things OX helps with is normalizing all of these so we can focus on SCA. I’ll choose a filter; it sorts by severity. There is a CVE associated with this particular Spring Boot library, but because this CVE might show up many times across all of your tools, OX correlates them together, and you can use this number as an indicator of how many times we’re doing that, a strength-of-signal. We’re using three primary factors to judge the overall severity: universally, the more red you see, the higher the severity score. We’re also correlating the SBOM info and doing an SBOM check; fortunately it’s using an approved license. If it weren’t approved, you’d see it flagged here; you and your policies have total control over which licenses are approved and unapproved, and I recommend you work with your legal team on that.
[7:33] There’s a lot to geek out on. Can you go deeper into the consolidated issue analysis, and how it transforms multiple vulnerabilities into a single actionable issue, aggregating across libraries for a more efficient root cause?
[8:12] Being OX, it goes really far, deep, and wide. I just refreshed because OX, being a SaaS service, is constantly adding features. One thing I’ll mention: for certain customers with very high security demands who are legally restricted from using SaaS services, we can offer this as a purely on-prem solution, so keep that in mind for government agencies. On consolidation: naturally we’re all used to running many tools, Checkmarx, Fortify, Black Duck, and others, which is great for full coverage, but it does get noisy. We help by letting you plug in your commercial tools that aren’t OX, or OX offers all these scans, 10 different scans across your platform, and then we de-duplicate, aggregate, and very importantly reprioritize based on those three factors: reachability, exploitability, and damage or blast area.
[10:02] I also want to note that the template I’m demoing is accessible to everyone: go to ox.security, there’s a free 14-day sign-up (you need a business address), and when prompted, you can connect your repo, which is super valuable, or just connect OX demo data to follow along.
[10:41] How many repos can you connect?
[10:44] In my demo I connect GitHub, GitLab, and Bitbucket; some customers have quite a few. You just select these parameters and you’re connected. And some customers just use ours: you can use OX’s own scans or connect all of yours. We even have a name for that, “OX in a box”: if I’m a newer company without a lot of legacy tools to support, but I still need this breadth and depth of coverage, simply deploying OX gets you all of that from a single vendor.
[11:40] To the audience, if you have questions at any time, drop them in the Q&A. Going into advanced dependency assessment: how do we differentiate between direct and indirect package dependencies, and what criteria do we use to evaluate reachability, exploitability, and potential damage?
[12:48] Let’s speak to specifics. Look for the dependency graph; this details very specifically what this looks like. Spring Boot itself is built on other dependencies, and there are indirect vulnerabilities associated with the Spring expression library, but keep in mind that the direct dependency is, from an attacker’s point of view, more attractive, because all they have to do is find a way to exploit it. Indirect dependencies are also exploitable, but research says it’s about 5% or less of attacks that actually make use of an indirect one. I’ll show the exhaustive view; there’s also a Tomcat vulnerability way down in the tertiary dependency. It’s valuable to understand this, because yes there’s a critical flaw in Tomcat, but because it’s buried three levels deep, you probably don’t want to drop everything and run to your dev team; that might be a waste of their time relative to fixing something higher up, like the Spring Boot starter web direct dependency.
[14:55] Do you hear feedback from developers about having that evidence and support, or is it more from the security team that it makes it easier to communicate and prioritize?
[15:50] Anytime you, as a security professional, can use a tool like OX to help you research a problem, you’ll maintain or raise your credibility with the developers you’re teaming with. Security is a team sport, and nobody wants to bench-warm or blow a play, so think about the value you’re adding. Let me show something I demo frequently: if you go into severity factors and search for “exploit,” I can show you whether the exploit is not applicable or applicable. We live in a noisy world, and a lot of things aren’t directly applicable; here OX determines there’s no active risk of an exploit for this CVE, meaning the library was imported, but the way your developers use it isn’t touching the vulnerable part of the package, so you won’t chase this as a critical finding, OX tells you to chase it as low and fix it eventually. That’s the work of our research team. Now the counter-example, where the exploit is applicable: this cryptography library is vulnerable, and OX can actually simulate a concrete exploit against your application; this is a statically linked copy of OpenSSL, so we give you details on why this finding is more serious.
[19:08] That’s great. There’s been a lot of chatter on LinkedIn that it’s beyond the CVE; CVEs aren’t necessarily the only indicator anymore. We have a question from Rodney: with all this contextual data, what methods would you use to provide it back to the development team for remediation, assuming they aren’t looking in OX directly?
[19:53] Let’s get this data back to the development team. One way is in the tool they’re most familiar with: just give them a pull request. This pull request would say, here’s a possible fix for the issue; open a PR, get a developer to review it, and if they accept it, the issue is fixed. The other way I’d recommend is building OX into a pipeline. OX can be integrated into your pipelines; in the pipeline settings you tell your tool how to integrate OX and set how you want OX to contribute. Let me show Bitbucket from the other side: there’s no OX dashboard involved, but if you don’t want your developers logging into OX, you can still get them the information that comes from OX right into their pipeline, via an integration between OX and your pipelines, in Bitbucket, GitHub Actions, or GitLab workflows, so they wouldn’t have to go into OX to see that information.
[22:28] That’s an aspect of the platform I hadn’t seen, the way you showed the connection. We talked about comprehensive issue management: how does linking SCA issues to the software bill of materials help assess compliance standards and package maintenance?
[23:14] SBOMs are hugely important and integrated into the platform, but they don’t begin and end at the SBOM; that’s just the software piece. There’s the entire pipeline piece, which is what we emphasize with PBOM. Let’s take this Pillow library. This is the SCA component of OX, and we tell you the SBOM checks we ran: red is bad, green is good; it’s using an approved license, it’s been relatively recently updated, and it’s a popular library with a lot of GitHub stars and forks, all health indicators, like a doctor running scans. We can check the SBOM info page too: how we’re using it, the copyright, all the metadata, linked back to this issue. The action here: the good thing is it’s still a popular library; if it were less popular I might be less inclined to upgrade. And if you upgrade it, we tell you that will resolve all the known vulnerabilities, killing all the birds with one stone.
[25:51] This was really great. The idea today was to go into this aspect of the capabilities. Aaron, anything you want to leave us with?
[26:08] We didn’t have time to cover one super cool thing a lot of people love about OX: workflows. Our mission at OX is to automate all aspects of AppSec, and this view goes a long way toward that. This is a no-code workflow where you drag and drop policies; it starts with a trigger action, then you add filters (everything color-coded yellow for the filter) and the action (in blue). For example, any container security policy: if there’s public internet exposure and a patchable type that is minor or patch, I can directly open a PR, because there’s no breaking API change in a minor patch. If it’s a major change, you know there will be a breaking API change, so I don’t have an open-PR step there; instead I open a ticket to Jira and Slack my security team. You can have a bunch of these running like little cron jobs, and that’s one less thing your security team has to tackle; you revise them as you find new issues. That’s a really healthy use of everybody’s time, to automate what we do.
[28:09] I’m glad you got the automation in, because that really is our mission: to automate your AppSec, or at least take those steps, and help you build scalable, secure development. Sorry for the technical difficulties today, but we got some really good content and excellent questions. For anybody not familiar with OX, visit ox.security; you can do a deeper demo through a product walkthrough or sign up for a free 14-day trial, connect your repos, and play with the platform, because it really is unique in that you can orchestrate everything, prioritize, and then build your remediation plan. Thanks again, Aaron, and to everyone who joined, thank you so much. Have a great day.
[29:20] Thanks everybody, bye.
