►
From YouTube: CHAOSS Risk Working Group
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
the
risk
working
group
meeting
for
april
1st
2021,
we
will
try
not
to
do
any
april
foolish
kinds
of
things.
This
is
the
these
are
the
minutes
that
I
put
into
the
chat.
I
can't
remember
if
anyone's
joined
since
I
put
the
link
in,
but
I
added
again
because
of
zoom's
particularities.
A
I
thought
we
would
start
today
with
some
introductions
since
arfan's
joining
us-
and
I
don't
know
if
drew
has
been
here
previously.
I
think
he
might
have
been
last
time
but
drew.
Maybe
if
you
want
to
introdu
or
drew
or
arfon,
maybe
if
you
want
to
introduce
yourselves
and
the
rest
of
us
can
do
the
same
real,
quick.
B
Sure
I
can
say
hi
yeah,
my
name
is
alvon
smith.
I
work
at
github
and
I
what
do
I
know?
Well,
I
don't
know
I
I
know
some
stuff
about
open
source,
I'm
really
interested
in
open
source
communities
and
what's
going
on
on
the
platform,
I
run
a
project
called
the
journal
of
open
source
software,
I'm
the
editor-in-chief
for
that
and
it's
my
second
time
working
at
github.
I
left
in
2016
came
back
about
nine
months
ago.
B
My
role
at
github
today
is
in
I'm
in
the
product.org,
and
so
I'm
the
product
manager
for
the
data
org,
which
includes
our
data,
science
teams,
data
engineering
and
what
we
call
data
experience,
which
is
kind
of
like
how
customers
internally
interact
with
data
and
but
we
also
run
like
the
data
warehouse
and
things
like
that.
So
I'm
especially
interested
in
this
group
I'm
interested
in
chaos.
I
know
matt
and
sean.
B
We
go
back
a
bit
in
fact
to
my
previous
time
at
github,
I
think,
and
I'm
interested
in.
Oh,
I
also
know
elizabeth
who's.
Here
we
used
to
work
together
at
github.
So
that's
cool.
Sorry,
I
didn't
see
your
face
on
the
call
yet,
but
I
I'm
interested
in
this
group,
especially
because
the
part,
the
org
that
I
sit
within
is
called
data
and
security
products,
and
so
we
actually
the
sort
of
one
big
area
of
focus
for
github
right
now
is
is
sort
of
you
know.
B
A
That's
exciting
to
to
hear
that
you're
in
that
role,
people
should
know
that
chaos
was
conceived
as
a
concept
in
a
conversation
between
matt
and
arfan
in
fredericksburg
copenhagen
in
june
of
2015,
and
I
nosed
into
that
conversation
to
to
join,
because
I
was
also
interested
so
arfan's
history
with
chaos
goes
back
quite
a
long
way
to
the
origins
and
drew.
Are
you
also
new
or
riddick?
Have
you
been
here
before.
C
A
Microphone,
okay
and
drew:
have
you
you've
been
here
before
or
no,
I
can't
recall
it.
You've
been
in
some
working
groups.
I
have
been
here:
okay,
all
right,
so
that
let's
move
on
from
the
introductions,
then
what
we've
been
doing
so
just
a
little
background
for
everyone.
A
What
we've
been
doing
is
focusing
sort
of
understanding
what
we
mean
by
dependencies
and
we're
right
now
focused
on
what
we're
calling
the
minimum
viable
product
for
for
dependency,
metrics
and
not
to
jump
from
two
to
four,
but
it
might
be
useful
to
just
open
up
the
minimum
viable
product
spreadsheet
and
just
get
an
overview
of
essentially
enumerating
the
repositories
that
projects
that
your
project
depends
on
are
looking
at
sustainability.
A
So
if,
if
we
look
at
work
the
world
from
a
repo
perspective,
what
is
your
repo
dependent
upon
and
then
fan
out
and
access
and
and
about
you
know-
can
calculate
chaos
metrics
for
those
dependencies
dependency
range?
You
know
how
many
times
is
it
just
a
single
dependency
referenced
in
your
product,
so
you
might
have
a
dependency,
that's
mentioned
in
nearly
every
component
or
one
that
only
exists
in
a
single
place.
A
Libya's
is
a
metric
that
is
for
projects
and
libraries.
My
project
depends
on
a
total
number
or
an
average
number
of
libraries
that
are
of
an
average
or
total
age,
so
in
some
sense,
there's
a
little
bit
of
a
signal
in
if
you're
dependent
on
really
old
versions
of
libraries
that
might
suggest
a
risk.
A
We
want
to
enumerate
known
vulnerabilities.
There
are
several
sources
for
this,
including
national
vulnerability,
vulnerabilities
database
as
as
well
as
other
sources.
There's
a
project
called
osf
scorecard,
which
is
the
github
repo,
is
linked
there
and
then
sort
of
creating
a
matrix
of
if
there's
a
known
vulnerability
and
the
project
is
not
active.
A
There's
a
combination
of
these
two
things
that
create
greater
risk.
So
in
terms
of
the
focus
of
this
working
group,
those
are
the
things
that
we're
targeting
and
the
one
we're
working
on
language
level
upstream,
dependency
enumeration
as
a
metric
right
now,
and
one
of
the
things
that
we
do
during
these
meetings
is
work
on
metrics.
So
often
we
stop
the
recording
and
and
work
on
a
metric,
but
maybe
before
I
jump
into
that
I'll
ask
if
there
are
any
topics
on
the
agenda
that
folks
want
to
jump
to.
B
Is
libya's
how
out
of
date
you
are
with
your
dependency
like
so
my
or
is
it
like
some
sense
of
the
maturity
of
the
package,
because
those
that
seem
like
different
things.
A
It
it's
how
out
of
date,
you
are
with
the
current
version
of
the
dependency
got
it.
That
sounds
makes
sense.
If
david
wheeler
were
here,
he
might
correct
me,
but
I've
come
to
understand
that
that's
what
a
libya
is.
So
if
your
oldest
library
is
stable
and
hasn't
been
updated
in
three
years,
and
perhaps
there's
no
reason
for
it
to
have
been
updated,
that
that
isn't
the
concern,
the
concern
is
if
there
have
been
11
releases
of
of
a
dependency
since
the
one
that
you're
dependent
on
that
would
be
a
a
libya
count.
F
So
I
know
that's,
maybe
not
adding
too
much
complexity,
but
I
was
thinking
a
lot
about
nested
dependencies
or
circular
dependencies
that
could
come
out
and
I'm
wondering
how
just
I'm
kind
of
raising
it
now,
just
as
we're
talking
through
some
of
those
different
characteristics
that
you
raised
in
the
last
sheet,
how
we
want
to
state
those
explicitly
to
either
encourage
them
to
be
filtered
out
and
or
addressed
separately.
F
I'm
sort
of
so
I
would
consider
that
a
transit
of
dependency,
so
not
indirect,
but
sort
of
then
that
and
that
dependency
has
a
dependency
on
circular
means
that
if
you
follow
that
chain,
eventually
it
points
back
to
itself
and
then
that's
a
dependency
is.
I
was
like
looking
at
a
whole,
all
the
build
files
required
to
run
something
might
refer
back
to
other
build
files
in
the
same
folder.
So
it's
those
aren't
really
dependencies,
because
that's
just
how
you
structured
your
code
base
yeah.
F
It
build
dependency
also
because
it's
a
separate
file,
so
that
was
just
the
technicality
of
the
the
tool
that
we
were
using.
F
It
could
be
considered
circular.
I
was
thinking
circular
more
being
transitive
to
transitive
to
transitive
back
to
yourself,
so
it's
these
are
kind
of
weird
edge
cases
that
I
don't
want
to
derail
the
conversation
I
just
wanted
to
mark
them
so
that,
when
we're
ironing
out
some
of
the
details
of
some
of
these
definitions
that
we
consider
what
those
edge
cases
imply
by
what
we're
recommending.
A
A
F
A
F
G
G
D
F
F
We
don't
want
to
pick
a
word
so
that
we're
consistent,
but
then
it
sort
of
the
impact
of
looking
at
transitive
and
indirect
dependencies
is
that
eventually
you
could
keep
following
the
chain
and
the
chain
might
go
all
the
way
around
which
is
worth
knowing,
because
that
sort
of
produces
some
awkwardness-
and
I
there's
originally
a
blog
post
about
that
that
I
could
share
that.
Looked
at
a
couple
of
examples
where
circular
dependencies
were
coming
up-
and
I
don't
think
that's
I
would
say
as
a
risk
metric
would
be
bad.
F
But
again
these
are.
These
are
more
edge
cases
and
more
when
you're,
actually
looking
at
creating
metrics
around
dependencies
that
there's
some
nuance
to
the
data
that
you're
collecting.
That
will
make
it
less
useful
for
you
so
like
I
know
I
have
30
dependencies,
but
10
are
from
the
same
file.
Then
it's
really
only
20
dependencies.
D
F
D
Well,
I
guess
one
of
the
things
that
I'm
wondering
sorry
for
the
illusion
here
we're
like
kind
of
a
chicken
and
an
egg
question
like
do
I
care
about
this
first
and
then
the
metrics
that
are
currently
being
developed,
or
do
I
see
what
I'm
saying
or
do
I
kind
of
try
to
understand
the
metrics
and
then
say
well
hold
on
before
we
do
the
interpretation
of
this
metric?
I
need
to
understand
some
of
the
metrics
context.
D
D
F
I
think
so
from
a
risk
perspective.
So
if
the
goal
of
defining
these
metrics
is
to
be
able
to
definitively
state
a
level
of
relative
risk,
then
say:
direct
dependencies
are
more
important
than
indirect
dependencies,
but
you
will
still
be
impacted
if
there
are
say
vulnerabilities
happening
at
those
indirects,
because
the
things
that
you
depend
on
depend
on
them.
So
it's
you're,
but
then
there's
a
level
of,
I
guess
abstraction,
where
you
assume
someone
else.
F
F
D
F
A
It
so
that
the
next
so
the
next
thing
I
mean
these,
these
agenda
items
are
in
kind
of
an
order,
but
they're
not
in
a
canonical
order.
So
the
next
thing
I
have
on
here
is
to
try
to
continue
our
work
on
language
level,
upstream,
dependency,
enumeration
and
but
I'm
open
to
reorganizing
or
ordering
the
list
as
people
see
fit.
H
A
H
E
A
E
H
B
Just
just
a
thought:
the
people
who
thought
about
this
are
people
who
care
about
reproducibility
and
so
like.
What
do
you
need
to
bundle
a
piece
of
software
such
that
it
might
run
for
a
long
time
I
feel
like
they
might
have
a
taxonomy
of
ways
to
think
about
like
the
different
aspects
of
reproduce,
but
I'm
getting
flashbacks
to
those
discussions.
So
yep.
B
Please
I
can
try
and
dig
out
some
books
there
if
that
would
be
helpful,
but
it
certainly
feels
a
bit
like
that,
especially
when
we
get
into
the
environment
level,
stuff
yeah.
F
Don't
want
to
create
new
language,
that's
going
to
confuse
people,
I
mean
we
spent
a
whole
day
talking
about
downstream
versus
upstream
and
whether
or
not
that
was
clear
to
people.
So
I
feel
like
this
is
the
same
argument,
no
argument,
but
just
point
that
there
is
not
necessarily
complete
clarity
in
what
these
mean
for
all
people.
F
A
A
A
And
so
these
are
projects
that
my
project
depends
on
that's
what
upstream
is
we
I
put
that
in
there,
because
we
frequently
have
to
remind
ourselves
of
the
difference
between
upstream
and
downstream
and
if,
if
folks
want
to
take
a
minute
to
read
through
what
we
have
here
generally,
the
practice
we
have
is
we'll
spend
about
10
minutes
working
through
advancing
this
definition,
and
this
one
looks
reasonably.
A
The
aim
of
the
metric
is
to
understand
code
based
dependencies
embedded
in
software,
and
it
explicitly
excludes
infrastructure
focused
dependencies,
like
databases
os,
and
we
have
chosen
to
define
those
in
in
something
called
an
upstream
infrastructure
dependency
metric,
so
that
exists
somewhere
on
the
risk
on
the
risk
list.
D
D
G
H
G
G
It's
enough,
you
know,
I
think
that
belongs
in
the
definition
or
the
description
that
you're
limiting
it,
that
to
within
a
language
thing,
but
language
level
itself
is
not
a
commonly
understood
term
saying
language
level.
You
know.
I
B
And
by
enumeration,
do
we
just
mean
listing
them
all
yeah?
We
want
every
one
of
us
tomorrow,
so
I
would
I
agree.
I
got
hung
up
on
language
level.
I
thought
about
it
and
realized
that
you
meant
within
the
programming
language,
but
because
we
just
had
that
conversation
about
operating
systems
and
databases,
so
I
actually
think
you
could
just
say
upstream
dependencies
brackets
within
language
or
something
or
at
code
level
or
something
I
don't
know
it
feels
like.
A
A
D
F
We
just
had
our
style
guide
come
through
last
week,
so
maybe
we
I
want
to
say
we
propose
a
change
immediately,
but
whatever
we
do,
we
want
to
let
the
rest
of
the
group
know
in
case
that
they
have
the
same
interests.
I
think
it
makes
sense
for
dependencies
given
that
there's
so
many
kinds
that
we
might
want
to
add
more
specificity
into
that
metric
name
than
other
groups
might.
But
that's.
E
E
J
D
F
A
D
I
A
Yeah,
I
think
not
now,
we've
reached
the
time
where
the
recording
of
what
we
do
is
of
less
utility.
So
I
am.