We Hack Purple Streams! Securing Open Source Dependencies Its Not Just Your Code That You Need to Secure With Rana Khalil

The importance of open source security management made headlines in 2017 when the Equifax breach resulted in the compromise of the personal information of millions of users. The breach was attributed to the use of a known vulnerable version of the Apache Struts open source framework. Since then, we’ve seen a rise in the disclosure (and exploitation) of vulnerabilities in open source software, such as the famous Log4Shell vulnerability that was dubbed as the “worst security flaw of the decade”. 

This resulted in studies being conducted and determining that open-source components make up more than half of an application codebase. The security implications of such a ratio can be significant. While organizations spend considerable time and effort ensuring that the custom code developed by them is secure, usually little to no consideration is put into evaluating the security of the used open-source components. This presentation will introduce Software Composition Analysis (SCA) - the process of identifying vulnerabilities in open-source dependencies. We’ll discuss the criteria you should consider when selecting an SCA solution and the importance of integrating such tools in your DevOps pipelines. 

Rana is an application security engineer consultant currently working at C3SA. She has a diverse professional background with experience in software development, quality assurance and pentesting. She holds a Bachelor and Master’s degree in Mathematics and Computer Science from the University of Ottawa. She has spoken about her research and work at several local and international conferences. In her non-existent free time, you can find her posting educational videos and holding workshops through her Academy and YouTube channel. She has received several awards and honorable mentions for her research and contributions to the cybersecurity community. 

Speaker Links: 
Youtube Channel: https://www.youtube.com/c/RanaKhalil101 
Academy: https://ranakhalil.com/ 
Twitter: https://twitter.com/rana__khalil 
LinkedIn: https://www.linkedin.com/in/ranakhalil1/ 
Medium Blog: https://ranakhalil101.medium.com/

Transcript

welcome everyone to a we hack purple stream I'm Tanya Janka your host and

Amanda's also helping me host but today we have a special guest and her name's Rana she's my friend she's ridiculously

awesome and I'm so happy she said yes to being like being on our stream and so you

might notice I've tweeted about her a lot so she's finally here I'm really excited and with this Rana please take

it away hi everyone uh thanks for having me Tanya I'm very excited to be here as

well because for those that don't know Tanya is actually my mentor when I first started out she used to live in Ottawa

doesn't live anymore which really sucks um but I'm really excited to actually be

on um you know a show that she had started um and so I'll start off by sharing my

screen

foreign let me know if you could see my screen

properly it looks great awesome all right um again I don't have

this ability on uh the chat and so feel free to stop me Tanya whenever anyone

has any questions and let me just remove the speaker top so that I could see the

slides myself all right okay

um so again thank you for uh taking the time to attend my presentation I'll start off by introducing myself

um so my name is uh Rana Khalil I have a bachelor's in a master's degree in mathematics and computer science I've

been fortunate enough to work in several areas in software engineering including quality assurance and software

development I made the switch to security about five years ago and now I currently work as an

application security engineer consultant at an organization called c3sa so for

those of you that are not aware what an application security engineer does essentially my responsibilities could be

divided into three the first one is testing any third-party applications or

in-house built applications that our clients use the second one is integrating security as part of the

software development life cycle so that's something that we're going to talk about um today so instead of

finding vulnerabilities let's say later in the sdlc what we do is we integrate

security as part of earlier in the sdlc so as part of every phase so that this way

um uh the it's significant it significantly cuts the effort at the time and the cost that is required to

fix those vulnerabilities and then the third responsibility is essentially developer education so you can see over

here on the slides I have an academy I also have a YouTube channel and a Blog

where I teach web application pen testing and I also do in-person training

teaching developers how to code securely um so that's pretty much it

um enough about me let's dive into the presentation

um so whenever I learn about a new topic and if you've attended one of my previous presentations they almost

always start this way um so when I learn about a new topic I always ask myself three questions the

what the why and the how if I can answer these three questions within the context

of the topic that I'm learning that means I have a basic solid understanding of that topic and so for our topic today

we're talking about securing open source dependencies so the questions that we're

going to be talking about are one what are open source dependencies two why

should dependencies be managed and three um how can these dependencies be secured

my aim for today is to have everyone in the audience be able to answer these

three questions by the end of the presentation and you'll see the whole presentation is based on these three

