Continuously Securing The Software Supply Chain

With new software supply chain attacks reaching the spotlight at an accelerating pace, security research uncovering novel attack methods, and new mandates and guidelines starting to come into effect — it can be hard to stay on top of the latest developments and their implications.

Catch this session to see a breakdown of the recent news related to software supply chain security and what you can do to meet new requirements and protect your software from such attacks.

Get a technical deep-dive on:

  • Recent software supply chain attacks and the attack methods behind them (eg: namesquatting and placement of malicious libraries in commonly used repositories)
  • Progress in standards and guidelines such as the White House Executive Order on Improving the Nation’s Cybersecurity and what action they will require
  • Best practices when incorporating a shift-left security strategy into your SDLC to effectively manage software supply chain risks
  • Software bill of materials (SBOM) – what you should track and how to manage it as an integrated part of your SDLC


Good morning, good afternoon, good evening everyone! My name is Courtney Gold, I will be your moderator today. For today’s webinar just a quick couple of housekeeping items before we get started as a reminder this webinar is being recorded so you will be able to receive this recording post-event, as a reminder we do have a QA chat box at the very bottom of your screen so please don’t hesitate to ask all questions we’ll try to get to them during or after the event. Other than that I’m going to let Asaf take it away. Thank you, Asaf.
Thank you, Courtney. Hi everyone it’s a it’s a pleasure to be here and i’m so excited to be here with you uh and today we’re going to discuss about how to continuously secure your software supply chain essentially using the jfrog platform. Before jumping into the technical part of explaining what are the features and the items that we’re going to cover uh first small introduction about about myself.

