Getting DevSecOps Right in Financial Services

Some of the largest financial services organizations in the world – including the top 5 banks in the US – all use JFrog to deliver applications faster, and more securely. Working closely with these top banks, trading and insurance companies has taught us a thing or two about getting DevSecOps right in these highly regulated, complex environments.

In this webinar you will learn best practices and patterns used by some of the largest FinServ enterprises in the world to accelerate software distribution while mitigating risk. Discover how to enable security, compliance, and auditability as an integral part of your DevOps processes, at scale.

Agenda:

• What are the unique challenges of DevOps and software delivery in highly regulated environments?
• What is DevSecOps and how it enables continuous security and compliance throughout your SDLC
• Best practices for DevSecOps at scale – for both legacy and cloud-native apps
• How Universal Artifact Management alongside Security and Compliance analysis accelerate secured software delivery
• Demo of the JFrog Platform and how JFrog Artifactory & JFrog Xray enable DevSecOps

More resources: 

• Start Free with JFrog
• JFrog for Banking & Financial Services 

 

Webinar Transcript

All right.

All right. Well, hello everyone. My name is Vincent Mayers and welcome to our webinar Getting DevSecOps right for FinTech. So thanks for joining us today. Just before we start, a few housekeeping items for you. First to walk through the webinar console if you’re not familiar that you see in front of you.

All the widgets are clickable and all the windows are available to maximize and minimize. So drag them around the screen to your comfort and so on. And if you’re experiencing any issues with the platform, just let us know in the Q&A box. Usually it will just revolve a refresh.

So any questions you have during the webinar or about the webinar content, please ask those in the Q&A box as well. We will have a Q&A session towards the end of the presentation to answer any of those. This webinar is also being recorded and you’ll receive the recording within the next 24 hours. So that’s it for me. And without further ado, let me introduce you to Will Manning, your webinar presenter for today.

Hey everybody, how are you doing? I’m Will Manning, one of the solution architects. And Vincent, thank you so much for the lead-in here. I’m Will Manning, as Vincent stated. I am one of the solution architects over at JFrog. And today we’re going to be touching on the fun subject of DevSecOps in fintech.

And just a little FYI on this, there are some slides with a lot of words on it. I’m not going to read the words. I’m just going to talk about them in general. We’re going to do a little bit of a product demo. We’re going to be focusing on some of the areas of everything from shift-left and the developer responsibility, into the CICD integration, into the things that you produce and the software bill of materials that you should have, because there are regulations that have that.

And of course, there are more regulations coming, especially in the United States with the Biden administration’s focus on InfoSec and improving the nation cybersecurity. So they’ve gone ahead and implemented this and they will be adopted more and more by more companies. And we’ll talk about that in detail.

But without further ado, let me kick that off with some of the goals we’re going to have today is I’m going to talk about DevSecOps in general. We’re going to talk about regulations planning, best practices, end-to-end security, and lots of other goodness. And as stated, this is me. If you’d like to follow me on Twitter, it’s just William Manning.

Without further ado, let’s kick it off. So, first of all, I’m just going to do a little intro about us. So if you’re not familiar with JFrog or you’re just investigating, or you’re a long time customer, we actually have been around since 2008. We went public last year in September.

But our focus as a company has been a long fruitful process of working with massive amounts companies and various industries and solidifying our place as being basically the name in binaries and binary security. We like to focus on the end to end.

One of the main features of our platform is the fact that we are a complete developer to deployment, to code, to cloud, whatever you say in terms of what end to end DevSecOps really means. We’re built for scale. We have companies that use us, everything from startups to individual students using it, all the way up to some of the largest corporations in the world, all using our platform for binary management.

Why do you need binary management? And we’ll talk about that too. But also, too, we have the ability to integrate into basically every aspect of your DevSecOps solution, from your developer to your CI down to your CD. And we can integrate with all the various tool sets that are on the market. We’re basically tool agnostic. We don’t care what you use.

We’re one of those companies that was like here’s all the things that you can do with us. We’re like a Swiss army knife for DevSecOps, and you fit it into where you need it. One of the key features of our platform, though, is the fact that we are continuous security.

Last week we actually made an announcement that we had acquired company Vdoo and their focus is on security. So our security footing will actually increase a hundred fold over the coming months and years. We are truly hybrid in our nature, meaning we don’t care where you install us. So you can use this in your own environment, in your own data center, in any cloud offering you wish to do.

We also have our own cloud offering if you wanted to use us for that. You can integrate them both together. So we’ve designed this to be as flexible as possible for all of our customers to work, like I said, in the systems that they’re used to thus the ability for us to have an integrated ecosystem of everything.

One of the things we’ll talk about today, like I said, is the developer responsibility. And we’ll talk about things like our ID plugins to provide security at where it matters most. When I talk about the platform, let’s just do a quick overview of some of the things we’ll touch on today. And so this way you understand all the pieces and things that we offer as a solution.

So number one, Artifactory, the cornerstone of our company. It’s the universal binary repository manager. If you really asked me what it really, really truly means is in my opinion, it’s actually a consistency engine. Because it manages all the third party transit of dependencies that you use, it can manage all the builds that you use. You can use this as part of the things that you do for your SDLC, your software development life cycle.

You can also go ahead and utilize it as a meta repository for the things you produce because of the fact… And one of the things we’ll talk about today is because of the way the binaries are stored in Artifactory, I’m not going to go into the big details, but it’s all meta driven. And if you’re using Artifactory already, or you’re planning on using Artifactory, understanding those metadata characteristics really can enhance the experience.

Because like I said, it’s not just a place to store stuff.It’s actually the context of the stuff you build and the stuff that you use and the stuff that you store. Next to that we have Xray, which is our security compliance and vulnerability scanning tool, meaning it’ll look for anything nefarious. And we’re going to talk about that extensively today, those third party transit dependencies. And I have some fun and scary and exciting statistics behind that.

