►
Description
Leading cybersecurity experts talk about how their organisations are going through DevSecOps transformation, challenges they face and what's needed to overcome to ensure a secure application.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Hello,
everybody
and
welcome
to
our
panel
discussion
today,
which
is
on
devsecops
the
transformation,
and
my
name
is
amul
renna
and
I'm
gonna
be
the
moderator
today
and
I
am
part
of
the
github
advanced
security
team
for
asia
pacific.
It
gives
me
a
great
pleasure
to
welcome
the
panelists
today
for
us.
Maybe
I
could
start
with
introducing
the
panelists.
A
Satish
has
been
working
in
cyber
security
and
risk
domain
for
almost
30
years.
So
that's
that's
a
very
good
and
rich
experience
that
he
brings
us
today
and
we
look
forward
to
you
know
getting
those
thoughts.
Yes,
the
second
panelist
that
we
have
today
is
commander
praveen
kumar.
So
praveen
is
chief
information,
security
officer
with
z
and
praveen
has
recently.
You
know,
he's
a
naval
veteran
and
has
recently
quit
navy
and
come
to
ce
street.
A
Praveen
also
brings
with
him
almost
20
years
of
rich
experience
in
cyber
security
and
other
warfare,
so
welcome
praveen.
We
also
have
a
baya
vidya
with
us
today.
Abaya
joins
us
from
infosys
avaya.
Is
the
group
manager
information
security?
We
inform
this
and
also
brings
close
to
20
years
of
experience
on
cyber
security
and
risk
last,
but
not
the
least.
We
also
have
a
sagar
today
with
us.
A
Sagar
narasimha
is
the
chief
information,
security
officer
of
amagi
media
and
again
brings
almost
17
years
of
experience
in
cyber
security
risk
and
consulting
so
welcome
all
the
panelists,
and
I
I'm
you
know
great
to
have
you
on
board
and
you
know
look
forward
to
talking
to
you
and
getting
your
thoughts
today
on
devsecops,
primarily
which
is
going
to
be
the
topic
for
discussion
today,
just
to
start
and
build
a
context.
A
You
know
I
have
been
fortunate
to
be
part
or
associated
with
cyber
security
and
application
security
industry
for
almost
two
decades
now
and
I
have
gone
through
the
transformation
that
devsecops
took,
and
I
have
seen
that
transformation
in
many
organizations.
A
You
know
from
the
days
when
application
security
was
just
about
a
penetration
testing
or
a
dynamic
testing
to
today
a
full-blown
devsecops.
You
know
implementation
where
you
have
penetration
testings,
you
have
sas,
you
have
composition,
analysis,
you
have
automation,
you
have
people
talking
about.
You
know
how
do
we
shift
security
left,
so
we've
really
come
a
very
long
way
and
I
think
many
reasons
to
the
same.
You
know
if
you
talk
about
what
have
been
the
real
drivers.
A
I
think
primarily
the
drivers
have
been
in
terms
of
data
breaches
are
on
rise,
so
60
of
successful
breaches
that
happen
today
actually
attack
your
application
layer,
and
it's
it's
really
really
very,
very
important.
If,
if
applications
are
your
most
vulnerable
areas,
then
you
know
you
have
to
take
care
of
your
applications
and
make
sure
that
you
secure
the
weakest
link.
A
I
think
also
in
terms
of
compliances
27001,
gdpr,
cert,
autosar,
rbi
guidelines.
I
think
regulations
and
compliances
have
been
becoming
very,
very
stringent
in
the
last
five
years
and
these
stringent
regulations
and
guidelines,
you
know,
enforce
organizations
to
look
at
application
security
very,
very
seriously
and
to
look
at
a
devsecops
motion.
A
I
think
we
recently
went
through
a
very
bad
patch
of
forward,
but
what
covert
has
really
shown
us
is
organizations
looking
to
now
digitalize?
You
know
every
business
it
had
to
if
they
had
to
be
successful
and
they
had
to
run,
they
really
had
to
you
know,
become
digital.
They
had
to
go
on
web
applications
or
mobile
applications.
A
So
a
lot
of
application
development
started
happening
and,
with
a
lot
of
code
being
written,
there
came
in
the
probability
of
any
kind
of
vulnerability
getting
introduced,
so
that
again
has
really
put
the
bar
high
in
terms
of
looking,
you
know,
csos
and
even
the
development
teams
looking
at
trying
to
make
sure
that
these
applications
are
secure.
So
that's
very,
very
important.
A
I
think
few
other
areas
are
number
of
releases.
I
remember
talking
to
a
few
development
teams.
You
know
five
six
years
back,
I
think
the
number
of
releases
we
saw
per
year
generally
used
to
be
two
three
or
maximum
four,
but
now
we
should
talk
to
development
teams.
The
kind
of
releases-
or
the
number
of
you
know,
releases
that
are
happening
today
are
somewhere
like
one
one
in
a
week
or
probably
hundred
in
a
year.
A
So
if
you
have
so
much
of
code
being
written
and
getting
attached
to
a
particular
application,
the
probability
of
a
vulnerability
or
an
issue
getting
introduced
goes
up
that
much
so
again
brings
in
the
need
for
use
of
you
know:
application
security
or
automating.
The
application
security,
I
think
open
source
has
been,
is
being
used
a
lot
these
days,
I
think
almost
70
to
80
percent
of
the
composition
of
any
software
today
generally
is
open
source,
while
open
source
is
the
way
to
go
ahead.
A
But
again,
open
source
comes
in
with
its
own
challenges,
its
own
issues,
so
I
think
that's
again,
something
which
we
need
to
really
look
at
very
very
seriously.
So
these
are
few
drivers
that
probably
we
have
seen
which
have
really
pushed
the
transformation
in
terms
of
devsecops
and
why
organizations
today
are
getting
very,
very
serious
about
application,
security
and
overall,
having
implementing
a
you
know
true
devsecops
initiative
in
their
organization.
So
with
that
you
know
I
would.
A
I
would
want
to
start
off
with
you
know,
asking
few
questions
to
the
panelists
and
understanding
and
knowing
their
thoughts
on
what's
happening.
So
maybe
I'll
go
with
so
satish
been
with
in
moby
for
some
time
now,
and
you
know
in
bobby,
is
primarily
into
mobile
advertising,
so
I'm
sure
you've
gone
through
a
devsecops
transformation
journey.
So
maybe
you
know
if
you
could
just
give
us
some
idea
on
how
was
your
devsecops
journey
and
what
were
the
challenges
that
you
really
faced
in
implementing
devsecops
in
your
organization.
B
Sure
ramon
thanks
for
having
me
here.
So,
in
fact,
I
think
you
touched
upon
most
of
the
areas.
In
fact
today,
no
doubt
application
security
is
one
of
the
biggest
driver,
especially
in
moby,
being
a
tech
focused
company
and
a
lot
of
code
being
written
and
a
lot
of
innovation.
In
fact,
I
think
that
drives
the
whole
business,
pure
tech
focused,
of
course,
cloud
focused
and
so,
while
involving
was
around
in
a
devops
journey,
but
I
think
devsecops.
B
In
fact,
I'm
sure
I
think
devsecops
has
evolved
over
a
period
of
time,
in
fact
just
to
see
how
the
overall,
because
fundamentally
security
was
always
like
it
is,
if
I
can
use
the
word.
Security
was
like
a
retrofitting
into
the
overall
build
cycle,
but
I
think
that's
where
the
whole
devsicops
emerged
right.
If
you
look
at
the
emerged
as
an
approach,
in
fact,
overall
approach,
how
we
can
address
security
concerns
at
an
early
stage
and
in
the
overall
the
build
and,
of
course,
the
whole
the
cicd
pipeline.
B
So,
while
absolutely
while
the
speed
is,
is
one
of
the
key
key
driver,
but
again
cesos
are
so
while
the
tech
coordinations
understand
the
need
for
security,
but
but
in
the
whole
agility
more
right
many
times
impact
teams
do
not
understand
or
realize.
So
I
think
it's
a
it's
a
lot
of
mind
shift
it's
a
lot
of
the
change
in
approach,
and
it's
all
about
how
do
we
incorporate
the
whole
security
in
the
overall
development
life
cycle?
B
So
so,
while
there
are
challenges,
but
I
I
call
it
devsicops,
this
is
journey
and,
of
course
we
are
in
the
journey
and
and
of
course
it
takes
time
to
mature.
So
so
that's
what
I
just
want
to
start
with
my
opening
comments.
A
A
You
know
changing
the
mindset
of
developers
who
really
resist
you
know
use
of
application
security
because
that's
an
that's
a
burden
for
them
as
that
they
feel
but
yeah
shifting
that
mindset
and
you
know
getting
them
onboarded
and
trying
to
communicate
to
them
that
yes,
this
is
a
must-
and
this
is
very
important,
is,
I
think,
that's
the
real
transformation
that
we're
looking
at
thanks
satish.
A
So
you
know
again,
I'm
sure
I'm
not
sure
if
how
relevant
it
is
in
in
navy,
but
just
to
get
an
idea
from
you
in
terms
of
you
know
how,
generally,
when
you
see
engineering
teams
and
security
teams,
you
see
a
lot
of
friction
as
we
were
discussing
and
understanding.
So
how
do
you
see
you
know
bridging
these
gaps
with
respect
to
you
know
getting
both
the
teams,
engineering
and
security
teams
together?
So
do
you
see
any
you
know
waste?
How
do
you
bridge
these
gaps
between
the
two
teams.
C
Ravine,
yes,
I'm
all
okay!
You
you
rightly
brought
out
that
the
journey
of
application
security
per
se
over
the
last
20
years
has
changed
you're
the
one
who
probably
has
been
through
this
journey
for
the
longest
period
of
time.
Let's
take
a
step
backwards.
Traditionally,
in
the
software
development
life
cycle,
developers
used
to
develop
code
testers
being
used
to
test
the
code,
then
at
I
would
say
somewhere
in
the
middle
of
2000,
early
2000's.
In
fact,
maybe
security
folks
stepped
in
and
said.
Okay,
let's
start
looking
at
security.
C
C
The
ratio
behind
this
is
very
clear.
The
cost
of
fixing
vulnerabilities
at
the
beginning
of
any
in
a
software
development
life
cycle
is
much
lesser
than
the
cost
of
fixing
the
vulnerabilities
at
a
later
stage.
I
personally
feel
it
is
easier
said
than
done.
The
reason
being
the
core
expertise
of
a
developer
is
to
build
functionalities
right.
They
are
largely
looking
at
functional
requirements
of
the
applications.
C
They
are
running
against
time
to
be
able
to
bring
build
the
applications
as
per
the
requirements
of
the
customers.
Suddenly,
the
absent
team
jumping
into
and
saying,
hey
look.
These
are
the
security
vulnerabilities.
You
need
to
look
into
more
often
than
not
for
a
developer.
This
is
greek
and
latin.
You
know
they
don't
really
understand
how
these
vulnerabilities
would
affect
in
in
the
longer
period
of
time.
C
Now,
how
do
we
address
this
problem
or
how
to
reduce
this
friction
is
what
you
actually
brought
out
right.
We
at
ze
are
looking
at
a
three
prong
strategy
tools,
technology
and
processes
get
the
right
set
of
tools
which
are
easy
to
use,
make
them
available
to
the
developer,
so
that
you
know
vulnerabilities
are
highlighted
at
a
much
earlier
stage.
C
Second
and
most
importantly,
is
train
and
sensitize
the
developers
and
equip
them
to
be
able
to
address
the
issues
before
the
code
is
checked
in
and,
finally,
and
most
importantly,
is
to
have
the
process
and
guidelines
very
clearly
defined.
We
at
z
have
taken
one
more
step
ahead.
Actually
we
operate
in
pods.
What
do
we
mean
by
a
pot
is
each
part
is
responsible
to
develop
one
or
a
set
of
functions
of
the
overall
project.
C
We
have
a
team
of
product
managers,
development,
development
teams,
ui
ux
experts,
data
data
scientists,
as
well
as
cyber
security
specialist
as
part
of
the
spots,
so
in
simple
words,
the
sport
is
some
some
sort
of
a
self-sustained.
You
know
fully
equipped
to
architect
design
develop,
deploy
any
given
functionality.
C
Talking
from
the
security
perspective,
in
simple
words,
security
is
built
as
part
of
the
design,
rather
than
it
being
an
afterthought.
In
other
words,
what
we
are
trying
to
build
at
ze
is
a
relationship
between
the
security
and
the
development
team.
Largely
in
in
most
of
the
organization
is
transactional,
whereas
in
in
in
my
organization
where
we
are,
we
are,
you
know
grouped
as
sports.
C
It
is
a
holistic
kind
of
you
know,
relationship,
that's
what
we
have
seen
in
the
last
three
to
four
months
is
we
have
been
able
to
reduce
the
that
so-called
friction
between
the
development
team
and
the
security
into
a
large
extent.
A
I
think
you
hit
the
nail,
you
know
it's
the
relationship,
it's
it's.
Basically,
the
collaboration
between
the
two
teams:
how
to
get
them
together
to
make
them
work,
but
you
know
empower
empowering
the
developers,
training
them
guiding
them
on.
You
know
thought
so
perfect,
perfect
thanks
a
lot
on
that.
So
by
moving
on
to
you,
you've
been
with
infosys
for
some
time
now,
you've
been
managing
their
devsecops
and
I'm
sure
I
know
you
for
last
five
years
and
I've
seen
you
know
the
devsecops
transformation
that
has
gone
through
in
infosys.
A
So
maybe
what,
according
to
you,
is
the
role
of
automation
in
application
security,
because
if
you
see
today,
a
lot
of
organizations
still
rely
a
lot
on
manual.
You
know
activities
when
it
comes
to
application
security,
and
did
you
see
any
challenges
with
respect
to
transitioning
from
a
manual
way
of
doing
application,
security
to
automating
this
entire
process
of
application,
security.
D
Hi
everyone
having
me
here
yeah
so
when
it
comes
to
the
challenges
before
challenges,
probably
I'll
talk
about
the
application
security,
automation
itself,
like
you
said,
the
post
pandemic
work
from
home
scenario,
forced
us
to
concentrate
more
on
applications,
because
application
is
the
backbone
at
imposes
it's
not
only
about
the
applications
that
inforcions
use.
D
It's
also
about
the
deliverables
that
we
give
to
our
clients,
and
we
have
to
ensure
that
the
all
these
applications,
the
internal
ones
and
the
deliverables
that
we
give
to
our
clients,
they're
all
secured
and
the
post
pandemic
scenario,
told
us
that
taught
us
that
we
need
to
look
at
these
applications
for
every
sprint.
The
sprints
were
probably
two
weeks
apart
and
to
go
at
that
scale.
D
To
perform
assessments
at
that
scale
was
really
difficult
if
we
were
in
a
manual
assessment
mode
and
we
had
to
move
into
automated
assessment
mode
and
when
we
are
talking
about
automated
assessment,
it
is
not
only
one
thing.
It's
about
sas
dust,
I
asked
now,
so
there
were
so
many
assessments
that
we
had
to
do,
and
automation
was
the
only
way
to
go,
and
when
we
talk
about
automation,
we
were
not
only
talking
about
shift
left.
D
We
were
talking
about
shift
everywhere,
wherever
it
is,
the
complete
phase
of
the
life
cycle
manage
the
software
life
cycle
management.
We
have
to
be
everywhere
to
ensure
that
the
security
of
our
applications
are
managed,
and
for
that
you
know,
rather
than
talking
about
challenges,
I
would
rather
talk
about
the
focus
areas
that
we
looked
at.
One
was,
of
course,
the
inventory
you
know,
because
we
wanted
to
look
at
the
complete
inventory
of
applications.
D
We
had
hundreds
and
hundreds
of
applications
in
the
ecosystem
that
we
had
to
bring
it
all
together
and
one
one.
The
second
thing
was
the
technology
focus
so
infosys.
As
such,
we
had
multiple
technologies.
We
have
multiple
technologies
that
we
are
working
on
and
the
coverage
technology
that
can
cover
everything
into
end
is
also
something
that
was
challenging.
So
we
had
to
look
at
multiple
things
which
can
cover
that.
D
So
these
two
predominantly
was
our
focus
area,
and
the
third
thing
is
how
the
detection
part
of
it
and
the
remediation
part
these
two
are
in
line
with
each
other,
so
detection
does
not
have
any
use
if
the
remediation
is
also
at
the
same
level
of
it
and
to
enable
the
developers
to
be
able
to
remediate
quickly
so
that
they
are
able
to
bring
their
code
to
market
at
a
faster
rate.
That
was
our
focus
area
as
well.
D
A
Yeah,
I
agree
with
you.
It
is.
It
is
the
remediation
rate
and
not
detection,
because
if
you
may
have
the
best
of
technologies-
and
you
know
you
may
identify
thousands
of
vulnerabilities,
but
if
they're
not
fixed
before
you
move
your
application
into
production,
it's
it's
basically,
no
use.
In
fact,
the
industry
trend
today
is
that
in
the
first
one
week
of
identifying
these
vulnerabilities,
only
15
of
these
vulnerabilities
get
fixed
and
that
number
goes
up
to
around
45
percent
in
the
next
three
months.
A
So
he's
looking
for
a
solution
which
can
help
organizations,
you
know
not
detect
but
remediate.
I
think
that's,
that's
that's
a
very,
very
critical
thing
to.
A
I
think,
as
an
organization
as
a
cso
or
a
security
team,
I
think
very,
very
important
aspect
is
security
governance
to
look
at
the
health
of
applications
in
your
organization,
so
different
organizations
take
different
routes.
There
are
governance
tools.
There
are
multiple,
you
know,
tools
that
are
developed
in-house.
So
how?
What
are
you
doing
in
your
organization
today
to
really
look
at
a
governance
of
your
applications
or
to
look
at
the
health
of
your
applications?
How
do
you
monitor
all
this.
E
Hey
thanks
for
having
me
up,
and
it's
a
pleasure
to
be
here
so
to
answer
your
question.
E
Basically,
amaki
is
an
extremely
dynamic
and
an
extremely
agile
company,
and
we
are
extremely
business
driven
in
the
sense
that,
as
long
as
features
are
working,
it's
good
to
go
so,
which
means
we
have
a
versatile
set
of
tools,
different
platforms,
a
diverse
set
of
open
source
tools
that
we
consume,
and
you
know
our
developers
writing
in
all
possible
languages
which
effectively
means
that
we
from
a
security
standpoint
and
a
securities
tool
standpoint.
E
We
are
generating
a
lot
of
vulnerabilities
alerts,
observations
and
findings
and,
as
these
happen
across
different
tools,
there
are
different
severity
categories.
There
are
different
parameters
based
on
which
each
tool
categorizes
the
severity
across
you
know
a
particular
piece
of
code
or
an
application.
E
So
there
are
two
of
two
ways
we
are
trying
to
govern
this
one.
While
we
are
exploring
a
standard
industry
standard
tool
which
could
actually
aggregate
all
of
these
observations
and
standardize
them
across
the
organization's
risk
management
framework.
While
we
are
still
doing
that,
we
are
also
trying
to
automate.
You
know
how
these
findings
are.
E
Being
funneled
into
one
particular
dashboard
so
that
we
have
a
single
pane
of
glass
in
to
be
able
to
demonstrate
to
the
leadership
and
the
management
on
what
what
is
the
security
posture
of
each
of
our
products
and
applications?
E
Meanwhile,
vapt,
as
usual,
is
always
one
of
the
most
reliable
sources
of
our
capability
in
terms
of
identifying
the
security
posture
of
each
other
of
each
product.
So
just
before
the
product
goes
live
or
you
know
periodically.
We
make
sure
that
there's
a
vfd
run
on
every
product
to
ensure
that
security
posture
is
compliant
to
maggi
standards.
A
Giving
us
that
idea
on
how
do
you
funnel
and
get
everything
on
a
single
dashboard
to
present
it
to
the
top
management,
because
if
they
are
satisfied,
your
applications
are
secure.
You
know
you
get
more
budgets
so
moving
on
to
sateesh
now
satish,
maybe
you
know
as
we're
talking
about
devsecops,
and
if
you
talk
about
cops,
you
know
what
comes
in
our
mind
is
shifting
security
left
moving.
I
think
praveen
spoke
about
it
but
moving.
A
You
know:
secure
security
from
the
cso
team
to
the
developers
and
helping
developers
identify
vulnerabilities
in
their
workflows
in
their
day-to-day.
You
know
job
when
they're
writing
the
code.
So
what?
What
are
your
thoughts
on
the
same
and
are
you
seeing?
Have
you
implemented
the
same
in
your
organization
and
are
you
seeing
some
impact
on
the
developer
productivity
person
by
shifting
security
left.
B
Yes,
I
think
this
has
been
always
a
thought
or
a
discussion
like
it's
important
to
shift
left
because
see
that's
where
at
the
early
stage
you
should
start
thinking
security
and
coming
back
to
developers.
I
think
a
lot
of
training.
In
fact,
education
needs
to
be
done
because,
as
I
think,
praveen
and
other
families
said
fundamentally,
developers
are
there
to
write
code.
Their
focus
is
on
functionality,
not
in
security.
B
So
I
think
that's
where,
while
it
is
not
that
they
don't
understand,
but
then,
as
you
said
rightly,
the
productivity
piece
comes
in.
They
may
feel
that
okay,
this
is
one
more
additional
burden
for
me
or
I
think
that's
where
the
tools,
I
think
the
tool
said
the
new.
B
How
how
you
need
to
ensure
that
you
need
to
write
secure
code?
I
think
that's
where
that's
that's!
The
most
of
the
organizations
are
putting
efforts
in
trying
to
see
how
they
can
take
security
at
much
early
stage,
of
course,
right
from
the
early
design
board.
If
I
can
say
at
the
design
stage
at
the
drawing
board
itself,
I'm
sure
traditionally
also
we
used
to
talk
about
threat,
modeling
and
that
still
exists,
but
coming
from
the
developer
perspective,
I
think
it's
very
important
to
do
a
lot
of
training
awareness,
education.
B
It's
not
the
standard.
Generic
education
very
focused
fat
training
for
the
developer.
Just
to
to
make
him
aware
that
how
why
it's
important
for
him
to
write,
sick
and
safe
and
secure
code?
That
is
one
sort
of
thing
and
second
provide
the
right
tool
set,
of
course,
because
that's
where
life
is
going
to
be
much
more
easier
for
the
developer
so
that
he
understands
and
then
of
course,
the
the
next
as
part
of
the
build
checks.
B
A
Yeah,
I
completely
agree
with
there's
a
lot
of
transformation
happening
and
I
I
completely
I'm
with
you
on
that
quickly.
A
Moving
on
to
praveen
praveen
again,
I
would
need
your
quick
thoughts
on
a
lot
of
open
source
is
being
used
today
by
developers,
and
I
said
this
is
this
is
much
that's
the
way
of
life,
but
how
are
you
managing
open
source
issues,
security
risks
because
it's
it's
a
very,
very
important
if
seventy
percent
of
your
code
is
open
source,
you
know
you
need
to
be
very,
very
clear
on
how
do
you
manage
it?
So
what
are
you
doing
in
your
organization
to
manage
open
source
risks.
C
Thanks
so
much
yeah
open
source
risks
have
been,
you
know,
talked
about
in
various
forums,
and
I've
heard
a
lot
of
people
talking
about
it
as
a
risk.
But,
as
you
rightly.
D
C
C
But
what
is
the
problem
with
the
open
source
code?
Let's
talk
about
that
fly
I
mean
largely
speaking.
The
nature
of
open
source
model
is
that
open
source
projects
make
their
code
available
to
everyone,
which
means
that
open
source
community
can
flag
potential,
exploits
they
find
in
the
code
and
give
open
source
project
managers
time
to
fix.
The
issue
sounds
great
right
as
a
as
a
security
practitioner.
You
know
there
are
whole
bunch
of
people
who
are
looking
at
security
of
that
part
of
code.
So
largely
where
is
the
problem?
C
I
feel
the
problem
is
largely
about
how
we
are
managing
the
open
source
code.
The
problem
is
not
with
the
open
source
code,
but
how
we
are
managing
it.
You
know
whenever
somebody
talks
about
open
source
code.
It
reminds
me
of
that
famous
you
know:
2017
equifax
breach.
You
know
all
of
us
know
right
they
were.
C
They
were
around
140
million
personal
data,
which
was
exposed,
and
there
was
a
huge
you
know
human
cry
about
that
particular
incident
and
most
of
us
know
that
was
actually
related
to
open
source
code
and
that's
where
people
started,
believing
that
the
problem
is
with
the
open
source
code.
But
the
problem
inherently
was
not
in
the
open
source
code.
It's
about
how
the
open
source
code
was
managed
by
equifax
in
those
days,
and
all
of
us
know
that
the
moment
of
vulnerability
is
flagged
in
an
open
source
repository
and
it
gets
remediated.
C
So,
as
I
said,
the
problem
is
not
with
the
open
source
code.
It
is
about
how
we
manage
it.
You
know
our
patch
cycles.
The
way
we
keep.
You
know
how
we
account
the
open
source
software
in
our
applications.
This
is
where
we
need
to
you,
know,
mature,
and
you
know,
having
our
inventory
clearly
flagging.
Those
parts
of
open
source
code
which
have
you
know
which
have
been
abandoned-
you
know
a
huge
part
of
open
source
codes,
are
not
maintained
throughout
the
life
cycle.
C
There
always
comes
a
period
of
time
once
you
know
this.
The
support
system
for
that
open
source
repository
is
not
available
anymore,
so,
which
means
each
of
us.
Each
of
us
as
csos,
have
to
take
specif
special
care
to
ensure
that
we
have
a
complete
repository
or
a
list
of
open
source
code
which
are
there
as
part
of
our
application.
C
What
is
the
status
of
each
of
those
open
source
repositories
and
also
ensure
an
another
major
issue
which
you
know
I've
seen
a
few
more
few
more
problems
with
open
source?
Is
that
a
lot
of
people
because
of
the
inherent
policies
of
the
organization
tend
to
copy
and
paste
the
open
source?
C
Libraries,
instead
of
you
know
importing,
is
as
a
library
and
having
a
having
a
you
know,
repository
of
that
we
tend
to
copy
and
paste
it,
which
means
there
is
no
record
of
that
open
source
software
which
has
been
used
in
the
code.
So
largely
speaking,
proliferation
of
open
source
components
is
there
to
stay.
There
is
no
two
ways
about
it.
What
we
need
to
probably
do
is
to
have
policies
and
procedures
to
support
and
manage
them
efficiently.
A
Thanks
thanks
praveen,
that
was
you
know
amazing.
I
am.
I
would
have
loved
to
continue
this
discussion
this.
This
was
so
knowledgeable
and
and
learned
so
much
about
what
organizations
today
are
doing
across,
but
unfortunately
we
have
a
time
has
come
to
end,
and
I
would
like
to
before
finishing.
A
I
would
like
to
again
thank
you
all
for
taking
out
time,
and
you
know
joining
us
for
this
discussion
on
devsecops
and
I'm
sure
all
the
viewers
would
make
good
use
of
this
knowledge
and
would
benefit
from
it
thanks.
Thanks
again
everybody
and
thanks
for
coming
joining
us.