My name is Asaf Cohen and I lead the security solutions at jfrog and been in cyber security field for the past 20 years doing mostly hands-on things such as you know ventilation testing defense operation and so on uh hunting it so i come from a solid security background and i joined jericho because uh as part of the video position because we can better together can deliver best security to our customers uh using our unique platform um so enough about me uh let’s go straight ahead to the agenda and as jordan mentioned please feel free to ask any questions just write it down on the chat box and uh we’ll answer it later okay so today the agenda is to uh very simple is to cover the challenges that we see the developers are facing while trying to uh to have secure security devsecops operation then we’re going to cover the overview about what is j4 platform enables us for devsecops and later on we’re going to wrap up with the demo it’s going to be a pretty long demo that’s going to cover all the checkbooks and items that uh that exist in as part of this explanation uh but again if you have any questions feel free to to set it up in this topic we’re going to cover uh many things in the joyful platform not just specifically x-ray which is the software composition analysis solution that jeffree is having but also going to run through the security benefits of having j4 got the factory with distribution engine from pipelines pretty much covering the main security features in each one so let’s start with the brief uh brief description about the developer workflow it’s a very simple and straightforward diagram of essentially a developer that writes and develop code on on its workstation then let’s assume that the developer is using npm package with npm package it has json it has package.json file that represents perhaps the open source software components that should be included as part of this package and once the developer runs npm install and do a git commit essentially the packages are being pulled into the developer workstation and once the git commit command is being triggered the ci in this case jenkins the ci server kicks in and produce the battery and this is from 10 000 feet the work the workflow the developers are having on their day-to-day work and what we see in here is that there is no security whatsoever for the pipeline there is no protection against dependency confusion no no protection against typos quoting no tracing visibility uh security features caching signed pipelines essentially the developer is potentially can be attacked by malicious actors and what we’re going to see right now is how does the j4 end-to-end solution allow us to have dev staff tops as part of this uh sort of this motion or devops operation so what we see is a very big and scary slide but don’t worry we’re going to go piece by piece in this diagram i’m going to explain about the features and how does the different products interact and help to set using one another the whole security operation so what we see let’s start with uh the public depositories and we see that the main product that we have at j4 is artifact factory is a is a product that manages all the batteries that you have within your organization it’s a battery management platform that pulls that has pretty much many type of repositories if you’re familiar with it we have we have remote depositories which are repositories that represent publicly available repositories such as the maven or npm and so on we have local repositories that are repositories for placing your first party code packages that should be accessible only to your company we have virtual repositories that uh that represent with one url a combination or a set of local enabled repositories and using altifactory uh uh we recommend set up different repositories for each team so uh each team should have its own set of repositories that represent the dev the qa and the body environment and by that matter you can best manage your whole bin ops or the operation and promotion of batteries between one step to the other so this is very important using artifactory best practices to set up a set of repositories per team that is well documented that 100 that we can understand what each team is doing and what binary which binaries are being used by each team obviously our factory does the optimization of not storing multiple copies of the same package it does this using checksum so it’s a smart uh storage also secure storage so the way autofactory store the batteries is secure better so we’re gonna learn about artifactory and the feature security features that the different repositories can can uh can be configured with in order to protect against uh volatile solution and type of spotting we’re going to start with out factory features we’re going to talk about x-ray which is the surface composition analysis solution the j-probe is having and x-ray uh is tied out really good into the artifactory and the platform itself so x-ray can scan and be essentially a gatekeeper application gatekeeper for incoming packages that can scan repositories bills and also release bundles so x-ray can be integrated in every step in the ci process and can provide you with the visibility and control to have a secure batteries that match the security policy that you would like to have in your organization uh we’re gonna talk about distribution distribution is the solution for uh for creating release bundles where these bundles are essentially a zip that that has uh batteries inside it and this zip is cryptographically signed in an unmute to unmutable matter and using distribution this can be in a secure manner distributed to the edge distributed the edge nodes that can deliver the battery closed amp to the last half quarter and while before being delivered to the end devices uh we’re going to talk about the whole permission set that artifact and the old path would offer we have the signed pipelines which is which is a feature in the type in the default pipelines default pipelines is a jfrog homemade ci solution that supports best practices when it comes to security such as side pipelines and also stick consultation using a secure vault that will keep the passwords inside the pipelines so the yama files that develops are being exposed to are only have the friendly name that represent the identity of the integration and that that way you can store all the passwords invite in one place and and not have those passwords scattered around the uh the different piano files in the in these in the devops device in the ci servers uh so so far we talked about i would say what they call the backhand uh the the where the security operations and devops have full control and to to have visibility as well as control and enforcement of the policy that they would like to have to have a solid secured pipeline now i’m going to refer to the what i like to call the front-end or the or the developers view that the developers can utilize the x-ray plug-in which is a plug-in that integrates natively into the developer’s ide in order to in the id itself show the potential vulnerabilities of those open source software components and enable the developers to make the right decision because we as security experts we have this ability to what we see here about artifacts and their uh uh cves and and we can do reporting on it but eventually we would need to work with the developer to solve solve the issues so that’s why it’s very important to enable a developer an empower developer to use the plugin and make the right decision because it will save both the developer and the security operations uh a lot of time we’re also going to demonstrate uh that we have a cli that works in parallel that have the same capabilities but parallel to the uh x-ray plug-in that can run dependency scanning on source code and utilize the same api towards the x-ray server same as the x-ray plug-in and it can run on the source code and on the dependency that are being placed in this in the source code file and it run dependency scanning on those on those projects again to enable the shift life approach and empower the developers to use those capabilities either in their native plug-in or in any way they would like because the cli can be integrated to many many types of places any questions so far before uh jumping into the to the explanation about uh deep dive into x-ray and then going on to the demo not yet okay great all right so uh zooming in on the extra piece we gotta also uh see a demo later on about everything but essentially x-ray as as devastated before can uh can be integrated as part of the cicd process and enable devstack ops because it’s being so integrated as part of the output spot of delta factory artifactory is where the developers and the devops work and having the security operation integrated into this uh workflow enables secure devsecops operation that have coverage of both new artifacts that are coming in both every build and as a gatekeeper for the release bundle before being released to the edge nodes so the way it works at any time you have an artifact or a build or release bundle x-ray can be triggered to scan based on a predefined set of policies and watches we’re going to learn about this later on so it will run the scanning against one or more policies that can be configured and each policy you’re going to see that has can trigger a violation with different severity and what’s more important is the post-detection actions that can be made so you will see that each policy has an if and it then statements so the if is what we will configure based on the severity or the cvs escort and then allow you to automate the process based on the uh security policy that you would like to have so we can start with the uh we recommend to start with uh setting up notification post action rules such as send an email write to a stack channel configure it to send something on a web hook or you can do more restrictive actions such as prevent the download of the battery fail the build or block the distribution of the release button so using this flexibility of the x-ray product you can set up the different policies to different stages in your ci and have a strict security policy that match what the organization looks for and more importantly is you’re going to see in the demo itself that we have many type of menus and many type of uh configuration which allow you to have the flexibility to define what you want to have and by this i mean that it’s not about solving all the cvs it’s about because you would never get to a situation that you sold all the cvs and you get a docker or an application that has zero cpes because eighty percent of the code of the products are based on open source software components and offers of software components uh might have cves and as we as we see the world uh moving forward we see that many uh eventually each product might uh might have cv this and that uh and those cves uh i’m not saying that those are uh uh good or bad i’m saying it depends on what you would like to achieve within your organization essentially if you’re a small startup or you’re a mature company or you’re a very mature company that sells uh product to the government you should not it doesn’t make sense for you to have the same x-ray policy for each one of those companies so by having this flexibility you can fine-tune the policy the way you would like and make sure that that you deliver uh the secure batteries that you would if you would have for instance later on in the demo we’re gonna see uh a release bundle that has been scanned by x-ray that had cv that has cves but it does not have any violations because it’s good enough for us because all the all the cvs are ranked as like five and below for instance okay uh so this is about the x-ray also i mentioned uh beforehand the shift left and the empowerment of the developers so we the plugins ports uh uh those ides that should cover uh all the all the uh all the relevant ideas that developers are using today as well as we have the cli that can have the dependency scan and the ongoing scan this is how it looks like we’re going to see this also in the demo so uh what we’re going to see in this demo we’re going to see the first we’re going to start with the developer view of the id integration and the cli how does it look like developer view and how can this empower the developer to identify the vulnerable packages later on we’re going to see artifactory and how does the virtual repositories volatile resolution uh include exclude patterns the billing phone the logs and the whole promotion can help you to create uh protection against dependency with fusion type of squatting and generic s1 we’re going to later on see x-ray uh how does the surface of the composition analysis when it comes to the cves any reporting capabilities allowed to protect against uh effect identify and prevent usage of vulnerable packages and get reducibility we’re going to talk about different pipelines to understand what are sound pipelines and secret notations and so on that as well as distribution of the signed batteries and those two less components can can help to protect against when the middle or intervention uh as part of the ci process so all in all we can see the jfo platform provided end-to-end security solutions starting from the developer all the way to the end batteries to help to a get and get the security of the batteries that you produce and b protect your pipeline and make sure that you proclaim getting the best security features okay so let’s go straight ahead to the demo i would first like to start with the with the ide just to show you how does it look so in this case you see that we have a visual studio code we have uh npm package that we built we have the package.json and we can see that we’ve declared those dependencies and you can see that we have the jfog uh plugin installed on this ide and as soon as going to go in here i can see all the dependencies and the transitive dependencies meaning the dependencies that they uh include as well so you get full visibility to all the open source software components that uh that are important as part of your battery and this is very important and for each uh for each library you can see the the artifact details and the issues so let’s just go uh either this one and you can see that we identified this uh component is of this version with npm with the relevant licenses and we see that there is a security issue we have this cve for this component and the fixed version is to use 400 so it’s very simple and intuitive for the developer to just upgrade to the latest version or essentially make the right decision when it comes to which open source software components to include while having the build the second uh the second illustration is about the cli i just ran it in advance i’m going to run it here because i wanted to see like the results while it’s loaded up what it’s doing right now behind the scene this cli scan the dependencies from the project from the source just like we saw before it sends the information through an api to the x-ray server and this produce this uh this table of uh vulnerabilities this you can see this is uh correlates to the plugin that we showed earlier so we have those we have these cves we have the vulnerable packages we know that we need to upgrade to this and that with the relevant css core and so on and you can also run the cli right now it runs without any context but you can also have the watch that i’m going to talk about later on but you can also include a context or a watch you would like to run the scan against um so this is what this is how the developer can use the jfrog front-end uh uh components or product products to make the right decision now let’s go on to the platform itself to see how does it look like uh on the platform for the security operations and the devops so first let me log in


