[0:00] Before we begin, a quick privacy notice: since this webinar may involve sharing sensitive information, we ask all participants to respect the confidentiality of what is presented, and not to distribute or use any part of the webinar without explicit permission from the organizers and presenters. Okay, just so we are all clear. So...
[0:00] Before we begin, a quick privacy notice: since this webinar may involve sharing sensitive information, we ask all participants to respect the confidentiality of what is presented, and not to distribute or use any part of the webinar without explicit permission from the organizers and presenters. Okay, just so we are all clear. So first, hello everyone. My name is Boaz Barzel and I’m the field CTO at OX Security. Today we are going to talk about one of the biggest challenges in the development world: on one hand, how we keep our teams working fast and efficiently, while on the other hand managing open-source risks effectively. We have a panel of experts and good friends from the industry who bring a lot of experience and insight.
[1:22] I’ll start by saying that we live in a world where open source is not just a competitive advantage that lets us deliver capabilities quickly and reduce time to market, it’s part of our DNA. It’s everywhere. It helps us integrate new technologies fast, build more complex systems more quickly, and at a lower actual cost. But on the other hand, it also brings a lot of security risks and vulnerabilities that can ultimately affect the speed at which I release my applications. And in all this dynamism, with open source on one side, the cloud on another, and developers who want to ship code, who need tools and copy-paste from place to place, there are processes and strategies that let us move fast. If I deploy in the cloud and use serverless, I don’t even need to set up a server. The goal in the end is not only to detect that I have a problem and understand my risk, but also to understand how I solve it without significantly slowing development. So after that short introduction, I’d like to invite our speakers to introduce themselves, starting with Shely.
[2:51] Hello everyone, I’m Shely Brownstein. I’ve spent 20 years in information systems and cyber, 13 of them as a CISO at financial institutions. I’m very glad to take part here, to contribute some of my knowledge and experience, and of course to hear from the colleagues here.
[3:19] Thank you, Shely. Over to you, Dan.
[3:24] Hello everyone. As Boaz said, my name is Dan, I’m the CISO of XM Cyber. For those who know it, XM Cyber is a product company specializing in continuous threat exposure management, another Gartner term. I’ve been at the company almost five years, four of them as CISO. Before that I spent six years at Check Point in several roles, mainly in technical support and customer management. The CISO role at XM combines many pillars, as a natural result of how our company is built, which isn’t necessarily the classic CISO role. The department is made up of several core teams: a SOC team responsible for monitoring, response, forensics, employee awareness, intelligence, and incident handling; a GRC team for regulation, risk management, process enforcement, and privacy, GDPR and so on; and an InfoSec team made up of analysts and DevSecOps developers responsible for consuming and producing insights from the various tools, remediation, and of course product security, including secure development, developer requirements, and specifically the whole open-source world, which we’ll expand on, exactly today’s topic.
[5:35] Wonderful, thank you Dan. And Eran, your turn.
[5:38] Hello everyone. I joined three months ago as director of engineering on the Nexi product at Cognyte. We work in the world of decision intelligence. Over the years I’ve spent more than 20 years in development, in all kinds of hats, from hands-on to managing development in various constellations. What’s nice about this kind of webinar is that maybe I can add a perspective from the development world too, and how things ultimately integrate together with security, which is always a kind of tension that usually exists.
[6:16] Right. That’s exactly why you’re here, to create some tension. Okay, this is great. First, thank you all for being here. Let me lay out the agenda. First, we’ll talk about how to identify and understand the risks in all the open-source components, because when I bring in an open-source component, I don’t necessarily know what’s inside it, and I need to understand that. Second, how do I create productivity while managing and significantly reducing risk, while still letting my business work and grow. Third, how we integrate security into the development process. We’ll see different angles and incidents and hear from the panel’s experience. And I’d like to start with a question, maybe to you, Dan: dealing with a situation where I have a dependency on an open-source component, and it’s discovered only after the product has gone to production. What does that mean, and how do I handle it from your side?
[7:55] First, you can split this into two parts. Even if you did work on the library and put it into production, that doesn’t mean a vulnerability won’t come out later, like Log4Shell or Spring4Shell. Those were things we had to respond to very quickly to reduce risk, both for customers and internally. What we did at our company is develop what we called a hotfix policy: a process we activate only when a truly critical vulnerability comes out, one with special characteristics, an exploit in the wild, a high CVSS score, and a very significant impact. We have a rapid triage process: where are the vulnerabilities, are customers vulnerable, and we run a fast mitigation. There are automations we integrate, like automatic scripts that alert us if there’s a POC for a given vulnerability in the wild. We collect intelligence from open OSINT sources, various feeds we maintain, and also from more advanced tools that pull from less visible places like the dark web and various Telegram channels, and of course third-party firms. But the most important thing is to understand whether there’s a POC in the wild and what the impact is on your customers.
[9:59] And from your side, Eran, how do you see it, how do you handle it from the development side?
[10:13] In most cases, as you mentioned at the start, the environments are very dynamic. We’re constantly releasing versions to production, often several versions a day, across many services. It’s a very living, breathing process. So the challenge is usually to understand, because it’s very hard to know in the end what’s exposed, what API is exposed, what stays internal, how the services communicate with each other. And most of the time it’s about understanding it, first doing that mitigation, and then, once you’ve done the mitigation, how do you push the update into production as fast as possible without harming the service. It depends on the type of update, and every time you push an update, with dependencies that sit on other dependencies, it’s very hard to know whether they’ve fixed it. There’s a real challenge there.
[11:20] That brings me to the next point, this dependency between components. You raised an interesting point, for example: we check one component that looks safe, but when I look more broadly I see it relies on other components, and together I realize there’s something bigger here. Shely, how do you see these challenges, looking at components that have dependencies, or different incidents where there’s some security dependency between them, how do we look at this more holistically?
[11:59] The whole dependency world is really very complex, as Eran said. It’s very hard to constantly close the gap. We don’t always know exactly which dependency affects what, or whether it needs updating right now. What we need to focus on is processes, as orderly a pipeline as possible, with automated steps in the middle that constantly scan our packages. That puts us into a kind of cycle. We obviously can’t always update everything; it’s all a matter of risk management. We need to genuinely examine each CVE and CVSS for how exploitable it is, whether it really poses an immediate risk. Unfortunately, many times we defer handling something because right now it doesn’t pose a risk, and we leave it for the next version. It’s a very dynamic, complex world. I hope we come out with very good answers at the end of this panel.
[13:10] I’m not sure we’ll come out with answers, but we’ll definitely come out with very good insights. I want to talk about the fact that we don’t fix everything. At the end of the day, we see that usually we prioritize release speed and our need to ship against the risk, and we do this risk management. Eran, how do you experience this management from your side, where you might be perceived, not always, as coming from a place of “I don’t have time to fix all this mess you sent me, let me ship, we’ll deal with it later.” How do you see it, and how do you manage these risks together with security?
[14:20] Many times, as a company or organization building a product, you don’t start with automation from day one. It’s a process that gets built. DevOps starts inserting all the processes into the release cycle. Suddenly we add another product that lets us do another check. Precisely because of this, you end up in a situation where the gap is by design. You always have this gap, and you constantly have to chase it: how do I reduce it now? And usually, to reduce it further, you need to do some compliance, and then you go even deeper into it. So it’s a very cyclical process that constantly feeds itself. The main thing that helped us was introducing automated processes as part of the release cycle. From the moment I write the code, and today it’s becoming much more complicated with all the GenAI and the copilots, which is another challenge we may discuss later, from the moment I write the code until I ship it and then add more fixes, these are complex, long processes, and you constantly need to do that tuning between the real business needs, protecting our customers and their data, maintaining our quality, and compliance and still being okay with all the challenges.
[16:18] I’d argue we very much need to adopt the shift-left approach, even though yesterday I heard a “back to the right” message, Eran. But I still strongly believe in shift-left, giving developers the ability to scan their code in real time, to find vulnerabilities before deployment, and to bring them into our processes from the start, knowing it also shortens their path later. We always talk about risk management: if I don’t update that vulnerable package, that dependency I found, then tomorrow or in a month when we decide we must update it, the work will be much bigger, and it gets stuck behind the other targets it still has, which keep piling up. So it’s a bit like a bone in the throat, you need to release it now so everything flows, and we won’t have to deal with the past. That’s the secret: processes as smooth as possible. It’s an endless dance that keeps coming back to us. We need to reduce the repetitions as much as possible, especially that complicated repetition of dependency-on-dependency, hidden packages, and updates from communities that nobody maintains anymore.
[18:07] I’ll add to that. Many times, because we don’t start from the ability to constantly fix, these gaps form, and as a development manager you’re always standing on some spot, asking, what do I do? Do I stop everything and start fixing now? What’s important? Do I take this feature and ship it, or do I fix this specific security issue sitting in some distant cluster? You always have to play this game. The more you’re genuinely shift-left and embedded in the team, and the team is truly all-in, the better a level you can probably reach.
[19:07] Right. In the end we do carry a lot of exposures. I can say that one year I reached a really big backlog of exposures I didn’t want to deal with, and we ran a kind of “cyber week,” a risk-closing festival, with an award for the top developer who closed the most. But that’s a very one-off thing we never want to reach.
[19:40] I want to ask you, Dan, and take this a step forward. You also deal with CTEM, which is a very interesting topic. I love Gartner’s acronyms, love-hate. With CTEM now on threat exposure, and Shely talking about shift-right versus shift-left, the reason you hear a lot about shift-right is that when I scan the code I find a mountain, whereas at runtime I find less, because not everything is reachable or exploitable. So how do you prioritize vulnerabilities, given that our resources are relatively limited?
[20:32] First, on shift-left versus shift-right, I actually concluded that shift-left does help significantly. From my conversations with the company’s customers, it saves costs. The further left you go and the earlier you prioritize your fixes in development, the more costs you save later. That’s proven in research too. As for prioritization, you’ve pushed on an open door, because in the end, the more you scan all your things, not just at the open-source level but at the code level and so on, you find dozens if not hundreds of vulnerabilities. So how do you prioritize, with limited resources, manpower shortages? There are all kinds of parameters. I’ll give one example we value highly: external exposure. We’re a cyber company; our backend, or at least the core of it, isn’t accessible to the world. So if we have a vulnerability that’s critical by CVSS but isn’t exposed externally, where an attacker has to really reach it internally and pass several layers, there can be a case where a medium-severity vulnerability that’s exposed to the world gets prioritized before the critical one that’s closed off. That’s one example, there are many parameters. It’s also very important to connect this to awareness and organizational culture, the secure-development topic Eran mentioned. We invest in it heavily, trying to involve employees and make them part of the whole process, bringing them examples, explaining; it’s all about awareness in the end.
[22:52] I agree very much. Now there’s another topic that comes up from what you said. We talked about prioritizing vulnerabilities; I want to talk about prioritizing tasks. Prioritization splits in two: there’s the prioritization of vulnerabilities, and you talked about reachability, which is great; but I also need to prioritize the developers’ tasks. People are on my back, I need to ship now, security interests me less, I have commitments to customers. Shely, on the security and risk side you’ve found vulnerabilities and you say “wait, stop.” How do you handle that situation?
[23:41] That’s a great question. I don’t think there’s a textbook solution. But broadly, what’s important is to take a very complex problem and simplify it. In the end it’s all risk management. In a utopian world my projects would ship with zero exposures, all the developers would be good kids, I’d have no copilot, I wouldn’t even know that word, but we’re not there. So what you need to do, similar to what Dan said, is take the inherent risk, the risk before controls, everything the systems flagged, and derive the real, effective risk: is this vulnerability actually exploitable, is it exposed externally, do I have other tasks unrelated to these dependencies, which by the way the same team handles, that carry a higher, more real risk of a cyber attack? I always step out of the regular operation and look through the eyes of an attacker and a defender. There’s a gap between attackers and defenders, and I need to shrink it as much as possible and add controls. That’s my view: see which vulnerability is exploitable, how easy it is to exploit, whether it’s been exploited, whether I’d even be aware of it, whether I have compensating controls in the process, and prioritize accordingly. I can carry an exposure for almost a year, as I said, and then reach the crowdfunding campaign at the end of the year. But we keep revisiting our threat map, which is why it’s so important to first know all the vulnerabilities, understand where I live, in which area, and where most of the risks are concentrated. There can also be quick wins that motivate the developers, my employees, and management: a single vulnerability across several projects where fixing one library resolves many projects at once. That’s a consideration too. So it’s about taking the whole set of risks, but viewed through the lens of the company, its defenses, and the updated threat map.
[26:17] Nicely put. Eran, how do you see this from a slightly different angle?
[26:31] I connect a lot with what you’re saying. One of the biggest challenges when you lead development is that you don’t want to reach a “stop the world” situation, where you say, we have a cross-teams initiative and we must fix everything. You want to avoid that. There are a few ways. One is education, as Dan said, raising awareness that it’s not just some thorn I have to deal with, but something real I need to understand as a developer: it’s important to protect my users’ data, to keep my service secure, to make sure the API I exposed is exposed correctly and not without a token. The ultimate way to do these things, and I’m a big believer in this, is more guardrails built into the system’s configuration. Automation is part of the software development lifecycle, which we’ve discussed, but built-in configuration matters too. If I’m exposing some ingress, I want to make sure my app is, by design, not exposed externally without me knowing. If I have the right guardrails, I can prevent the edge mistakes that can happen, and that’s another layer that helps me move away from “stop the world,” so I’m always in a living, breathing system that I maintain.
[28:13] On your last point, Eran, we also use all kinds of tools at the infrastructure level, infrastructure-as-code. In one of the tools we use, we have a policy where we write for the DevOps developers what’s allowed and what’s not, and they can’t bypass it. It’s literally a YAML config file where you put all the restrictions, “don’t open an app,” and then they get a popup, “you violated this policy.” That’s even more locked down. Right. We also use these kinds of policies as part of the deployment process. It’s the ultimate way, because, and I’m sure this has happened to many people, you exposed some ingress, often regardless of where you are, you simply copied the code or copied the YAML from somewhere, and then by accident an ingress is open even though you didn’t really want to expose anything; it got exposed by design because that’s what happened. That’s why automation is important, it cuts out all the mistakes. We’re human, we make mistakes.
[29:43] Now, on the open-source topic, there are cases, and I’m not sure if you noticed, but we’ve passed 200,000 documented CVEs, with the lion’s share in the last five years. It’s crazy, but that’s a talk for another time. What happens is, I might be using a component now with no critical vulnerability, and one day I wake up and there’s a critical vulnerability in the wild. So let’s start with you, Dan: how do I prepare for that, when suddenly a new vulnerability is discovered in an application running, reachable and all that? I need to make some change, some mitigation. How do you do the risk assessment and respond?
[30:47] I mentioned it briefly, the hotfix policy. I’ll give the Log4Shell example, because it was a really good case where many companies were hit and vulnerable and knew it was out there, and we had to respond fast. What we did was activate this policy; we’ve run it several times. It’s about building a policy with all the stakeholders in the company, and there are specific people who are supposed to monitor and activate it. I, the CTO, and our head of research know how to activate this policy. Once it’s active, we set up a channel and gather, whether in the office or on Zoom, and everyone knows their role. The research folks map and bring the fix into the product for customers. The VP of customers and sales updates customers and brings them the mitigation as fast as possible. Marketing produces the blog. And we, as security, map where all the exposures are and attack it as fast as possible, whether by disabling the service, and of course checking it doesn’t harm the service. That’s the way we chose to attack it. I’ve activated this policy about six times in the last two or three years, and it worked like clockwork. It’s not gospel, you just need to rally the people in the company, because usually the whole board should be involved. I’m speaking from the perspective of a product/SaaS company.
[32:24] Nicely put. Eran, how does it work at your end?
[32:27] Usually you try not to reach these situations, but if you do, you need to first understand as fast as possible what’s affected, what’s exposed, what exists. That process of understanding what’s exposed isn’t always simple, because not everyone knows what’s actually exposed externally. I think that’s usually where we got hurt the most. The same with the famous Log4j: we had to come and map which components contained it. Some were components we used directly; some were components we use, like Elasticsearch or Spark or others, and then you need to know what you’re closing, if you need to close it, because not everything, as we said.
[33:45] From the development direction, how do you usually handle it? I love this topic, because I remember a few years ago when Log4j came out, the conversations I had with many companies, they spent months going over their code components to understand which were used and which weren’t, what had vulnerabilities, which version I’m using. It was a huge effort. With today’s technology, in two minutes I map everything, I see everything, I know what’s vulnerable, which version to move to, open a ticket and close the story. I love seeing how once it was terribly hard to handle these situations and today, with technology, it’s a few button clicks. That’s one of the reasons I love this topic, this fast progress where you can solve problems that used to be terribly hard.
[34:38] That leads me to a question for you, Shely. In the end we’re talking about development that brings in open-source packages, and those packages bring vulnerabilities and new disclosures. When I secure this, I want technology or processes that don’t make developers feel they’re working all day for security, but rather that security is inherent, part of their role, and not reaching some crazy “cyber week,” but really building this in. So how do you integrate the security of open source and packages into the development process, in a bit more depth?
[35:37] Without going deep into specific products, I’ll say it again: orderly CI/CD pipeline processes. And it doesn’t have to be one; I can hold two or three types of pipelines suited to the teams. You need to integrate automated tools: first a tool that checks the packages I download, then automated code-scanning tools before I deploy. Now, even though I’m a CISO, I should take a step back here: most of these tools, the three leading ones in the market for security, all give you more or less the same thing; one gives a bit more, one a bit less, but that’s not the issue. What’s right to look at is the convenience for the user, and the user is the developer. The more intuitive the tool is for the developer, even if it’s a complex tool, if the developers are used to it and like it and accept it, the better it integrates into the pipeline and I can flow with the processes. Because the goal, as I said, is for security to integrate into the development processes, not to change or break them for security’s sake. It’s a slightly different way of looking at the picture, a bit like that image where you see either an old woman or a young woman depending on where you look. That, in my view, is the key in this world. So as we said, integrate automations that genuinely help the developer day to day, in the whole shift-left world: before I do an MVP/build, I do a code scan and a package scan. By the way, on runtime, I admit I’m still not mature enough on how to do runtime security effectively and bring the power back to the SOC and not just QA, but it’s absolutely along the whole path: keep uniform processes and as much automation as possible. Both Eran and Dan talked about this before me. That, in essence, is the secret to not reaching that crazy sprint where I have to close lots of exposures, and to not carry around a backpack full of unnecessary risk.
[38:30] I want to add to what Shely said: I look at automation in the lifecycle the same way I look at alerts in production. If you have a lot of alerts in production and not all are severity-one, at some point you just dismiss them and the story ends, and at some stage you stop paying attention. Same here, it needs to be part of the process. Many times the configuration of these tools, whatever tool we used, wasn’t good enough. For example, on some step there was a recommendation to “migrate” a dependency, and migrating a dependency is an event, so everyone said “wait, the process doesn’t work,” and just hit cancel or dismiss. Then later, when we wanted to reach a certain compliance, suddenly you realize there are so many places you didn’t notice, because everyone hit cancel; it was crying wolf at everything.
[39:57] I’ll tell you exactly what this is. We had this challenge too, the thing you both raised, and what we did to improve it, a relatively new process where we do see the change, is to run a production-readiness session, an SRE function for those who know it. Every time you release a new feature or something significant, you hold a meeting of people, not just automations, because in the end, that’s where the enforcement and loop-closing were missing. We call it “prod readiness,” with interfaces, infrastructure, and security, who go over everything. In security, we have sections that also talk about open source: “show me how much you closed.” We literally go through it and say, you closed, you didn’t close; you didn’t close, I’m not giving you approval, release the feature. It’s not all black and white, every case on its merits, but you get the idea. In the end it’s our loop-closing.
[41:12] I want to add something else. In the end we also look at the quality of each developer’s projects. That’s an important thing to look at, because a developer who collects exposures like mushrooms after rain, even if at low severity, accumulates them, and that indicates the level of their security awareness and what these things they collect along the way mean. So it’s very important for me to also map these teams. I can say at almost any given moment where each team’s weaknesses are, and based on that, if we talk about awareness, I tailor things. It’s not some bombastic training; when I say “training” it sounds big, but you do a kind of small micro-training where you, together with the team lead, gather the team lead and the specific teams and show the real-world exploitation of those exposures we live with today, because they took the not-most-updated version since it was only severity seven and I let it keep going and didn’t block it. So it’s important to know the quality of our development, to see that I’m not widening the gap but shrinking it as much as possible, and each time I manage to streamline the work, whether through automation or sometimes through manual processes, simply sitting with the developers to see what’s missing and what’s not working in the process.
[43:02] Right. Eran, how about you? This is an interesting topic, this readiness angle.
[43:16] I connect with it. There’s a balance and complexity here, because when you have quite a few development teams all constantly running, it’s very hard to catch when the production-readiness moment will be. We know this even from the world of high-level design: how do I bring the requirement into something? Often the conception was “let’s close it at design time and everything will be fine,” but at design time it’s not always so, and then you get a situation of how I still manage to catch things before they happen. It’s a story worth thinking about. In these things I try as much as possible to rely on the process rather than on people’s process, because from my experience the people’s process always falls through, because they’re people: someone was under pressure, someone had to ship something, there was a development manager on their back. So our way to stop or prevent this is to make it something automatic, not because we don’t believe in people, but because we need to believe as much as possible in automated processes that build these guardrails for us.
[44:47] I’ll say, it’s allowed to say we also don’t always believe in people; that’s our profession, zero trust. Zero trust all the way. That takes me to James Clear’s Atomic Habits, which ultimately talks about habits, good ones and ones we know are not good and do automatically without noticing. I love this approach of automation, not automation as a tool, but automation of the process. I think that’s really one of the steps for instilling a culture of security as part of product quality. I also want to tell our viewers that if they have questions, we’re getting close to the end, so feel free to write them in and we’ll address them in a few minutes. But before we get to questions, I’d like to hear a recommendation or tip from each of you, from your experience, that our audience can take away. Say I’m now planning a process to instill secure development or open-source security. Where do I start? Dan, maybe we’ll start with you.
[46:37] First, I did this process almost two years ago, started getting into this whole world with relatively little prior knowledge. What I did first was a full risk map of the entire CI/CD process, literally mapping everything in a labeled diagram: okay, what do we have at each stage, starting even from a bug in Jira that goes into GitHub, goes to Jenkins, somehow up to AWS, and so on. A full map of everything is the key for me. And if we’re talking specifically about open source, I’d recommend integrating an ASPM tool that’s dynamic, dynamic is important because today it changes all the time. A dynamic ASPM can give you a real starting point to understand where you stand, and from there you can derive everything by risk, by severity, by the prioritization of security versus fast delivery; it’s always about balance. In my company that’s less of a struggle, because our risk tolerance is very low, a cyber company has no tolerance, so I’m a bit lucky there. It’s always funny when I talk to our developers, who work at a cyber company, versus non-cyber developers; you see the difference in the security awareness of a developer in the cyber world, who is a developer, not security, versus a developer who has no idea, who’s now developing some fintech or gaming platform and it doesn’t interest him at all.
[48:30] Nice. Shely, how do you see it, what would you recommend?
[48:38] Dan talked about the technological side. With your permission I’ll talk more about the management side. I got to implement secure development at two organizations where I was the CISO, the whole world of secure development. In the end it’s not a process that’s only ours, security’s. It’s very easy to say “who’s the project owner? I’m the project owner, I also fund the system and handle budgets,” but in the end this project isn’t mine. If I don’t know how to recruit all the development teams into this, I’ll be left alone in the battle, I’ll scan myself for myself, and in the end everything will be open. So if I have one very big tip for you in the SSDLC world, it’s very important not to work alone. You need to understand how the developer works, what they’re used to, including their bad habits, and make adjustments together with them on how to work correctly and effectively, and listen to their difficulties and contain them. You can also push back sometimes, that’s fine, and steer them; not everything has to stay as it is, we came to make a change, but with determination and sensitivity. You need to understand that if they’re not all-in on this project, it will fail, and then we’ve lost a lot of millions, in my view. For us it’s a metric; we put it as a KPI for developers, whoever doesn’t handle security. It’s one of the metrics. Same for us, by the way. Good, excellent.
[50:38] Eran, amazing. Maybe just to add, since Dan and Shely covered the two main things. Let me put it lightly: every time you join a big company, like now that I joined Cognyte, the first thing that happened, and surely people will identify with me, is I got a compliance training. Now, I don’t know if you’ve seen all the videos going around about people using ChatGPT to answer compliance trainings, because everyone wants to finish them. There’s a cybersecurity compliance training. Why do I give this example? Because it’s exactly the wrong management. The right management isn’t all kinds of compliance just to check the box and have someone paste something into ChatGPT to finish it, but management that’s part of understanding, the KPI. I really liked that. We didn’t do these things, and I think it’s meaningful, because it can really raise the level. I’m a big believer in automation, management, and as many guardrails as possible, for peace of mind.
[52:05] Wonderful. Today we went through several main topics: code management, productivity, automation, how I integrate security at the developer level and the code level, how I look at things. I want to take a few questions from the time we have left. I see someone asked you, Dan, about the IaC tool you use. Do you want to tell them?
[52:27] Sure, it’s no secret. We use Pulumi. For those who know it, Pulumi is like Terraform but supports several languages. They have an open-source version we started with, and once we matured with it and wanted to scale, we took the paid version. Great tool.
[52:50] Now I’ll throw out a few questions, whoever wants to take them. First: what way would you suggest to identify internet-exposed vulnerabilities? I think you talked about this, Dan.
[53:02] I can answer. There are all kinds of ways. First, there are dynamic scanning tools you can use, both paid and open source. I also noticed that I managed to get a lot of detection of these things via my WAF, the web application firewall. Somehow, I didn’t expect it, but we configured it so that we monitor everything and then run analysis and see what was attempted and what wasn’t. So that’s another, unexpected way, and suddenly we got very interesting signal from it, and we did a mitigation and hardening project from it too. And of course PT (pentest), but PT isn’t scalable; you can do a pentest but it’s point-in-time for a specific spot, which has drawbacks, so it’s important to use something dynamic.
[54:01] There’s another question, I think this is more for you, Eran: as a developer, how can I be aware of risks and weaknesses in the code I write when I have no background in the security field?
[54:13] I think there are two ways to handle this. One is to accept the axiom that there are many backend developers who often say “I’m not frontend, I have no idea how authorization works, there’s an API and it’ll be fine.” So I think it’s important to do that education, because the backend can also expose some API. Two, I think mainly to use tools that do the bubble-up for these things, and that mostly comes from a specific tool. You can look at all kinds of sites on GitHub and so on, but I think that just doesn’t fit the development pace we’re in today. So tools are the ultimate way, you could say.
[55:19] There’s another question: how can you deal with open-source packages and understand whether the vulnerable part itself is being used? I understand where the question comes from, interesting question. I can say what we do. In this case it’s a very interesting question, because even when I use open-source packages that bring more packages, all the dependencies, when I use a package I don’t necessarily use all its capabilities, functions, or modules. So the critical vulnerability may be in module two, while developers using module one, it’s not really critical. This is much deeper; it’s really about getting into the code, trying to understand how the code works and which parts it calls. I can say there are tools today that do this automatically and integrate the pieces. In this case, the way to handle it should be through a tool, automatically, as Eran said: I identify a package, I identify the dependencies, I identify whether it’s in production and where, whether it’s backend or frontend, whether there’s access via an API, and then if I have the part of the code that I call and I know that part represents the vulnerability, I can say that function really is exploitable. You don’t always have the time to investigate this; sometimes, at least as a CISO, you say “I don’t want to take the risk, folks, if there’s something there and you don’t have enough, go fix it.” Sometimes you reach that point too. That’s why a tool is really the way to handle it.
[57:10] I completely agree. I see we’ve finished, we’re at our time. So I really want to wrap up and say thank you all. It was a very interesting discussion, one of the better webinars I’ve had. I don’t know if it’s because of the audience or because of you, but it’s surely because of you, since I can’t hear the audience. There were some very interesting points here. We can really go deep into this topic; it’s a very big and deep subject and we only touched part of it. So first, thank you to Shely, Dan, and Eran, you were truly amazing. We’ll talk again. And to all our audience, thank you for being part of this, asking questions, being in the engagement. If you have more questions or want to go deeper, feel free to follow us on LinkedIn, and of course OX Security; it’s something we do regularly. Let’s stay updated, stay together, and secure systems well. Automation, don’t forget automation, it’s important, automation on process. That’s it. Thank you, everyone. Goodbye.