But it can also be used for things like compliance and governance. And we’ll discuss that, too, how you can actively utilize that as part of the solution. To the right of that we have our distribution platform. And our distribution platform is basically you have our distribution hub, and then you have the spokes with the Artifactory edge notes.

They’re lightweight, immutable versions of Artifactory that are used for deployment. And they also would incorporate the security aspect of this. We have this concept of release bundles. Say you’re deploying a web service. You might have a helm chart and a series of Docker images. This allows you to package those up, digitally sign them so they’re secure, and deliver them down to the edge.

One of the things we’ll talk about today is that there’s a lot of financial institutions that have air-gapped environments, meaning you cannot connect to the internet. And we’ll talk about how you can utilize Artifactory for basically those third party ingestion of components. And then on top of that, too, how you can actually use our distribution platform for air gap distribution. We’ll touch on that towards the end.

We have our pipelines product, which is our CICD and CI orchestration tool. Meaning you can use it as a straight CI, continuous integration tool, or you can use it as a continuous deployment tool, or if you already have your own set of CI tooling in place, you can use it as a way to orchestrate those jobs. At the bottom we have access because if we’re talking about security, of course, we’re talking about ACLs. We’re talking about Access Level Controls that you can actually use for your products.

So that you can integrate into your IDP whatever SSO you might be using, whether it’s LDAP or OAuth or SAML, or any multitude of those things, utilizing those to actually have it so you have those permission models that you can have. In addition to that, we also have the things like access tokens for more service style offerings. And at the very top of this, we have mission control and insight.

That’s actually our main common, basically single vision into how everything in the ecosystem is operating. And also with our insight product, providing you characteristics. Just so you guys are aware, one of the things we’ve implemented over the recent months is we’ve opened things like Open Metrics. And having Open Metrics allows you to connect actually Artifactory to tools such as like Splunk or Datadog or Dynatrace, or using things like Prometheus and Grafana to make sure… Grafana, I don’t know where that came from.

But utilizing those to actually monitor your system. And actually one of the things I’ll show today is also that with say you use Splunk as part of this integration, we now have an integration with Splunk and our Xray products so you could actually have a visible dashboard into how your things are going terms of your security and compliance over time.

So let’s go jump into the main focus of this. What is a highly regulated environment? Since we are talking about FinTech. We are talking about the fact that there are certain protocols and procedures that you need to adhere to in terms of being an operationally distinct company when it comes to FinTech. But it also means that this is actually across the board into things like MedTech and aerospace and others.

But the idea behind it is heightened security. Things like physically air-gapped environment. Not pulling in things directly from the internet, having it in some sort of escrow where you can identify, evaluate, and look at things that you might be utilizing for your software. The ability to have separate access level controls for various groups and various aspects behind that.

And today I’m going to actually talk about some new features that we’ve introduced recently. One of the things that we have behind this that can help out is a product inside of our Artifactory product called Projects, which actually will allow to segment groups into more isolated silos and giving them more autonomy, though, to do what they need to do while still ensuring security aspects behind the control.

And understanding that having all these regulations are in place, especially in FinTech, because you’re dealing with money. And you’re dealing with personal data, you’re dealing with financial data. And when you guys are building what you’re building as an organization, understanding best practices on how you can accomplish things better and ensure that you’re providing the best level of control around security from the developer level called shift-left. And we’ll discuss some shift-left mentality.

But through the entire SDLC process, not only doing those aspects of looking at it, but also recording it and understanding that if something is introduced, how you can remediate it and also, too, how far back does it effect what you’re doing? So of course, when you are looking at this, being able to do auditing and having digital signatures.

Because also another thing is we recently introduced with our pipeline product is the idea of signed pipelines. Looking at the aspects of actually having something such as like a bunch of different CI tooling. And in this case, our CI tool pipelines, being able to go through those various steps and actually digitally sign those steps to ensure that you can go back and audit them and look at them and say, “Yes, we did this at this time.”

Having all that metadata, as I said, allows you to accomplish this. And I’m going to less time on the slides and more time on the demo because I think that’s actually where we have our greatest strength. Most of the problems that a lot of FinTech companies run into are these, the things that we’re showing here.

I mean, we understand that there’s gated SDLC or however you understand that. In some cases there’s… A lot of banks have been around for a long time. They have older antiquated processes. There’s a lot of things that are still done manually. Some things are also for developers is one of the main, probably the biggest problem I see with most companies that I deal with, especially in FinTech, is how do you maintain a velocity of development so you can get those features out there?

Everybody wants to be quick and first out there with fixes and remediation and things to entice their users to come and use the platform or enhancements to the security. But also how do you maintain that level of security? How do you make sure that what you’re doing isn’t going to be something that’s going to be terrible? Because nobody who works at the company wants their company to be the headline is hundreds or thousands or millions of records were hacked and pulled from. Nobody wants to be a headline in terms of especially security.

And one of the other things we’ll talk about is, how do you ensure that you always have that level of responsibility where you are looking at the software you’re developing and you have that lineage so that you can go through and track the progress, you can see where things are deployed? If you run into a problem, you can identify them quickly. And like I said, and at the same time, security and compliance is a paramount feature of everything you do.

I mean, if you guys are in FinTech and you work for more larger corporations, think about how every quarter you have to take your quarterly evaluation or your security evaluation or things like that. And I’ve had to do that in the past myself. That’s great. But at the same time, how do you also automate this? And we’ll talk about that today.

Now, the next thing I wanted to discuss here is we want to look at the ideal goals around this, which is, when we work with companies, we look for roadblocks in the process. You should look at things to like automate more that allows you to go in and actually take a lot of the human feelings out of it and evaluate it in a more precise environment.

Looking at it and saying, “We are going to adopt DevSecOps in a way that becomes not only just something that we talk about, but it has to be also a cultural change.” And we’ll talk about that. And that involves the things like develop a responsibility. Being able to go and identify all the gaps in the process. Being able to look at it and make sure it adheres to the regulations.