real quick




and uh i hope you can see here the uh the diagram let’s start we start with the id and the cli functionality let’s go into our factory understand how can it help how can it be configured to protect to protect against dependency confusion and type exporting attacks so uh let’s go to the repository section you can see that we have the local remote and virtual and for each local uh for which local repository you can let’s take this one as an example first i would recommend you to see that the important uh repositories are flagged to be scanned with x-ray that’s one and you can see it also has an included screw pattern i’m going to explain shortly what is this and you can see under the advanced app that you can set up the most resolution for the important uh uh for the toyotas repositories that you would like to have during the resolution what does it mean and let’s give a complete example let’s assume that i developed in my company uh let’s let’s assume that i’m working a company named a soft company very uh very unique name and i create in inside my uh inside my organization i have my own private proprietary library which is a soft lib for instance so of course i would i would place a soft lip in one of the local repositories because i don’t want to publish it to the external uh internet so i publish it in my local repositories and in my code i all the time referred to as athlete latest so whenever uh whenever someone is going to resolve this package uh it will utilize the virtual repository which is the one url that that represents a set of local remote repositories and as soon as the uh as soon as this uh softly library is going to be resolved using the virtual repository it will go in and look for all the for the latest package so it will first go into example the local repositories it will identify that i have a softly version let’s say two and it will also going to check the other equal source with the target to find the latest so let’s assume a malicious actor somehow know that i developed with an internal package called saflib and he’s going to upload to the global repository a new package with the name a softly version 1000 so our defactory is part of the resolution process is going to let is going to look up for the latest and that’s how dependency confusion attack is being triggered if someone is able to to have the same package name with the late with the newer version uh so obviously the latest version is what is the one that’s going to be uh eventually going to be in the resolution process and this is what will be served to the developer and the ci system by setting up the flag for the political resolution uh repositories it means that artifactory first going to do the lookup for those uh toyotas repositories meaning that as soon as it will do the search on the subset of depositories that are marked as product resolution it will find the softly version 2 as the latest and it will serve this if it has not find the package in those set of biologists resolution repositories it will go and search for external for the other repositories and that’s how it will result from the external one but setting political solution on repositories or local repositories that you have that that has your internal id will help you to protect against defense confusion attack and this is very important feature to know about so that’s about an example about token repositories let’s go on to remote repositories okay in the remote repositories uh let’s take this one for instance you can see that again you can select whether you want to index or not this repository with x-ray as well as you can set up uh include and exclude patterns sorry i missed this okay here it is include an exclude patterns which essentially using a regular expression you can set up which artifacts you would like to resolve from this repository so you can have either include patterns or you can have also a two exclude pattern as again as best practice if i would in my company i would go for all the remote repository going to exclude the pattern a softly