questions and then we'll also look back to answering these three questions at the end of the presentation

all right so we'll begin with our first question which is what are open source

dependencies now you'll notice I have a ton of diagrams in my presentation and

they're all references to how the real world works so pay attention to the diagrams and this is the first one so

you can see over here you've got all the modern digital infrastructure at the top and it's all built on open source

projects developed by people around the world now um as we go along in this presentation

you'll understand how fragile this ecosystem um can be and the issues that result

from having an ecosystem such as this one I feel like people tend to underestimate the type of issues that

can result from this type of system just because they don't really properly understand how big of a problem it can

be and so what we're going to do is first we're going to set the context to

understand the skill of this problem and then we'll talk about tools that have been developed specifically to address

this problem from a security perspective all right

um to set the context I borrowed a few slides from this amazing talk that was

given at the hack in the Box uh security conference it was titled finding

vulnerabilities and malware and open source code at scale and it was done by Mark curfew I've got the name of the

talk um on the screen the talk essentially focuses on how in

the future instead of ransomware in desktops it'll the future is going to move to ransomware and web applications

and that's done by uh introducing malicious code in open source libraries

that major Frameworks use on the Internet it's an interesting and really

scary talk because they actually have a demo in that talk I definitely recommend watching it but to get back to our topic

which relates to this talk um uh the talk really starts off by

essentially discussing how people consume open source software and it

Likens it to the making of echoed cocktail so um or essentially making a cocktail so

the first thing that you do is uh choose a framework for the application that you're developing so let's say if you're

developing an application in Java then maybe you're using the spring framework if you're developing an application in

Ruby then maybe you're using Ruby on Rails or for python maybe you're using the Django or flask or so on but the

idea is that the framework that you're using is open source which makes the basis of your entire project open source

code and then you want your application to have custom functionality

or custom features that allow you to sell your application and so you uh you

write your own custom code to add that functionality but then you realize well

I want other functionality in my application that other people have already implemented let's say being able

to log in using Facebook or being able to log in using other social media

accounts or let's say being able to pay through PayPal and so on so I make your life harder and reinvent the Wheel by

writing that code yourself so what you do is you actually import open source libraries

that solve the problem that you're trying to solve or that implement the functionality that you're looking for

and so what ends up happening is you essentially have a cocktail of code

where 90 of your code is open source code and only 10 percent is custom code

and that's a significant ratio because um while organizations spend

considerable time and effort ensuring that that 10 custom code is properly

secure usually little to no consideration is put into ensuring that the open source code which

makes up 10 90 of your application is actually secure

um now you might be thinking you know for the developers in the audience you might

be thinking well I'm not sure that's true I'm looking at my code base and I'm definitely only importing let's say

three libraries three open source libraries and there there's no way that can be 90 of my code and I actually get

that comment a lot um and so my answer to that is usually while it might seem to you that you're

only importing three open source libraries you're likely using much much more than that so what happens when

you're requesting a library let's see this is the library that you directly request in your code what happens is

this Library says wait a minute I need this library to survive and so it pulls it down and then this Library says well

wait a minute I need this library to survive and so it pulls it down and then this Library says well wait a minute I

need this library to survive and so it pulls it down and so on and so what you end up with is essentially let's say 100

libraries instead of the three libraries that you directly imported so the ones

that you directly import are the ones in green so these are called direct dependencies the ones that your direct

dependencies uh rely on are called indirect or transitive dependencies and

those are the ones that are in Gray now so you end up essentially with like

an interconnected graph of dependencies that becomes really difficult to manage

manually a really simple example that I like to use to better understand this

concept is imagine you invite three people to your house that you absolutely trust now you really trust those people

and that's why you're giving them the address to your house and letting them in but then those three people end up inviting three other people

and then those three other people end up inviting three other people and then those three people end up inviting three other people and so on and so instead of

three people showing up to your house um you end up with a hundred people at

your house and of them out of those 100 people maybe one of them is malicious and ends up trashing your house

um and so that's essentially kind of how libraries work if there is issues so

security issues or what we call vulnerabilities and any one of the

indirect dependencies it could trickle up to uh the direct dependencies and eventually make your application also

vulnerable and so we'll talk about that in the next section

all right um now to um understand how open source code makes up a large portion of the

