►
From YouTube: CHAOSS Risk Working Group 7-8-21
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
A
A
Okay,
so
that
I
was
telling
michael
van
the
guidance
I
got
was
from
sean
was
working
through
this
mvp
doc.
He
didn't
really
share
our
other
guidance
beyond
that,
so
my
interpretation
was
looking
for
holes,
augmentations
and
potentially
filling
out
some
of
these
submetric
questions.
B
B
Yeah
so,
like
maybe
okay
repository
dependency
enumeration,
can
it
be
a
metric
if
it
is?
What
is
the
question
that
I
I
can
answer
with?
That
will
be
a
thing
then
over
there.
If
you
have
a
question,
then
we
can
think
through
developing
a
so-
maybe
maybe
I
would
say
like
we
can
give
a
like
for
a
short
break
to
this,
and
since
I
have
worked
on
that,
we
all
have
worked
on
that
dependency
metric.
B
B
B
Yeah,
it's
in
the
agenda
number
two
and
yep:
this
is
the
document,
so
this
is
the
document
we
all
have
been
working
on
right.
So
we
have
this
metric
upstream
code
dependency.
The
question
is
what
projects
and
libraries
my
project
depend
on
and
the
entire
metric
has
been
developed.
So
now
this
is
like
in
a
refined
chair.
B
Similarly,
we
can
take
this
format
and
look
at
the
spreadsheet
shown
as
here
and
then
okay,
what
a
particular
metric
that
I
can
develop
and
address
a
particular
problem
or
a
situation.
A
B
Yes,
so,
like
repository
dependency,
enumeration
that
my
pro
so
I
think
we
have
already
covered
this
point
one
in
this
sheet,
which
is
which
is
this
particular
metric.
A
B
A
A
Well,
sean-
and
I
just
met
a
professor
yesterday
from
uc
davis,
who
submitted
a
paper
or
just
published
a
paper
about
project
sustainability,
so
I
literally
asked
them
this
question
yesterday
of
how
they
defined
sustainability
and
the
way
that
he
got
around.
It
was
particularly
in
their
project
they're,
looking
at
graduation
rate
within
the
apache
incubator
program,
and
so
for
them.
Sustainability
of
a
nascent
project
was
defined
as
successful
if
they
were
able
to
be
graduated
from
it
versus
retired
or
discontinued.
A
C
The
way
that
I've
I've
defined
sustainability
in
the
past
has
been
related
to
kind
of
project
health,
which
is
you
know,
the
the
likelihood
that
the
project
will
continue
to
meet
your
expectations
at
some
point
in
the
future.
C
And
that
way
it's
super
general
and
you
you
can
say
well
what
does
that
really
mean,
and
what
data
are
you
using
to
infer
that
likelihood
or
calculate
that
likelihood
and,
and
things
like
that,
but
certainly
a
project
that
hasn't
been
touched
in
10
years
is
not
likely
to
be
touched
in
the
next
year,
just
kind
of
anecdotally
and
therefore,
if
it
breaks
there
is
no
one
there
to
fix.
C
A
So
mostly,
I
guess
in
the
context
of
dependency
to
sustainability,
it
can
be
a
narrower
definition.
I
guess
to
your
point:
sustainability
is
about
meeting
expectations
of,
in
this
case,
the
project
that
depends
on
it.
I
guess
we
put
it
in
that
context.
So
then,
in
that
case,
we're
defining
sustainability
is
just
what
we
depend
on.
We
want
to
make
sure
that
that
piece
continues
to
be
a
viable
piece
of
code,
that
we
can
reference
in
our
software.
So
to
your
point,
things
that
would
indicate
that
would
be
age.
A
C
Yeah,
have
you
guys
seen
the
the
open
ssf
criticality
score,
so
I
feel
like
that
at
least
the
the
descriptions
of
the
elements
that
they
use
and
and
why
they
think
that
you
know
a
higher
commit
frequency.
C
A
I
mean
that's
also
something
that
already
exists
as
a
tool
too.
So
I
think
that's
easy
enough
to
reference
if
you're
having
trouble
defining
what
the
sustainability
elements
are
important
for
you,
then
this
is
one
you
can
start
with
and
change
to
meet
your
needs
because
that
has
updated,
created,
contributor
size
frequency
of
commit.
C
C
My
sustainability
risk
derives
from
my
direct
dependencies
who
their
sustainability
risk
derives
from
theirs.
It's
someone
down
the
chain,
and
then
you
have
this
giant
aggregate
up
at
the
top.
B
So
a
question
is
like
okay,
your
dependency
sustainability
derives
from
a
direct
dependency,
but
there
is
a
sustainability
issue
with
a
like
transitive
or
second
order
dependency.
B
Do
you,
though,
yeah
yeah
yeah
like,
for
example,
you,
if
you
look
at
the
image
like
if
sophia,
can
you
open
that
bricks
up
the.
B
The
risk
of
the
stream
code
dependency
tab
like
in
the
browser
yep
scroll
down
there
to
the
image.
There
is
a
image
like
circular
image
in
there
go
down
one
more
one,
more
okay
on
this
one
circular,
so
our
project
depend
on
project
a
and
on
project
c,
and
project
c
depends
on
project
a2.
C
C
In
my
experience,
asking
teams
to
fork
and
change
a
transitive
dependency
is
almost
it's
not
quite
the
nuclear
option,
but
it's
it's
like
the
last
resort
in
a
lot
of
cases,
because,
especially
if
they
don't
like,
if
the
the
happy
path
is
yes,
you
do
that
you
submit
a
pull
request
and
they
accept
it,
and
everything
is
happy.
The
bad
path
is
no.
I
fork
it
and
now
I've
now
now
it's
mine
forever.
A
Yeah,
I
was
kind
of
just
thinking
through
the
remediating
options
that
you
just
mentioned.
So
it's
sort
of
the
okay.
Let's
say
you
find
out
that
something
is
more
or
less
risky
than
your
options
are
to
try
to
address
it
by
either
contributing
to
the
project,
submitting
an
issue
or
a
pull
request,
trying
to
remove
the
dependency
entirely
in
terms
of
ripping
it
out.
If
you
can
or
three
forking
it
to
make
it
suit
your
needs,
but
then
you're
also
kind
of
assuming
responsibility
over
the
fork.
A
C
I
I
think
it's
probably
actually
a
fourth
which
might
be.
It
may
just
be
a
rabbit
hole,
so
I
apologize
for
this,
but
in
in
this
case,
well,
let's
say
it
wasn't
the
circular
dependency.
Let's
say
it
was.
It
was,
I
think,
the
one
up
above
just
the
base.
A
C
You
can
assert
pretty
to
a
pretty
high
degree
of
confidence
that
that
vulnerability
is,
does
not
impact
our
project
and
therefore
you
don't
need
to
do
anything.
The
the
risk
is
kind
of
whether
it's
a
sustainability
risk
or
vulnerability
or
any
kind
of
thing
it's
non-impactful.
So
as
you
go
down
the
track,
if
you,
if
you
go
through
the
transitive
graph,
the
further
you
are
away
from
the
root
application,
the
like
the
the
accumulation
of
that
risk
kind
of
goes
down
over.
It
goes
down
with
the
length.
C
It
it
could
be
that
or
it
could
be
that
so
imagine
that
that
dependency
c
has
one
function
and
the
function
has
a
you
know
it,
but
it's
it'll.
Let's
just
say
it's
dead
code:
it's
it's
not
referenced
anywhere
and
it
has
a
vulnerability
in
it.
Then
a
is
not
affected
by
it.
Neither
is
our
project
or
anybody
else
that
uses
it.
Similarly,
if
c
you
know,
there's
a
whole
section
of
c
that's
vulnerable,
but
a
only
depends
on
one
function.
That
is
self-contained
and
isn't
vulnerable.
C
The
problem
is,
that's
a
very
expensive
operation
to
an
expensive
calculation
to
to
make,
but
it
does
go
the
other
way
because
on
one
hand
a
lot
of
the
metrics
are
about.
This
is
more
risk
that
you
have
that
you
didn't
realize,
and
it's
kind
of
it's
usually
about
bad
news
while
saying
that
this
doesn't
affect.
You
is
good
news,
and
people
like
that.
Sometimes.
A
A
Is
your
risk
actually
going
down,
so
that
should
impact
the
way
that
we
choose
to
aggregate
or
treat
some
of
the
safe,
far
down
the
tree
transit
of
dependencies?
But
I
mean
there's
also
the
corollary
where,
like
I'm
assuming
it
really
just
depends
on
context
where,
like,
depending
on
how
far
out
you
go.
If
it's
all
one
language
library
that
gets
taken
down,
then
that's
fairly
sweeping,
depending
on
the
nature
of
what
it
is
and
what
else
in
your
project
depends
on
it.
C
Yep
absolutely
yeah,
and
similarly,
as
you
go
down
the
tree,
there's
more,
there
are
more
dependencies
at
level
n,
plus
one
than
there
are
at
level
n.
So
yes,
the
the
risk
of
each
particular
one
is
less
the
aggregate
risk
of
that
level.
Might
I
don't
know?
I
feel
like
that
there
has
to
be
an
academic
paper
like
to
be
written
about
this,
but
I
I
haven't
come
across
one.
A
It
means
right
for
exploration,
because
I'm
thinking
of
sort
of
the
m
plus
one
model,
but
then
it's
sort
of
like
how.
How
often
are
things
coming
up,
because
if
it's
say
there's
20
more
now
at
level
3.
But
if,
in
that
list,
there's
overlap
with
another
tree
in
the
other
part
of
your
software,
then
that
should
be
escalated
more
than
anything
else
in
the
tree,
because
it
has
a
higher
level
of
impact.
So
I
guess
that's.
A
How
can
we
measure
relative
impact,
which
I
think
is
a
really
hard
problem,
but
in
terms
of
say,
you
mentioned
partial
dependencies,
so
say
right
now,
there's
even
with
something
like
even
criticality
score.
It's
measuring
across
the
entire
project
or
even
vulnerability.
Assessments
are
measuring
across
the
entire
project
and
if
you
don't
use
the
entire
project,
then
that
risk
might
may
or
may
not
be
as
important
for
you
to
consider
or
whatever
issue
is
with
the
code
base.
A
So
is
there
a
way
to
actually
delegate
orally
specify
sort
of
area
of
impact
within
a
project
which
I
know
I
called
it:
partial
dependence
which
isn't
great
either
but
like
or
maybe
that's
the
assumption
is
we
can't
do
that,
so
it's
just
going
to
be
estimating
no
matter
what.
C
I
mean,
I
guess
you
really
want
like
a
heat
map
of
control
flow,
so
you
see
like
if
you
like,
look
at
the
look
at
the
source
code.
I
guess
and
see
that
you
know
here
that,
like
all
the
hotspots
start
at
like
the
entry
points
and
then
they
flow
out
and
get
less
over
time
as
although
you
probably
need
the
thing
to
exercise
the
thing
in
order
to
drive
that
otherwise
you
don't
know
what's
getting
called,
but.
A
In
these
in
the
data,
you
should
be
able
to
see
the
specific
folder
structure
and
calls
like.
I
think
it's
not
just
calling
a
project
like
if
it's
calling
a
github
repository,
it's
your
you
can
see
the
full
url
of
the
call
sure.
So
in
theory,
we
should
have
some
information
that
specifies
what
area
of
the
project.
The
thing
that
I
don't
know
is,
if
we
can
measure,
say
the
criticality
score
for
sub
components.
C
Probably
not
because
I
think
well
the
criticality
score
as
like
the
the
implementation,
the
project
idea,
the
the
project.
No,
I
think
that's
all
against
a
repo
like
in
general,
so
it's
not
even
against
a
particular
tag
or
commit
or
anything
it's
like
this
is
the
general
repo.
C
C
B
Is
a
this
is
a
fun
fun
project
idea,
so
is
it
calling
same
in
every
language
like
I,
what
my
knowledge
is,
like
you
call
entire
library
in
certain
languages
and
you
call
certain
function
within
that
library
in
a
certain
language?
Not
so
the
pattern
is
not
same
in
across
all
the
languages
or
all
the
development
environments.
A
So
then
it's
specifying
a
specific
file
that
it's
referencing
or
something
that's
mentioned
in
that
file,
which
does
have
a
specific
location
in
a
project,
because
it's
then
you
have
to
know
where
it
is,
but
that
to
your
point,
if
you're
calling
a
language
library,
you're
calling
the
library,
even
if
you're,
not
using
the
whole
thing.
C
Well,
you're,
including
the
whole
thing,
but
you
still
you
know,
even
if
I
include
the
I
don't
know
the
java,
runtime
or
or
something
and
I
write
to
the
screen,
something
that's
gonna,
there's
an
entry
point
for
that
function:
it'll
go
there
and
then
it'll
do
whatever
it's
gonna
do
to
like
get
the
text
on
the
screen
for
like
npm.
C
You
know
you
have
to
explicitly
export
the
functions
that
you
want
callers
to
be
able
to
call.
Similarly
for
c
and
c
plus,
like
there's
it's
different
for
each
language,
but
I
think
I
mean
the
only
languages
that
don't
really
do
that
are
probably
the
ones
that
are
it's
just
a
blob
of
source
code
and
it
now
it's
yours,
but
I
think
that's.
B
C
Yes,
yes,
that
function
gets
to
decide,
obviously
like
what
it
wants
to
do,
but
I
I
think
that
the
key
is
that
not
all
parts
of
a
prod
of
a
dependency
are
accessible
through
the
defined
entry
points
and
it's
really
hard
to
get
into
a
library,
not
through
one
of
those
entry
points.
C
I
mean
if
they
look
like
a
a
web
server,
you
know
or
an
app
just
a
regular
like
web
app
like
talk
to
a
database
on
the
back
end,
but
you
can't
from
a
web
browser
like
connect
directly
to
the
database
through
the
app
you
can
only
go
in
through
the
you
know,
whatever
routes
and
entry
points
they
define.
So
if
I
had
a
dependency
on
a
database
but
never
actually
made
any
calls
to
it
in
my
in
my
web
app
then.
A
So
I
guess
out
of
all
that
that
last
point
I
think,
would
probably
start
to
discuss
the
kinds
of
parameters
we'd
want
to
include
that
would
change
the
weighting.
So
you
said
number.
D
A
Calls
to
a
specific
dependency,
I
don't
know
if
we
want
to
get
as
specific
as
the
kind
of
dependency,
because
I
don't
again,
I
don't
know
how
easy
that
is
to
enumerate
with
a
given
data.
I
know
trying
had
mentioned
up
front
we're
thinking
about.
What's
in
an
s-bomb,
I
think
there
are
a
few
other
tools
that
we
can
consider
in
terms
of
safe
package
managers
but
and
aggregators
that
are
looking
across
package
managers.
We
just
launched
one,
but
I
don't.
I
haven't
actually
used
it
that
much
to
say
what
it's
good
for
you.
A
A
Get
re-recorded
well
publicly
says:
there's
plans
to
add
more
data
sources,
so
it's
meant
to
be
an
aggregator
so
that
you're
not
having
to
query
multiple
places
to
see
dependencies
against
one
thing.
So.
E
A
Another
tool
that
you
can
reference
but
in
terms
of
say,
bringing
this
back
to
a
metric.
So
you
know
we're
getting
down
to
the
last
10
minutes
of
the
call.
A
A
B
E
B
Yeah,
but
I
don't
think
in
terms
of
dependency,
we
have
any
metric
that
is
released
and
we
can
refer
it.
We
can
say:
okay,
these
are
the
filters
we
can
apply
within
it.
That's
what
we
are
trying
to
develop,
so
so
this
one
which
I
have
like
refined
it.
Everybody
has
made
their
comments
and
everything
is
there,
so
I've
just
refined
it
it's
ready
for
it
like
it
just
needs
a
review.
Does
it
make
sense?
Is
it
okay?
Then
we
can
release
it
as
an
upgrade.
B
B
C
I
think
cyclone
dx
just
released
one
but
then
spdx,
I
think
we're
waiting
for
spdx3
to
solidify.
So
is
it
that
tool
or
is
it
s.
C
B
B
C
Oh
actually,
I
actually,
I
do
know
the
answer
to
this
so
correct.
I
think
cyclone
has
a
tool
that
they
released
a
couple
weeks
ago.
Can
you
share
the
link.
C
C
There's
probably
going
to
be
a
bunch
of
tools
in
the
s
bomb
generation
space
popping
out
over
the
next
six
months.
B
C
B
B
C
B
A
B
B
B
C
Yeah,
honestly,
I've
been
asking
for
those
tools
for
for
quite
a
while.
Okay,
I
never.
B
A
B
C
Yep,
okay,
so
I
was
interesting.
A
lot
of
the
tools
are
really
really
simple,
so
I
don't
know
like
it's
certainly
a
good
place
to
start,
but
I
have
a
feeling
that,
as
it
mature
like,
I
don't
know
if
the
tools
will
need
to
be
significantly
changed
in
order
to
be
useful
from
what
I'm
looking
at
it's
it's
basically
just
a
text
file
of
of
the
of
the
of
the
dependencies.
C
Well,
I
guess
you
know
it
has
hashes
and
licenses.
Okay,
yeah,
maybe
that's
wrong.
Maybe
it
does
have
more.
I've
got
it.
I've
got
to
test
this
out.
B
A
A
All
of
the
different
types
of
context
that
we
have
listed
in
this,
so
I
think
once
that's
live,
then
we
can
refer
to
it
versus
having
to
rewrite
it.
I'm
also
thinking
now
about
our
conversation
around
the
second
one.
B
If
you
are
thinking
in
that
term,
I
would
say
if
you
look
at
the
notes
we
have
taken,
and
this.
A
B
A
A
Within
those
dependencies,
and
so
it's
sort
of
again,
I
think
we
would
we're
going
to
have
to
define
what
we
mean
in
terms
of
sustainability
here.
If
we
use
that
word
or
we
just
don't
use
that
word,
and
we
say
something
more
specific
that
relates
to
long-term
viability
of
the
code
or,
however,
we
want
to
call
it
yeah.
A
Well,
I
think
we've
sufficiently
widened
the
net
again
michael
you've
been
with
us
for
a
few
months
now.
That's
why.
B
But
like
now
at
least
looking
at
all
the
discussion
being
converted
into
a
metric
is.
A
A
Okay,
well,
that
was
the
agenda
for
the
meeting,
so
we.
A
A
Yeah
the
sun
is
obscured
and
my
my
floor
lamp
died
this
week,
so
I
only
have
a
desk
lamp.
Oh.