and that way i can make sure that i don’t have any type of spotting or anything that i did not intend to resolve for those remote repositories so this is about the protection against typo spotting when it comes to virtual repositories so as mentioned we have one url that uh that represents a set of local and remote depositories and just for you just for you to see uh you can change the order of resolution and you can see that anyway uh jfrog platform always resolved first from the local repositories and then go to the remote one just as they as a default action when it comes to the resolution process and if you set if you mark a set of local repositories as polarity solution it will first going to look from them and then going to move forward okay so we covered so far out of this diagram we covered the ide cover the dependency scanning we covered the protection and the security features in lte factory as part of the depending on fusion and type of spotting and now we’re ready to move on to x-ray so let’s go to x-ray


okay, when it comes to x-ray sorry when it comes to x-ray um so I’m going to explain what is a policy and what is watch and how can you, by using these functionalities can set up the right security policy that you would like to have so let’s start with creating a new policy let’s call it uh asphalt a description whatever and you can see that each policy can have one or more rules what are those rules you have the rule name and you have the if and the event criteria so let’s start with the if can be by severity such as the low medium high or critical or you can find it with based on the cvs score so I can say that this uh policy or this rule is going to apply if the cvss score is between 8 or 10. so this is the if and if it match the criteria if it will go to the automatic action that first it’s going to to generate a violation that’s for sure and then the uh the then that action can be divided into two sections like the notification area and the restriction the restriction area so when it comes to identification you can set up you can click on the web book you cannot define the watchers you cannot find the deploy you can send out custom emails you can automatically get jio tickets and when it comes to if you want to get full control you can block the download as well as unscathed artifact from the repository you can block the distribution of the release model or you can also fail the build and set up a grace period of x amount of days so you don’t going to fail all the bills at once uh but you can see all the flexibility when it comes to the uh to the post detection actions you can have and using a watch i’m going to show this shortly you can also define uh on what you want to apply this policy on a repository or a build or this bundle and let’s go straight ahead to this just to show you an example of license by the way if you’re interested in false compliance you can also use x-ray to have the same uh set of like the rule name the if area that you have the allowed license or the bed licenses and you can you can mark like licenses that you would like to have or unknown licenses or multiple license and so on this is the if and in the then you have the same set of operation of notification as well as prevention i would say so let’s go to the watches