modern digital infrastructure from a real world perspective let's look at a few statistics so uh synopsis does a

study every year where they do essentially an in-depth analysis or a study of the current state of open

source security compliance licensing and code quality risks in commercial software and the results are all

summarized in a report called the open source security risk analysis report or

in short will assess ossra and the link to the report is on the

slides um if you're interested in reading it um so essentially what they did is they

examined over 2400 Commercial Code bases across 17 Industries including financial

and Healthcare and they reported out of the 2400 code basis 97 of them contained

open source code so what that means is that almost all the code bases contains

some form of Open Source Code and then when they looked at each individual code base they found out that for each

individual code base 78 of the code is open source code and that's a

significant number so approximately eight percent eighty percent of each application was made up of Open Source

dependencies and only 20 was actually a custom code now again the ratio this

type of ratio can have significant compliance privacy and security related implications and that leads us to the

next question that we would like to answer which is why should open source dependencies be managed

now uh we briefly touched upon that in the past couple of slides um from

security and a privacy perspective but there's also a functional and a licensing perspective

um uh that uh that we will touch upon now uh to highlight the skill of this

problem from a functional perspective there's nothing better than using real world incidents that happened so a few

years ago a developer got really upset that one of his npm modules was taken

down due to a copyright infringement and so what he ended up doing is instead of just taking down the one Library he

ended up on publishing over 250 of the libraries that he developed for

um npm and he had put on npm and one of these modules was called the left pad

module or leftpad library and it was literally just 11 lines of code and all

it did was pad something to the left um now this might seem like not an issue

that he took down this 11 lines of code which are on the screen however this ended up causing a ripple effect that

took down majority of the applications worldwide that were built in JavaScript

so you had developers waking up to Broken builds and filled deployments just because someone took down 11 lines

of code from the npm repository and the reason was because this library was

embedded in a major framework called The Express framework which was used which

is used to build node.js applications and so the builds for majority of the

applications that were built using that framework ended up failing because they couldn't pull down that Library which is

quite insane if you really think about it and it goes back to showing how fragile this type of ecosystem can be

now of course after this incident npm put certain restrictions on who can

unpublish libraries and it essentially there's a ton of restrictions right now

but essentially the bottom line is if a library has any dependencies on it

you're not allowed to publish it but you could see the type of issues that really could result from

this type of ecosystem but again um this is from a functional perspective we're here to kind of talk about

security and privacy and so how does it affect the security and privacy of applications

well let's talk about a really famous speech that occurred a few years ago I'm

sure everyone in the audience has heard about the speech so it was called the

Equifax breach and it was where the personally identifiable information so

the pii information of hundreds of millions of users in the US and Canada

were stolen now the reason that breach occurred was because Equifax was using

uh the Apache struts framework and at the time the version of Apache

struts that they were using was vulnerable to a remote code execution uh vulnerability now they did know about uh

about it so they were informed that they were using a vulnerable version however they didn't patch it in time and so what

ended up happening is they ended up getting uh breached and the scary thing

about all this is that um these are all uh these are all article um headings or titles sorry

um and you could see over here one of the articles that came out during that time was that the code responsible for

the Equifax breach was downloaded 21 million times last year so the year before the breach had occurred the code

that was responsible for the breach was downloaded 21 million times which is insane and this one is even worse most

of the fortune 100s still use the flawed software that led to the Equifax breach and so even after the breach had

occurred and made worldwide news um uh they evaluated The Fortune 100 and

they saw that they're still using the same vulnerable software that allowed Equifax to be breached

which is insane um a more recent example again which I'm

sure everyone is aware of is the La Porte vulnerability that was released in

December of last year it affected millions of devices worldwide

um I remember last year when I saw someone post about this on Twitter

before it was picked up by the media I remember thinking oh my God we're screwed because lock for J is integrated

in millions of java based software and servers worldwide and like the

exploitation of this vulnerability which was really simple to exploit not only could lead to remote code execution but

essentially you could use the remote for execution vulnerability to install malware and other backdoors

in networks that you infiltrated um and so when this came out there was

essentially a worldwide Panic on figuring out if any of the software that you're using in your organization and

uses the lock for J library that was vulnerable and this highlights why it's

super important to have a software bill of materials or in short what we call an