Designing your SDLC is not only to meet it, but to exceed those expectations. And then also, like I said, automate, automate, automate. I cannot stress automation enough because it gives you more of like a clean room style evaluation. So this way, it’s very set in this nature and providing back direct feedback into these kind of things.

I see some people have actually already been putting some stuff in. I’m glad that you guys are all here. We will definitely be addressing some of these questions. I see that we have some already. But let’s continue through. So like I said, a lot of the things that I’m trying to help here is try to figure out ways that we can help you. Of course, there’s going to be stuff focused around the platform. I mean, I work for JFrog. Of course. This is our webinar.

But at the same time, there’s things you can take away from this, like I said, that kind of goes outside that. Because in a lot of ways, the thing is, is that the adoption of DevSecOps has been a little hard. It’s always the thing, but also, too, and it’s funny, is it needs to be intrusive, but at the same time, it’s something that you need to do all the time.

And most of the companies that we deal with we’ve already started implementing this or they’ve implemented it in some way, but they know it needs movement. It’s not perfect. It doesn’t adhere to everything that they’re trying to do. Or the fact is it’s very limiting in its nature causing delays and, like I said, depleting the velocity that a lot of organizations are going through.

So the first thing that I want to talk about, and this actually comes down to it, is develop a responsibility. You got to remember, a lot of the problems that most software companies run into when they are developing for FinTech is making it easier for developers to work with third party solutions, those third party transit of dependencies. And we’ll get into that.

But doing it in such a way that they have direct feedback into the things that they’re working on. So they understand that if they are bringing these sort of these breaches in or potential threats, then they have some ways to immediately attribute to it. And we know this because a lot of the regulations that are out there that you have to adhere to all kind of are centered around the same thing, which is responsibility for non introduction of potentially threatening things, security hardening and stuff like that.

The ability to audit and evaluate software to make sure that there isn’t the introduction of something bad. And there’s all these various aspects for accountability and auditability and traceability and compliance. And we all know this if you work in the industry. This is just the thing. But also, too, when you have this, there are things that you can do. And I actually recently just added this.

A couple weeks ago, I gave a talk on software bill of materials, like I said, around compliance in the government sector. And it’s very pertinent here because having that software bill of materials allows you to have all that information that you need. And if you look at the stuff that I’ve outlined here on the deck, you guys know this. I’m not saying anything new.

But if you are new to FinTech or you just moved over from another company that has to deal with some sort of financing or whatever, these are things that you need to always keep in mind. And these are the things that we want to make sure that when you have the proper tool sets in place, that it allows you to actually do what you need to do in a more coherent manner.

So what are our options? And we’re going to talk about that. But before we talk about that, let’s talk about some of the reasons why we’re about to talk about what we’re about to talk about. And like I said, how do we do these things? How do we do it without sacrificing velocity? How can we make sure that maybe we have a single framework of tools that will allow us to actually adhere to the compliance rules and standards while still providing the ability for us to operationally run.

There’s many, many questions all the time that come up around this. I field these all the time. So first of all, let’s talk about statistics. We all know about the terrible data breaches and stuff that we see in the world today. How many records have been stolen? I mean, these numbers have grown substantially. This is actually an older image I have. But there’s a breach index and I think it’s actually gone up substantially, especially with last year. And we’ll talk about that soon.

But also, too, if you look here, these are scary numbers here. If you don’t deploy security automation, you have a 95% higher cost associated to it. It’s amazing that in some ways a simple thing can cost financially so much in the long term. But you also want it to be simple and precise. So this is the scariest stat that I’ve ever seen. I love showing this slide and I’ve showed this to other people.

So for every 100 developers, there’s usually 10 ops people and one security person. That’s pretty bad. And so that’s the reason why I always bring up the ideas of automation. Automate as much as you can because this one person per 100 can’t be in all places at all times. So what we’re going to talk about today is binary management. I gave you a little bit of statistics behind that.

We’re going to talk about software bill of materials. We’re going to talk about FOSS management, release storage. When you produce something, how do you have all that accountability? We’re talking about automation, air-gapping, access level controls. And then we’re also going to talk about replication a bit. Because remember I mentioned consistency.

But let’s talk about FOSS. Because everything I show here will actually roll into software bill of materials because this will actually become basically the gold standard for your bill. You can use this as a way for accountability so that you can adhere to all the regulations in a very precise, simple manner. Bill of materials cannot be discounted in any way.

So let’s get started. So let’s start with the fun, scary stats that I talked about. So remember, 85% to 90% of the software that you produce is… I said right. I keep saying right all the time. 85% to 90% of the software that you produce is someone else’s software. These are APIs, libraries, base OS, and things like that. 99% of that contain at least one open source vulnerability and 75% is an open source component that has this.

These numbers are the reason why we are who we are as a company and the reason why this responsibility is so much a part of what you’re doing. Because 49% of the code base analyzed always contains at least one high risk item. 90% of applications use one or more components of outdated or it was abandoned. This is a terrifying statistic.

Think about this. And then remember, when I talk about dependencies, when I talk about FOSS, I’m not just talking about the standard direct dependencies, but I’m also talking about the direct and indirect dependencies. Because remember, when we have dependencies, dependencies depend on other dependencies.

And when you think about this, one of the scariest things is when I read this the first time and I started doing evaluation on this years ago, the fact is that you look at some of these binaries and you say, yeah, somebody stopped working on this four years ago. My God. That means that there’s going to be no updates. Say I find the bug. Maybe it’s my responsibility to go and do this, or do I look for an alternative?

And then the other part about this is that most of these can be just done just by updating libraries. Some of these vulnerabilities that you run into that you’re having can actually just be fixed by a simple update. And one of the things I’m going to show you today is that part of our platform, part of Xray is the fact that you can go in and actually see these remediations as part of it and act on them. And not only that, but also too at the developer level.

The people who are doing this coding… I’m a coder by standard, obviously with my little white here and everything. I’ve been doing this for a long time. And the idea behind it is that the code that they’re producing and these dependencies, being able to prevent some with remediation at that level allows you to reach the velocity and actually go ahead and address the issues you’re running into.