so once we define the policy that we would like to have in our organization you can create a watch a watch is the glue that associate the policy to the entities in j4 platform so you can see that you have the you can set up x amount number policy of policies you would not would like to have and you want to have you want to assign those this amount of policies to this and that repositories or this in that build or this and that release bundle and you can have uh you can have with full custom customizable uh manner to select the repositories or select the bills and so on and by this you pretty much have the whole flexibility and going back to what i said earlier the flexibility to define the security level that you would like to have with the uh different steps that you want to have in your security maturity in the maturity of your security that you would like to have because small startup should not have the same policies and watches as a mature company or mature corporate i would say and it’s not the same as a mature company that sells the government it also depends if you sell something to the government you make a mobile application or develop a lambda to the cloud whatever eventually you have in here all the power you can have to get visibility as well as control on what’s happening inside the pipeline and this is very important so developers have the empowerment to do and make the right decision but you here using the platform have this ability and actions to take in real time as part of the devops operation and this is very powerful when it comes to the um uh to the enablement and the devsecops approach you need to be tied into where your developers work and need to enable security in those areas if you have one platform that that everyone are working collaboratively on it that’s the best case scenario okay so once we define the uh policies and watches let’s go to cnx report uh i’m just gonna go switch on to the uh to this uh dashboard of i’m just gonna take a docker image because it’s pretty interesting so in this case you see a build of a docker i choose a docker just so i can show you the uh abilities uh let’s take i don’t know let’s take this field for instance and you can see for each uh build that we have the uh the build info and this this field info is being uh populated using the the jfrox cli or the j4 plugins that are integrated into ci systems such as jenkins and so on we support a lot of ci ci syllables and essentially gains all the information all the information that is carried out during the build cycle so you see the different forward you see the different properties you see the different uh included libraries environment variables a lot of information you can gain in addition to the uh to the artifacts and the dependencies that were gained and produced during this field so uh and uh just to show this is a json but you don’t necessarily need to work with json it’s all been it’s always been the parts started the published model you see that this build create two type of batteries uh let’s say i don’t know this one is an example you can see that the target artifact is this and the dependencies for this is all of those packages you can see where they’re in which path are them and which uh type and so on so this is for the published models uh using this platform you can also see the release history so if you got a battery that is promoted from qa to release again as part of the promotion you can have x-ray again to run this on a different policy and so on so you can uh make the right uh promotion and security gatekeeping between those promotions uh and let’s go on to the x-ray data to see the detailed information so when it comes to x-ray you can see that uh in this case we have seven cves uh we got 17 buses that have been detected we see the different violations and the reason here we see more violations of the cvs because for the purpose of the demo i wanted to create i wanted to use a policy that populates a lot of information so in this case many you can see that there are policies on the licenses and policies on the securities and something you can have multiple policies triggering different violations from different security levels um and you can also see the descendants tab so you can from the package you can drill down into the different artifacts all the way to the transitive dependencies and so on and if i go to the security um just hold on i wanted maybe i would take this example apologies i don’t want to show an interesting cv okay so same thing we see a docker image with the build info with release history and so on okay started the cves i wanted to show an interesting cv that has additional information okay uh so you see the cvs the severity uh which component is that we found and on the descendants tab here it’s a docker image so you can see you can drill down all the way to the sub there to the where the component is being placed okay and under the security it would take a cv you can see that for each cv you get the uh cv number the cvss core you can see that it has the uh the nvd information the developer version and so on the impact path which can drill down all the way to the component trigger this violation so in this case we have this build that uh produced this docker image in this there we have this jar file that’s inside of it you have this uh this uh vulgar package that triggered this vulnerability and what i want to show you that is special from about this cv that is uh not for other cv so we have as part of the video acquisition we have the jfox secured research team that uh maybe you saw a blog post on the news uh a group of security researchers that continuously monitor cvs and check for potential zero days uh disclosed several more than 400 zero days in the past uh four years uh stay tuned because we recently published an article about malicious packages in npm and python and i can tell you more to come but as part of this team’s operation of checking and creating automatic scanner that will look for malicious components this team also have a responsibility to check cves and triage them and give security insights about those cities so you can see that the jfook security research team has defined this cv as critical and you can see that whenever there is a critical cd that is a high impact cvs because cvss4 is essentially the result of the calculator that you set up the dcb is vulnerable because uh it is locally mode or it has this and that can lead to remote cause inclusion or denial of service and so on and you get this number and there are many many um so many cvs with so many numbers but eventually what counts is whether the attacker will try to chase down the cv or not and from an attacking point of view attackers are lazy and attackers when they when attackers triage cbes they also look about whether exploits exist is it easy to exploit what are the prerequisites to run the cvs this is this cv is easy to export or i need to have dependencies or quiz to have the cv for instance the band battery should be compiled without this in that configuration for instance uh so you can see that all these unique insights about from the jefferson security group is being displayed also in here so you can see this is like nvidia information usually general information about this version suffer from this on this without any actionable or uh straight english information about what does it mean so this is unique jfrog security text about summary simple english about what this vulnerability is about details about this vulnerability something that that has more information about the specific functions and what led to this vulnerability and the reason why it is considered as critical risk you can see in here that this cv can be exported remotely and also under the reference step there are reference to advisories publicly available exploits and technical advisor about this tv so this tv is really critical because if an attacker would like to exploit this cve they have all the technical information they would need in order to exploit the cv as opposed that you might have a cvss score of 9.2 that uh that might not have any exploits or in technical advisory just the fact that you have a cbe uh on this component we have a potential remote constitution of enough service vulnerability without any technical information so it’s very important to prioritize and understand with additional insights from security experts what to tackle first and what’s the meaning of those vulnerabilities not to mention that in addition to triaging those cvs and understanding the risks there are also additional information about radiation such as starting from upgrade 2 to the suggested fixed version or mitigate by so if there are additional counter nozzles such as change of configuration and so on this can also apply i want to show maybe there is another uh interesting cv in here okay uh so whenever we have a solution like resolution remediation about upgrade or mitigate buy or a patch by if there is patching this we can also reference to a patch so this insights are very powerful when you come to this using the impact path you can go all the way to the package and see uh different information about about this package and so on um so we went over the the x-ray the configuration the history and so on let’s move on to the distribution which is uh this piece of the puzzle and then go to scientists so first it’s a distribution uh very simple you can set up uh you can configure you can configure the response to be a set of uh a set of uh uh batteries that are gonna be zipped together so you can see in this context we have 178 batteries that are all grouped together one zip and this is immutable zip as part of the uh as part of the information you would find it has a checksum and its digital signature so no one can change this uh uh this release bundle but represent your release and uh using this release bundle you can send it out using encrypted https connection from your artifactory all the way to the edge nodes that you can place on the cloud closer to your kubernetes or in other places that you would like to deliver so you don’t need to rely on ftp or other messages that are not secured and not allowed to have an encrypted matter in this case you can see that we also have x-ray data and even though we have cves there are no violations so meaning that in this case we had a policy and the policy would uh i can pull it up but essentially if the cvs score is i don’t know 8 and above set up a violation if it’s not let it pass so you can use x-rays the last gatekeeper before uh sending it out to uh different edge notes uh let’s see if there are any questions on the chat