s-bomb that lists all the components that your application or software is

using and we'll talk more about that when we reach the next section of how do

we solve this problem um all right so so far we've been

talking about libraries that were developed with good intention to serve a specific purpose however the developers

didn't develop them securely and so they unintentionally introduced

vulnerabilities into the code now there's a whole other type of libraries

that are made specifically to serve a malicious purpose this article came out

less than a week ago so you could see it's December 14 2022

morning developers that there was a flood of malicious JavaScript Python and

net packages that were uploaded to package repositories in hopes that developers would download them and fall

victim to this type of attack so this is a big problem that is definitely being used by throw actors that needs to be

addressed

um now the rise in the disclosure and um exploitation of vulnerabilities like the

Apache struts one which we discussed and the log project vulnerability is the reason that the use of vulnerable and

outdated components uh was listed as the six most critical security risk facing

web applications today so if I remember correctly used to be lower I think it was number eight or number 10 I can't

remember but now it's the sixth most critical security risk uh facing web applications today

I'll stop right now is there a question there's no questions in the chat there's

comments that you're really good at explaining and we really like your examples thank you thanks everyone if you have

any questions feel free to write it in the chat and um I'll be happy to answer them

all right so um if we go sorry go ahead Tanya

no no that was it that was all the stuff I wanted to say you're doing great awesome all right thank you all right so

um if we go back to the uh synopsis open source security and risk analysis report

that I referenced earlier um um we see that like out of the 24 uh

thousand over 24 000 applications that they analyze um they they um found out that 81 of

them contained at least uh one uh known open source vulnerability

um so um 80 of the applications that they analyze were using at least one library

that contained uh vulnerability and 49 of the applications uh were using a

library that contained a high risk vulnerability like the log project or

the Apache struts vulnerability that allows an external attacker to gain or

more code execution on your network now that's pretty that's pretty scary because that means 50 percent

of the applications that they analyze were vulnerable to uh we're using a

library that was vulnerable to remote code execution uh vulnerability which is

insane um so that's from a security perspective

another thing that they did look at in the report that we're now going to spend too much time on because it's not from a

security uh perspective but it is still important is licensing uh issues so in

some countries like the US creative work which includes software that was written

or code is protected exclusively by copyright by default and what that means

is that you're not allowed to legally use copy distribute or modify software

without the explicit permission from the Creator or author in the form of a

license that grants you the right to do so and so if the project that you're

essentially using think of it like you're taking something from GitHub if the project that you're using does not

contain a license then by default depending on um on the platform and also the country

of the person that wrote the piece of code um it might be copyright protected

um and that means you're not allowed to use it um and so again depending on your organization and

the type of product that you provide you might be introducing some form of risk or a legal risk to your organization by

using that software and so the study found that out of the 2400 code bases

that they looked at um 20 of them contained open source libraries that either had no license or

had a custom license so if it had no license again depending on the platform where you took the product uh sorry

where you took the software from or the country or the person that developed the software you might be at risk and you

might be introducing risks to your organization um and then a custom license is something that you need to review and

have a legal team look at before you could use it because a custom license could have essentially any clause in

there that says you're not allowed to use their um their specific Library

uh so the study also compared the different licenses that were available in each code base and they found out

that 53 of the audited code bases contained license conflicts what that

means is for example um uh an organization is making use of

an open source library that allows you to let's say freely use it even for

commercial purposes but then they're also importing another library that has a license that says

you're only allowed to use it um but not for commercial purposes so that means there is a conflict

um in the licenses now depending on the type of product that you're developing uh the uh licenses

um might open you up again to an additional level of risk that you might want to not take in your organization so

that's from like a licensing perspective how these open source dependencies could

cause certain issues okay

um so so far we've talked about the privacy I have a question oh okay sorry I I

picked the worst timing um so so Ken was saying not including a

license on the repo means it's not for public distribution can you expand on

this topic yeah so it makes sense yeah um so it depends on the platform uh that

you're using um it's sorry that you're taking the um library from

um and also the country um of the person that developed the license so I believe I looked at GitHub

and um it is not like I I can't remember correctly so don't call me on this

um but I looked at their Rules of Engagement and um it is not for public distribution if the user doesn't say

explicitly that it's for public distribution um I'll actually ask Tanya do you know