SolarWinds was the biggest thing around this. I mean, think about this, those libraries, those dependencies you’re utilizing, SolarWinds, it affected 18,000 customers. It also affected a bunch of branches of government in the United States. And this was actually, by the way, the catalyst for the Biden administration’s goal of improving the nation’s cyber security.

And this is extremely important because when you look at this, I don’t know if you guys are familiar with the way the hack happened, but it was a third party library that actually was introduced into their Orion software. It was actually deployed in two updates to their customers. It had a 14-day sleep before it opened the back door.

So it waited until the software was deployed, set a timer, opened up the back door and exposed the ability to go in and do crazy amounts of stuff. So when you think about that, the idea behind it is if I’m a developer developing my code, I have all these transit of dependencies that I’m bringing in. I can pile on my code. I go ahead and suddenly I have the vulnerability.

Well, if I have that vulnerability, that vulnerability carries along with it eventually to wherever I deploy this. And when I have that… Oh, it looks like it didn’t put my little skull at the end. Sometimes the screen doesn’t go right. But understanding all these level of complexities on where these software components live and how deeply they’re buried and how something so tiny can actually expose so much.

So when I’m looking at this, that’s where the software bill of materials comes in place. I need to know where these potential threats were actually introduced into my system. And by having that, it also lets me know what I used, how it was built. Was there any environmental variables that were set? What kind of information was there?

If I went through an SDLC, dev, QA, staging, production, I can collect as much additional metadata along with that to adhere to the standards. But also when I go in and if I do find something nefarious or it does not meet my compliance or something gets exposed, I can trace that information to find out from the onset what happened. It allows my root cause analysis to be quicker and then my remediation to be more expedient.

So when I’m looking at this again, the whole did behind it is that once again, I have this software bill of materials to say here’s everything I produced. And say something was actually introduced that was potentially like a change. Here’s a change item. I changed something in the code. It’s not operationally running the way that I want. I could see it inside the software bill of materials where it changed.

And then I can go in… Oh, it looks like it didn’t actually do the second little one. But the thing is that if I did introduce something threatening, I know in the bill of materials. That’s what that little red line indicates. And I can go ahead and say, all right, well, I introduced this. Where did I introduce it? I don’t know if it’s actually showing that last bit. Oh, that’s weird.

It looks like this presentation tool is acting very strange right now. All right. I don’t know if you guys saw my little item that I had there. But this can also be carried over into complex items like Docker. Oh, it went black on me for a minute there. Oops. I hope you guys can still see what I’m presenting. I don’t know. But things like Docker, which are complex entities.

And when you have accountability and a shift towards virtualization, you need to know not only the application you’re running, OS is in it, all the pieces and components that are part of this. And this even goes over to things like web services, where you might have multiple images of Docker and a helm chart. And being able to take all that information and turn it into a bill of materials of a bill of a materials and understanding all the software that you’re creating.

And by introducing something like our Xray product, this allows you to go in and find all those pieces and components that are inside, understand where they were utilized and how they were utilized. And then on top of that, provide end-to-end continuous security and metadata management and things like that. Now, Xray, the way it works is it corresponds.

And I’m going to demonstrate this. But I wanted to kind of just have a quick overview just to kind of show you how the pieces work. So Artifactory works on the idea of check sums. All those binaries that you put up in there have a calculated check sum behind them. And our Xray product uses those calculated check sums for those values of those binaries that you either third party transit of dependencies you use or the stuff that you build.

And it takes that index and it matches it against potential threats. And then you can write rules and policies to evaluate those binaries and perform specific actions. And these actions can be like block the consumption of a binary, flag it, being able to add additional metadata, queue off a secondary process, notify the proper people internally that they need to go and address this.

But really it’s a way for you to have full accountability of everything that you do. And the thing is I’m going to go ahead and in a few moments I’m going to give a full demonstration of everything that we’re talking about. And then I’m going to show you some of the aspects of the things that you need from those compliance, such as the ability to provide all this information so that you could philosophically have a development organization that has security built into it and have it from, like I said, shift-left the developer level.

How you can have a part of the CI process, how you can have a part of the release process, and have that accountability and auditability and traceability so that if something does go wrong, you have root cause analysis easily. You have the ability to go in, and if you get audited, you can provide data functionality back immediately. It’s to expedite the process on top of that.

And then we’re going to talk a little bit about air-gapping. Air-gapping is a big thing with a lot of financial institutions, and we have plenty of information on how you could take like an Artifactory instance externally, have that with Artifactory and Xray, bring in those binaries, have a transfer medium. And they immediately have those available inside Artifactory itself for the internalized developers.

If you can’t have the ability to pull directly from the internet, this is ways to do it. But also, too, we have air gap distribution. And we’ll talk about that too. The ability, if you have remote sites, how do you package up binaries that you need to deliver it, package it up in such a way that it’s digitally signed and available, bring it to a location, upload it, and still have the same results that you had in your one environment to the other.

I’m looking to make sure I have enough time to do this demo. So I’m kind of going through this a little faster. And I hope that the visuals you can see them because I can’t see exactly a hundred percent what I’m presenting right now because I’m getting a weird screen. That’s okay. We’re at the signed pipeline one. I’ll touch upon the fact that we have a CICD tool called Pipelines.

One of the things that you could do is that in the various steps, those very gated processes, that those various parts of your SDLC, you can use our product to either even extend. So say you’re using an existing CI server. You can connect that CI job when it’s done to our Pipeline server and add in the functionality of being able to actually sign those steps that you have accountability to say on this day, at this time, it was digitally approved for this function.

So in other words, I can go from dev to QA and say on this time and place, I hand it off and here’s a digital signature that represents itself. We have that ability. And if you ever want to find out about it, please contact your rep and we can go in. And let me know, we can give a whole breakdown on that. Now, enough time me doing slides. Slides, they’re great. They’re good information to start.