we did i mean we can answer this now um we did kind of speak on um it was based on the security question but we did obviously have something recently come up for the log for shell and people are kind of curious you know how can the jfr platform protect them i mean even not just locker shell i mean there could be stuff in the future as well so how can we help them now and in the future that’s that’s a a good very very good question and the answer is that let’s let me use this diagram to explain so the the look for shell vulnerability pretty much i think caught the the whole world by surprise because log4j is such a basic open source software component that’s embedded in so many java applications and if if someone would ask you what is what this component is doing very simple it does it opens a file opens a lot right the few uh lines of text and close it that’s it and along with the years it added more and more functionalities that people were did not think it can be used for for malicious purposes and then found out that this vulnerability is very serious because uh uh you can trigger this vulnerability easily uh from remote uh can sometimes be without any without any authentication in case the uh there is logging of the user agent in http request so sometimes it could be even before navigation and it pretty much caught the world by surprising when i talk with our customers about this if you expect uh it was a real challenge it was a real challenge because uh the process that the customers need to go through is amazing they first wanted to know uh oh wait where do we have it start with the identification phase of where do i have log4j as part of my platform and this is for the identification part and after they identified it let’s assume they identified usually it took them a few days or weeks even today some customers still trace local log4j here and there uh vulnerable look for j so then the identification phase was very hard but it come to the uh after they identify all the all the places they need to figure out how to fix this it can be either through uh upgrade which sometimes possible sometimes it’s not possible it can be either by setting up the configuration of the flag of the environment variable or it can be i also saw there is accommodation sometimes to to just remove the jdni uh class from the back from the zip file itself and even after they finish this deploy they face the problem of wait i did all this work right now but what happens two weeks from now let’s assume that the developer uh one wants to roll back on git to the previous uh previous version so how can i prevent the usage of this malicious package how like how can i make sure that no one use this anymore so we have and let me i share the screen so uh jfrog mitigate book full shell we have this blog for this blog post of uh of all you need to know about the local shell which is a very comprehensive has a lot of details about the uh the vulnerability what causes this vulnerability uh how how does it trigger and the different it’s been updated like four or five times already uh with all the information about the vulnerability but we also provided with the uh remediation steps on how can you utilize the j4 platform to mitigate the logical shell vulnerability and this blog post has uh many ways you can utilize the platform to discover or block or also fix uh fix the vulnerability in the same version this is not we we proposed this as uh one of the mitigations that was bought that was proposed over the internet um so we we offer this and the platform enables you to do this always it’s recommended to update to update the latest version but you can see here that if you would have jfrom with the best practices uh in your organization you could have identified all the places you use log4j in one query in one shot you can use and there are many ways using x-ray and multifactory and api in many many ways you can in one shot identify immediately all the applications and you can also block using x-ray you can block the usage of of the vulnerable local j packages so going back to the presentation uh if you want to prevent a developer from rolling back and use the vulnerable package you can set up an actual policy that will block download on the vulnerable packages and that and by by sitting on where inside the pipeline and leveraging the power of jfrog you could have uh it was very clear that customers that had j4 platform and could utilize this information uh would have been in much have been in much different situation than customers that need to start understanding where is the software material and uh which batteries are being used where managing the batteries is important and just think about what will happen hopefully not but we can assume that a critical cbe in other technology is going to rise up somehow within the next one two three five ten years in in case this is happening and you have a new critical cve are you ready or not ready for uh for facing this and if you have the j4 platform you have all the tools you need in order to immediately identify detect where it is think about the resolution prevent your developers from uh uh blocking the access to this uh this package and also we have the suggested fix with the suggestion of the security group that can really help you to face these kind of challenges uh courtney i hope this this answered the question it was uh i know it’s been a long uh answer but i think it was very important given the the recent uh the recent uh situation that we’ve been in no that was great i think if um anybody else on this call today if they have any more additional questions beyond that please again reminder to do that in the q a chat and we can also follow up with you um after this event as well but all right continue thank you all right so we we went through the distribution how x-ray can scan and survey the gatekeeper and last but not least is pipelines pipelines is uh is the j4 offering of ci server um just one second okay there it is and what we see here is essentially a pipeline that has a different step of creating an npm package and using an x-ray candidate creating a release bundle signing it and distributing it you can see the different runs that we have in here and if i’m going to see the yellow file you can see that in the yellow file that describes this whole pipeline you would not encounter any password because the passwords and the integration are being managed by the administrators of the platform it’s in the other tab it’s in here so the administrator uh uh sets the username and password for integration with all the other systems and in the yellow file you have just a friendly name that is being used and that’s how you can you can prevent the exposures of little text passwords in your uh in your yammer files which is known to be a very weak area for uh for current uh servers usually log in to ci servils and you just be exposed to many type of filtex password uh not to mention the signed pipeline so if you’ll go to whatever runs