more on that topic so it it depends on like you're saying which country so by default everything

in Canada is copywritten like the moment you publish something it's a and are able to prove that you

are the one who first published whatever it is you own a copyright and I know this because I used to write music and

so the moment your song gets played on the radio or you release an album or any sort of thing like that you're like

that's right I was first um and it applies to code as well so if you wrote that code not while you were

working for an employer so if you work for an employer the work you create usually belongs to them but it depends

on if you're a contractor or full-time employee Etc but if you read the contract that you do generally they own

a copyright to the work that you do but not always and I have seen that trip people up

um I don't know what the default licensing is on GitHub though yeah yeah so us is the same as Canada by default

um software is uh copyrighted and so you're not allowed to use it without the explicit permission of

um the the person that wrote the code um I yeah so don't quote me on the

GitHub thing I read it a while ago and I remember seeing that it wasn't meant for public distribution unless a license is

included um but again um everybody do your research because I'm not sure

does that answer the question it does he says thanks so glad to hear that I'll keep it in mind when

publishing my repos I think the GitHub default is no license at all but npm includes a default license for you

okay awesome all right answer thank you any other questions

that is it mostly it's just me and Ken in the chat talking about how awesome you can do that thank you all right

okay um so so far we've talked about um privacy security and license

compliance issues we even discussed it from a functional perspective um that could potentially so the issues

that could potentially um come from using open source software um now the question is how can you avoid

all these types of issues um the first thing that you absolutely

need is something called a software bill of materials for in short and s-bomb

we've touched a little bit up on that when we were discussing the log for J vulnerability but essentially this is a

list of all the open source and third-party components that an application or a piece of software is

using so think of it as the equivalent of a list of ingredients that you find

on a package of food that you want to buy so just like I might want to know the ingredients because let's say I have

certain food sensitivities or I'm allergic to a certain type of food I

would like to know the list of ingredients in an item of food that I'm buying in the same sense

I want to know uh the software bill of materials for my application or the

application that I'm using so that I know exactly the risk that I'm introducing in my organization by using

that certain piece of software now depending on the software that you

use to create the SAS bomb it might include slightly different items I have

a small list of information that is usually included and it's based on something called the software package

data exchange standard or in short spdx now remember so you've got things like

the package supplier the package name the version whether it's a direct or indirect dependency the Creator and so

on but essentially now remember the graph that we looked at so when you

directly pull down a dependency those dependencies need other dependencies and those dependencies need other

dependencies and so on and so you end up with a huge graph of dependencies

um and so this is not something that you could uh do manually or you could

analyze manually just coming up with that full graph um and so this is

something that you need to do um automatically or in an automated uh

faction and that's essentially like all the direct dependencies and all the indirect or transitive dependencies

would be um would be included in something called uh the s-bomb

um now it became absolutely important to have this software bill of materials or

as bomb um when we saw an increase in the exploitation of vulnerabilities in

third-party software like the Apache struts vulnerability or the log project

of vulnerability and so last year it became mandatory in the US that you need

to provide an usbom or again a software bill of materials for uh software

vendors Contracting with the federal government just so that the government is aware of the level of risk it's

accepting um when using your software now I live in Canada so we're not there yet in

Canada um but it is something that I believe they're currently working on right now

and something that hopefully will happen um in the near future

oh we have another question yeah so if you're using npm is the package.json

file produced by mpm would that be a good enough example of an s-bomb

um I believe that only contains the direct dependencies isn't that correct

I don't know I actually don't program an npm but I have a feeling you're right because the um the transitive

dependencies are like the ones that are linked as like second layer generation and below I can't see anything in there

so yeah so I also don't program in npm but I would imagine that would only contain your direct dependencies and

then those dependencies also pull down other dependencies so you need a tool that actually

um I think there are um certain packages that you could use in npm that will generate that s-bomb for you um but I

don't think they would like specifically the package.json file would have that

yeah but great question awesome go on lead us Rana all right

um now again um creating this s-bomb is not something that you could do manually because it'll

take forever you'll have to you know go to um your config files and figure out which ones you're directly importing um

and then from there figure out you know for this Library which Library does it depend on and then for that Library

which Library does it depend on and then for that Library which Library it depends on and so on and so it takes

forever to do manually and so there are tools that are called software

