►
From YouTube: Securing Critical Projects WG (January 13, 2022)
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
Okay,
so
we
are
officially
recording
hello
and
welcome
everybody
to
the
securing
critical
projects
work
group
meeting
I'll
be
facilitating
today,
we
could
typically
do
it
the
way
that
we
normally
do
and
again
participation
and
questions
anything
is
encouraged,
feel
free
to
either
use
the
raise
your
hand
or
just
shout
out
or
whatever
works.
It's
always
nice
to
get
a
good
discussion
going
during
these
work
group
meetings.
A
So
to
start
off,
we
can
do
what
we
normally
do
and
see
if
there
are
any
newcomers
who
would
like
to
introduce
themselves
and
talk
a
little
bit
about
what
brought
them
to
the
work
group
meeting
and
what
is
how
they
work
with
open
source.
Do
we
have
anybody
today.
B
Yes,
I
can
go
first.
This
is
eric
ties.
I
lead.
I
am
the
director
of
open
source,
technical,
consulting
and
the
center
of
excellence
for
wipro
technologies.
We
do
a
lot
of
work.
Obviously
we're
gsi,
I'm
not
gonna,
sell
you
a
sales
pitch,
but
my
team
in
general
works.
A
C
Hi,
I'm
julia
farioli.
I
work
at
the
twitter
open
source
programs
office.
I
am
here
today
because
I
was
actually
one
of
the
the
people
who
worked
on
the
original
criticality
score
and
looking
to
to
re-engage
now
that
I'm
I'm
a
bit
more
settled.
So
it's
nice
to
nice
to
meet
you
all.
A
A
Okay,
cool!
Well,
yes,
welcome!
So
this
is
the
securing
critical
projects
work
group.
I
think
the
name
is
pretty
succinct
in
terms
of
what
the
work
group
is
working
towards,
why
we
all
come
to
the
meetings
focusing
on
securing
what
we
consider
to
be
critical
projects,
we're
trying
to
figure
out
the
best
way
to
do
that.
It's
quite
a
complicated
problem.
A
There's
a
lot
of
good
work
going
on
and
collaboration,
especially
in
the
open
source
space,
at
least
in
my
experience,
typically
yields
better
outcomes,
so
yeah,
so
we're
all
we're
all
working
towards
securing
open
source
in
different
ways,
typically,
which
might
be
a
good
way
to
get
acquainted
with
some
of
the
stuff
we're
working
on.
Typically,
we
like
to
do
some
project
updates,
so
some
of
the
initiatives
that
are
kind
of
affiliated
with
this
work
group
are
the
open
ssf
in
general.
A
We
talk
about,
and
actually
the
first
one
that
we
have
on
our
recurring
themes
is
the
criticality
score.
So
I'm
curious
if,
if
you
julia
or
you
jeff
or
if
anyone
has
any
updates
on
the
criticality
score
project,.
A
Okay,
anything
on
your
end,
jeff
or
anyone
else.
A
Either:
okay,
okay,
yeah,
but
just
to
in
case
folks,
aren't
familiar
with
it.
The
criticality
score
is
a
fantastic
tool
that
is
being
built
that
is
built
and
currently
being
refined.
I
believe
I
think
they
have
their
own
work
group
if
I'm
not
mistaken,
or
they
have
their
own
their
own
repairing
meetings,
but
we
at
ostip
have
been
using
the
criticality
score
to
guide
our
research
and
to
to
to
help
solve
this
problem
of
of
what
are
the
critical
projects?
What
data
do
we
can
we
point
to
that?
A
We
can
that
we
can
refer
to
and
say,
hey
you
know,
using
this
quantitative
data
method,
you
know
we
can.
We
can
determine
a
score
or
some
metric
for
criticality,
so
it's
a
very
cool
tool
check
it
out.
If
you
haven't
already,
maybe
in
one
of
the
calls,
if
abhishek
or
one
of
them
join,
we
can
get
a
more
up-to-date
update
on
that.
Next,
we
have
security
scorecards.
D
I
don't
see
anybody
on
the
online.
That
would
also
know
I
should
probably
know
more
than
I
was
ready
to
to
chat
about.
A
No
worries
I
mean
it
is
technically
the
first
meeting
of
the
year.
I
know
a
lot
of
folks,
you
know
especially
november
and
december,
taking
some
much-needed
time
off.
So
I
understand
we'll
be
getting
back
into
the
swing
of
things
and
but
the
security
score
cards
is
a
great
tool
too.
Sorry.
What
was
that
jeff
yeah.
D
I
was
just
gonna
say
we
do
have
a
a
weekly
or
actually
it's
bi-weekly
meeting.
You
know
more
goal,
focus
goal
focused
and
engineering
focused
and
it's
constantly
trying
to
improve.
You
know
the
quality
of
the
the
the
scores
and
you
know
adding
new
scores
where,
as
best
practices
are,
are
identified.
A
Very
cool,
yeah
and
and
just
to
give
a
quick
overview
of
that
project
too
in
case
you're
not
familiar
the
security
score
cards
is
another
similar
project,
trying
to
add
some
metrics
and
some
insight
into
security
practices
of
different
open
source
projects.
So
that's
another
one
that
we
have
used
to
as
part
of
our
research
and
to
help
guide
resources
and
determining
which
projects
are
critical
and
not
only
which
projects
are
critical,
but
hopefully
once
we
get
there.
A
A
Next
and
is
there
any,
and
I
guess
we
could
do
all-star
next,
since
we
have
you
here
jeff.
Are
there
any
updates
on
all-star.
D
D
I
did
add
a
new
policy
so
that
you
can
require
that
every
or
every
repo
in
your
organization
has
an
owner
or
has
a
person
or
group
with
an
admin
permissions,
and
it's
not
simply
the
org
owner
that
has
access.
D
So
this
is
a
good
way
to
find
you
know
abandoned
repose,
where
maybe
the
the
person
who
owned
that
that
repo
has
been
removed
from
the
org
and
there's
nobody
really
responsible
for
it.
So
that's
a
good
good
policy.
You
could
use
to
try
to
find
things
that
may
be
not
not
up
to
date,
not
somebody's,
not
responsible
for
it
and
could
potentially
be
vulnerable
due
to
that
very
cool.
So
that's
a
new,
a
new
one.
D
We
also
added
the
ability
for
you
to
set
to
set
up
settings
so
that
all
star
will
fix
your
branch
protection
rather
than
just
notify
you.
So
if
you
have
a
required
branch
protection
settings
on
your
github
org,
if
any,
if
any
repo
is
out
of
spec
allstar
will
go
ahead
and
just
make
the
changes
to
bring
it
back
into
spec.
D
So
those
are
two
recent
features
we're
doing
some
planning
as
well
and
planning
for
primarily
a
a
performance
upgrade.
So
it's
been
running
mostly
with
the
original,
like
proof
of
concept
or
mvp
architecture,
which
is
a
little
slow
to
update
all
the
repositories
with
whatever
alerts
they
need
and
we'll
be
moving
to
a
more
robust
architecture
based
on
web
hooks
to
get
it
a
lot
more
responsive.
D
Just
another,
just
one
more
thing:
we
we
have
been
discussing
all-star
features
and
planning
in
that
scorecards
meeting.
So
maybe
we
maybe
we
need
to
update
the
the
name
of
that
meeting,
but
it's
on
the
the
the
community
calendar
it's
every
other
thursday.
So
that's
another
place
to
come
and
talk
about
all
star,
more
detail.
If
you're
more
interested.
E
Hey
a
quick
question
on
the
first,
I
I
gotta
confess
I'm
not
as
familiar
I
mean
I
haven't
actually
dived
as
deeply
into
all-star,
but
you're
saying
one
of
the
updates
was
a
policy
which
allowed
you
to
identify
projects
that
don't
have
an
authorized
like
maintainer.
Is
that
the
way
to
or
or
any
is,
did
I
get
that
right.
D
Yeah
exactly
so
in
in
github,
your
settings
are,
you
know
right
and
then
above
right
is
an
administrator
which
has
access
to
changing
all
the
settings
of
the
repository.
So
the
policy
as
it's
written
you
can.
You
can
turn
it
on
and
it'll
flag
anywhere
any
repository
that
doesn't
have
any
group
or
user
assigned
to
the
repository
as
an
administrator.
D
E
Yeah,
I'm
kind
of
I
thought
the
architecture
of
the
thing
was
that
maybe
I'm
missing,
maybe
I'm
getting
this
confused
within
toto,
but
that
it's
like
that
it
was.
It
was
associated
with
github
actions,
and
so
is
there
something
that
runs
periodically
to
check
for
repos,
which
are
not
don't
have
an
idea.
D
No,
so
it's
not
an
action,
it's
just
a
github
app
you
install
and
it
runs
periodically
in
the
in
the
in
the
open,
ssf
infrastructure
to
check
all
the
repositories
that
are
that
have
all-star
installed.
A
A
As
you
all
probably
know
quite
well
november
and
december,
a
lot
of
folks
were
out
with
vacation
holidays
and
whatnot,
so
definitely
getting
back
into
the
swing
of
things.
Getting
some
good
stuff
planned
for
q1
next
is
kind
of
is
something
in
the
topic
of
what
we've
been
talking
about
the
last
couple
meetings,
which
is
identifying
critical
projects,
so
there
have
been
some
updates
made
to
that
list.
I
know
this
is
definitely
a
work
in
progress.
A
There
were
some
very
good
suggestions
in
the
github
repository
for
some
updates
that
can
be
made
to
make
this
more.
I
guess
accessible
and
in
easier
so
just
want
to.
A
I
just
saw
these
today
the
issues
github
issues
essentially
39
through
46.,
so
I
haven't
gotten
to
those
just
yet,
but
I
definitely
agree
that
you
know
as
part
of
what
we're
working
on
in
identifying
critical
projects
the
process.
We
should
also
work
on
refining
the
process
and
doing
it
as
best
as
we
can
possibly
can.
You
know,
give
it
our
best
shot,
and
I
definitely
think
that
the
concept
of
curation
or
basically
open
sourcing
it.
A
You
know
working
within
this
work
group
and
the
open,
ssf
and
the
open
source
community
community
at
large
is
probably
the
best
way
to
achieve
that.
I
did
add
a
number
of
suggestions
from
github
issue
number
36.
I
believe
that
was
marta's.
Yes,
martha's
suggestions
looks
like
marta's
not
here
today,
but
it
was
just
a
bunch
of
suggestions
to
to
add
to
our
list
for
consideration
as
critical
projects.
A
A
The
next
update
I
have
regarding
that
is,
I
took
kind
of
an
initial
stab
at
something
we
talked
about
in
terms
of
kind
of
taking
it
one
step
further,
which
would
be
some
kind
of
prioritization
or
classification
of
projects,
including
the
feedback
from.
I
believe
that
was
from
arno
at
the
last
meeting
to
put
in
a
summary
page
to
kind
of
describe
everything
in
one
place,
so
I
definitely
would
love
you
know:
I'd
love
the
work,
groups,
thoughts
and
comments,
and
contributions
to
this.
A
So
with
that
being
said,
I
don't
want
to
take
up
too
much
time
talking
about
this.
Specifically,
I
think
it
does
require
a
little
bit
more,
maybe
some
more
dedicated
time
on
its
own
working
on
this,
so
just
to
complete
my
general
update,
so
some
updates
have
been
made,
taking
an
initial
step
to
kind
of
prioritizing
or
classifying
projects
once
they
have
been
identified
as
critical,
trying
to
find
a
way
to
further
essentially
classify
the
projects.
A
So
with
that,
that's
all
the
kind
of
the
recurring
updates
we
have.
I
thought,
as
part
of
especially
as
part
of
opening
the
new
year-
and
I
did
see
a
good
suggestion
from
michael
from
michael
wisner.
I
don't
believe
he's
here
today
is
is
michael
here
today.
Sorry,
I
don't
want
to
assume.
A
A
A
I
think,
especially
if
we
capture
some
notes
on
as
to
how
progress
is
going.
You
know
we
have
a
a
repository
that
we
can
refer
back
to,
but
if
there
are
other
ways
that
we
can
track
progress
of
the
projects
that
we're
doing
so
that
you
know
when
we
have
town
hall
meetings-
and
we
talk
about
you
know
when
people
ask
you
know
when
folks
come
back
to
us
and
ask
like
so
what
did
the
work
group?
So
what
progress
has
the
work
group
made?
A
E
You
know
best
practices
and
things
like
that,
but
I
I'm
kind
of
and
along
those
lines
what
it
made
me
think
about
is
you
know
we
put
in
a
lot
of
effort
in
a
sprint
at
the
end
of
the
year
to
try
to
you
know,
identify
projects
which
which
ought
to
be
using.
You
know
additional
authentication.
So
we
said
this
token.
You
know
here
here.
Let's
split
that
down
for
the
list
of
folks
who
could
get
a
free
token?
E
A
Any
idea
I
personally
don't
I
think
david
wheeler
would
be
the
person
to
talk
to
he
kind
of
spearheaded
that
project.
I
do
believe
a
good
amount
of
tokens
did
go
out
by
the
end
of
the
year.
Thanks
to
our
efforts.
Yes,
yeah.
F
A
We
can
sit
on
that
and
when
david
gets
back
for
the
next
meeting
I
would
be.
I
would
be
curious
too,
as
well.
That's
a
good
question.
It.
E
E
A
Absolutely
yeah,
I
think
getting
them.
The
tokens
was
probably
a
good
first
step,
but
you're
absolutely
right.
Maybe
if
there's
a
way
we
could
gain
insight
as
to
how
many
were
actually
used,
how
many
are
still
being
used.
That
would
certainly
help
to
see
you
know
if
that,
if
that's
worth
the
effort
in
a
in
a
future
iteration
absolutely
but
yeah,
good
good
question,
we'll
we'll
definitely
talk
with
david
about
that
next
next
time,.
A
Yeah,
I
believe
he
just
had
a
conflict
for
for
this
specific
time
slot
so
yeah.
Okay,
thank
you,
dave.
Anyone
else
love
to
hear
from
you.
G
D
A
We
certainly
used,
oh
sorry,
go
ahead.
Jeff.
D
G
I
was
asking
whether
we
can
roll
up
all
star
figures
in
some
way
as
a
as
at
least
one
sort
of
pool
of
matrix.
D
Yeah,
I
do
have
installation
numbers,
I
have
to
pull
them,
so
I
don't
have
them
off
of
my
head,
but
that
would
be
something
to
do.
Where
do
you
think
we
should
track.
B
Is
it
possible
to
use
lfx
security
for
this
purpose
and
lfx
reporting
capability,
not
security,
but
the
other
parts
of
lfx
for
the
actual
metrics,
how
it
pulls
in
a
lot
of
the
metrics?
A
I'm
familiar
with
lfx,
I
haven't
personally
used
the
security
reporting.
Do
you
know
like.
B
What
means
security
was
on
the
top
of
my
head,
but
I
mean
in
general
security
versus
just
generalized
project
metrics,
it's
it's
pretty
robust
and
has
a
lot
of
new
capabilities.
It
might
be
worth
looking
at
if,
rather
than
reinventing
the
wheel
leveraging
a
tool
within
the
foundation,
that's
just
readily
available.
A
Absolutely
do
you
do
you
know
if,
if
lfx
security
has
any
any
ways
that
you
can
access
any
of
that
any
of
that
data,
or
is
it
something
you
have
to
be
a
project
using
lfx
to
access.
B
Well,
lfx
in
and
of
itself
has
a
metrics
dashboard.
The
security
component
is
fairly
new
and
it
incorporates
things
like
snick
and
blue
bracket
and
other
things
to
actually
do
vulnerability
and
and
other
scanning.
So
it's
less
about
metrics,
but
just
in
general,
the
lfx
metrics
dashboards.
For
what
you're
suggesting
here
to
provide.
B
B
Security
is
kind
of
a
separate
conversation,
but
it's
still,
you
know,
still
relevant
in
the
topic
of
osf
or
os
and
stuff.
A
Yeah,
that's
a
good
point.
We
tried
to
incorporate
what
we
called
selection
criteria
so
be
able
to
point
to
something
to
to
be
able
to
to
justify.
You
know
why
ansible,
for
example,
should
be
on
our
list
of
critical
projects,
so
I
could,
I
could
see
I
could
see
if
there's,
if
there's
data
outputs,
like
you
mentioned,
I
could
see
that
being
a
selection
criteria.
You
know
just
another
data
point
to
consider
so
yeah.
Thank
you
for
that.
A
Has
anyone
else
used.
Any
of
these
tools
are
familiar
with
anything
that
might
help.
I
know
I
mean
jacques.
I
like
your
question
about
the
security
score
cards,
because
I
feel
like
that,
could
potentially
provide
insight
into
into
actually
figuring
out
how
to
help
projects.
G
Yeah
it'll
also
give
us
a
sense
of
like
what
you
might
call
the
water
level
or
the
water
where
the
water
table
is
in
terms
of
security
practices.
You
could
look
for
things
that
are
lagging.
You
know
particular
indicators
that
are
falling
behind
things
that
turn
out
to
be
easier
and
harder,
and
do
we
focus
on
those
you
know,
for
example
like
if
branch
protection
stays
stubbornly
low.
Why
is
that?
So
you
know
what
feedback
to
be
give
to
github,
etc.
A
Yeah,
I
I
think
that's
I
think
that
could
be
a
potential
good
kind
of
workshop
or
something
we
could
do
as
a
work
group,
even
where
we
could
say
you
know,
for
this
half
of
today's
meeting,
we're
gonna
just
all
hop
on
score
cards
and
see
what
we
can
come
up
with.
A
A
But
yeah,
that's
a
that's
a
very
good
point
and
and
another
point
I
wanted
to
bring
up
that
just
to
see
what
the
work
group
thinks
about
it
is,
it
does
seem
like
curating
and
maintaining
a
list
of
critical
projects
is
something
of
value.
It's
something
of
value
to.
I
know
to
other
projects,
to
other
open,
ssf
projects
and
and
and
just
in
general
I
mean
you
look
at
nist
and
you
look
at
what
a
lot
of
folks
seem
to
be
focused
on.
A
A
If
that's
something
that
makes
sense
for
us
to
continue
to
do
as
a
work
group
and
to
dedicate
you
know
a
portion
of
our
work
group
meetings
to
to
to
working
on.
I
just
would
like
to
hear
what
the
work
group
has
to
say
about
that
and
something
that
and
it's
something
of
value
that
we
could
provide
to
the
open
source
community
as
a
whole
to
the
open
ssf.
To
really.
E
Yeah
I
mean,
I
think
I
think
this
is
really
valuable,
I
think,
but
but
the
I
it
seems
like
our
focus
has
mostly
been
on
identifying
those
projects
which
are
both
critical
and
sort
of
under-maintained
or
under-produced.
E
I
think,
with
some
of
the
terminology
of
one
of
those
research
papers,
we
looked
at
right,
is
it
so,
while
you
know-
and
some
critical
projects
may
be
on
the
list
and
may
fall
into
that
state
of
being
underproduced
right,
I
could
think
of
a
lot
of
java
projects
that
you
know
we're
one
time
you
know
very
well
produced
and
then
you
know
kind
of
over
time.
That's
kind
of
you
know
that's
kind
of
slipped,
and
you
know
now
you've
got
the
log
for
j.
E
You
know
stuff
right
so,
which
is
is
like
the
perfect
example
of
a
critical
project.
No
one
was
really
thinking
about
as
being
particularly
critical,
but
then
it
was
like
oops,
it's
it's.
It
is
pretty
underproduced
so
that
it
lets
to
summarize,
I
guess
the
mirror
it
would
be.
Are
you
looking
for
you
know
the
the
critical
projects
or
the
underproduced
critical
projects.
A
I
think
the
objective
first
and
foremost
is
without
getting
too
into
the
into
the
nitty-gritty
is
identifying
critical,
open
source
projects.
Okay
on
the
under
production
paper
was
one
of
the
data
points
used
to
help
to
help
guide.
You
know
which
projects
were
critical,
so
yeah.
I
think,
first
and
foremost
that
stitch
projects
are
critical
and
I
think
you'll
find
through
that
process.
A
So
I
think,
in
my
opinion,
the
objective
is
really
first
and
foremost,
you
know,
regardless
of
you
know,
I
don't
think
well,
you'll
ever
get
full
consensus
on.
You
know
what's
critical,
which
ones
are
the
most
critical,
but
just
just
to
answer.
You
know
this
is
our
best
take
at
which
projects
are
critical.
It
might
not
be
all
of
them.
It's
probably
a
good
representative
sample
of
them.
B
I
think
this
becomes
more
and
more
relevant
in
the
context
of
proprietary
tooling,
which
you
know
even
most
proprietary,
tooling
uses
out
a
lot
of
them
use
outdated,
open
source.
You
know
package
libraries
because
their
their
you
know,
release
cycle
is
not
necessarily
agile.
It
can,
you
know,
take
you
know.
Some
of
them
are
still
every
three
months
six
months
for
larger
development
sets,
so
they
don't
necessarily
think
about
things
like
log
for
j
or
others,
and
certainly
a
lot
of
them
are
now
but
being
able
to
point
them
in
the
right
direction.
B
For
for
this
at
a
broader
scale
and
providing
you
know
either
a
list
to
start
with
of
things
that
should
be
scanned
and
then
eventually
you
know,
I
realize
it's
a
different
working
group
but
tools
to
automate
the
you
know
the
governance
around
finding.
You
know
using.
F
B
List
is
a
potential
first
step
in
automating
off
of
potentially
automating
off
this
list
to
hit
these
more
more
regularly
would
be
an
ideal
outcome.
I
would
think.
A
I
know
they
always
say
hindsight
is
2020,
but
if
you
go
back
in
our
work
group
meetings,
when
I
first
presented
the
our
ostip
stuff
back
in
july
of
last
year,
we
did
have
a
couple
of
the
logging
frameworks
on
our
list.
A
They
come
up
in
the
harvard
research
a
lot
too,
because
they're
everywhere
and
they've
been
around
for
a
long
time,
and
you
know
with
that
many
components.
You
really
can't
review
them
all,
but
you
know
at
least
we
knew
we
were
barking
up
the
right
tree
and
hopefully
with
something
like
this
when
something
big
like
this
happens,
a
crisis
so
to
speak,
you
know,
hopefully
the
response
will
be
more
resources,
more
review
of
this
kind
of
stuff
to
prevent
this
from
happening
again.
A
D
Yeah,
I'm
in
support
of
that.
I
think
that's
clearly
shown
that
it's
useful
with
both
this
great
mfa
project
and
alpha
omega
project,
and
I
think
there
will
be
more
to
come.
D
I
think
also
just
want
to
point
out
to
everybody,
because
not
everybody
was
in
the
previous
meeting.
We
did
have
a
goal
discussion
in
that
meeting
and
update
our
goals
a
little
bit
it's
in
the
it's
in
the
dock.
If
you
scroll
down
to
the
december
16th
meeting
where
we
did
kind
of
narrow
our
goals
a
little
bit
towards
identifying
projects
as
being
the
primary
goal
of
this
group,
but
of
course
this
this
is
fluid
and
up
to
the
group.
So
it's
something
that
that
we
could
revisit
if
we
need
to.
A
Okay:
okay,
okay,.
A
A
Okay,
so
with
that
we're
at
36
past
the
hour,
we
could
take
about
15
minutes
or
so
we
could.
We
could
discuss
some
of
the
candidate
projects
and
kind
of
go
through
our
process
of
providing
feedback
and
kind
of
going
through
the
work
group,
so
I'll
pull
that
up
and
I'll
put
a
link
as
well,
because
I
know,
apparently
there
were
some
access
issues,
I'm
really
trying
to
fix
that.
So
please,
let
me
know
if
you're
having
any
issue
accessing
this
document.
A
But
so
the
way
I
currently
have
it
broken
down
and
again,
if
anyone
has
any
comments
or
thoughts
on
how
to
improve
this,
this
is
all
a
work
in
progress,
but
currently
there
is
the
critical
projects
tab.
So
this
is
essentially
the
the
list
so
to
speak.
You
know
these
are
the
ones
that
have
gone
through
all
of
our
discussions
and,
and
you
know
they
have
selection
criteria
to
back
them
and
we
as
a
work
group
at
least
don't
disagree
and
and
think
it
it's
worthy
of
being
critical.
A
Then
you
have
the
summary
tab
which
I,
which
was
my
you,
know,
initial
attempt
at
addressing
some
feedback.
As
to
you
know,
if
someone
who
doesn't
know
anything
about
us-
or
this
were
to
come
across
this,
would
they
know
what
it
is?
So
I
put
in
a
summary
the
the
prioritization
is
the
very
nascent
part
where
that
we
could
probably
get
to
that.
That
deserves
a
probably
a
whole
session
on
its
own.
But
again,
if
you
have
any
comments
or
want
to
put
any
notes
in
there,
that
would
be.
A
That
would
be
great
next.
The
next
tab
is
candidate
projects.
This
is
meant
to
be
the
sheet
that
captures
kind
of
the
discussion
forum
where
projects
are
to
be
discussed
by
us,
the
work
group
and
justified
to
be
critical
or
not
just
to
go
through
the
whole
worksheet.
Next,
you
have
the
selection
criteria,
so
you
know
we
definitely
want
to
demonstrate
that
we
are
not
just
pulling
stuff
out
of
our
butts
as
they
say,
or
you
know
just
making
stuff
up.
We
try
to
be.
A
A
Next,
is
the
community
slash
open,
ssf
member
editions,
so
this
is
kind
of
the
the
backlog
so
to
speak.
So
this
is
where
you
know.
People
have
suggested
many
things.
One
of
the
github
issues
had
a
bunch
of
new
projects
that
were
recommended.
A
We
had
a
good
suggestion
from
docker
poll
count
data
reports
on
that
to
get
some
some
more
candidates
on
there
and
then
and
then
there's
survey
responses.
So
there
is
a
google
form.
It's
a
public
survey,
an
anonymous
public
survey
which
I
have
provided
a
link
to
it
in
the
top
so
feel
free
to
use
that
yourself
or
to
share
that
with
people
again
to
just
get
as
many
diverse
viewpoints
as
we
can,
but
that's
a
general
overview
of
the
sheet
and
the
current
process.
A
Again,
you
know
I
would
love
to
iterate
this
and
make
it
in
a
way
that
is
efficient
and
you
know
that
pleases
or
that
works
for
as
many
people
as
possible.
I
know
we'll
never,
please
everybody,
but
so
yeah,
that's
kind
of
the
general
process
right
now.
So,
as
you
could
see
in
candidate
projects,
we
do
have
about
25
that
one
of
them
being
package
managers,
which
is
very
vague,
so
that
almost
requires
almost
a
session
on
its
own.
A
Our
discussion
on
its
own,
but
the
rest
of
them
being
you
know,
projects
that
are
recommended
one
way
or
another,
make
it
past
kind
of
the
first
round
of
kind
of
review
and
and
yeah
review.
And
then
you
know
it's
up
to
discussion
and
to
help
us
justify
whether
it
belongs
on
the
list
or
not.
So
let
me
see
where
we're
at
with
time
we're
at
41.,
okay,
we
could
take
at
least
10
minutes
to
talk
about
some
of
these,
so
the
first
one
we
have
is.
A
If
we
can
come
to
a
conclusion
today,
we
have
metasploit
framework,
so
this
was
originally,
I
believe,
chosen
because
of
the
criticality
score
looks
like
based
on
our
initial
discussions.
A
G
I
know
very
little
about
metals
metasploit.
It
is
supported
by
rapid7
who
are
sort
of
a
security
consultancy.
The
reason
I'm
familiar
with
it
is
that
it's
one
of
the
very
few
signed
collections
of
ruby
gems.
G
That's
how
it
first
came
to
my
notice
when
I
ran
the
numbers
on
which
gems
are
actually
signed.
There's
just
not
very
many,
and
this
one
stood
out
because
it's
a
whole
family
of
gems
that
are
signed.
G
E
This
was
when
we
were
kind
of
chuckling
a
little
bit
in
the
last
meeting
because
it
was
like
okay.
Is
it
critical
infrastructure?
It's
a
little
odd.
I
mean
my
I'm.
I
think
my
pen,
testing
team,
probably
uses
it.
You
know,
but
to
do
hacking.
It's
a
little
a
little
odd,
though,
on
the
list.
So
anyway,
that
was
a
chuckle.
C
A
G
Yes,
this
this
sort
of
highlights
that
we
might
need
to
work
out
whether
we
bias
some
environments
over
others.
So,
for
example,
there's
a
lot
of
focus
on
things
that
show
up
at
production
time
sure
they
show
up
elsewhere.
But
production
time
is
where
we're
really
worried
about,
because
then
they
get
access
to
production
assets.
G
G
B
I
guess
my
opinion
on
that
and
kind
of
an
approach
that
we've
been
looking
at.
Is
it's
really
more
about
pre-production,
trying
to
mitigate
the
potential
for
issues
in
production
by
you
know,
incorporating
as
many
possible
touch
points
prior
to
released?
You
know.
Certainly,
pen
testing
of
a
production
application
is
a
relevant
context,
but
if
you're
you're
have
the
right
processes,
best
practices,
automation
of
you
know,
vulnerability,
checks
and,
and-
and
you
know,
n
number
of
other
component
things
that
can
be
done.
B
You
know
certainly
having
this
criticality
list,
which
will
drive
vulnerability,
checks
more
frequently
as
well
as
better
development
practices.
You
know
don't
use
libraries
that
you
haven't
vetted
internally,
things
like
that
and
the
list
kind
of
goes
on
and
is
being
developed
by
these
varied
groups.
B
You
know
it's,
I
think
production
is
obviously
the
end
goal,
but
you
know
my
understanding
of
what
a
lot
of
the
industry
is
really
trying
to
do
is
to
avoid
having
any
of
those
issues
or
having
a
pen
test
come
up
with
nearly
you
know,
nothing
almost
nothing
in
its
tests,
because
we've
done
enough
of
the
due
diligence
up
front
right.
So
that
is,
the
kind
of
the
question
of
production
is
important,
but
it's
really
the
processes
from
I.
You
know
initial
check-in
and
development.
B
E
I
I
agree
with
eric
julia.
I
think
it's
a
you
know,
it's
sort
of
we
shouldn't
drop
it,
but
I
mean
we
shouldn't
lose
it.
I
mean
yeah.
If
a
pen
test
team
got
exploited,
that
would
wouldn't
be
awesome.
However,
I
do
think
it's.
There
are
other
there's,
probably
hotter
things
to
put
focus
on.
E
A
That's
that's
a
great
consideration
too,
because
I
think
that
since
that's
the
goal,
I
think
kind
of
coming
up
with
the
most
critical
things
that
should,
I
think,
maybe
be
the
the
strongest
guide.
But
you
bring
up
a
good
point
about
you
know
what
point
in
the
development
process
should
be
solved.
D
So
before
the
break,
we
were
really
kind
of
looking
at
the
most
critical
and
and
kind
of
with
an
unsaid
goal
of
getting
around
100
projects,
because
that's
what
the
mfa
was
looking
for
now
we're
at
a
different
different
time,
and
and
as
we
mentioned
you
know,
maybe
we
need
to
consider
these
projects
that
are
at
a
different
tier.
I
noticed
I
hate
to
derail
a
little
bit,
but
I
noticed
you
had
this
selection.
No
sorry,
not
selection
criteria.
What
was
it
the
summary
tab?
You,
you
started
a
prioritization.
F
F
D
That,
first
and
think
like
are
we?
What
priority
are
we
looking
at
right
now
and
should
we
expand,
or
should
we
just
to
limit
ourselves
to
that
high
priority
now,
and
in
that
case,
we
probably
would
say
no
to
this
project.
A
E
Another
thought
bubble
I
like
what
you're
thinking
about
a
strict
priority.
Some
of
it
might
also
help
if
we
kind
of
categorize
these
things
a
little
bit.
So
you
know
you
could
you
could,
for
example,
say
something
like
kvm
hypervisor
right?
That's
an
example
of
something:
that's
yeah!
That's
that's
open
source.
You
know
it's
used,
you
know
all
over
the
place
right
versus
make
the
make
command
is
used
to
produce.
E
You
know
you
know
whatever,
whatever
flavor
of
make
you're
using
right.
So
there's
like
the
the
production,
the
supply
chain
thing,
the
dev
tools
or
whatever
you
exploit
one
of
those.
You
know.
Potentially
it's
it's
a
huge
impact,
but
it's
a
different
class
of
thing.
It's
not
like
it's
different
priority,
but
it's
like
a
different
category.
So
there's
both
so
categorization
might
be
a
little
bit
easier
than
prioritization
right.
We,
we
might
have
far
fewer
disagreements.
E
E
You
know
tab
right,
community,
open,
ssf
member
additions
tab.
I
was
like
oh
yeah
yokto
project's
in
there,
which
is
used
to
build
that
you
know
yakuto
project
build
new
boot.
These
are
used
to
build
tons
of
internet
of
things
stuff
right,
which
you
know.
If
you
know,
if
bitfake,
which
is
a
project
within
yocto
project,
got
you
know,
exploited
it'd,
be
like
you,
wouldn't
you
wouldn't
be
able
to
know
because
it's
produced
all
kind
of
exploited.
E
You
know
linux
distributions
out
there
that
people
are
using
to
build
devices
with
so,
but
it
doesn't
appear
on
any
of
the
other
tabs.
That
was
the
thing
from
a
process
standpoint
I'm
like.
Okay,
we
had
this
feedback
that
these
things
are
important.
I
was
like
well
yeah
super
important.
Why
aren't
they
on
one
of
the
lists.
E
It
didn't
wind
up
on
a
list
that
was
ones
we're
working
on.
It's
on
a
community
input
list
see
what
I'm
saying.
What
are
we
doing
to
migrate?
Those
things
the
community
has
told
us
these
are
critical
and
migrate
them
onto
the
list.
We're
actually
working
on.
A
Right,
that's
kind
of
that's
part
of
what
we're
working
on
as
a
work
group
yeah.
So
they
ideally
they'll,
go
from.
A
You
know
just
general
editions
so
like
they
are
in
this
tab
to
this
to
the
candidate
project,
and
then
you
know
we'll
discuss
as
a
work
group,
and
you
know
if
a
case
a
good
case
can
be
made
and
then
it
gets
on
to
the
list.
Ideally,
you
know
I
I,
like
the
you
know
to
essentially
ingest
from
as
many
points
as
possible.
Go
through.
A
You
know
one
or
two
iterations
of
you
know
some
kind
of
analysis
and
then
come
up
with
our
kind
of
our
candidate
projects
and
then
to
get
back
to
to
your
question
jeff
about
my
my
take
to
as
to
prioritization.
That
was
really
just.
A
A
So,
maybe
that's
something
we
can
put
as
a
future
topic
idea,
I
think
david
would
would
david
wheeler
would
would
want
to
participate
in
that
discussion
too,
but
I
think
yeah,
the
categorization
slash,
prioritization,
that's
going
to
be
probably
a
natural
next
step,
in
addition
to
you,
know,
maintaining
and
curating
this
list
of
critical
projects,
but
I
really
think
like
a
lot
of
things
in
open
source,
you
know
by
open
sourcing
it
by
you
know
allowing
the
work
group
folks
to
to
comment
and
to
to
to
edit
and
to
make
changes.
A
I
I
think
that's
probably
going
to
be
the
best
way
to
get.
You
know
a
good
representative
list
that
represents
you
know
a
good
amount
of
diverse
viewpoints.
D
Yeah,
so
to
bring
it
back
then,
pending
pending,
like
a
better
prioritization,
get
going
on
like
the
the
bar
that
we
had
been
using
before
the
break,
I
would
say
a
no
to
metasploit,
based
on
like
the
idea
that
we've
been
focusing
on.
Oh.
A
Oh
no,
no
worries
at
all.
Would
you
like
to.
A
Yeah
that
actually
is
awesome
because
that's
kind
of
what
I
was
thinking
when
I
took
this
kind
of
first
stab
at
prioritization.
I
definitely
think
it's
going
to
be
pretty
important
to
differentiate
which
projects
are.
You
know,
like
the
the
graphic
and
that
we
all
see
the
that
one
project
that's
holding
up,
everybody
that's
run
by
one
or
two
people.
We
want
to
be
able
to
identify
those
those
projects
that
have
essentially
no
resources.
A
What
I
called
those
were
tier
zero.
I
wrote
tier
zero
projects,
are
volunteer,
run
and
have
little
to
no
dedicated
resources
and,
as
you
go
up,
you
get
higher
amounts
of
dedicated
resources
the
highest
being.
You
know
this
is
a
google
project
that
has
you
know
dedicated
resources
assigned
to
it.
So
it'll
help
us.
I
think,
that'll
be
great
to
help
guide
the
discussion
of
how
do
we
prioritize
where
resources
go
or.
E
I
mean,
but
that
was
the
point
I
was
making
earlier,
is
our
goal
to
identify
critical
projects
or
to
identify
critical
projects
which
are
under
produced,
and
I
think
it's
not
either
or
it's
both
and
it's
what
our
earlier
conversation
was
right.
So
no
one
would
question
that
linux
is
not
a
critical
project.
No
one
would
also
argue
that
it's
it's
it's
under
produced.
It's
it's.
You
know
thoroughly
well
produced,
so
that's
this,
so
it's
it's
not
either
or
it's
both
and
I
think
from
what
I
heard
gathered
earlier.
E
H
E
I'm
fine
with
with
the
that
was
the
conclusion
the
earlier
conversation,
this
meeting
right,
and
so
I
was
like
okay
and
you
may
have
something
which
is
critical
today
and
falls
into
the
underproduced
category.
You
know
over
time
right
because
this
is
not
a.
This
should
never
be
sort
of
a
static
analysis.
I
think
this
analysis
needs
to
needs
to
happen
continuously
and
and
because
you
know
some
things
fall
in
and
out
of
favor
over
time
right.
G
I
can
suggest
that
we
can
frame
this
as
a
as
a
like
on
a
risk-based
approach.
Some
of
them
we
are
including
because
we're
concerned
about
the
magnitude,
the
event
magnitude.
So,
for
example,
like
your
your
docker's
and
your
linux
kernels,
the
magnitude
of
exploit
is,
is
very
high.
G
So
how
frequently
something
will
go
wrong
so,
for
example,
a
project
that
is
is
underproduced
will
have
we're
saying
you
know
cause
they
would
have
a
higher
frequency
of
bad
things
happening
because
there
are
fewer
people.
Looking
for
people
able
to
respond.
E
Yeah,
it's
it's
a
both
in
kind
of
a
thing:
it's
like
the
cross
product
of
under
produced
and
critical
and
and
heavily
used
either.
You
know
in
terms
of
the
number
of
times
it's
included
or
the
number
of
times
it
runs
right.
You
know
yeah.
Those
are
that
that
cross
product,
absolutely
or
if
you
will,
the
overlap
of
those
two
sets
is
that
you
know
it
should
be
the
highest
that
that
should
be
the
highest
priority.
G
A
Cool
wonderful
well
looks
like
we've
got
a
couple
minutes
left
three
by
my
account.
I'd
like
to
first
thank
everybody
for
for
a
nice
discussion.
Today,
it's
nice
to
see
everyone's
faces
and
get
back
into
the
swing
of
things
for
this
year,
also
yeah.
So
we've
got
a
couple
things
in
for
potential
future
topics
to
to
kind
of
go
into
in
more
detail.
A
If
anyone
else
has
anything
that
they
ever
want
to
talk
about
or
present,
you
know,
please
feel
free
to
throw
that
up
in
the
future
topic
ideas
and
with
the
last
two
minutes
I
like
to
you
know,
have
a
little
bit
of
a
cushion
just
in
case
someone
didn't
get
a
chance
to
say
something
they
wanted
to
say,
or
you
know
just
kind
of
leave
that
last
minute
or
two
open
for
kind
of
any
last
remarks.
A
If
anyone
wanted
to
say
something
so
with
that
I'll,
throw
I'll
throw
one
in
real
quick
for
the
recording.
G
H
Wonderful,
thank
you.
I
had
a
question
there
was
nobody
mentioned.
Did
I
mention
earlier
of
a
separate
meeting
discussing
the
criticality
score?
Can
I
get
a
reference
for
that?
I'm
a
little
curious
to
maybe
join
that
one.
A
Yeah,
I
think
I'm
I
think
I
could
find.
I
think
I
could
find
it
in
their
github
repo.
So
I'll
put
it
in
the
meeting
notes.
A
Question,
oh
okay,
yeah
there's
a
small
chance.
Maybe
I
made
that
up
or
I
thought
I
saw
it,
but
I
swear.
I
saw
it
on
the
calendar
for
it
to
discuss
criticality
score
but
yeah
if
there's
I'll
put
in
any
links.
Next
to
the
updates
and
the
meeting
notes.
A
Awesome
thanks
so
much
jeff
okay
looks
like
we're
at
noon
on
the
dot,
so
are
noon.
For
me.
Sorry!
But
thanks
so
much
everybody
great
discussion
today
and
I
look
forward
to
seeing
you
in
two
weeks.