►
From YouTube: CHAOSS.Risk.Sept.25.2020
Description
CHAOSS.Risk.Sept.25.2020
A
B
A
C
A
A
A
To
that,
like
this,
discussion
has
already
been
discussed
like
where,
should
we
locate
this
dependencies
now
I
see,
evolution
is
already
have
already
started,
working
and
risk.
This
is
coming
again
and
again
and
even
from
the
value
the
discussion
is
still
going
on.
So
should
everybody
do
it
on
their
own
and
then
we
combine
it
collectively
or
what
should
be
the
goal.
D
I
kind
of
like
what
so
what
we
had
laid
out
of
all
the
different
types
of
dependency
categories,
because
I
think
for
me
what
could
make
logical
sense
that
if
we
have
more
of
a
holistic
set
of
dependency
categories,
then
no
single
group
will
own
all
of
them.
There
might
be
natural
fits
within
a
series
of
them.
D
I
mean
this
is
just
this
is
saying
this
before
actually
look
at
how
things
are
broken
out,
and
maybe
it's
not
going
to
be
as
clean,
but
just
in
terms
of
feasible
tackling
like,
I
think
it
would
make
sense
to
kind
of
split
it
up
then,
and
even
if
it's
not
a
perfect
alignment
to
individual
working
groups,
I
think
because
it's
such
a
big
topic
it.
It
should
lend
itself
well
to
different
pockets
talking
about
it
because
they
might
come
up
with
different
things
organically.
D
B
Yeah
and
then
I
then
there's
one
person
that
basically
has
to
hop
from
working
group
to
working
group
to
make
sure
that
any
like
alignment
is
is
being
done.
So
it's
it's
mostly
like,
like
your
your
suggestion,
has
huge
benefits
in
that
the
conversation
can
occur
in
three
different
places
and
a
lot
of
the
different
people
who
attend
the
different
working
groups
can
bring
their
insights.
A
B
And
so
he
has
a
lot
of
interest
in
dependencies
and
sophia.
He
had
actually
sent
me
the
exact
same
video
that
you
sent
me,
and
here
you
are
in
the
risk
working
group,
obviously
with
some
awareness
and
interest
in
dependencies
and
as
venat
had
pointed
out,
it's
in
the
evolution
working
group
too.
So.
A
A
F
Why
don't
we
just
try
to
basically
have
everyone?
You
know
focusing
on
dependencies
in
their
groups
and
then
just
basically
call
a
dependencies
meeting
and
have
everyone
from
all
the
groups
are
interested
in
dependencies?
Show
up
sometime
yeah.
So,
like
you
know,
we
did
this
sort
of
thing
organically
in
the
in-person
conference.
So
why
don't
we
just
use
the
remote
to
you
know,
call
effectively
a
bit
of
a
workshop
on
okay.
B
C
F
C
B
F
B
F
B
F
C
F
F
F
F
F
F
H
F
E
F
C
F
F
D
F
F
F
F
F
C
F
F
F
F
F
D
F
C
B
B
B
D
It
was
more
of
a
comparative
measure,
at
least
how
we
were
using
it
internally
so
like
if
you
know
that
you
have
a
dependency
on
this
piece
of
software,
how
much
is
it
actually
being
used
and
so
one
way
to
quantify
it,
and
so
that
was
that's.
I
think
where
it
came
from
because
of
knowing
how
our
dependency
server
thing
thinks
that's
what's
happening,
but
just
as
a
way.
C
D
C
C
Okay,
because
I-
but
I
I
agree
with
you-
I
don't
know
if
any
of
you
are
familiar
with
the
cii
work
recently
on
this
they're
trying
to
identify
through
dependencies
and
stuff
and
the
ones
that
came
up
at
least
in
the
javascript
area,
for
the
most
part
are
projects
that
most
people
have
never
heard.
Of.
I
mean
people
have
heard
of
lodash,
but
most
the
rest
that
you
know
you
only.
B
F
And
that's
why
we
have
the
supply
chain
risk
right,
and
you
know
the
open
source
ecosystem
got
all
these
really
interesting,
fragile
places.
I
still
love
that
xkcd
comment.
If
that
comment
that
you
in
there
that
you
know
that
that
should
be
our.
You
know,
in
fact,
if
the
dependency
was
out
of
nebraska,
if
I
remember
it.
B
C
C
The
real
pain
point
is
what
is
an
intersection
of
what's
important,
combined
with
what
isn't
getting
a
lot
of
support
it,
so
that
that
xkcd
cartoon
is
great
example
of
the
it's
not
just
that
it's
widely
used,
it's
widely
used
and
the
person
who's
supporting.
It
is
it's.
You
know
they.
They
have
many
other
things
to
do
with
their
life
and
nobody
realizes.
There's
a
problem.
Yeah.
F
Like
zlib
was
a
problem
in
this
way
right
in
terms
of
getting
updates
happening
to
it,
because
the
person
who
was
the
maintainer
didn't
really
have
a
good
test
infrastructure
and
was
very
reluctant
to
take
in
changes.
It
might
break
things,
and
so
there's
all
these
interesting
forks
that
are
emerging
or
people
are
doing
what
they
needed
to
do.
But
a
lot
of
people
were
using
and
depending
on
xeno.
F
C
F
You
know,
if
you're,
installing
a
container
in
order
to
do
a
task,
what
you're
bringing
in
with
it
is
ambiguous,
sometimes
and
those
are
all
effectively
dependencies
in
order
for
your
task
to
execute,
because
they've
all
been
put
in
there,
some
of
those
are
sitting
in
the
tear.
They
don't
need
to
be
so.
F
You've
got
stuff
in
there
that
you
know
you're
not
going
to
can't
have
a
vulnerability
if
it
hasn't
all
really
or
not,
doesn't
much
matter,
but
nonetheless
it's
there
and
then
there's
some
things
in
there
that
then
have
a
dependency
on
the
infrastructure
for
running
the
clouds
you
don't
have
access
to.
So
that's
what
I
mean
by
direct
dependencies
in
indirect,
okay.
D
So
if
you
start
factoring
in
a
different
type
of
software
development
architecture
and
tooling,
that
has
less
dependencies
on
proprietary
infrastructure
and
tooling,
then
that
is
a
category
of
dependency,
so
they're
at
a
certain
point,
you're
now
mixing
in
architectural
principles
with
the
level
of
dependencies
that
you're
incurring
what
tools
are
we
selecting
knowing
that
they're
more
or
less
dependent
on
these
things?
Are
there
now
because
of
the
microservices
architecture?
D
There
are
ways
to
reduce
individual
dependencies
because
things
are
running
modularly,
so
maybe
your
software
execution
dependency
only
fails
for
one
of
your
five
things,
and
so
that's
not
a
complete
failure.
So
you
essentially
can
engineer
different
elements
of
risk
and
dependency
depending
on
all
these
things,
which
I
just
feel
like
makes
the
conversation
a
little
bit
too
complex
for
coming
up
with
simple
metrics.
Unless
we,
unless
we
say
in
this
context,
this
is
the
I
think,
then
we
can
have
very
defined
risk.
D
So,
like
the
omaha
example,
I
think
that's
that's
very
much
like
the
people
risk.
What
happens
if
that
guy
goes
away,
then
this
thing
will
eventually
fail
and
there's
no
one
who
knows
what's
happening
or
no,
who
knows
how
to
jump
in
there
and
fix
it.
So
I
see
that
as
sort
of
like
a
a
people
dependency
and
then
I
think,
to
david's
point,
that's
sort
of
if
you're
looking
at
it
from
a
supply
chain
perspective,
then
that's
a
big
area
of
risk,
which
was
highlighted.
D
F
F
B
B
So,
for
example,
I
know
david
you
had
put
like
known
vulnerabilities
in
those
dependencies,
so
we
can
get
a
landscape
view
of
what
the
dependencies
are
and
it's
almost
like
a
neutral
look.
I'm
guessing
is
what
this
dependency
tracker
thing
is,
but
this
will
allow
us
to
then
do
a
deeper
dive
as
to
which
metrics
or
which
thing
what
questions
we
should
be
asking
against
this
data.
C
F
We
have
a
bunch
of
relationships
so
that
you
can
actually
track
it
and
then
the
ntia
stuff
right
now.
One
of
the
things
I
might
I
have
to
work
on
for
them
is
writing
up
some
examples
and
so
starting
to
articulate
what
is
known
versus
what
is
like
are
your:
is
your
dependencies
set
complete
or
not,
or
is
there
ambiguity
in
your
dependency
set,
and
so
this
is
something
that
has
been
identified,
that
they
want
to
be
able
to
track
for
various
devices
like?
F
Can
you
say
that
you
have
listed
all
the
dependent
all
the
first
level
dependencies?
All
the
second
level
depends,
you
know
for
all
the
pencils
of
a
package.
Can
you
be
explicit,
you
can
list
them
all,
or
do
you
know
that?
There's
something
you
don't
know,
and
so
this
concept
of
it
is
everything
known
or
is
it
unknown
is
an
element
that
has
to
be
working
out.
F
We
have
to
work
our
way
through
the
tooling
with
and
up
till
now
what
happens
is
people
have
put
what
they
know,
but
they
don't
try
to
figure
out
what
they
don't
know
and
what
they're,
assuming
and
when
they're
writing
the
feeds
on
dependency
trees.
These
directed
graphs
and,
like
you
know,
a
lot
of
the
things
that
sort
of
show
your
component
packages,
but
you
may
not
be
showing
all
the
libraries
you're
expecting
and
they're
running
on
the
os
underneath
you
and
so
that's
that's
getting
interesting
to
me.
B
E
F
D
E
F
C
F
Omg's
is
basically
just
models;
no
one's
actually
implemented
the
format
or
kind
of
a
serialization
of
it.
Yet
it'll
be
close
to
spx3.
If
we
keep
our
keep
working
it,
but
anyhow,
so
you
have
a
bill
of
materials
that
someone's
giving
you
for
a
product,
and
then
you
have,
you
can
start
walking
through
it
with
dependency
track
and
then
looking
at.
B
C
G
C
A
C
Various
databases
that
say
for
this
component:
what
are
the
known
vulnerabilities
and
you
hopefully
look
up
for
this
component?
One
of
the
known
vulnerabilities
are
the
versions
that
I
have
now
there's
a
next
step,
which
is
of
the
known
vulnerabilities,
which
ones
apply
to
my
system
and
that's
a
much
harder
analysis.
F
Okay,
what's
absolutely
staggering
is
how
much
the
commercial
world
does
not
acknowledge
that
they
have
open
source
underneath
them
and
they
don't
even
try
to
track
down
the
lower
levels
and
the
when
you
start
talking
to
people.
You
know
at
the
end
customer
point
and
you
realize
just
how
unsophisticated
a
lot
of
them
are.
The
crawl
walk
run
aspect
has
to
be
taken
into
account
and
there's
a
lot
of
the
commerce
there's
a
lot
of
the
ecosystem.
That's
completely
crawl,
isn't
even
crawling
yet
in
the
whole
day,.
F
C
Yeah
yeah
and
I
think
what
that
shows
is
that
they
didn't
understand
the
other
five
percent,
because
what
I'm
gonna
tell
people
is,
there's
only
two
kinds
of
organizations,
the
one
that
know
they
are
and
the
ones
that
don't
know
they
are.
Those
are
your
only
options.
There
are
no.
There
are
no
projects
any.
There
are
no
companies
anymore
of
any
real
size
that
don't
use
open
source
if
you're
using
windows
and
mac
you're,
not
using
you're
using
open
source,
you
don't
use
any
technology
at
all.
Yeah,
that's
going
to
be
a
challenge.
B
B
D
C
I
mean
it
actually
takes
relative,
a
little
little
effort
to
write
a
code
that
looks
for
say
a
gem
file
or
you
know,
or
a
basically
the
various
files
for
the
various
programming
languages.
That
tell
you
here
are
the
libraries
at
the
least.
You
should
be
able
to
load
that
in
and
be
able
to
see
right
away.
Well,
what
am
I,
depending
on
okay,.
A
C
C
One
of
the
problems
with
that
is
the
and
the
thing
that
I
try
to
get
people
never
never
to
do
is
when
we
copy
that
open
source
project
into
our
directory
here
and
then
we'll
start
making
edits,
because
then,
as
soon
as
you
do,
that
it's
not
typically
no
longer
tracked,
it's
known
and-
and
now
you
may
and
over
time
it
becomes
increasingly
difficult
to
figure
out.
Is
that
the
real
pro
is
that
the
original
project
is
this
so
modified?
C
B
C
A
C
Okay,
I
don't
own
some
of
these
projects,
so
I'm
just
gonna
delete
my
name
and
say
security
threats,
dashboard
projects.
So
if
you
don't
mind
before
we
end
I'd
like
to
just
quickly
note,
there
is
another
group
open
source
security
foundation,
open
ssf,
there's
a
working
group
called
security
threats
which
is
kind
of
misleading.
It
doesn't
tell
you
what
the
working
group
is
about
they're
interested
in
developing
a
dashboard
to
create
metrics
and
measure
them
for
security
related
metrics
for
projects
that
seems
to
be
highly
related
to
this
risks
group.
C
A
C
To
measure
things
now
they
have
a
very
specific
goal.
They
want
to
create
a
little
dashboard
where
you,
you
know,
basically
enter
a
url
and
poof.
You
get
metrics
on
it.
So
they're,
not
you
know
if
it's
something
that's
hard
and
requires
specialized
work,
and
we
can
do
it
for
50
projects,
that's
not
what
they
want.
They
want
to
be
able
to
do
it
for
a
very,
very
large
number
of
projects.