composition analysis tools or in short SCA that automate the process of

generating an s-bomb um and not only do they do that they also identify known vulnerabilities in

the open source dependencies and ensure that you have license compliance when it

comes to those open source dependencies so having an Aspen is great but if

you're not doing anything about that aspawn to identify if any of the software that you're using is actually

vulnerable then um essentially it's just that you're aware that you

have a list of libraries but you're not actually checking them to see if they're vulnerable and so an SCA tool

essentially comes up with that ask Mom and then it cross-references it with vulnerability databases to identify if

there's any known vulnerabilities with the libraries that you're using so

essentially these tools work in three steps again the first one is to generate

an s-bomb so that's a list of all the direct and indirect dependencies with

the version numbers that you're using the second step is a cross references

the list with vulnerability data sources so depending on the tool that you're

using the vulnerability data sources might be different some tools actually most tools use on the nvd database but

you which is called the which stands for the national vulnerability database

however you could see the commercial tools have a variety of sources so

um the more sources that you have the better because sometimes vulnerabilities

don't actually make it to as you know a full-on TV and then end up getting put in the MVD database instead some of them

are just put in GitHub issues or comments or through private vulnerability databases or so on and so

the more variety that you have when it comes to your vulnerability data sources the better

now once you've cross-referenced the list of direct and indirect dependencies

with your vulnerability data sources if you get a hit that a specific library is

uh known to be vulnerable to so and so vulnerability then the tool will report it and that's essentially how the tools

work now uh there's a ton of SCA tools out there some of them are open source like

dependency check which is developed by the ovasp organization big shout out to

a wasp and everything you know for everything that they do so that's an example of an Open Source

One others are free but not open source so you've got npm audit is free GitHub

sorry not GitHub what was this called um uh dependency

Dependable I'm like trying to remember okay uh so dependent plot is integrated

in GitHub you could use it for free um it has its own separate issues

um I think there's a webinar by Jim Monaco that talks about uh dependabot

and like the set of issues that come with that but if you're not using anything the panda block is a great

source um to use until you could use a better product um and then there's other ones which are

commercial like Vera code um snake um and so on

um now I don't want to endorse a specific vendor so instead what I'm going to do is discuss the features that

you should consider When selecting an SCA tool and then I'll leave you to you

know depending on your organization what works best for you when it comes to choosing an STD tool

um so the first one and this is the most important one is language support So npm

audit can identify vulnerable npm libraries it can be used to identify

vulnerable Ruby libraries same goes um with again depend about one of the

issues that Jim Monaco talks about is that although it says it has support for many programming languages it was mainly

developed by JavaScript developers and so it covers JS libraries really well but when it comes to other languages it

does a mediocre job at best and so it's really important to make sure that the

sca tool that you're using actually covers the languages that are used by

your organization now the second one and we touched upon

this is the vulnerability data sources uh that the tool references so again the more diverse the vulnerability data

sources uh the more coverage that you're going to get um not everything is assigned to CBE rating

um and again you know it ends up getting logged in the National vulnerability database some of them are reported

through commit logs issue talkers social media private vulnerability databases and so on and so the more diverse the

vulnerability data sources the more coverage you're going to get

the third one is accuracy so the Tool's ability to identify if your application

is using a vulnerable function so it turns out just because you're using a

vulnerable component doesn't necessarily mean that you're vulnerable

um you have to actually be calling the vulnerable function or using the vulnerable function in order for you to

be vulnerable and I remember reading this somewhere I can't remember the statistics Source

um if anyone has it feel free to put it in the chat but the statistics have shown that 90 of the time you're not

actually vulnerable when you're importing a vulnerable library because you're not using the

vulnerable function um now that doesn't mean that you know oh the risk is so low

um no and that you shouldn't update um if you're not using the vulnerable function uh you should definitely update

because just because today you know you as a developer are not using the vulnerable function of an outdated

Library it doesn't mean that tomorrow a new developer is going to join the team or you might forget and you might

accidentally import um you might accidentally use the vulnerable function

um and so you should definitely update but the accuracy feature which is only available

um with actually very few um uh commercial tools

um comes in handy when it comes to um uh I guess uh

evaluating the risk of which one you want to update first so prioritizing

which one you want to update first because if I'm actually using the vulnerable function then I definitely want to update those first and then when