But it’s always good to dive in and actually show something. So let’s go ahead and do a demo. So let me show you some things like how to implement shift-left. How do you actually implement it into your process? I’ll show you a couple of jobs on how you can integrate that in. And then we’ll also talk about some of the release bundle aspects. But I want to show you the accountability behind that.

So let me go ahead and share my screen. And I am going to try to attempt to share my screen. It’s having an issue, it looks like. Oh, here we go. I’m going to… What is going on here? So let’s go ahead and let me show you this is the latest version of our JFrog platform. I’m not saying just Artifactory, but our JFrog platform. And if you’ve worked with Artifactory enough, let’s go ahead and let’s look at one of the new features and functions in here on ways that you can actually go ahead and even segment what you’re doing.

So, as I stated before, actually in one of our latest versions of the product, we actually implemented the idea of projects. Before we had this, you were either a super user or a controlled user in which you had to have certain enablements. That was great. But I’ll tell you right now in larger organizations, it was hard because the thing is that there was so much dependency on whoever the super admins are to actually go ahead and do things like create repositories, assign permissions, add people to those permissions and whatnot.

When we introduced the Project aspects, one of the key factors of introducing the Project aspects is autonomy. So you can actually now create a project in Artifactory where you can have specific roles and specific groups. But the best part is you can have a Project admin. And the Project admin can have control over various aspects of this project, such as you could set things like storage quota and limits. Everything will be associated to a Project key so you can query it to find out data.

If there is a breach, you race it back through just that specific project. You can have them manage their own resources, such as their own repositories and bills. They can invite their own members. So they can add people. You have the ability also too to share binaries between projects at certain levels. So maybe you have one team that creates security modules for every product you produce. You could share them between projects and teams and assign whether they’re read-only access or not.

You can actually have them either you implement global security or even more localized security. So they can have the global aspects that might be the heightened security and they might have their own set of even stronger security basis, say for things like developers. And the best part, like I said, is that they can have their own autonomy.

But when comes down to it is that when we’re using this, remember, we’re going to talk again about repositories and repository security, this third party transit of dependencies. So you have local repositories where you do your builds. This is where you have like your dev, your QA, your staging, your production. These are where the binaries you produce, the things you build, the Docker images you have, this is where it all goes in.

And whenever you define a repository, even your own type, you have the ability at the bottom to say JFrog Xray integration. This is before where I was talking about our Xray product does evaluations based on metadata list, based on the check sum. I’m not going to go too heavily into the check sum base. But just so you’re aware, if you’re not aware with the way we store our binaries is every time you upload a binary into Artifactory, we calculate this unique SHA-256 check sum.

Once you upgrade the SHA-256 check sum, what’s really cool about it is that we do like non duplication. We have metadata representing that binary inside of the database. And each of those representations of that binary in the database could have its own context. But this also means that if you do find an issue from that, that you can actually go ahead and actually see if this binary touched other builds and other jobs.

Understanding the blast rate is, how much did this affect? Now, saying that, that means that our Xray product uses that same valuable metadata to do its x-ray evaluation. Meaning that it’s extremely efficient because it’s actually not checking the physical binary, but the metadata representation behind it. This carries over, of course, to our remote repositories, which are the third party transit of proxies.

The thing is it’s a request-based proxie. So when you request the third party entity and then just to show you a show, I mean, we have all these various repository types. When you request for those third party transit of dependencies, it gets requested. It comes into Artifactory. It gets stored there. It can be evaluated by Xray. If it actually meets your criteria, it can be released to the developer. If it does not be your criteria, you can block it.

You also have the ability to go evaluate it and then release it if it doesn’t actually seem to be something that could be potentially threatening because maybe a binary got reported with a specific function and the specific function you’re not using. So it doesn’t really affect you so you can kind of override it. But the idea behind it is that I want to go in and evaluate these third party trends of dependencies before I utilize them.

Now, saying that, we also have the ability to encapsulate in two things called virtual repositories, where you would actually do your entire project based on the repositories that matter to that project, so that development schema itself. And then we just introduced federator repositories. This is not the place to kind of discuss it. But the idea is your ability to go out and have multiple locations and transfer between those locations.

And actually instead of just doing standard replication that we have now, which is push based, pull based, event based, CRON based, star and mesh. With federator repositories, it’s a full boat replication of those binaries to those other locations or other Artifactory instances in a more succinct manner.

Now that I explained to you kind of like how the binaries can be organized and a little bit, but the thing is, is understanding how these remote repositories works or the binaries that you produce, let’s go in and take a look of how we evaluate them. Because this is actually an essential bit.

So when you are working with Artifactory and you are working with our Xray product and the platform in general and having that full end-to-end solution, the way we do a majority of our work is two ways. And we about develop a responsibility, shift-left. So there’s one way to do it, which is going in and defining policies and watches.

Policies are the rules on how you evaluate binaries and watches is how you actually implement those rules. And with our Xray product, we have two flavors: we have security and we have licensing. And when you define the rules behind this, you give the rule a name, then you have a criteria, which is what you’re going to evaluate it based on.

And then you have a series of actions you can take based on that criteria. Remember, if it’s the criteria, it’s a bad thing. So first of all, you can use CVE. So CVE is usually the standard in which most companies evaluate the nefarious nature of certain binary. Does it have a CVE value? Meaning that there is a threat.

And you can go in and set the severity level to be either low to critical. And we also have all severities. So the ability when that value comes in, so CVE is either informational or warning and then low to highs is it’s characteristic, or you can use things like CVSS score if that’s more your thing. If you’ve never used CVSS score, there’s plenty of information on there.

There’s two versions, there’s V2 and V3. But the idea of it is it’s more of a score. There’s many different factors of that score such as, is it a network thing? Is it a data thing? Is it a malicious like growth thing where it goes in and takes over processes?

But it has this zero to 10 score and then you can set the score and say, hey, if it’s between these two values of the CVSS score, do something. So if you think about it programmatically, criteria is the if statement and then the actions are the then. Now, the actions are the cool part. The actions are these things that you can do so that you can be more on top of the potential threats that you have.