You see that we have the different fronts the different stages the success the pipe info the resources and I want to show you here uh just an example I want to show you here in the artifacts um


Pipe info, okay. So you can see that in artifactory uh it stores for each run for each run it stores the uh the information let’s just take random one you can see that each step of the pipeline has a json and uh and associated with it the signature of the stack so in case you have the whole pipeline in different steps let’s assume that you have a step and then the next step is the day after the jfrog sign pipeline will make sure and will verify the signal the cryptographic signature check of each stage that was beforehand before proceeding to the next one that’s how we can make sure that no one interfere or change the batteries during the whole b cycle so uh by having uh by having this you can make sure that the the battery that you produced is indeed the battery that was generated in each step in this uh in this pipeline and going back to our big picture i hope now it makes more sense uh while we cover the whole many features of the end-to-end j4 platform to enable uh secure software supply chain operation and enable dev setups from the developer all the way to the end batteries i did not went through the uh the whole world best but of course we have as part of the platform support for sso integration with ldap and extensive uh role-based permissions for each user uh if you’re not familiar we have pretty much blog posts for every items that that was uh discussing here and feel free to reach out to your uh jeffrey representative or his support or whoever you feel like uh it will eventually get to the right team that can answer you in case you have any further questions um so that’s it for now uh courtney anymore last question from the from the audience we did we had one coming i would say it’s a fairly straightforward question but does jfrog support get scanning okay this is also a very good question uh because we saw we saw scanning of the source code so just to clarify what we’ve seen is scanning the dependency scanning using the cli and when it comes to git scanning and it’s it’s planning the robot for uh uh for the upcoming quarters uh if you’re already talking about upcoming features when it comes to enhancing x-rays you can get uh we also have uh the video acquisition that occurred a few months back as and the video acquisition bring with it the very unique technologies that holistically look at batteries and can check for beyond software composition analysis of open source software components it also have features such as scanning of configuration and protection analysis and stability scanners meaning that understanding the context of the docker checking the configuration of the docker and crosstrack this with the cvs for instance the cv might be relevant according to the software material but it will mark as okay because the docker is configured with this and that and that because nginx is configured with security best practices those group of cvs are not relevant as well as one of the key features and unique features that we do brings in is the potential zero days so as part of the video position uh the new x-ray can also will also be able to scan first-party code for potential zero days this is a very unique engine that utilizes data flashes and symbolic execution and fuzzing and uh and it checks the first party code to find potential uh zero days in the code that the developers are having so the new x-ray is going to empower the whole uh uh x-ray and the j4 platform to look holistically at the batteries so more things to come even further uh features are upcoming but uh if you would like to hear more reach out to us awesome and as a reminder to everyone on the call if you have a question that comes up after this event and you wish you would have asked it don’t stress about it we can just we can answer that later please email us at webinars that’s webinars and we’ll get those answered to you within 48 to 72 hours and then also just as a reminder this has been recorded this will be sent out with additional assets that you will find um helpful um but other than that i want to thank everyone for joining the call today i want to thank us off for your time that was some really great information um other than that i will sign off and assaf have a great day thank you so much and everyone else thank you all for joining thank you thank you bye bye

Trusted Releases Built For Speed