►
From YouTube: A complex web of open source software dependencies risk | Sean Goggins | CHAOSScon NA 2021
Description
A complex web of open source software dependencies risk
Today, software project development is nearly impossible without the use of interdependent components. These interdependencies have such a strong impact that software projects often fail if an open-source project library malfunctions. This was observed in the NPM project, when an open-source project contributor deleted 11 lines of code that he had contributed to an open-source library causing many other projects dependent on this library to fail. This presentation will present a synthesis of the complexity of managing dependencies, and the relationship between open source software dependency metrics, quality assurance, and security. Members of the CHAOSS Risk working group will answer a simple yet a complex question: what are the categories of open source software dependencies, and what metrics can make these risks visible. Participants will gain insights into: 1. What to measure? And 2. How to measure dependency risks? To answer these questions we worked across Linux Foundation projects to identify various dependency issues, and develop a set of metrics based on: 1. Goal 2. Question 3. Metric Approach. The metrics we then implemented using the CHAOSS Project’s Augur software will demonstrate one approach for visualizing and assessing dependency risk across large project portfolios. The key takeaway is it is work measuring the riskiness of a piece of software you're using or dependent on.
A
I
don't
think
I
need
it
all
right.
What
we
really
want
to
communicate
from
the
risk
working
group
is
that
a
lot
of
times
in
chaos?
We
have
a
problem,
we
understand
it,
we
know
of
a
range
of
contained
solutions
and
we
go
about
building
metrics
and
developing
tools
for
those
metrics
to
reach
those
solutions.
A
When
we
started
into
the
dependencies
world,
it
was
a
lot
like
the
la
brea
tar
pits
or
how
many
people
have
thought.
I
just
want
to
stream
something
on
the
internet.
I
want
to
stream
a
show,
and
first
you
have
to
figure
out
what
channel
it's
on
and
what
all
the
channels
are,
and
you
end
up
finding
this
giant
array
of
channels.
A
We
want
to
understand
if
our
project
is
secure,
if
it's
safe
and
how
do
we
measure
dependencies?
That
was
the
big
one,
because
there
are
a
lot
of
tools
out
there
that
measure
different
dimensions
of
dependency
and
the
biggest
thing
not
being
looked
at
is
how
can
I
use?
Can
I
use
some
dependency,
that's
fundamentally
unsafe.
If
I
can
build
something
trustworthy
around
it
and
how
do
I
handle
it?
A
If
a
lot
of
my
applications,
functionality
actually
derives
itself
from
dependencies,
also
designing,
so
that
a
mistake
isn't
the
end
of
the
world
and
then
ultimately
measure
dependencies
and
the
dependency
problem
looks
like
this
classic
xkcd
model,
where
there's
some
random
project
from
a
person
in
nebraska.
I
want
to
point
out
that
xkc
is
calling
out
nebraska.
A
A
Each
of
these
links
which
are
available
in
the
slides
is,
is
one
way
of
approaching
dependency
risk
in
open
source
software,
and
so
we
sifted
through
all
of
those
and
came
back
to
these
questions,
to
define
you
know
what
are
the
indicators
of
dependency
risk?
How
can
we
quantify
them?
What
can
we
measure
does
time
matter?
A
In
some
cases
it
does
sometimes
it
doesn't
and
what's
the
value
of
any
particular
dependency
metric
oops,
and
so
we
used
the
goal
question
metric
process
that
has
been
essential
in
the
chaos
project
to
define
two
metrics
so
far,
one
is
upstream
dependencies
for
my
software
and
the
other
is
live
years,
and
so,
in
the
case
of
libya,
I'll
just
use
this
brief
example.
Our
goal
is
understanding
the
scope
of
dependencies
in
a
project
so
and
then
identifying
the
higher
level
dependencies.
A
And
then
the
question
is
what
is
the
age
of
the
project
dependencies
compared
to
the
current
stable
release?
I
will
not
go
through
the
detailed
description,
but
you
can
think
of
it.
This
way,
you
can
look
at
it
at
a
project
level
and
understand
how
out
of
date
each
individual
dependency
is.
You
can
also
look
at
it
at
an
ospo
level
and
say
how
what's
the
total
number
of
libyars
a
particular
project
is
out
of
date
and
across
all
of
those
projects
which
which
dependencies
are
most
important
say.
A
I
have
11
000
projects
in
my
ospo,
which
are
the
dependencies
that
are
at
high
that
place
me
at
the
highest
risk.
So
you
can
use
libya
to
get
a
coarse
grain
view.
So,
instead
of
looking
deeply
into
11
000
projects,
you
can
focus
intently
on
the
50
or
500
dependencies
that
have
posed
the
most
significant
risk
for
you
at
this
time.
A
This
is
just
another
picture
of
all
the
different
ways
that
we
looked
at
risk
from
the
perspective
of
people
and
the
tribal
knowledge
that
exists
within
projects.
The
money
that
exists
to
invest
how
maintained
is
the
project?
Is
somebody
keeping
track
of
your
dependencies?
I
know
we're
writing
code
fixing
bugs,
but
you
still
have
import
statements
and
libraries
that
you're
using
who's
checking
to
make
sure
that
that's
happening
test
coverage
is
obviously
important
fit
for
purpose.
A
So
a
medical
device
has
a
much
more
stringent
set
of
controls
on
it,
perhaps
than
a
website
and
then
are
there
any
export
restrictions.
Obviously,
there's
a
list
of
countries
we
can't
use
dependencies
from
and
at
the
end
of
the
day,
thanks
thing
in
large
measure
to
sophia's
driving
us
towards
a
goal.
Okay.
A
So
what
can
we
measure
we
sorted
through
all
this
stuff
and
we
came
up
with
a
list
of
what
we
call
our
minimum
viable
metrics
and-
and
so
it's
just
listening
all
the
dependencies
that
exist
in
your
project
and
we
can
use
other
chaos
metrics
when
we
identify
the
50
oldest
ones.
Perhaps
we
can
then
use
other
chaos
metrics
to
assess
the
health
and
sustainability
of
those
projects
that
we're
dependent
on
and
how
many
times
is
a
dependency
reference
in
a
particular
ecosystem.
A
So
are
we
causing
other
people
problems
by
being
out
of
data
on
something
and
we're
also
implementations
of
osf
scorecard
and
then
a
matrix
of
known
vulnerabilities?
So
the
the
piece
that
sort
of
intersects
with
security
and
dependencies
is
vulnerabilities,
database
and
known
software
vulnerabilities,
and
so
that's
sort
of
an
orthogonal
cross
piece
that
we
can.
We
can
build
a
metric
around.
C
C
So
I
think,
for
sort
of
the
next
level
out
in
terms
of
how
we're
going
to
explore
metrics
and
continue
to
develop.
This
is
thinking
not
just
about
what
we
can
actually
measure,
which
is
what
we
focus
on
initially,
but
in
appropriate.
What
we
should
be
measuring
to
actually
make
this
more
of
a
meaningful,
a
meaningful
evaluation.
B
B
C
C
Because
of
that
ambiguity,
where
we're
initially
debating
between
just
overall
age
versus
age
of
less
stable
release,
which
doesn't
necessarily
mean
the
most
current
and
essentially
acknowledging,
if
there's
a
better
way
to
track
what
what
is
actually
still
a
stable
and
secure
release
versus
just
the
time.
So
it's
definitely
an
approximate
and
we've
seen
a
few
different
approaches
to
try
to
make
it
more
aligned
to
how
that
individual
organization
evaluated
risk
in
their
own
context.
A
B
C
I
mean,
I
think,
the
the
side
comment
here
too
is
another
element
of
discussion
in
our
working
group
is
what
is
the
best
sort
of
the
easier
ways
to
bring
in
more
context
around
say,
waiting,
sorting
and
evaluation,
so
we
can
enumerate
everything.
Do
we
know?
What's
more
or
less
important
has
more
or
less
impacts,
more
or
less
ability
to
address
and
other
things
that
might
actually
factor
into
someone's
individual
risk
assessment?
C
And
so
I
guess
that's
sort
of
that
question
of
the
data
we
wish.
We
had
and
expanding
it
on,
because
I
think
just
enumerating
a
set
of
dependencies
is
a
great
starting
place,
but
it
can
often
be
very
overwhelming
and
unclear
what
actually
has
the
biggest
potential
impact
to
take
down
my
system
tool
up
or
whatever
it
is
so.