So first of all, you can use our Webhooks. So you can design a Webhook, have a JSON post and post this information somewhere. So it could be something actionable like JIRA or something like that. And just so you know, by the way, if you’re a user of say something like Microsoft Teams, we’re also going to be introducing a new Microsoft Teams integration and some other integrations in the future to make this more of an active participant too.

When you define a watch, which is how you actually apply a rule, one of the parameters is an email address. And this will actually allow you to send an email to said recipients. We also have the ability to do another email in this case. So say you have a critical issue and you have a red team that says a red team handles all high priority items. You can send it directly to them.

Now, I’m going to give you a little bit of the best practice that I give to most of our customers that come in and they’re just starting to implement Xray and Artifactory. Okay? The first thing is the next of the features are very aggressive. And if you’re new to this, I’m going to tell you right now, if you implement these features and you’ve never evaluated the binaries that you’re using, you’re going to break everything.

Everything is going to shut down depending on the values that you set. Because we’re going to block a tremendous amount of things you probably don’t even realize you’re doing. So what we have here is I’m going to talk about the aggressive features first. And then I’m going to talk to you about how you could start evaluating and start thinking about action plans based on that evaluation. And then how you can then implement these features afterwards when you’ve gotten to a comfortable level where you know you’re not going to disrupt all the builds without actually it being something that should be disrupting what you’re building.

So first of all, block download. The block download functionality will go ahead and say you have a binary in the system and a new zero day comes out. A new problem with this binary comes out. It’s a critical nature or whatever you set the threshold on the evaluation for. It will block the consumption, add that binary from that moment forward until you allow it, or not allow it maybe.

And it will also block any of the versions of that, but this will let you know that anything in perpetuity that that is behind it is not available until you evaluate it and look at it. Now, what about future or new binaries? Well, that’s where we have the idea of block on scanned artifacts. This means that this gives your developers… If you have an air-gapped environment, you can kind of do this too.

But this is for the ability for you to go in and say, “I want to be able to give my developers flexibility and responsibility, but I want to be able to have it so that they use this new library to build whatever they’re building. We want to evaluate it before they get their hands on it, before it actually gets to them.” That means that the developer can request it or the CI tool can request that binary. It gets proxied into Artifactory. It gets evaluated by Xray.

If it meets the criteria of your organization, both on the compliance side and also on the security side, it’ll be released to the developer. If not, they will receive an error message that this is currently not available. I mentioned release bundles before. That distribution side of our platform. And what we have here is we have actually block release bundles.

So you could even have shift-left with the developer, or you can even at the far end of this have it right before it gets into production, you can give it one last scan, one last little blessing before you send it out the door to wherever its destination happens to be. And then of course we have things like the obligatory fail build.

Now, these features here, like I said, are a little bit more aggressive and they’re built that way on purpose. They’re built to protect. But at the same time, yes, they could be obtrusive. I’ll tell you right now, I’ve heard from many companies like, “We turned this on and suddenly all our builds broke.” That is good because it’s also letting you know potential financial risk, reputation loss.

Remember, it’s not just finance and all that. It’s also reputation. Like I said, you don’t want to be that company that gets mentioned in the headline for a potential threat that could have been resolved by a simple fix. Now, let me talk about the second type of policy we have, and then I’m going to show you develop a responsibility at its finest. Okay.

And if you look here, we have licensing. So for licensing, just so you know, with our rule sets, you actually have the same actions. We treat licensing just severely as we do with the standard security stuff. The difference is the criteria. So we have like allowed licenses and banned licenses. That goes without saying. If you have your own license, you could upload it into Xray and you can make it part of the evaluation list.

We also have the ability to disallow unknown licensed. You’d be surprised how many binary types out there have unknown licenses, where somebody put a indirect dependency. Maybe not the dependency you’re using, but it’s indirect dependencies for that. This will allow you to stop that because unknown licenses can be just as bad as security threats.

And then you have things like shadowing and spoofing. And one of the clear indicators sometimes is the fact of multiple license. Maybe somebody uses a standard GPL, but then has an addendum behind that GPL that says everything you do belongs to us and you need to attribute it to us and let us know. Ways to stop the ability to have those ancillary licenses that are attached to the primary, which usually indicates something bad.

But as I said before, these can be very aggressive features. So when I look at maybe how I’ve deployed these, because when I want to deploy these rules and these policies, I should actually go back and show you because I don’t have any policies defined there.

But in my policies here, I can go ahead and attach them to say all the repositories that I’m utilizing. I can attach it to specific repositories I’m using. I can go in and say I want to do certain aspects. You have a lot of flexibility in how you want to evaluate the binaries at the repository level.

You can also go ahead and attach these policies to build specifically, not even the repositories. Every time a new build comes in, you can say all builds I want or specific builds I want to have certain restrictions on, or I want to have certain patterns on how I evaluate these.

And even now, like I said, my releases, I can evaluate them here by attaching my policies. But even when I’ve done something like this and I said if you put those aggressive versions in first, you could still go in and get a tremendous amount of information just by simply going in and looking at say how these policies were designed and built.

And we have in the product the ability to see the results of that and allow you to say, “Oh my God, we didn’t realize it was this bad.” Here’s an example of where I’m watching a Docker repository. And if you look, I have a tremendous amount of actual vulnerabilities I potentially introduced.

But I could have stopped this early. I could have stopped a lot of this stuff early simply by enacting something like the ID plugin that we have. And I’m going to show you that right now. So we talked about how you can actually automate some of this functionality. But at the same time, say I’m using something like VS code.

If you look here, I’m working on a GO project. And the GO project I’m working on, I have a whole bunch of transit of dependencies and indirect dependencies. How do I know these are safe? But if I’m a developer, I want the ability to go in and address these before they start.

So if you look at my dependency list here, you can see that I’ve actually got the JFrog Xray plugin. I have this also for IntelliJ, a cliff, Visual Studio. But as a developer, I can go in here and look at the things that I’m utilizing, right? So here, if you look, I actually see that this library I have here that I’m depending on has three vulnerabilities.