those are updated then I'm going to start updating the ones where I'm not actually using the vulnerable function

so it does come in handy but it's difficult to do because you would have to compare software compensation

analysis with um static code analysis as well

all right um the fourth one is the remediation capability um so some SCA tools have the ability to

auto-generate for requests and update to a non-vulnerable version however that

does come with its own risks of breaking the bill when you update and so

something that you might want to do in a test environment first before it gets pushed into prod

uh the fifth one is configuration and integration so the Tool's ability to be

configured to let's say um pull from different vulnerability sources

um or be integrated in your pipeline um and so on

and then the last one is reporting this one is self-explanatory and so I'm not

going to spend much time on it it depends on what is important for you in your organization and how you want that

information to be presented so depending on that that might affect the certain tool that you end up

selecting for your organization all right so um like I said I'm not

going to endorse a specific vendor um but what I'll say is from my personal

experience um uh you get what you paid for when it comes to Sea tools

um it's great to start with um open source or free um essay tools but then at some point

you'll realize the limitations of those tools and then you might want to move to uh commercials tools that provide more

of the features that we just discussed

all right um so we're almost done the presentation um but I didn't want to end it without

um showing you an example of an essay tool and showing you how easy it could be to run the sca tool

um so Olas to shop so it's right over here um is an open source intentionally

vulnerable application that is developed Again by the owasp organization and it's

written in node.js um and so the tool that I'm going to use to see if it's using any vulnerable

dependencies is npm audit and you'll see over here how easy it is to actually run

this tool it takes a couple of seconds maybe minutes if it's the first time that you run it and it'll report the vulnerable

dependencies I'm just going to click play

and you can see over here I'm just running it in the root repository of OAS

Juice Shop and then it just takes a couple of seconds to run and here we go you could see there's 76

vulnerabilities 67 of them are low five moderate too high and too critical and you can see over here it says it's scan

to 23 900 M5 packages so that's how many dependencies this small intentionally

vulnerable application was using so it highlights how you can't do this manually you definitely need an

automated tool to do this and you could see it gives you the information of each vulnerability

um the verification bypass one they're actually using the vulnerable function and so you could really exploit this

vulnerability and it essentially allows you to completely bypass um authentication as an unauthenticated

attacker and all it took was essentially just running npm audit in the reposit in the

root directory of uh the Repository that's how easy it is to get started

with um sea tools all right

so this concludes our presentation now uh before I end I wanted to Circle back

to the three questions uh that I said uh will answer during the presentation so

the first one was uh what are open source dependencies so we set the open

source dependencies or open source software that an application uses they

come in two forms the first one is direct dependencies which you directly Import in your code and indirect or

transitive dependencies which your direct dependencies depend on

the second question that we asked was why should open source dependencies be managed we looked at real world

incidents and statistics from the open source security and risk analysis report

that was done by synopsis to understand the open source dependencies need to be managed for the purpose of privacy

security and license compliance and then the third question uh that we

asked was how can these dependencies be managed and secured for that we talked

about software composition analysis tools or in short SCA tools to automate the process of generating an s-bomb and

identifying vulnerabilities in open source dependencies and identifying

licensing issues we also talked about the different features that you could consider When

selecting an SCA tool and that is it

um thank you for taking the time to listen to my presentation I hope that was useful

wow that took a flower I did not oh yeah it felt like it it was like 15 minutes

you were great and we have a few questions so I just put all of your links into the chat so people can just

click them if they want to but if you're watching this later we will post it in

the YouTube video comments underneath the video so if you're like oh I don't want to type that out don't worry we got you okay so there's two questions one is

do you have any thoughts on npm audit versus npm outdated I would run bows but do you have any

thoughts on it I've actually I have I'm only familiar with npm audit I'm not familiar with npm

outdated so I can't comment on that I think it just tells you if stuff's old I find whenever I get the npm I make a

mess um like it's like oh you ran this you should run that I'm like should I

yeah so if it tells you like if things are old so npm audit tells you if things are vulnerable if npm outdated tells you

if things are old um then I agree with Tanya you should run both um because just because it's outdated

doesn't mean that you aren't introducing a level of risk in the future by using

an outdated and unsupported uh piece of software so run both and then update

