Vulnerability Management in Large Enterprises @ DevOps Kathmandu Meetup

October 28, 2021

< 1 min read

Vulnerability Management in Large Enterprises

Software dependencies are part of a developer’s life and so are software vulnerabilities. While we have a very good set of tools and tool-chain to handle the dependencies, handling software vulnerabilities is often confusing and creates a lot of commotion when customers find vulnerabilities and you are blindsided. In this talk, Leela will discuss a way to manage this so that the vulnerabilities can be handled under SLAs.

View Slides Here


Leela Padmaja

Leela Padmaja

Leela Padmaja is Senior Software Engineer with expertise in developing applications in Core Java and GoLang, and served on the internal Security Champions Team. Since joining JFrog, she has expanded her skill set to include expertise in Jenkins Framework Development and has developed plugins to meet the objective of continuous automation. Leela began her career as developer and manual tester working in multiple test frameworks, including Selenium and Fitnesse.

Video Transcript

okay so first of all thank you very much
for everyone to join this talk and i’m
sure you will love this talk and enjoy
this um so i’ll before i just start i
just wanted to mention that in case if
you have any questions um throughout the
presentation please feel free to ask um
in between or towards the end of the
presentation either way as you prefer so
um let’s get started
so uh i want to touch upon this topic
mainly because the software dependencies
are part of each and every developer’s
life so our software vulnerabilities but
while we have very good set of tools to
handle the dependencies handling the
vulnerabilities is very very confusing
because it creates lot of commotion when
customers find the vulnerabilities and
you feel very blindsided as well so that
is the reason in this talk i want to
discuss a way to manage this so that the
vulnerabilities can be handled very
easily and very early in the development
so as raju mentioned a quick
introduction about myself
i am leader i am working as a senior
software engineer at jfrock and i work
developing the applications in goldbank
and java as well and i served as
security champion also in jfrog
i am also experienced in developing
jenkins plugins and ci cd frameworks as
so let’s get into the actual topic right
away it’s one minute there is some
problem with my video
we can hear you just fine i’m not sure
if you want to try it one more time if
not uh you can feel free to continue and
we certainly can see your slides and
so by end of this talk you will know
what is the vulnerability management and
why is it important to have
vulnerability management system right in
the development page itself and what are
the stages of vulnerability management
you should have in your process so these
are the things we will be uh touching
upon and then um
deep diving in detail so the first one
is what is vulnerability management
so this is the process of identifying
evaluating treating and reporting all
the security vulnerabilities that you
are having in your system and the
software that runs on them
so this is called vulnerability
and why do we need this
because vulnerabilities provide
opportunities for attackers and hackers
to enter into your system once they are
inside they can absolute all the
resources we are using and they can
steal the data or the denied access to
access to the services actually so that
is the reason if you do not identify and
patch these vulnerabilities you are
effectively leaving all the doors to
attackers to enter into your network
that is not something we all want we
so what is the process what how can we
avoid uh having this in our system
so when creating a vulnerability
management system there are very a lot
of stages of that involves in but mainly
uh there are four stages that any person
has to consider into the process to
ensure that there are no vulnerabilities
or overlooked
and having the system also helps us
finding um
vulnerabilities and the found
vulnerabilities are addressed
yeah as i said the process involves many
steps and each organization have its own
way of handling the vulnerabilities but
mostly they will be following four main
stages um the only difference would be
how they are implementing these four
stages so let’s see what are those the
first one is identifying vulnerabilities
and the second one is evaluating the
found vulnerabilities and treating them
and finally reporting the
vulnerabilities so these are the major
four steps that one has to consider in
their management process of
so let’s get into each state in bit
detail and understand how one has to
incorporate these in their development
process so the first one is identifying
so this requires um identifying all the
vulnerabilities that are affecting your
system so far in the code base
and introducing a complaints and
security tool in the continuous
integration bill helps in identifying
them as early as the dependency
declaration states because as a
developer you will be handling with a
lot of dependencies in your code and
adding uh new
new dependencies and new tools
um as you develop your application so as
soon as you add them it is important
for important for you to know whether
that dependency is causing any new
vulnerabilities in terms of security or
in terms of licensing all of this so
when we have a tool that is finding all
this information right in the early
stage of development it would be great
so in our development process in jfrog
we have a x-ray tool that identifies all
the security vulnerabilities and license
violations early and blocks a bill if
there are security issues in the
development phase itself so they will
this will uh
give a provision for a developer to not
to proceed until he fixes the issue and
then make it
secure enough
this provides an automated and
continuous auditing of software
artifacts and dependencies through the
development’s life cycle from coding to
production so that is what uh every
developer requires right because it is
it takes very
large effort to fix them if you find
very much later in the development
process like
right before religion or right before
going to production so rather than that
when it is found in development life
cycle itself as a developer you will be
able to come up with the plan to fix it
and patch the problem and proceed
with the with much more confidence
so uh i just wanted to give you a
pictorial view of an automated system
that we have uh in our company where cia
server requests a bill uh to be scanned
as soon as the developer pushes the code
into a source system it be it hit github
vcs any visual system and then uh the
pre-configured x-ray will watch the
triggers and when it finds a violation
it will respond with an indication that
the build job should fail
that helps you identify vulnerabilities
at the development stage itself because
when the bill phase you will be notified
by a mail or via slack notification
whatever you you’re using in your system
uh or thanks to my notification so so
that you will be knowing that the build
is failing because of the dependencies
that you have introduced or the code you
have written
so that’s the stage one now let’s move
on to the stage two evaluating the
vulnerabilities now you found the
vulnerabilities now you got to know that
there are these are the vulnerabilities
that you have in your system or in your
application code what is the next step
how do we evaluate why why should we
evaluate first of all
because when you identify
vulnerabilities it is important to
vulnerabilities and the severity of
those vulnerabilities because it
determine where to prioritize our
security efforts because there is no
point in uh spending lots of time in
fixing low severity threats
whereas when there are so many high
severity or critical severity of threats
spending time on low severity doesn’t
make sense isn’t it that’s the reason we
need to know we need to evaluate and
know what is the severity of each threat
that you have already found and
come up with a plan to fix all of them
so this is a sample report from x-ray
tool uh when you build a
scan by x-ray tool this is the report
you will be getting and it has around
eight violations and all of the
violations they reach the severity so
you know that there are high severity
violations there are three and then two
low violations um
so this way you will have a clear
picture that you have to start working
on high severity first rather than
picking up low severity first
i hope that makes sense
and if you start remediating the most
severity vulnerabilities first by
knowing what are the artifacts that are
being impacted you can reduce the chance
that an attack will occur while securing
the rest of your system
so that’s that’s absolutely right right
when when the severity is high or
critical or major that means that these
are like very prone to um
spoil your security and you’re giving a
provision to hackers enter into your
system so if you if you make sure that
you are taking care of these severity
but no vulnerabilities first that means
you are securing your system majorly
so next one is stage three now you found
the vulnerabilities you evaluated and
then you have a plan in place now how do
we remedy it
so when the plan is in place you can
start beginning beginning the
remediation efforts but during this
stage we will be uh increasing
monitoring or reducing access to the
iron areas identified as a tree schedule
but but as a developer in some cases
when violations are detected in your
development process you would like to
accept or whitelist some of the
violation because if you find eight
violations during your bill or
especially this is very important for
point to consider
when you’re
scanning your system right now i mean a
legacy application which you have in
place from couple of days or months or
years if you just have started taking
care of scanning um on regular basis you
most likely you will be finding a lot of
violations in the beginning a mix of
major and high and critical and low as
but it is practically impossible to fix
all of them in a short span of time or
in um
in the moment so you should have a plan
like okay first i will be fixing this
and then next uh low severity and then
um normal severity all of these plans
should be there but until then we can’t
keep failing the bill isn’t it so that’s
the reason we will have to whitelist
some of the violations until we have uh
fix ready
usually this will happen in four cases
uh first would be the conditions needed
for that vulnerability to happen or not
made in a specific case
your particular execution case is very
different than
where the particular condition is
and as an organization your company
is aware of the violation but they would
still like to release the product and
also there is a chance that violation is
not a show stopper and you would like to
deal with that later or in the next
and finally i just just said violation
is valid but you need more time to deal
with it i mean more time to fix it or
more time to diagnosis and analyze where
the root cause is and how to fix all of
this you need little more time so these
these these situations the time-based
ignore rules enables us to silence the
violation for a set of period
so that you will have enough time to fix
them and then take care of
rescanning later
so how can we do that
so here it is sample uh configuration
that we have in that x-ray tool provides
us where you will be able to ignore the
um that enables us to have a granular
control on the violations that should be
ignored so where you can select what is
the type of vulnerability you want to
ignore and what for what component you
want to ignore and for what artifact you
want to ignore and what watch all of
these you will have flexibility of
controlling the ignore rule and then
finally there is an expiry date
so by setting this expiry date you will
be able to silence the particular
violations until that period
as i just said by setting this date on
ignore rule according to severity of
vulnerability and cvss core helps us
reaching the remediation process
when it is low severity the build will
be still failing because it’s a
so you it’s for the low severity ones
you can set a expiry date and then you
can take care of remediating that
particular vulnerability slowly and then
gradually so during this grace period
that we are defining in this
configuration the bill will not fail and
the violation will be ignored and once
the period expires again the ignore rule
will be deleted and if the bill still
contains the violations even then then
again the violations will be created and
will start will failing from there
so this feature is really really helpful
for a developer to uh silence the bill
until he is really ready to fix it um
but of course the timings how do we
decide depends on organization and the
team collaborative decision that we will
talk in the next slide
so timelines as i just said
how to decide the timelines usually they
decided by organizations and is also
recommended to decide based on the cvss
common vulnerability scoring system
so in our company i i just have put a
ignore rule
sla here so what we do is whenever we
find a critical cvrt vulnerability we
will have a sla of up to five calendar
so a developer can fix that particular
vulnerability within ids from now on so
the expiry date will be set to five days
from now
and at the same time for high we will be
going for 30 calendar days
but when we say 30 calendar days because
it is still high first first step will
be investigation is it affected severely
or not we will be verifying validating
and if it is severely affected then
again we need to uh
uh sit down and then uh communicate with
the team and take immediate action but
when it is not much affected uh in terms
of the functionality and the
scope of the
area then you will be taking 30 calories
and rest all like medium normal low you
will have up to 90 calendar base sla to
set the expiry but not later than 120 in
worst cases
so this is the kind of ignore rules sla
that we follow so this is this enables
our developers in such a way that we
will have a clarity on what severity of
vulnerabilities we will be first working
on and then what need to be fixed so
that we in that order we will be able to
make sure that
we are making our system secure enough
and final stage is reporting
after remediating uh reporting
vulnerabilities may seem very
unnecessary but it will help you improve
your security and responses in the
future for sure because having records
of all the vulnerabilities that we found
during investigating um the current
system will definitely help you the
future events as well i’ll just give you
an example of our recent
scenario where we found a
security issue so where we had to
quickly go back to our patch history and
uh to see um what was the possible
routes and the times of the entries of
that particular attacks have happened so
that is how that is where the reports
will really really help you in figuring
out and narrowing down the current issue
quite well
so x-ray provides a beautiful way of
reporting all the
security vulnerabilities so we use the
um x-ray tool um
at most to get all that information like
the left-hand side one is the
vulnerability report where no
remediation exists and the right-hand
side is with all the cv ids and cvss
scores and with the remediations
finally the key takeaway from this
meetup i just wanted to mention is
having a vulnerability management system
in the development process is very very
important for any organization
irrespective of what level of um
products they have and what kind of
religious they are doing because it will
ease the remediation process
a lot for the developers and you will
not have to worry about uh security
threats right in the last minute of
releasing um or doing um annually or
monthly quarterly audit and then finding
the issues then and then all together
sitting down to solve all of them
and humiliating most severe
vulnerabilities first to avoid security
threats and hacks is very important
rather than spending time on unnecessary
threats threats or threats uh i agree
but you should have a proper plan by
evaluating and then accordingly have
them uh remediated
and the third point i clearly wanted to
mention is having ignore rules is very
very uh important and it makes the
process very seamless and easy as well
for developers and the company as well
because it will provide you a provision
of silencing the bill uh so that you
will be able to proceed with the
development process but at the same time
you will be able to take care of the
remediation as well
and having the right tools to support
you to analyze the vulnerabilities and
then fixing the vulnerabilities early in
the development is also very very
so we use x-ray um so there are a number
of tools out in the market so we can
check out but i’m i’m sure you have to
look at x-ray tool and then you will
find lot a lot of benefits in that tool
and an effective vulnerability
management program continually monitors
analyzes and assess the race and
wrapping its forms around the weaknesses
of security and shining a light on
exposures that can negatively impact the
enterprise so that is why this is very
very important in any system any
management any organization
so any questions or comments um that’s
all i have to share here
i’m just checking chat box
thank you again
after a nice presentation
so yeah there are a few questions on the
google doc
so please share my school first
so the questions we have in the document
um should i start answering
yeah yeah so uh i see first question how
is each package vulnerability identified
while building like npm and pid so x-ray
tool provides us a great provision of
selecting a package type so
x-ray tool with artifactory integration
when a build is deployed into
artifactory artifactory has a provision
of scanning the type of the artifact
when i say artifact it’s like it could
be r it could be npm it could be maven
bill it can be docker
image all of this so uh it will it will
x-ray for the walks and scans the
package accordingly
i hope uh
make sense
and the next question is how do we
identify the development process is
violating the license
so again it depends on the tool that you
are using whereas we have
we will have a provision of creating the
policies and
watches where you can select what type
of watches you can create like license
or security so according to the type of
the watches you have it will validate
the license of the each dependency that
you are adding in the
form.xml or you know gravel wherever you
clearing your dependencies and figuring
out if that particular version of um
dependency has any security threats or
license threat and accordingly it
reports the violations
yeah just just a follow-up question on
so that that’s question from my side so
yeah as a developer uh
yeah i might be uh
stealing someone’s code right or i could
not be referencing the right source i
could be doing bunch of things to i mean
find my way around the license so
yeah how do we identify that i mean do
we scan
the code base are
how does that work like actually i
wanted to know more about like what is
licensed violation
in phosphates and how do you do that
in your process
so what is licensed violation is so it’s
for example i mean i’m just taking a
random example if you’re using common
scio apache commons io as the one of the
dependencies in your application uh if
common cybo a particular person is
having a weak management of passwords or
management of handling the file
that comes under a security threat
that comes under a vulnerability right
so that is why it is not recommended to
use that version of the dependency of
commons io
okay so when x3 scans it it finds that
this version is not secure enough and
so this is the example of
security coming from the license um
just for example i’m taking comments i
go but if there are if you’re using any
particular third party dependencies or
any open source tools in your
application if they don’t have enough
strong license information uh declared
to use the dependency that’s when it
start violating the license based
so the license of any any um open source
tools have to define the license
properly and
the strong license needs to be given
even if it’s open source the license
information should be declared properly
and appropriately if that is not there
the license violations will start
throwing up
for each and every library i would be
using uh that’s a requirement
oh sorry can you repeat the position
yeah i might be i mean importing for
uh while building app in react
we might be using hundreds thousands
library sites so
all of them they need to have those uh
license defined uh how does it work i
mean not everyone is i mean
good at defining the license right
so correct so
so each um jfrog x-ray tool has a
package of different different licenses
like open source violation if sorry open
source license and then enterprise
license and enterprise license all these
license defined in the library in places
so it will compare with the existing
licenses out there in the market and
with the license that your your
application third party dependency is
using and if it is not fitting into the
library then that’s when it throws the
so as an organization if you are okay to
use that license irrespective of the
violation then you will have a provision
of violating it sorry ignoring it
permanently or temporarily to ignore
until you find the best
okay no license definition is also a
license violation then i mean
yeah it comes under license violation
because then if the
tool you are using is not having license
that means they they can change any time
and the application that depends on that
particular applica dependency can impact
uh anytime because when you are giving
to customers using in no license third
party dependency it can cause anything
so that’s the reason it is not
recommended to use the new license but
english it should have open source
license strongly defined and
mentioned there
okay so yeah
and that answers that okay
yeah um so is x-ray open also open
source tool
uh you have tile license you can um try
for 14 days i think for free and then
experience all the um features that it
provides and accordingly uh you can
decide if you have if your organization
needs it and then you can take on that
that is evaluated for package or per
application or entire architecture or in
all steps to calculate sla
so um
thread is evaluated for artifact when i
say artifact it’s like for profile uh
jar file or the package file or um
docker image or npm package these are
called artifacts individually artifacts
so threads will be identified i mean the
scan will happen off and the threats
will be fine
fine and then reported in the uh
now sla coming to sla when you were
calculating sla it is per secure per
either it will be security violation or
license violation sle is per violation
so for each violation you can take a
call on what kind what what is the
estimated period of uh
fixing it and all the dates you can come
up with per violation
so uh so i have a question on this part
uh so for example like if we say
yesterday is violated in like to say
last week or in like a few days
so does that mean like the number of
pirates has the accident that you need
calculating like
by referencing all of the view within
your side effect does that mean
that way i mean like
uh let’s say for example if we have 100
views and uh two of them have several
entities and three of them has minor one
and this is that one reads the sla so
we let through some kind of alert
saying that ssd or the error deposit is
just used up
um i’m not sure if i understood the
question properly so um
can you repeat it once
yeah i mean like let’s say for example
uh we have 100 views 1000 beats for
per week
so let’s think of that right so if we
have violations of let’s say for example
if there is uh very severe vulnerability
which is on tin of the build like ten of
thousands right on by you know on the
total so does that mean like ssd is
violated or
or let’s say for example if we have
thousand artifact of
100 services that means 10 billion per
service and if
the vulnerability is on one specific
artifact only so will that also uh like
count it under the setting
so in the practical real-time
application you will be uh giving i mean
when you are releasing to your customer
it will be either the docker image or it
will be either ftm package that will be
the deliverable drive
so this package will be created using
multiple artifacts so
consider let’s take docker email docker
image will require
if it is a java based
application docker image then it will
require a jar or war file to be bundled
inside the docker image
right so i’ve got a var or jar again
there will be multiple uh
subjects like your application only is
having multiple modules and then five
modules together we have created a
bundle of watch file and then created so
now when the scan happens it it happens
on the each each and every layer of
the entire package so docker image is
the top most layer and then uh the
next immediate layer is the jar number
jar one dot just
one dot just and then the next layer
will be two and three yards and then two
has four answers i mean two a and then
three has three a and three b so these
are all the layers of the
image or package
so the scan will happen on all the
artifacts and then the report will be
now uh so each each security violation
that is reporting it will clearly show
what is the impacted artifact is it like
the entire image is impacted or only a
particular jar file is impacted or is it
like which when you are bundling the
image you might be using some
third-party applications like maybe
elasticsearch or postgres all of that so
maybe those are having the issues so it
will show you the impacted artifact so
accordingly you can define the sla if it
is related to your own code then um from
the organization level you can take a
call and then um consider the sla but
whether to release the product or not it
depends on the security of the security
violations that you are finding
okay so that also means like then we are
separate is scanning for let’s say for
example if we have zarfire running
docker so that we separate scanning for
a topper and the base image and also the
artifact as well right
okay so what are the
benefits was
sorry i couldn’t see them now what are
the main um
benefits of
so i think adi is typing
i was i was a little ahead of myself i
thought they thought you were answering
that question before i was just adding
an additional benefit but please
continue leela
so scanning with github or docker how
causes jprog
the main benefits
with jfrog x-ray productivity it has
very uh tightly coupled um
scanning policies defined in x-ray so
when compared to github or docker hub
scanning it will give you much more
granularity of violations that you have
or the security threats you are
introducing in your system so that is
where it stands out and then it will
help you in finding out very um granular
information about what is not right in
your system
yeah just just a follow-up i mean uh on
that so
does uh i mean the jfrog ecosystem it
also solves this the implementation i
recently i stumbled upon this tool
called cubescape that helped me scan my
kubernetes cluster and
find whatever bad practice i was doing
regarding the security
and on its scan uh at the very bottom it
was giving me okay this is cv related to
this and you can fix this with these
things like
does jfrog i mean also saw this thought
saying okay upgrade this version or
are there any
because it’s usually like uh when there
is something reported it would be nice
to have like
what’s next right
how to fix that so
do you guys i mean through the platform
enable that
yeah and also if you’re a developer you
will have a there is a ide plugin as
well for x-ray so right when you are
developing in your ide intellij has
eclipsed health plugins so when you are
developing itself as soon as you
a new code or new dependencies you can
quickly scan and then check if you’re
not introducing any new violations or
you’re solving i mean whenever you’re
fixing the existing violations it is
very easy so that will help you in
figuring out as early as in development
rather than waiting till the last minute
okay so yeah i was just going through
the github and yeah i found bunch of i
client libraries right so
usually i mean this uh x-ray
system it will
do all the scanning on on the
remote server or does the process happen
how how does it work just wanted to know
a little bit about it
yeah like uh you have to plug in or
whenever i’m doing uh let’s suppose git
comment i want to know right right so
can we plug x-ray before that and just
get the benefits and how does that work
you need a remote server where x-ray
will be installed and then set up with
appropriate watches and policies and for
your organization um
security uh
scan you wanted to uh look i mean this
is like some com some organization
doesn’t want to look at license
violations in the beginning at least
when they’re just starting out but the
security is something they will be
always looking at because that that will
give a lot of scope for hackers so uh
that is how you have to define the
watches and policies in x-ray and then
keep it ready so when you are building
your application or core source code you
when you deploy the building to the
artifactory remote server so
x-ray automatically scans both bills or
artifacts that you are deploying and
then gives you the report
that’s that’s after the i mean build
process right what about uh me
something locally
and you mentioned earlier this is a
plugin and that can
be i mean integrated with
developer i mean id i’m using so
uh does that also work the same way
yeah same way same even for ide you will
be defining the remote server which
where your x-rays installed and then all
the policies and what you saw defined or
you can have a local installation of
x-ray as well because x-ray has cli
installation available as well or docker
image also you will be finding and you
can install in your local but i would
recommend to have a remote server so
that so all the developers in the
organization will be
referring to the same set of the watches
and policy rules um we are following
because it’s most likely when you are
having your own server in the local
setup there is a high chance that you
will be missing out configuring some
particular violations compared to the
other developer
yeah yeah agreeing either we have a sync
policy of all those things right or we
have a centralized place to i mean
govern that yes
yeah and i saw one more question also um
in this we just answered this is based
on static analysis on the code base i
think that’s what we just spoke right
is this based on the static analysis on
the code base
yeah so again when i say static analysis
um it is it is all depends on um see
x-ray comes up with a lot of predefined
uh rules and violations and um the
library of
licensing the validation and library of
security cvss violation the library but
defining the policy like if you are
having a doctor if i mean if you are
having a build one and build to this
particular build i am more interested in
validating both security and license and
the second one i am not interested in
life is only security so this
configuration need to be done in x-ray
server um so like i just said maybe you
can have a remote server for the whole
organization and then uh using regex or
a pattern of bills that you can
configure a watch and
against that you can start scanning so
it will it will do the respective
analysis based on your watches
yeah that’s good okay thank you
and uh final call for getting the
dessert free so let’s go into this link
let’s fill up the farm
stop my share so if anybody has any
questions or any anything you want to
add just feel free to unmute and
now let’s start the discussion here
yeah i have one question but i’d like to
give the floor to the audience
jonathan you have something
um yeah so i’m using um i’m not using
jackets we’re using build kite over here
um do you have any integrations
i’m not sure if uh
hi jonathan this is ari uh i don’t um
i’m not sure if leela is uh
if she if leela are you one able to
unmute yourself
i’ll uh i’ll slackly in just a moment
jonathan can you repeat the question
because if we don’t if i’m not able to
answer it for you i will make sure that
we get back to you with that because i’m
not sure why
i’m looking at the various integrations
that of cloud providers ci cd providers
that are already integrated with jenkins
is one of them uh build kite is what we
use over here uh do you have an
integration with both kite
could you i’m going to ask you would you
mind going ahead and spelling that out
for me
it’s in the chat that’ll be awesome
thank you so much i don’t know the
answer to that 100 percent uh but we
will get the uh a build kite okay we
will get the answer for uh we will get
the answer
for that and let me just slack leela
here are used
and see why uh or or what the what what
the issue is
um i think uh someone else mentioned
that there was another question that
we’d like to be able to get the answer
for you as well um
and uh
interesting i’m not sure why uh
it happened
yeah it’s i i have one question i mean
it’s a very generic reason though uh
in the projects i’m working uh yeah
there is i mean
very little uh and done i mean
scanning the code but we haven’t gone in
depth like how to
properly mitigate that process usually
it’s a seasonal i mean
uh some
team they help us find the
vulnerabilities and yeah mitigate those
but up to the package level it’s done in
very less manner even
yeah i myself skipped that npm audit
fixes so many times so
yeah for a starter what you saw just
like how should they i mean start with
i mean so today i i think you have
mentioned it in in the docs you guys
provide a free 14 days trial and
yeah what’s the process next for someone
who is looking to
do this assessment
and and make their application more
secure and follow the secure practices
what’s this step forward
ah that that makes sense well we’ll um
so basically you’re looking
what’s i think the question is what’s
what step after the four what steps do
you need to take after the 14 day trial
to get what you’re looking for from a uh
best practices standpoint
yeah not just 14 days after it’s it’s a
general question like if somebody is
starting this process like okay
how should they start
okay well let me get the what i can do
is i will get the answer to that and
then update the link um so you have that
um on the sheet as well
and uh and i apologize i’m not sure uh i
don’t think leela just said bye bye and
left uh so i’m not sure what the
technical difficulty is but uh we’ll
definitely we’ll definitely do our best
to go ahead and get that for you as well
see here
and i’m also going to put a note here
for uh
the integration that you were requesting
with build kite jonathan um so we can
check so we can check on that as well
okay and i like i like the google sheet
by the way i’ve never i’ve i’ve sat in i
don’t know about 200 meetups in the last
a year
leela is back now yay
there you go thanks leela there was a
couple of questions that i couldn’t
answer and i was stalling the best of my
abilities so i’m glad you’re back
yeah thanks i lost power so i connected
back on the mobile
uh one of the questions uh lilo came
from jonathan he wanted to know if uh we
have does jfrog have built kite
integration i have not heard of it but
uh maybe you could speak to that
i have uh i have heard about it but um i
don’t have complete knowledge but as far
as i i remember building is the kind of
continuous delivery pipeline which is
similar to 10k
um and they have uh integration with
artifactory as well you will be able to
pull the artifact from artifactory uh
using the integration uh into build kite
this is all i know um
i’ll look and see if we have any
documentation on that and if we do i’ll
get that back to you on that jonathan
awesome and
and also and also milan had a uh and had
a little bit more detailed question he’d
like to ask as well
yeah it’s it’s basically like uh what’s
the i mean step forward for somebody who
is trying to start fresh uh on this
journey like
uh either using jfrog or without jfrog
like how do they start
uh to manage their vulnerabilities like
what’s your advice where should they
um i don’t think i’m the right person to
answer this question um harry you have
any idea whom they can check with do we
have any uh
portal where they can talk about this
yeah so i think it’s so i think if i
understand the question right now milan
so it doesn’t matter so basically let’s
say you’re not doing let’s say from a
vulnerability standpoint you’re really
starting at square one where is a good w
where do you begin what’s the right
starting point um to do that correct
yeah yeah it’s it’s a very open question
like somebody here in meetup they might
be just starting that process so
yeah we have talked so many things about
that in the talk itself but as a like
straightforward guideline uh what could
be the process
yeah so what’s so what’s that um what’s
what’s what’s a what’s what’s a good
good beginning point or something like
um and i think it’s a little bit lilo do
you have any do you have any advice on
where if an organization does not have
anything in place right now
um where they would want to begin in
order to start this journey what would
be a good point
okay well that’s definitely something
that we back get back to you um and
again like i was saying i love the
google sheet um i’ve sat in over 200 uh
meetups in the last year maybe even more
and i have never seen someone
effectively use this method i love it i
think it’s great i might i might use it
for my meetup too
right yeah
it’s just a backlog so
sometimes the simplest things is uh
is is is really a great answer because
you hear questions and you hear links
and all of these things going across and
uh um i might even uh i might make a
copy of this and say wow and uh and use
it for mine so thank you for uh thank
you for the impact you had on me
okay so
i need anybody
if you want to ask anything or maybe
maybe share your the practice you are
doing or maybe any kind of
difficulty or anything you want to talk
about a reason with the topic
yeah tulsi you might want to see
something monies
so so i i want to share like the
simplest apples that i’m also doing
these uh so even uh if you don’t have
zefra and you or any other third party
components so uh in case of the docker
i would say like the cloud itself like
google you know so they have inbuilt on
levity scanning things
uh which will give us i need to do
the scanning of the docker image not
they don’t go into the like artifact
illegal but that is the packages which
are inside the uh container so that gate
is scanned and they also show us the
safety of the vulnerability inside those
docker images in almost real time they
might take a few seconds or maybe even a
minute right
so that would be a good one and also
there are like few open source kodi
scanning platforms
uh so like snake so this nick also has
open source uh
scanning tools so that is also one
option if you are going for the open
source and
uh so yeah so i just want to share about
these tools this will be a good starting
for do the scanning
the security topic are the the scanning
of those one and everything which often
miss during the starting things and we
don’t care but in the long run that we
like very
very much pain so i just started to
start in the beginning
and get some metrics out of it and also
evaluate the process or evaluate the
packages or the uses of the packages or
even the code analysis
so that we are very good in the long run
yeah i i know a package i think
everybody knows it is
this uh i bought from the github that
usually ask for the version upgrades
that depend on what or something
it it usually
does so much of housekeeping for me
yeah i think that’s available for every
everybody using github at the moment so
it used to be rather better but it’s
freely available
as well has container scanning as well
you just need to enable it on your
repository and i think if you’re using
ecs or any or any amazon services you
know you’ve got free containers coming
there as well
and google
it’s just i think a matter of getting
your process right to get it back into
your task list of things to do and it
just needs oversight from within your
and also the guitar is scanning does
this kind of the aws key so
so this is like the bad package but
github just gives already someone is
hardcoding the aws keys and this alerts
to the github but i think we have to
enable the feature for the for this kind
of a security alert
any more questions or comments
are we good
okay since we are good okay so uh let’s
do wrap up so thank you already thank
you lida uh for getting into us and uh
like achieving a very useful session so
and also thank you all for being with us
and so i hope all right we’re almost
here like you
got something useful in this topic and
you will also implement a new thing
between the security and vulnerability
scanning on your workplace or in your
project which will be very much
uh so by saying that i just want to
thank you all again and we’ll see you on
the next meet up in
next month
until then let’s stay connected with us
on slack or as connected with us on the
google doc
yeah and already do we do
like the desert
rifle now or
you know what it’s better it it’s better
than that anybody that entered in is
going to get one today uh i made i made
an executive decision um as uh
so anyone that put it in i’m gonna we’re
gonna mail a jfrog t-shirt to um so if
it’s there and as long as it doesn’t and
if it’s uh it’s our pleasure it’s our
pleasure to send it um and we’ll get it
to you okay
yeah sure that that’s very interesting
and then thanks for that
okay okay
so thank you all and
also happy ttr so we are having a
very interesting
festival right ahead next week so just
do celebration wisely and get in touch
with the family and friends
and we’ll see you
in next month
okay thank you and bye-bye
bye-bye thanks