I can even go in here and find it on the other side and say, “Oh look, here’s the dependency. Here’s the indirect dependency. It has an issue. It has one issue here. But also I provide remediation.” So this is another aspect that a lot of people don’t realize that we offer, which is I can actually have developer responsibility. I can automate the evaluation of binaries before they use them.

I can also automate the evaluation of continuously evaluating inside of Artifactory. This provides a simple level of security at where it matters most, which is at the developer level. This is your first line of defense. This is the greatest ROI you can [inaudible 00:48:49]. Now, saying that, I want to talk about builds.

So let me share Artifactory again. And let’s talk about a build. So that’s at the developer level. And I know we are very, very limited on time. So like I said, I am kind of expediting this a bit because I want to be able to show you everything that I’m doing. So let’s go ahead and look at say a build that I produce.

So I already showed you the shift-left mentality. I showed you how you can evaluate it. but what does it look like when I put into say something like a build? How can I utilize it part of the next step? And by the way, I’m about to show you how you can actually ahead and attribute to the software bill of materials So you know how things were actually built in an automated fashion.

Let’s go look at a dock build right here. Okay? I’m going to show you. Now, I’m using Jenkins in this case. And actually, I’m actually going to share my entire screen case for you guys. I can. All right. Let’s do this. So I’m going to share this. Here. So now let’s go in and let’s look at this again, because I want to be able to show you some of the features behind this.

So first of all, let’s go look at the job I have. So this is my Jenkins server that is actually producing it. And if you look, when I was showing you that, this is a direct link in our product to the actual build that produced it. Now, you might ask yourself, “That’s great. Don’t I have all this information available already? Don’t I already have all this level of detail I have?” Yeah, you do. But it’s in different areas. But you don’t have the full picture.

So let’s go take a look at what it produced. So first of all, let me show you the steps that I took to get to here. Let’s go look at that right now. So if I look at these steps, you can see where I’m actually like cloning this out of my GitHub. Here’s my dependencies that I’m pulling. I’m going to build and deploy it. I’m going to test it. I’m going to Xray scan it and I’m going to promote it.

Now, if I were to show you what that looks like. I’m going to show you right now. Let me log in. And I’m going to show you what the job I had that produced that and what that looks like. Okay. This actually was logged in and then it took me out. So let me go head to the build that I did. So let’s go in and look at my GitHub where I have this located.

I’m going to look at the seven steps. I’m going to go ahead and find the build I’m showing you right now. I’m going to show you the Jenkins file behind it. And let’s go look at it in it’s raw form. So if you look here, we have a plugin for all the major CI systems. So you can use that or you can use our JFrog CLI. It doesn’t matter. There’s multitudes of way.

We have this all very well documented. That’s not why I’m diving into it directly. But just to show you, I’m using the Artifactory plugin. I’m going to collect all the information around how it was built. I can dynamically pull in the actual dependencies that I need to support this container, the application level. Remember, there’s application, there’s also application run time. And then there’s also to the LS.

I’m going to go ahead and build it based on the dependencies I have. I’ve got a unit test to say it’s functional. Now, if you want to integrate Xray to evaluate it, it’s easy. Here’s the stage for Xray. All I have to do is I have my plugin, Artifactory, I’m going to say Xray scan. I’m going to pass the job name and the build number I’m using for this.

And then in this case, I’m just printing the results out, but I’m also capturing the results. And then also, just so you’re aware, based on that, I can automate from one phase of my SDLC to the next. So I can actually say I want to move it from say my source repository, where I’m actually evaluating it initially, and promote it somewhere. And in this case, I’m going to say it’s released.

So I’m actually going through and building it and automating it. We have webinars that are all just directly dedicated to how you actually integrate the CI process. But I want to share the results so you understand what’s being produced here because that’s the important part.

So look at the bill that was produced. It was promoted, even though it contains a real issue. And understanding actually what’s part of this, because usually when you produce something, you get a series of outputs. Why would you want to know all this information? Well, you get a series of outputs. But I don’t know what’s in there.

Well, if you use ours and you use our best practices, I can say here’s this Docker image. And I can also show you that I have a node for an end and I have a Java backend. I could show you what version of the application I’m hosting without me having to go hunt things down. This is also accountability in the software bill of materials.

But say something does go wrong. I want to have a root cause analysis. There was a problem that happened. I could actually go in here and actually do a diff between two Docker images at the application level, at the dependency level to say that, hey, we had a problem. I need to go in and address it.

I could show you if something was actually… How it was built, all the environmental and system information. Because sometimes some of the biggest threats that you have to your organization with the release of your software can be actually attributed to somebody leaving something on in the environmental variables.

Maybe there is a port that you can monitor to say this is how the application I’m running is doing. Always make sure you turn it off because we don’t want to have it exposed when we go live with this. This will allow you to go in and say, “Oh, we didn’t set that bullion to say that we want it to be non-motoring equals false. We left it at true. Oh, that could have been the security leak we had.

But also now I can show you every little component, every third party transit of dependency that was actually utilized for this. The base so west, the run time, the application. And if you look here, this container has almost 1100 violations. It has over 300 security threats that are actually in here. And this is not just one layer. It’s not just one part.

These are pieces all throughout this image. It’s a very complex thing. But let’s go look at one of them. Well, first of all, we have remediation. Oh, look at this. You know what? This is an issue, but hey, the binary that I’m using for this, if I move up to version, I can actually fix this. Remember what I said before, 74% of all fixes for potential threats can be done by a simple update. A simple update.

This allows me to say I need to move up to this version. I could check that off my list [inaudible 00:55:46] information on why there’s such a threat, including any sort of reference information associated to it. But the part is to the right. Look at this. Here is this potentially threatening jar, this jar in a jar of a layer of an image of a build.

We went that deep into it and we found this hiding inside of another one. These are the threats that are real. This isn’t like SolarWinds. This happened because of a third party transit of dependency to the main set of functionality that was actually being utilized by their core software. But also, too, attribution. And you have governance and compliance.

