[0:42] Hello everyone, welcome to “ASPM Mastery: Securing AppSec Beyond the Basics.” Before we get started, a quick privacy notice: as this webinar may involve the sharing of sensitive information, we kindly ask all participants to respect the confidentiality of the information presented, and please do not record, distribute, or use any part of this...
[0:42] Hello everyone, welcome to “ASPM Mastery: Securing AppSec Beyond the Basics.” Before we get started, a quick privacy notice: as this webinar may involve the sharing of sensitive information, we kindly ask all participants to respect the confidentiality of the information presented, and please do not record, distribute, or use any part of this webinar without explicit permission from the organizers and presenters. Thank you all for joining. I do apologize in advance that Uttam was not able to join us today due to a personal circumstance at the last minute. So before we get into the topic, I’d like our panel to introduce themselves. Artem, would you start?
[2:04] Hi everybody, my name is Artem. I’ve been in the security field for more than 15 years, at least eight of them in the application and product security field. I’ve been in offensive and defensive roles, everything you might imagine, and currently I’m the head of product security at SOFTSWISS, and we have a very diverse portfolio of products to secure. I’m excited to be here today.
[2:42] Thank you very much, Artem. Colin, over to you.
[2:48] Hi, hello everyone, pleased to be here. I’m Colin Bell, based out of Ireland. I’m currently the CTO for the AppScan product, an application security testing tool, and I’ve actually been working with that tool since 2007. I worked for a while at IBM running our services team, so I’ve always been more customer-facing, but prior to that I was also a pentester and an application developer, so a lot of experience in this space.
[3:17] Fantastic, thank you, Colin. Maxim, over to you.
[3:24] Thanks, hello everyone. My name is Maxim, and I’m currently responsible for information security and business continuity at uklon, a software product company that creates a taxi service and delivery service based in Ukraine and located in other countries as well. I’ve been in the information security sphere for more than 13 years, and because we’re a product company, I’m eager to share our experience of how to make a product secure and stable.
[4:01] Great, thank you very much, Maxim. I’ll introduce myself quickly. My name is Boaz Barzel, I’m leading technology evangelism and directing enablement within OX Security, and I’m proud and excited to sit here with our panel. First, this is a question-friendly webinar, so put your questions in the Q&A throughout and we’ll address them. Before we get started, I want to talk about what it means to be a master in ASPM. When we want to take an organization’s AppSec maturity to the next level, we think about how what we do today will evolve, what the industry is doing, and what best practices, tools, and processes we can use. In this session we’ll talk about how we define ASPM mastery and what moving beyond the basics means, key considerations for scaling security and aligning it with business goals, future trends and innovations, and best practices, where our panelists will share their advice near the end. Let’s start with the current state. Artem, what are the most common challenges your team faces today, how are you trying to move beyond the basics, and how are you measuring that?
[6:33] There are several challenges, of course. One is scaling our practices. Another is evolving our practices so we have complete awareness of the applications we have: what we’re running, where we’re running it, what versions of what software, what services, which dependencies we have at each installation, and what our installation actually looks like from the attacker’s perspective. So for us the challenges and goals are building awareness of the attack surface, making sure everything is covered by our practices, both technical and process-based, and, maybe last but actually most important, having our development and engineering teams work in concert to deliver the most secure product. Those are the primary challenges, and I think we’re on our way to solving them. I’ll start generally, but we’ll probably drill into more technical detail during the webinar.
[8:49] Very good. You mentioned working together with development, which we’ll come back to. Maxim, what’s the role of automation and integration in advancing application security maturity at your organization?
[9:25] In my organization we currently have more than 130 internal products, because a taxi and delivery service is an ecosystem with a lot of internal projects. To manage and control the security and continuity of all of them isn’t easy, and without automation we’d need a dozen engineers just to control that scanners are implemented and run. So automation of searching for new products, setting up scans, launching them correctly, adding results to dashboards, creating tickets, and you can imagine across 130 projects how many tickets we have for found vulnerabilities, controlling the fixing of all of them, and re-scanning to confirm fixes are really implemented, all of this is majorly the responsibility of automation. Without automation and a complex ecosystem of security posture, it would be hard to manage. We don’t need one dedicated solution, we need an ecosystem for security management across all the internal applications we develop.
[11:38] That’s really interesting, and I like the use of “ecosystem”; we’re not looking at separate areas or projects anymore, we want to look at it holistically. Colin, from your experience, how has the shift from traditional application security practices to ASPM-related frameworks impacted overall risk management?
[12:13] That’s a good question. Fundamentally, ASPM provides a more integrated and continuous approach. For the past 10 years I’ve been pushing a position I call continuous security, which tries to expand beyond what DevSecOps introduced and make security everywhere in the life cycle. I’ve never been a fan of shift-left; I believe in shift everywhere. But a true continuous security model is based on really good governance, good standards, and strong audit, and to do that correctly you need really good metrics and visibility. That’s what ASPM is really providing: that central piece of visibility that helps a risk manager make good decisions. The key advantage is a centralized approach that enables the process to be more proactive than reactive. Security for the last 20-odd years has been very reactive, and now we’re trying to move toward proactive, continuous security, which really emphasizes a continuous-improvement mindset.
[13:59] I agree. So how do you ensure that scaling your AppSec practices doesn’t lead to a drop in the quality of the security outcome, since focusing on one area can mean missing others when you try to capture everything?
[14:42] It’s a tough thing, and a lot of organizations struggle with it. It probably starts from the top and works down. When scaling AppSec practices, it’s important to maintain high-quality outcomes, so start by automating tasks like vulnerability scanning, build things into your CI/CD pipeline in a way that doesn’t impact dramatically. But beyond that, something I’ve seen emerge in the last two years is getting better visibility on scoring and looking at risks, like exploit prediction scoring (EPSS), which is based on which vulnerabilities are most likely to be exploited, so I’m not reacting to everything, I’m making good judgments about what to fix. And probably the best practice to maintain quality is to develop a core group of security champions; you can’t emphasize enough how important that is, so the development team and security team work much closer together. Security driven by the development team on the development team’s mandate alone doesn’t work; it has to have those couplings.
[16:34] I second the shift-everywhere approach. On scaling practices without dropping quality, first we need to set realistic goals; as we build practices we don’t need to try to reach high maturity in each one immediately. There’s always the Pareto rule: you get quick wins for 20% of the effort. So plan your practices in advance, keep in mind you’ll probably be scaling them, and set realistic expectations for the initial implementation, technical or procedural. Once you’ve tested and proven a practice on a smaller scope, scale it horizontally; once you learn how it works across teams and projects, you can ask how to improve the quality of what it delivers. For example, we implemented a lot of tooling internally; my team has a passion for coding and securing things, so we started small with smaller coverage, tested, worked closely with engineering teams, and after some time, longer than if we’d pursued only quick wins, we came up with a solution that proved scalable in our enterprise. Now when a new project starts, we click a few boxes and it’s onboarded into our security practices. It doesn’t solve every problem, like the effort to review false positives or tune static-analysis rules, but it scales really well for us.
[19:36] That’s great to hear. Maxim, what strategies have you used to align the AppSec effort with the broader organization and the different teams you collaborate with?
[19:53] Our strategy wasn’t that different. We split all applications by teams, because different applications depend on different fields of our product and different technologies, then created a schedule for adding those products into our security process. The first step was an audit of the system, defining breaches and issues and setting all required scans and security measures. We tried to do it every month, a new system or project each month, and because we have 10 teams, the complete setup of security posture management for all applications took a bit less than a year. The main issue with implementation was the shadow of running: teams work by sprint progress, so you find a vulnerability in an application and then you need to verify it was fixed before release, because if it’s not fixed before release it goes to production, and then it’s much more expensive and effortful to fix. So if product teams work bi-weekly, we should implement the same checks on a bi-weekly process. We scanned products bi-weekly and added every new product monthly, and that’s how we managed to add all our applications and products.
[22:43] I love that. The Holy Grail with scaling and quality is the ability to give the developer the vulnerability at the time they’re developing, before it goes to testing, staging, or production. It’s difficult and really hard. From an effectiveness standpoint, Maxim, what are examples of KPIs you measure?
[23:37] The main KPI for now is the amount of vulnerabilities not closed by the end of the sprint; the ideal is zero. From another point of view, vulnerabilities have different scales, critical, high, medium, low, by CVSS score. We agreed that high and critical vulnerabilities should not appear in re-scan results, meaning a found vulnerability should not be repeated during a re-scan. Medium vulnerabilities can survive one or two re-scans, and low vulnerabilities, I’ll be honest, we’re not counting them for now, because we started this process in September 2023, a year ago, and we’re still improving. So our KPI is the number of vulnerabilities overall and the number carried over from previous periods, which should be zero, because it’s normal to find new vulnerabilities, but not normal to have the same vulnerabilities from previous periods.
[25:26] I like that, focusing on the amount we were not able to fix instead of the amount we fixed, which gives another layer of risk management: is a vulnerability critical or not, can an attacker reach it, can they exploit it, what’s the business impact. Artem, I promised you’d talk about collaboration. How do you keep development and security teams in sync while scaling AppSec initiatives?
[26:38] First, we approach our work the same way the engineering teams in our company do: we develop our tool chains as an internal product with release cycles and change logs. We’re always in touch with our developers. We have certain mandatory steps where we interact in the development process, but we always encourage teams to come by and ask anything if they have doubts. We also introduced gamification and education: we developed an internal knowledge base about our tool chains, how to use them properly, where to ask questions, and it also covers coding, application security topics, and attack scenarios specific to our field. On gamification, a good practice we have, and will repeat, is conducting internal capture-the-flag competitions aimed at technically savvy people. The feedback I receive is “wow, I didn’t know the code I wrote could be exploitable the way you showed us,” or “now I have hands-on experience bypassing browser security mechanisms.” So it’s a holistic approach: we have formal, mandatory interactions with engineering, informal connections, and we approach our internal tools as services that we advertise and sometimes sell to the teams, because they’re quite independent with diverse tech. We try to make people want to use our security services, not make it mandatory.
[29:31] Very good. I like the gamification part; I’ve heard it from a lot of companies introducing leaderboards and small competitions with prizes, scoring development teams on several metrics. I’ve heard from customers that teams were working toward the weekend just to move from C to B or B to A and be on top. So I really like the gaming experience you’ve introduced; it’s important for getting developers more involved. Let’s take another aspect of ASPM. Through your personal views, what trends are you excited about, coming from the application security space but especially around ASPM, that take it beyond the basics? Maxim, let’s start with you.
[31:30] From my point of view, the future of application security is the creation of an ecosystem: from coding, integration with code repositories, with systems for code development, with service-desk systems, with metrics and reporting and analysis systems, to create one ecosystem for finding, scanning, and providing issues in the most common way for developers, whether that’s GitHub issues or service-desk tickets, and for management with reporting and dashboards. It should be a centralized solution for the whole pack of information security and application security controlling. I also strongly believe AI will take part in the application security process, because the time for unique developers and engineers, I believe, is gone; AI will be part of analyzing products and analyzing vulnerabilities.
[33:34] I agree, there’s no way around it today, everybody’s talking about AI, and if you use it the right way, ensuring the data you ingest is clean and your prompts are good and you validate the answers, there’s a lot we can do with it, in the front end or back end. I do think we’re still a bit far from seeing the full power of AI, but it’s definitely an advisory tool we can use today to understand our data and our application security program better. Colin, what trends do you see today, coming from the AppScan side?
[34:38] It’s very different when you’re providing software for this purpose. On AI, you honestly can’t avoid it. One thing we’re noticing is a lot of use of AI to help with writing code and writing remediation, but the caveat is it’s only as good as what goes into it. We see a lot of cases where “the AI wrote the code, therefore it’s good,” and that’s often not the case, because it’s not quite there yet, it may be writing just as bad code as you would yourself, though maybe quicker, which might make you more efficient. From our perspective we’re looking at AI for detecting vulnerabilities, for giving really accurate contextual remediation advice right at the point someone’s writing the code, just-in-time advice and training. Beyond AI, because you can get bogged down with it, there’s a lot more around continuous security and continuous improvement, and ASPM brings the ability to do that effectively. For example, if you have an application being attacked at the perimeter and you can see information on the SIEM, now you have an opportunity to go back to your threat modeling, update your threat model, your security practices, or your guidelines. That dials into the continuous security model, and it’s only possible by bringing the information to a central point for that level of visibility. It’s not just a case of the pentest team does that; the pentest team now needs to see what’s happened as it was developed all the way through the life cycle, so they can make more accurate testing. There’s a lot of emphasis now on continuous improvement: security is not just something the security team does, it’s something everyone does.
[38:17] I agree, AI writing less qualitative code faster. We used to joke about copy-pasting from Stack Overflow; well, AI learned from Stack Overflow, so you’re coding faster but still making the same mistakes, at a larger scale. Artem, from your perspective, which innovations and tools will have the biggest impact on reducing risk? Bear in mind we just said AI writes code faster, so we expect more vulnerabilities.
[39:07] I have personal favorites. The first makes the life of an application security engineer easier; Colin mentioned EPSS, and some vendors are doing private research in this area, like exploitability and reachability scoring. Everything that helps reduce the noise-to-signal ratio is great, so when Dependency-Track added EPSS into their flagship product, which is open source, a lot of people, myself included, were happy. Another important trend is improvement in attack-surface management, discovery, and observability, because it’s really challenging to know what you’re running, where, and with what configuration. I have an example: I worked at a company that was extremely mature at managing its assets, very strict about deployment and configuration, with a dashboard of every piece of code running and reporting to us. But one day a bug-bounty submission came in with a critical Log4j issue, and we thought “no way, we cleared this completely from our infrastructure months ago,” but there it was, sitting on some box with manually adjusted parameters made during an incident that everybody forgot about. It wasn’t easily discoverable; the researcher applied some pentester magic to find that endpoint. So in that situation, major processes failed us, and I think having a really good attack-surface management and observability tool chain is of extreme importance.
[41:53] I agree. If you’re trying to elevate your AppSec program through ASPM, you look at comprehensive visibility, not just points around the pipeline but everything: your software supply chain, the collaboration aspect, connecting your right hand with your left hand because until now they’re doing different things. As we scale and try to keep quality without dropping all the workflows, automating triage and analysis becomes more critical, because code is written faster and we’ll see more vulnerabilities since quality didn’t rise. So we need to take everything we do today, not be bound by technology, and expand it to the entire pipeline, the ASPM approach. With that, I’d like your advice for our audience. Please add your questions in the Q&A or chat. Colin, what’s your advice to people watching today?
[44:27] It probably depends where you are on your journey. Having seen lots of organizations succeed with application security, one of the biggest advantages comes from building a program that envelops security champions and really good security awareness training all the way through. If you’re starting a security program, look at the separation of security from the development team and make it an independent thing, because for continuous security you need governance and audit, and someone in a position to make those decisions. That’s probably the biggest advice.
[45:24] Very good. Maxim, what’s your advice?
[45:30] Don’t try to be the opposite of development. Don’t just force them to fix your found vulnerabilities; understand that the primary goal of development is to create business function. Be more respectful of them, don’t push them to fix vulnerabilities at the moment of release, find issues as early as you can, and then increase the importance of fixing them during development, before the sprint ends. It will be easier for them, easier for you, and your product will be much more secure.
[46:39] Very good advice, and I agree with the collaboration aspect; it’s what makes AppSec unique, because as a security practitioner you discover the problem, analyze it, and then send it back to development to fix. Artem, what’s your advice?
[47:03] Depending on your current level, always have realistic expectations and goals for improving and scaling your practices. It doesn’t make sense to implement security scanning for thousands of projects and find out nobody’s looking at the results. The best approach is to start small and scale when you’re ready. And I’ll support Maxim and Colin: you have to be part of the organization, not a source of annoyance for developers and engineers. It’s always best when people understand why they’re even doing security and how to do it, and see you as their best friend.
[48:13] That’s really good. What I’ve seen also helps is providing confidence in the results. A good next step for security teams is the ability to provide a level of trust and confidence in what they share with developers, so when they come to developers, the developers understand the security team did their work, the reachability and exploitability analysis, this is a true positive, not a false positive, and it’s already consolidated. So instead of getting them to work hard fixing vulnerabilities, we want them to focus on a more holistic security issue, helping them fix less and solve more. I see we have questions from the audience. The question is: do you think there’s a difference in fixing alerts produced by dependency scanners, code scanning tools, runtime security scanners, web application security, cloud posture, and so on? What tools are the most critical and should be prioritized?
[50:07] I would say we’re also controlling update management, meaning all elements of our internal infrastructure should be on the latest long-term support (LTS) versions, and all those scanner findings are presented in one flow to developers to fix. On prioritization, the prioritized things for us are vulnerabilities found, or that can be found, by external sites, meaning an external hacker may attack or break our applications. Everything found internally we handle with a CVSS approach, providing urgency for development and DevOps teams. I can’t say dependency is more important than web application, or update is less important than vulnerability-scanner results; it’s all important. I believe the correct question isn’t which scanner is most important, but which attack surface is most important: external attacks are most important, because an external party can hack you, and internal features can be handled after.
[52:09] Something I’d add: we offer four capabilities, dynamic analysis, static analysis, SCA, and IAST, and all of those get findings from different parts of the system. Through machine learning and analytics, we provide correlation of results: here’s your static result, this is what it looks like dynamically, this is what it looks like on IAST, and better still, here’s a fixed group and the point in code where you need to fix it. It’s about making that information much more manageable, which is what ASPM should help provide. So whoever asked that question, you probably are running all these things, but bring that to a central point and get analytics on it, and you’ll get a much richer level of information.
[53:18] Exactly. What you explained around prioritization is really important, and it touches the reachability discussions happening in the market today, because the sheer amount of security issues from all those tools ends up at: can an attacker reach it, can an attacker use that vulnerability to damage my applications? That’s a really interesting point. I see we have no more questions, so before we conclude, anything you’d like to add, Artem, Maxim, Colin?
[54:23] No? We’re on time, that’s fantastic. First, I’d like to thank everyone in our audience who’s been watching, it was a wonderful discussion with a lot of good insights, and it’s great to talk about application security and ASPM with you. Thank you again, Artem, Maxim, and Colin, for joining us. This will be recorded and shared later. Thank you very much, and thank you all.