everything yeah oh I like it I I have a friend that works on SCA tool and I won't explain

which one because we're being vendor neutral but he was saying it's like having a ticking time bomb in your app

even if it's not exploitable if you have something where it's a really big vulnerability you still want to put it

in the backlog and fix it um okay so Camilla asks when updating

dependencies I see some people focusing on updating just the production dependencies do the dev dependencies

offer big risks as well or is it okay to prioritize production dependencies over Dev

it is definitely okay to prioritize production dependencies because that's what's external

um and that's what it's being used by the client and most of the time that's what has um uh pii information in it

um or confidential information in it um however that doesn't mean that you shouldn't update

um uh development um your development environment or your

test environment or so on I worked as a pen tester before I started working as

an application security engineer and so for some of uh our use cases is we acted

as an internal threat Factor um and so we were already we were given

access to the network and then from there we had a certain goal to reach another part of the network or another

Network that the organization was using and the way we did that was essentially look for

um vulnerable servers in those networks in order to see if they're exploitable

and then maybe they could give us or more code execution um to you know those to a server that is

within the network that we want to reach um so definitely something that can be

used by an internal attacker now if your deaf environment is also public then

that should be updated um right away as well I have to say like I think that if

you're gonna do testing you would want to test Endeavor a lower like I mean if

it's an emergency maybe you're gonna run off and do prod because you're working at Equifax and it's 2016. but like

I definitely want Dev and QA and uat to mirror prod so I can get good tests

right because like what if you updated it and then you broke everything you're gonna be unpopular to say the least

that's a great point it's actually quite conventional to start with prod and

update prod uh before um trying it out first in test because like updating libraries does sometimes

break builds um and so it's important to update them in the lower environments make sure they don't actually break

anything in the code and then replicate that in prod that's a great Point Tanya

I was guessing it's a security perspective it depends on how scary it is like I

worked somewhere once and we were so scared we turned off our servers like we had this big meeting and everyone was

freaking out and I was like we do have the option to just turn them off like overnight or for a day until we fix

everything and yeah we look dumb briefly but they're just so so worried about the

thing that we had going on and um yeah we just I this might sound nuts but we just turned them off

patch tested overnight and then in the morning turned them back on and we're like well you know we serve Canadians

hopefully most of them are in bed sometimes it's it's a good enough reason

to act like the vulnerability is a good enough reason to turn off your service yeah oh my gosh that was great does

anyone have any more questions from Rana and also I hope you clicked all the links I put and followed her on

everything she's also on Mastodon too I figured that out during the call

no I'm not you're not no I'm not oh okay so

um the thing that some Mastodon servers have been doing so it was the one that says bird site

um so there's there's one Mastodon server where they've followed a lot of people that are just really cool on

Twitter and they're taking your tweets and sharing them onto Mastodon so people

can follow your Twitter tweets on Mastodon okay interesting

well you're fortunately invited to the infosec.exchange server which is where

all of the security nerds are hanging out I was like why isn't she on infosec Exchange

I just never I never got around to it um but yeah no definitely something that I

want to join because everyone is moving to that platform um I'll of course continue Twitter until

it completely breaks down but um um I definitely um will be on Mastodon as well hopefully

in the near future for sure okay everyone this is literally your last chance until you see Rana

Ken this was so awesome thank you so much no problem thank you for attending

happy to be here do you have a question Ken

I've been able to um give all mine so thank you for that awesome awesome there's a whole bunch of

comments in the chat saying thank you and it was great and it was so helpful

yes thank you so much for being on our show Rana no problem thank you so much for having

me I'm so happy I'm finally on there we have purple sure I know well just to be

clear you can come on again whenever you want absolutely when I prepare a new presentation you'll be the first person

to contact about that awesome okay everyone since I got all

the questions and lots and lots and lots of thank yous we are gonna shut down for

now if you celebrate Hanukkah if you celebrate Christmas if you celebrate New

Year's if you celebrate literally anything I hope you have a wonderful time thank you so much Rana thank you

Amanda for organizing me so I show up on time and do all the things I'm supposed to do and thank you we have purple

community um I really appreciate you coming and I know a lot more of our community is

going to watch this when we release it to YouTube I will definitely send a message in the community so everyone can see and that's it that's all I got thank

you very much thank you for having me and happy holidays everyone