Join Kadi and guest co-host Sola Otudeko for a chat with ABN AMRO's Ingmar Vis. Listen in as they discuss:
-
The value of breaking builds.
-
Why automation is key for agile development.
-
Lessons he's learned throughout his open source journey.
-
What pushed him to give back to open source.
Listen to the episode
Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm
Show notes
Hosts
Panelists
- Ingmar Vis, Product Owner Software Development Infrastructure, ABN AMRO
Relevant links
Transcript
Kadi Grigg (00:11):
Hi, my name's Kadi Grigg, and welcome to another episode of Wicked Good Development, where we talk shop with OSS innovators, experts in the industry, and dig into what's really happening in the developer community.
Sola Otudeko (00:21):
And hi, I'm Sola Otudeko, co-host. I'm also at Sonatype, and it feels strange introducing myself to Ingmar in particular because I've been here about five years and been your customer success engineer for about five years. A customer success engineer, and I also lead the team of customer success engineers here at Sonatype International EMEA regions and the APAC regions.
Ingmar Vis (00:44):
My name is Ingmar Vis. I'm a product owner for a large bank in the Netherlands, responsible for two teams mainly focusing on secure coding and on the infrastructure for our software logistics factory, which is the pipeline factory you could say. I've been working there for close to 20 years and been in IT for a dozen. Yeah, looking forward to today.
Kadi Grigg (01:07):
Well, Ingmar, thank you so much for taking the time to be here. Let's dive in. So, can you tell us a little bit about your role at ABN AMRO. You mentioned that you support two teams, and one of them is secure code, and I'm curious as to what that means. So, can you give us a little bit of an insight as to what your role is?
Ingmar Vis (01:26):
Yeah. ABN AMRO is a large bank. We have about 3000 developers working across 500 to 600 Scrum teams in our IT organization. All of them use standard pipelines, a lot of tooling. A lot of technologies being used. Of course it needs to be secured also. From that perspective, there are a lot of governing teams, central body of teams that deals with not just the tooling, but also the policies, the governance, the triaging of findings that come out of these tools. And one of these supporting teams is the Secure Coding team. We call it SECO. It's just a short name. Everything has a short name nowadays, and our bank is known notoriously for all the abbreviations. So, the SECO team, it consists of about six members plus product owner. And what we do on a day-to-day basis is deal with questions from developers that run into security violations.
Ingmar Vis (02:27):
That can be whenever they make a commit, the pipeline runs, and a quality check fails. Then they call us and ask for help. It can be proactive that they want to engage with a team of experts that will help them with a consultancy session. It can be knowledge sharing in the form of anything. Basically, we provide trainings. We do workshops. We have training platforms. We sit together with teams. We do peer reviews. It can be anything. But we also have a big stake when it comes to the profiles, the quality gates, the rulesets, and what we call "build breakers." Those areof course, the things that people run into when they have code that does not meet the bar. And a lot of times people ask for help. They come to us, they ask what type of upgrade they need to do. They ask for temporary risk acceptance, where we play a large part, large role. And there's all kinds of engagement with developers and also with team leads or other product owners across the board.
Kadi Grigg (03:37):
So, being in the banking industry has some unique regulations around it. So, I would imagine that's a very complex process for your team to handle, especially with regulations changing. Is there anything that is specifically unique that your organization has to deal with on a day-to-day basis that other industries may not have to deal with?
Ingmar Vis (03:57):
I don't know about other industries, but we do see a large growth of the number of controls that need to be adhered to. It can be all kinds of controls coming from the regulators mostly. And these controls you, of course, need to attest to and provide the evidence that you adhere to these controls. Doing that at scale, at a large enterprise like us, I consider ourselves quite a large company, is challenging, because there are so many different players on the board. You always have your front runners who are very engaged when it comes to governance, compliance, security controls, and everything. Your security champions basically. But that's always the same people. So, we consider them ambassadors. They are used, of course, to communicate with their following through all kinds of communities that we've set up in the company.
Ingmar Vis (04:54):
But the front runners are the easy ones. Then you also have your-- well, the people who are new, who don't yet know about all the controls that are in place have a hard time hitting the ground running. Because when you enter a Scrum team, of course, there's so much information coming at you at once. It's very hard to comprehend the total body of information. So, there's a large group of new people coming. And it's also one of the challenges to have this constant flow of new employees, of new colleagues embrace the same culture that we've been trying to achieve over the years since maybe 2015 when CI/CD became a big thing. So yeah, newcomers have a hard time grasping all the information. And you have this big chunk of people in the middle. They're not new. They're not the security champions. They're just the hardworking team members who are trying to provide business value everyday, developing features and might be somewhat isolated from all the information coming at them, "protected" maybe you could call it by Scrum Masters. So, you also have challenges with penetrating your information into some teams, because they're just constantly packed with work. So, that's quite a challenge for us.
Sola Otudeko (06:17):
Ingmar, you mentioned earlier on about build breakers. And obviously that has an impact on the ability of developers to push their code through the development lifecycle. How accepting are folks of that particular process? Do they complain about it? Do they ask you to remove them, or they just accept that it's part of the process that they have to follow through to ensure quality and security in what they're releasing?
Ingmar Vis (06:42):
That depends. If you have a small application with a small codebase and you have one build breaker, this is fine. You can just fix it. Take a look at it, sit back, discuss it in your team. If you're working on a legacy codebase of hundreds of thousands of lines of code or maybe over a million, you run into hundreds, maybe more of critical security vulnerabilities, because the codebase might be over a decade old. It might have been handed over five times from team to team. The original developers and architects have long gone to a different team, different company maybe. Then it's quite challenging. Now you have to differentiate a little bit between how you approach these teams. The trick is, of course, that a build breaker is quite hard. It doesn't distinguish per se what type of application you're looking at.
Ingmar Vis (07:45):
Application context is missing quite a lot. It's black and white. You have a CVE this is of a category or a CVSS score, 8.9 or 9.8, or maybe something in between. This is a build breaker solely based on the severity level of the CVE. If you have many of them, teams will complain. They don't have time to fix this. They maybe misunderstand their own code due to the fact that this is legacy, very old code. There is a high business demand or a regulatory change that needs to be pushed to production, yet you have a build breaker. Now that's a very difficult yet common situation if you work in an organization like ours. There are so many systems. We might have over 3000 business applications running at the same time.
Ingmar Vis (08:41):
A lot of them are proprietary. A lot of them, again, are legacy. But still changes are done. Now developers will push back. Product owners will push back.IT managers and business people will push back. So, there is always a discussion when it comes to these kinds of situations. We're not in the department of "no." We are here to provide people help. We don't want to make things more difficult than they already are. And believe me, things are difficult. There are so many controls that you need to adhere to. So, we look at these situations and then comes the SECO team comes into play because we treat these situations individually. If there is a small improvement, it's already an improvement. We don't expect teams to fix thousands of build breakers all at once.
Ingmar Vis (09:33):
This is something that will never happen. If you look at the amount of technical depth expressed in man hours, then such an application with so many build breakers would have thousands and thousands of hours of technical depth that would need to be resolved before they would be able to push something to production again. That is not reasonable. And that's not something that will happen. So, here we take baby steps. We make agreements. We look at what is the most likely CVE that will be exploited. How can we address that? Can we put waivers on the other CVEs that are found? Give them slack sometimes, make agreements 3, 6, 9 months to fix some of the lower-level CVEs that have a lower level of exploit predictability. Also, look at the business context. Is this application internet-facing?
Ingmar Vis (10:31):
What's the what's the CIA rating of an application? How do those factors come into play? Then you can make an informed decision on how you continue. But the very first thing is that the build breaker is activated. And I'm always happy when it happens, because then at least people are in our shop. You also have a lot of applications that are not actively developed yet very vulnerable but unknown to the general public of developers. Because if you don't build something and you don't have your continuous monitoring setup, we do. But if you don't have that or you don't pay active attention to it, then you're not aware of all the CVEs that are in your application. So, the build breaker is very-- this is a happy scenario for us, because the customer comes into the shop, and we can start this engagement. With a small SECO team running this shop for 500 to 600 Scrum teams, it's always nice to see customers come in. Every time the bell goes, "Okay, who's in our shop today?"
Sola Otudeko (11:33):
Okay, do you really have a bell or do you have a dashboard kind of thing where you monitor what's going on?
Ingmar Vis (11:38):
Sirens and a Batman light.
Sola Otudeko (11:40):
You've actually answered another question I was going to ask just now. You've described quite a lot of work that your team does in relation to the build breakers and the overall process. And you said at the beginning there's a team about you and plus about six folks. So, I imagine there must be a lot of automation. How many users or so-- you said 500 Scrum teams in total. That must relate, and I translate into a couple of thousand developers that a lot of people, that your small team is supporting. So, I imagine a lot of automation. And do you do that as well?
Ingmar Vis (12:15):
Yeah. That's the number one thing. Automate everything. We automate everything when it comes to onboarding our users. We automate onboarding of applications, of courseto our tooling and to the pipelines in general. We automate the process of quality gates, of course, in pipelines. And we're looking at automating the remediation capabilities also. That's more like future state and development that will be doing ourselves and also working together with Sonatype on the ideation for that. But like I said, part of the vulnerabilities that are detected are never going to be exploited anyway. We want to automatically apply temporary expiring waivers to the lower-impact CVEs, yet they are build breakers, but we will apply automatic waivers there giving teams, again, some slack to fix them, put them on the roadmap, on the backlog, come back to us in time when they have thought about it, so teams can only focus on what's really important and vital at this moment. In the fire department-- I'm also a volunteer fireman-- there's this ground rule of treat first what kills first. And that applies to CVEs also in your application. And the same thing applies to applications in the bigger application landscape. So, if you look at all your applications, and if they all have the same Log4j CVE in it, you're going to treat some applications first. That's part of triaging. So, you look at it from that perspective.
Kadi Grigg (13:58):
How do you know what you're going to triage first? Is it just based on what's the most critical?
Ingmar Vis (14:03):
If you take an example of the most critical, but if everyone has the same critical severity, then you need to look at other things. We operate at such a large scale that there are so many applications that have the same type of vulnerabilities in them. You're not going to be able to treat them all at once. We have teams that are responsible for many applications. So, they will also have to choose which ones are going to be treated first. So, then you can look at application context. We use CIA ratings for the impact of a cyber breach. So, if your application would be breached, what is the financial monetary impact of losing the confidentiality, integrity, or availability of the data? That's expressed in certain values. And if you take those values and apply a mathematical calculation, then you can see what is the actual risk. So, you calculate the actual risk based upon numerous factors: CIA rating, exploitation probability, CVSS score, and maybe other factors also. So, then you can choose. And then if everything still remains at the same level, then we just draw a card.
Sola Otudeko (15:19):
I'm also thinking obviously we're talking a lot here about the use of open source. The vulnerabilities are associated with open source components and libraries that to your developers use. How important would you say the use of open source is to your development efforts? I don't know if you measure the impact of open source versus homegrown code and how much use it across your applications.
Ingmar Vis (15:45):
Yeah, I don't measure it. I don't have the exact data. A rough guess is anywhere between 80 and 90% of the code that makes up an application is open source code. But that's a rough guess. Also, based upon all the things that I've read about it, and it does look like that will be true for us also, I didn't apply any measurements on it, but it's vital for us to consume all this open source. We use Nexus Repository Manager with a lot of proxies to all the open source hubs that are out there. So yeah, for us it's vital. We're pulling in libraries by the hundreds, by the thousands everyday.
Sola Otudeko (16:27):
And frequency of releases, what would you say? You release on a daily basis, hourly basis? Or is there a standard across? I know there'll be all sorts of different types of applications the larger ones, desktop, mobile, etc.
Ingmar Vis (16:41):
Yeah, it very much depends on a lot of factors. So, we have maybe a thousand, maybe 1500 builds per day. So, that's something that tells you a lot about what's happening on the CI front. The deployment phase is something different because not every build leads to a deployment. So, I don't know the numbers. I couldn't tell you how often there is a release going on to production. I know that, for example, people deliver our mobile-native apps which is basically the shop of our bank. So, if you look at our total brand, it used to be traditionally with bank offices and people coming there to do their banking business. Nowadays, it shifted to Internet banking. And that shifted maybe in 2010, '11, '12, '13. That was the big shift to mobile first, and now that's fully embraced.
Ingmar Vis (17:37):
The next shift you'll see is API-first, but that's coming after. Now, if you look at our mobile portfolio, which is quite big and quite strong also in the Netherlands then they release daily and multiple times a day. That's also because they embraced Scrum-based development. So, they have a very strong and powerful group of developers that are working on all the initiatives to automate everything as much as possible. And they've come so far that they can release multiple times a day. They do have some details with app stores, etc., that maybe slows down the process just a little bit. But technically from our end it's very fast. Now, if you look at very big legacy applications, they might release once a year or twice a year and if I look at my own team, SECO team, we also do software development. The stuff that we create, develop, and release, we always release on a Friday afternoon before we stop. So every Friday.
Sola Otudeko (18:50):
Okay, you've got a weekend buffer to fix any issues. And I'm sure you'll focus on hoping everything goes smoothly and not affect the weekend.
Ingmar Vis (19:02):
Yep. Tradition.
Kadi Grigg (19:03):
So, that sounds like, especially like just-- I'm just thinking about like the mobile group in general-- that's a lot of open source that you're handling. So, I'm curious as to what have been the biggest challenges that you've faced in managing your open source? Have you seen anything in software supply chain risk or automation that makes you uneasy? I'm just wondering what are your thoughts on how you guys have handled open source and the biggest challenges you've faced, and maybe even what has been your biggest success?
Ingmar Vis (19:34):
We consume open source at a rapid pace. The things that people run into is, of coursebreaking changes in libraries, upgrade parts that are difficult for teams to challenge or to take. So, difficult upgrade path. It might be that a lot of dependencies from the open source are end-of-life but yet still consumed, and no upgrade path from a logical standpoint is available. So, those are challenges that we face. We have big amounts of end-of-life software, open source software, being consumed for which teams need to refactor their total applications, shift from, for example, from AngularJS a shift to a newer frontend framework is being done to Vue.js 3. It's not like you can just apply a script that changes your application, and then it's a Vue.js application.
Ingmar Vis (20:41):
So, refactoring the total frontend-- the frontend community is very big and has a lot of applications in our bank. So, refactoring that at scale takes a lot of time. You can take anywhere between 18 and 24 months for a refactoring at scale to happen if you shift from one old framework to a newer framework. So, it's also an open source challenge there. We see this quite often that also in the Java world. So, traditionally a lot of development for our bank has been Java-driven. Also, there you see a lot of older frameworks being used for which people need to migrate to newer versions. Very challenging. Also, especially when again these legacy applications come into play, you're never going to refactor a decade-old application on Struts 1 to something different, because the original architects are gone. There's no one who understands this total codebase. You need to decommission this application, build something new if you really want to move forward. And then it becomes a budget and priority discussion. What are you going to do? Ultimately the business, of course, decides.
Sola Otudeko (21:55):
Thanks, Ingmar. And so obviously, I know this has been a long journey in terms of reaching the levels of maturity that you have in place, with all the automation that you've put in place as well. So, for users who are let's just say less mature maybe starting on this journey, they are using a lot of open source still trying to work out what to do in terms of managing in building out their software supply chain and putting these processes in place. What advice would you give people who are starting out on this journey?
Ingmar Vis (22:31):
Get some experts that will help. See if you can find the right people who have all the knowledge. If that's not possible, then go on a study course yourself and make sure that you understand how open source vulnerabilities exist, how they threaten your security as application owner. Try to understand the most typical vulnerabilities from your own applications. So, if you create a software bill of material for your application, look at some of the common libraries that you're consuming. Try to find out what the vulnerabilities are, try to understand them, and try to see if you are exploitable and get some understanding of what's actually going on under the hood. I think those are some nice starters to start off with. You can also go all wild and try to understand exploits take a course on TryHackMe or Hack The Box. But maybe then you're looking more at the offensive than the defensive point of view, which is also really interesting. And we do it a lot. But maybe that's not something you would do when you start off.
Kadi Grigg (23:44):
You were talking about the open source risks and challenges you faced. What were some of the things you learned going through Log4j? How did you handle that? Because it was pretty much a crazy time for everybody in IT. So, I'm curious as to how you handled that, and what lessons have you learned and changes have you made since then?
Ingmar Vis (24:02):
We played quite a vital role in that Log4j crisis at our organization. My team, SECO team, eventually when the initial disclosure of the vulnerability took place, I'm not sure what day of the week it was. Let's, let's call it a Thursday. We found out early morning that something was wrong, and first thing we did was validate the severity and exploitability of the vulnerability. So, through that practice, we collected all the CVE details and collected the scores looked for exploits which were already available and also created some proof of concept, just Dockerized proof of concept. Just showcase also to everyone interested in this topic what the vulnerability is, how easy it is to exploit, and why we and the rest of the world also was at risk. And of course, document all that stuff.
Ingmar Vis (25:00):
Then second thing we did: create an impact analysis. So, all the reports from Nexus Lifecycle use the advanced search see how exposed we are to this look for software bill of material, but that was not that much available at that moment yet. It's more something that we're looking into nowadays. We also ran our container security tool again to see-- of course from the Docker images that we have-- to see what type of images are exposed to Log4j and then check our crown jewels. So, we have a list of crown jewel applications, maybe 60, 65 applications that are of utmost importance that if they are vulnerable, then our whole organization is basically vulnerable. So, those get extra attention, you could say. So, the payment systems, the mortgage systems, everything in the security systems.
Ingmar Vis (25:59):
Take a closer look at them specifically. We created remediation strategies per scenario. So per scenario you could say for proprietary applications, for Dockerized applications, for VMs, for COTS, or what we call commercial-off-the-shelf applications. So, create remediation strategies for each of those scenarios. And then finally, of course create centralized communication channels. So, migrate all communication to a single channel, create teams that work on specific topics like firewalls, like data analysis like communication to the teams that need to upgrade or perform workarounds sign all those work items, and then share all the data with the organization. So, it's validation, impact analysis, remediation strategy, and communication strategy. That's the whole quartet of actions that took place. And it taught us a lot for the next major crisis.
Ingmar Vis (27:07):
We have all this information in our back pocket. We made an effort expanding decision-- three steps people could take to find out if they were vulnerable. Because what we saw with Log4j was that new versions were being released that contained new vulnerabilities. That was really terrible, of course, for everyone because they needed to upgrade again. And some upgrade paths are more difficult than others. But yeah, we learned so much for the next big crisis. We have all this information in our back pocket. We can build on that. We learned how to communicate how to create these overviews for our customers-- by customers I mean internal customers. So IT leads or developers, everyone who needs to be aware. So, I think for the next crisis we're better prepared than for the last one. So yeah, looking forward to December.
Kadi Grigg (28:08):
Aren't we all? Yeah, I know all the Twitter and everything is just like, "Whoa, what's gonna happen this year?" And I'm like, please, can we just have a quiet Christmas?
Sola Otudeko (28:15):
Yeah, indeed. And I was also thinking-- cloud. Ingmar, obviously everybody's talking about cloud, migrating to the cloud in various ways, whether it's tools, applications, code, etc. What are you doing in terms of anything to do with the cloud? How do you see, if anything, the impact of migrating development to the cloud, tools to the cloud on your supply chain. And then again coming back to open source, do you see that there is a major difference or change in the way that you do any of the things you do based on the need to support cloud efforts in any way?
Ingmar Vis (28:56):
It's difficult for me to answer. I think we don't do cloud-native development. So, we don't have our IDEs running in a cloud environment. We don't store our source code on public-available repositories. We do use Azure Cloud. We do use Azure DevOps for our SDLC. What does that change? A lot of things are automated, so that's a big benefit for us. So, we use a lot of infrastructure-as-code. We provision and control most things through automation. So, there's a big upside to that. However, that infrastructure-as-code is also something that needs to be secured. So, that's the challenge that we're looking at for the next year. Diving into that topic looking at all the possible capabilities for infrastructure-as-code security, something that's very high priority for us.
Ingmar Vis (29:57):
I don't see a big difference for the developer's point of view, because it's still the same. The application is being developed, source code is being stored, versions pushed through pipelines and deployed somewhere. For the developer, it really doesn't change. But from the administrative perspective a lot of things have shifted. Previously, things were more centrally governed and controlled and managed by a central body. Now, responsibilities are put more into the DevOps teams themselves. They control a lot of their environment settings, configurations, and variables and are responsible for their environment at much higher degree than in the past when everything was self-hosted and self-managed in our own data centers. So, that's a large shift of responsibility. Also with all the infrastructure-as-code, a lot of focus is put on that. So, teams control their infrastructure. It's much more automated. So yeah, teams are looking bright from that perspective. There's a steep learning curve. There's also a large chunk of applications still needed to be migrated. That's a path that takes time. So, you're not going to migrate everything. You will remain self-hosted with particular applications, but we see that most of the applications will be in the cloud. A large sum of that will be containerized. So yeah, that's the future.
Sola Otudeko (31:31):
And talking about the future, and you mentioned one or two things about what you're doing next year. What would you say are your top initiatives for well, I guess this year is done for next year? And any other plans you have in place to address any challenges you have in the software supply chain?
Ingmar Vis (31:48):
Well, one of the things that we created is a secret detection tool. It's a hot topic, buzzword also. We've been working on it for 12 to 18 months already. And it's finally finished. It's a tool that we created. It's called RESC. Repository Scanner. It's not just a secret detection tool, but it does much more. It uses a rule file in form of YAML. But what it mainly does and offers us is something that we found missing that's total control of the rules, that very high focus on triaging and reviewing of findings. And that's easy and sophisticated integration with our security incident and event management. So, what we have now is an end-to-end flow created. We scan all our source code for secrets. We have many. We triage those secrets through our UI.
Ingmar Vis (32:49):
Any true positive is delivered to our SIM tool out of which incidents are created for the DevOps team responsible for the source code. So, they get an incident in their ServiceNow as soon as a secret is detected and found to be a true positive. So, that's end-to-end flow. We will be open sourcing this entire tool at the end of December, and we'll be sharing it on GitHub. So, that's the GitHub account of ABN AMRO where it can be downloaded. It's completely Dockerized. It's frontend-backend services, everything. So, that's one of the things, and we'll develop forward on that also together with the open source community.
Sola Otudeko (33:29):
Fantastic. Actually, I was going to throw one last question in which was-- so, you've mentioned a lot of good things that you folks-- that I'm sure people listening would be thinking, "How can I get ahold of some of this stuff that Ingmar's talking about?" And you just answered that question. So, thanks very much.
Ingmar Vis (33:46):
We're the first one in our company, first team to actually deliver real application in the form of open source to the outside world. We also have an open banking platform that delivers APIs to be consumed. So, these are business-to-business APIs that can be used to leverage the ABN AMRO financial services. And we became a part of that platform when we want to open source our tool. So yeah, we'll be riding along with them. And we just thought that it was the right thing to do. We see a lot of protection of intellectual property in the info-security world where vendors are either scared that another vendor might run away with the idea or have a very strong idea, and of course from a monetary perspective want to keep that for themselves.
Ingmar Vis (34:42):
But I'm more of the modern age where I say that we need to provide this to the open source world so everyone can become a little bit safer, and we can embrace that as a community. Also, from another perspective, we want to get feedback on our application, see what others think, get new requirements in. And finally, we want to be known as open-source friendly. So, it's also a cultural thing showing that our company supports developers that want to create open source, want to contribute to the open source community, are very much welcome. We've had a chance to work on this for 12 to 18 months spend a lot of time on this, not just on the open source, but as a total product of course. And we really want to show that to the world.
Kadi Grigg (35:30):
I love it. I think that's why I love the open source community though. There's so many great people in it like you Ingmar who really do embody all of the values of the community, where you contribute, you also release, you want feedback too, which is really important. It's not like you're just king of the castle, and this is as good as it's going to get, and nobody can add to it. So, I think that's really powerful. So Ingmar, last question for you. We've talked about a lot of different things today with you in the journey you've taken at ABN AMRO. So, under this lens and what we've talked about, what would you say wicked good development looks like to you?
Ingmar Vis (36:08):
People who love their work. People who come in everyday and create new initiatives, embrace innovation, take time to help each other, learn from each other, be patient with new people, teach them all the old tricks, but also listen to the newcomers. So, that's all so wicked good. A lot of times people might be afraid to speak up let their voice be heard, because they're new and they think that things are happening for a reason. But the challengers are the real people that you need. So, I think that everyone who challenges the establishment and comes up with new ideas, questions why things are happening in this fashion-- "Why is this taking so long? This is consuming way too much time of my team. This should not have priority." That's the type of people that we want. We don't want the silent people who just say "yes" to everything. We want people to say "no."
Kadi Grigg (37:09):
Beautiful. I love it. Well, Ingmar, thank you so much for taking the time to speak with Sola and I.
Ingmar Vis (37:14):
You're welcome.
Sola Otudeko (37:16):
Thank you, Ingmar.
Kadi Grigg (37:19):
Thanks for joining us for another episode of Wicked Good Development, brought to you by Sonatype. Our show was produced by me, Kadi Grigg. If you value our open source and cybersecurity content, please share it with your friends and give us a review on Apple Podcasts or Spotify. Check out our transcripts on Sonatype's blog and reach out to us directly with any questions at wickedgooddev@sonatype.com. See you next time.