So if you look here, you can easily pull out every single piece of license that you have for everything that you produce. It’s all right here. You can also see in the standard, anything like if you work at Docker, anything long enough, if you look, here’s all those Docker layers. How do you know what’s in those Docker image layers?

It’s one of those things that surprises me. Well, you have the ability, you can literally go into this layer and see what’s in the layer. What third party application stuff is in here, including the ability for you to go in and even look at even like a jar and its sub-components and then the individual characteristics behind it.

And you can view this to see where it’s been used somewhere else. You have the ability to look at issues like your jury. You could associate the information. This is all bill of materials information. You could actually even diff between two Docker images at the artifact level, the dependency level, the environmental system. Any software that you publish into here, you could do a diff cause analysis.

What changed between these two builds? You could actually have all those layers. You could have SDLC. Everything here. Now, this area, I could publish as much metadata as I want into each one of these SDLC components to say, hey, this bill went out. It was terrible. We got a report that there’s a security threat with it. How do I know?

And you can get, did it go through QA? Yes, it did. It got signed off. Here’s all the QA results. And then if you need to pull all this information and put it into a report, it’s all simple JSON. All that information I showed you is right here. It has everything you need in one location. It’s all ready for you to access and build out those reports.

And we even have reports that you can even build around it where I can say I’m going to create a report on builds. And I can go in. And actually if I need to supply this to somebody, I can say, okay, I want to grab the latest build or I want to go mini revisions back and I want to find out all the information around it.

So I can actually go ahead and write these reports. They take time. So I’m actually just going to go click into like a license report that I did. It shows you everything I need. Like I said, I’m going over time a little bit and I’m sorry. I’m going to try to stick around for a couple questions.

But I wanted to kind of show the fact that you have this level of accountability, that you can do distribution platform, where I can go ahead and generate things like say I have here say a release bundle, or I was talking about before. But I actually have the ability to go ahead and export a release bundle to bring somewhere.

And I could actually go ahead and show you. I think I’ve got… Oh, I don’t have Xray enabled on this one. But I can even scan multi complex, multi-layer components. And then we even have the ability for you to go in. And even if you wanted to know when we were talking before about, how do I know if I found something nefarious? How do I know what else is affected?

And if you look, I have multiple versions of a library in here. And if you have all that build information, the bill of materials, all those things that you’ve kind of pulled in to Artifactory, you actually inherently have the ability for you to go look at any potential threats that you have and say, “Hey, how far back was this used?”

Oh, well, if you look here, actually this [inaudible 01:00:11] I can reference them across builds. It has its own Xray data. But then on the other side of this, just so you know, I can also go in and look at it and I can expect all the finer details on this binary. I can look at this information. It’s a dependency that I’m using.

But I can look at these indirect dependencies, which are right here. These are the direct dependencies for this, but it’s indirect dependency for me. And I can see the scope and the scale in which I’ve actually had something utilized. Having that bill of materials, instant remediation data, the ability for root cause analysis information, tracking and tracing. It’s all built into our platform.

I wish I had another hour to discuss this and dive into it. But then the thing is that I do want to show one thing, because I think it’s one of the coolest new features that we’ve implemented. I talked about monitoring. How do you monitor this? Well, you can monitor this in Artifactory. That goes without saying.

But also, too, if you are using say a third party tool, say something like Splunk or any of those, we have this data readily available to you. And I can go in and look at say my platform deployment that I’m going to show you some of the things I have here. But I can go into my Xray information and we now expose this.

So if I wanted to look at say any of the information I might have or say, I don’t know, the month to a date, let’s just do a quick search. This will actually go. Of course I probably should have done year to date maybe. But the idea behind it is that it is going to pull up all the information on this.

How do I have accountability for the things I produce in such a way that I can do it actively? So this is actually connected to this system I was just showing you, but it shows me like the number of vulnerabilities, number of licensing issues that I’ve had. This also shows me, what are the highest potential violations and watches? Which policies are causing the most? Which rule is queuing off the most?

And even down to I can also look at the latest issues in an easier manner. So I wanted to show you that development gives you the ability to layer on top of some of the processes that you’re already doing, but also it allows you to go in and implement a vast array of ways for you to actually ensure that you’re providing the same level of security across the board.

So having the binary management, the security vulnerability scanning, release management that shows you the bill of materials. The biggest thing is developer education and having the ability for them to use the ID plug-ins for that evaluation. And then automate, automate, automate as best you can.

I’m going to take some questions now. But I wanted to say thank you. I’m sorry that some of it actually got a little wacky there. The tool I’m using blanked out on me. And I hope you guys were able to see some of the information. I know there was a question that says, what should be the major benefits of using JFrog Artifactory rather than Nexus?

Well, actually there are multitude of things. So first of all, if somebody’s asking about Nexus over us, well, the way we store our binaries, number one. It allows it so that there’s better space retention. The way we actually store the binaries in terms of mapping those dependencies is another. The ability to have as much supplemental metadata as possible to represent everything that you produce and build.

The accountability is another. The act of actual remediation information. There’s a lot of reasons why. Replication is another huge one. You have more than one location providing secure replication between those locations to make sure everybody has a consistent method. There’s on and on. There’s a lot of features.

We’ve seen a lot of companies that have moved over from them to us, hundreds a year a time. The thing is they’re good people. They’re a fine company. We just do things better. I work here. So of course I’m going to say that. And I mean it, a hundred percent. I’ve been here for the company for a long time.

But I hope some of this information has been useful. I hope you guys have been able to see and hear me. I don’t know. But thank you for your time. If you have any questions, this will kind be a nice time to do it right now. And if not, thank you again. This will be available. And I am always available on Twitter.

And also, too, if you’d like to speak to one of our reps, you’re already a customer, let us know. I’d love to have deeper dives and discussions around that. Thank you for your time, everybody. All right. I think I’m going to take us out. I don’t know how to end this. I don’t think I can end this. Vincent.