►
From YouTube: OpenSSF TAC Meeting (March 9, 2021)
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
I've
been
doing
this,
please
let
me
know
so.
Thank
you.
Everyone
for
joining
we'll
go
and
get
started.
So
the
objective
for
today's
meeting
is
that
we
want
to
start
kicking
off
this
process,
we're
reviewing
the
quote
charter,
slash
of
each
of
the
working
groups
and
move
them
through
this
formalization
process
that
we
came
up
with
a
little
while
ago.
A
A
So
with
that,
I
think
the
the
approach
I
was
thinking
of
and
please
feel
free
to
jump
in
and
comment
is
we'll
just
have
each
lead
go
ahead
and
present
the
overview
of
their
group
discuss
the
projects
specifically
that
they're
working
on
and
what
they
anticipate
working
on
in
the
next
year,
or
so
we
can
have
open
discussion
after
that,
we
can
actually
go
through
the
readme
separately
as
well,
and
then
at
the
end,
we
can
kind
of
discuss
if
we
see
any
overlaps
or
other
ways
to
facilitate
sharing-
or
you
know
getting
these
things
sort
of
more
in
sync,
any
questions
or
comments
about
that
before
we
get
started.
A
Okay,
well
that
I
am
going
to
go
on
mute
for
a
minute
and,
let's
start
with
best
practices
probe,
you
want
to
jump
in
there
or
whoever's
presenting
for
you
guys.
I
would
love
to.
B
B
We
currently
have
five
sub
projects
that
are
part
of
the
group,
and
my
dream
is
someday
to
figure
out
how
to
get
a
copy
of
our
little
reference
architecture
picture
plugged
into
a
markdown
file.
That's
a
problem
for
another
day.
Our
five
projects
are
the
common
requirement
enumeration
project.
This
is
an
oauth
sponsored
project
that
identifies
requirements
that
are
banned
universally
across
different
specifications.
B
Next
project
is
our
secure
software
development
fundamentals,
exp
class.
The
purpose
of
this
is
to
help
developers
learn
the
fundamentals
of
developing
secure
code.
We
have
skf
the
security
knowledge
framework,
which
is
our
third
project.
The
purpose
of
that
is
to
help
actually
has
a
couple
different.
This
serves
all
three
of
our
quadrants.
It
helps
identify
good
practices
for
errors
in
code,
helps
developers
adopt
that
by
showing
examples
of
how
to
write
code
better
and
helps
provide
them
learning
about
security
requirements
or
industry
frameworks
that
might
be
relevant
to
a
specific
piece
of
software.
B
I'll
be
excited
about
that,
then
we
have
our
awesome
cii
best
practices,
badges
project
and
the
purpose
of
that
is
to
help
developers
identify
and
adopt
good
practice,
and
this
again
supply
helps
identify
a
series
of
oss
and
floss
good
practices
and
implement
the
badging
system
to
kind
of
so
developers
can
brag
humble
brag,
a
bit
saying.
Look
how
great
I
am
I
and
I
do
things
at
a
certain
level
of
maturity.
B
I
can
demonstrate
this
capability
and
then
finally,
our
last
project
is
our
scorecard
project,
and
that
is
a
tool
that
helps
automate
the
analysis
and
of
these
a
project
and
give
you
kind
of
a
feel
for
how
many
of
the
practices
some
of
these
projects
a
patient
or
project
could
execute
on.
Are
they
doing
that?
Do
they
have
published
tests?
Do
they
have
different
factors
enabled
in
the
project?
B
C
Yeah
I
was,
I
was
curious
about
intersections
between
the
scorecards
project
and
the
the
metrics
project
in
identifying
security
threats.
B
I
would
have
to
route
you
for
specific
questions
dan,
but
yeah.
There
absolutely
could
be
either
a
synergy
or
relationship
between
them.
We're
not
looking
at
scoring
anything
with
the
scorecard
we're
just
basically
saying
there,
here's
a
list
of
desired
security
objectives,
and
does
this
project
meet
those
criteria
or
not?
D
E
I
can
talk
about
it
at
mine
or
now,
whatever
you
guys
want.
So
the
purpose
of
the
metric
dashboard
is
to
pull
together
data
not
necessarily
to
calculate
it,
so
the
scorecard
being
a
tool
metric
is
the
service
would
be
one
way
of
looking
at
it.
C
Okay,
so
there's
some
overlap
between
the
the
inputs
to
the
score,
and
so,
if
I
think
of
the
metrics
project
is
having
a
bunch
of
different
data
elements,
some
subset
of
those
overlap
or
feed
into
the
thing
that
would
be
calculated
in
scorecard
or
these
totally
different
kinds
of
metrics.
No.
E
No,
so
some
of
it
is
directly
consuming
the
output
of
the
scorecard,
so
so
scorecard
runs
on
a
project
x.
Has
this
set
of
data
will
suck
in
that
data
and
display
it
in
it
for
for
that
project,
we'll
also
suck,
in
other
things
from
other
tools,
but
we'll
provide
the
the
web
ui
and
the
api
and
whatever
we
need
for
folks
to
consume,
say
tell
me
about
x,.
F
Yeah
and
dan
that's
similar
for
the
best
practices
data.
So
the
idea
is
both
scorecard
and
best
practices
provide
data
that
is
consumed
by
security
metrics
and
made
available
through
an
api
and
a
and
visual
dashboard
dashboard.
B
We
also
have
a
set
of
participant
personas
in
the
open
source
development
world
that
we're
collaborating
with
another
working
group
on
and
along
with
that,
you
have
user
pain
points.
So
some
of
our
next
steps
would
be
as
we
get
the
integration
of
our
five
sub
projects
a
little
bit
tighter.
We
would
be
able
to
kind
of
reflect
upon
those
pain
points
and
see.
B
Do
we
have
any
areas
of
opportunity
in
any
of
these
five
areas
and
then
we're
also
looking
at
curating
that
set
of
desirable
good
practices?
A
developer
could
follow
so
reviewing
things
that
are
currently
in
the
scorecard
reviewing
industry
frameworks
like
853
or
161,
or
the
cyber
security
framework.
B
B
That's
what
our
dream
is
to
help
people
code
more
goodly.
A
More
goodly
is
a
great
okr,
quick
question,
which
working
group
are
you
working
with
on
the
presonus,
the
vulnerability
disclosure
working
group
awesome
and
then
are
those
going
to
be
published
publicly
at
some
point,
because
I
could
definitely
see
those
being
useful
to
a
number
of
other
groups
like
the
metrics
dashboard
or
even
tooling,
and
things
like
that
if
we
were
to
expand
on
those.
B
Yes,
they
will
be
published
publicly.
It
is
less
a
less
sexy
activity
than
other
things,
so
there
is
less
participant
interest
in
it,
but
my
dream
would
be
to
figure
out
where
the
best
place
to
formally
publish
those
are
once
they're
refined
and
actually
I'm
leveraging
them
in
a
couple.
Other
working
groups-
they're
not
open
ff
related,
so
I
think
they'll
be
very
useful
and
my
dream
is
to
get
them
publicly
published
in
the
near
future.
A
B
Awesome
well,
I'm
krobe,
I'm
here
to
talk
about
my
favorite
working
group,
the
vulnerability
disclosures
working
group.
The
purpose
of
this
group
is
to
help
improve
overall
security
of
open
source
software
ecosystem
by
helping
to
mature
and
advocate
a
well-managed
vulnerability,
reporting
and
communication
practice
set
of
practices.
B
We're
looking
to
our
objective.
We
have
three
main
objectives:
we're
looking
to
document
and
promote
reasonable
vulnerability,
disclosure
and
coordination
practices
amongst
the
open
source
software
ecosystem,
trying
to
specifically
initially
target
maintainers,
but
there's
a
lot
again:
those
user
personas
I
mentioned,
there's
a
lot
of
other
interested
people.
This
particular
working
group
has
a
lot
of
representation
from
the
research
bug,
bounty
community,
so
they're,
very
interested
in
the
finder
persona
and
those
pain
points.
But
again,
my
main
focus
would
be
to
focus
on
open
source
developers.
B
We
have
working
on
identifying
vulnerability
disclosure
pain
points
for
the
main
painter
consumer
security,
researchers,
and
our
next
step
would
be
to
kind
of
take
some
steps
to
address
those.
We
have
those
pain
points
documented.
Those
are
published,
I
need
to
figure
out
a
better
way
like
with
the
personas,
to
find
a
consistent
way
to
publish
that
as
an
artifact
and
then
let
people
leverage
that
or
collaborate
or
build
upon
it.
But
we
have
those
pain.
B
Points
documented
in
a
series
of
google
documents
is
what
it
is
and
then
we're
looking
to
fulfill.
Take
the
development
adoption
of
standards
based
open
source
vulnerability
exchange,
so
we're
looking
at
things
like
cert
cc's,
vince
tool,
we're
talking
about
standards
like
oval
or
cvrf.
B
Competitor
frenemy
companion
of
the
cve
program,
so
we're
kind
of
talking
about
all
things
related
to
vulnerability,
management
and
disclosure
and
again
my
particular
focus
is
to
help
open
forgiveness,
open
source,
maintainers
tools
or
templates,
or
recommendations
on
how
they
can
manage
it,
because
most
of
them
are
not
software
vendors
and
then
you
know
they
don't
necessarily
professional
security
folks,
so
make
it
as
simple
as
possible.
B
And
that
is
about
that
right
now
we
are
working
on
a
vulnerability
disclosure
white
paper
which
we
hope
that'll
be
our
kind
of
first
major
deliverable,
which
we
would
be
able
to
address
the
frame,
the
problem
and
try
to
provide
a
series
of
recommendations
again
for
open
source
and
then
I'm
having
people
that
have
had
a
lot
of
interest
outside
of
the
open
source
community
to
be
able
to
leverage
this
potentially
at
a
broader
industry
level.
B
Here's
a
set
of
reasonable
practices
might
be
simpler
to
implement
than
iso
or
some
of
the
other
existing
cbd,
the
and
the
mtv
public
party,
mpb
multi-party
disclosure
frameworks.
So
our
first
deliverable
is
going
to
be
this
white
paper
that
we
just
kicked
off.
We
now
have
a
draw
man
for
and
we'll
find
some
section
owners,
so
we're
hoping
to
have
potentially
a
deliverable
ready
for
review.
B
Maybe
early
mid-summer
would
be
our
dream
and
then
we
go
out
on
a
road
show.
I
see
a
lot
of
synergy
just
naturally
between
this
and
the
developer
best
practices
group.
I
think
that
we
will
be
able
to
kind
of
identify
voter,
really
disclosure
good
practices
and
then
help
advertise
them
or
broadcast
them
through
mechanisms
like
the
cii,
badges
or
the
exp
training
class.
Again,
I
think,
there's
a
big
interrelation
between
this
particular
part
of
development
and
the
broader
writing.
Better
software.
A
Any
questions
or
comments
yeah,
do
you
anticipate
like
this
group
primarily
be
more
focused
kind
of
like
how
best
practices
is
currently
where
it's
kind
of
more
documentation
and
and
information
for
developers
or
at
some
point,
will
there
be
tooling
involved
like
the
exchanging
of
vulnerability
data
and
things
between
vendors,
like
kind
of
what's
the
vision.
B
B
The
team
wasn't
super
interested
in
that,
but
yeah
eventually-
and
I
feel
this
group
should
have
opinions
on
things
like
oval
and
cvrs
csaf
and
be
able
to
have
an
opinion
to
provide
to
the
open
source
community.
You
know
this
is
the
other
right
way
you
should
participate
in
these
disclosures.
You
should
you
should
or
should
not,
leverage
cve.
If
dwf
is
an
alternative
and
then
advocate
once
we
have
formed
our
opinions
advocate
for
that
and
then
potentially
try
to
influence
those
standard
bodies
to
help
be
more
open
source
friendly.
B
Some
of
us
participate
in
the
you
know,
with
mitre
and
the
cve
board
and
stuff
in
our
work
capacity
and
I'd
like
to
again
see
help
to
see
a
broader,
open
source
perspective
brought
into
some
of
those
groups.
B
A
Yeah,
that
would
that
would
be
really
awesome,
because
I
could
definitely
see
how
you
know
this
organization
could
help
influence
some
of
those
things
to
pick
up
some
adoptions.
I
think
there's
a
lot
of
disparity
across
the
board
right
now.
Right,
there's
a
lot
of
ideas.
There's
a
lot
of
competing
standards
out
there
that
people
are
trying
to
be
nice
to
bring
some
kind
of
unity
across
that.
B
And
cbd
is
a
very
heavy
process
intensive
process
so
ideally
we'll
be
able
to
provide
things
like
a
a
generic
reporter
template
so
that
you
know
an
open
source
project
just
copy
and
paste.
This
template
put
it
in
the
repo.
If
you
have
an
issue,
this
is
the
type
of
information
we
want,
provide
a
generic
security
handling
process
policy.
You
know
this
is
how
our
pro
project
could
copy
and
say
this
is
how
we
handle
vulnerability
reporting.
You
know
this
is
these
are
any
slas
or
expectations.
A
B
I
think
it's
availability
and
the
fact
the
vince
tool
is
not
currently
open
sourced.
I
talk
with
art
mania
all
the
time
and
yeah.
That's.
The
desire
of
the
carnegie
mellon
team
is
to
open
source
this
and
I
think,
once
that
happens,
we
will
start
to
get.
You
know
actual
developers
get
in
there
and
try
to
make
it
a
little
better,
but
I
think
we'll
also
get
broader
participation,
because
people
inherently
distrust
closed
source
things
in
this
world,
so
they're
they're
skeptical
about
it
until
they
can
look
at
it.
B
Regardless
of
intentions
yeah,
I
think
that
the
cert
team
has
the
best
intentions.
It's
just
a
matter
of
procedurally.
Can
they
get
this
thing?
You
jump
through
all
their
hoops
internally
into
their
masters
to
get
this
open
source,
and
I
think
once
that
happens,
we
can
reopen
that
conversation
to
say
perhaps
vince
is
the
recommended
pool
of
open
ssf.
A
Yeah
that
could
be
really
interesting.
Actually,
I
think
once
that,
matures
and
like
you
said
it
actually
gets
open
source
at
some
point
which
hopefully
soon
I
know
according
to
their
plans
but
yeah.
If
we
had
like
some
recommended
guidelines
and
people
could
just
jump
in
and
like
said,
build
it
into
the
pack,
the
badging,
which
could
then
show
up
and
score
cards
and
the
metrics
dashboard
and
all
this
kind
of
stuff
and
just
get
people
on
the
same
page.
That
would
be
really
really
cool
david.
G
Yeah,
just
real
quick,
I
think
I
I
actually
totally
understand
the
little
bit
of
concern.
Many
of
us
have
been
bitten
before
on
the
promises
not
delivered,
and
it's
I
think
the
problem
is
the
folks
we're
interacting
with
are
good
people,
but
not
the
ones
who
make
the
call.
Is
there
anything
that
we,
the
open
ssf,
could
do
that
might
push?
You
know
we
mean
formal
letter.
I
don't
know
hey
we'd
like
to
use
this,
but
you
said
you
released
it
this
way.
Can
you
do
that?
I
mean.
B
Perhaps
I
I
don't
know
what
the
where
it
lists
where
it
sits
on
their
backlog
and
prioritization,
but
I
will
definitely
ask
the
question,
because
I
have
to
talk
to
art
we're
commenting
on
an
iso
standard
together.
So
I
owe
him
feedback
tomorrow.
So
I'll
ask
him
it's
worth
a
try.
If
a
letter
from
us,
an
email
from
us
officially
helps
push
them
that'd
be.
A
Great
yeah
that'd
be
really
interesting
to
see
if
there's
something
that
we
could
even
do
to
help
push
forward.
Even
the
open
sourcing
of
it
right
like
not
just
a
letter
but
hey
we've
got
a
good
people
that
could
you
know,
help
run
reviews
and
just
get
it
prepped
and
ready
and
help
drop.
Something
just.
B
B
Well,
let
me
let
me
get
some
specifics
from
art
and
team.
It's
cool
that
sounds
good.
Any
additional
comments
or
feedback
is
either
do
both
of
those
efforts
seem
like
we're
going
in
the
right
direction.
H
This
is
jennifer,
I'm
I
I'm
a
new
member,
I
guess,
of
the
vulnerability
disclosure
group
and
so
far
I
think
it's
going
really
great
and
thank
you
for
your
awesome
facilitation.
It's
very
inclusive
and
very
productive
and
action
oriented,
which
I
definitely
appreciate.
I
have
a
few
kind
of
interrelated
questions,
so
the
white
paper
is
this
first
deliverable.
I
love
that
idea
that
we're
trying
to
put
into
writing
things
that
have
been
maybe
oral
tradition
before
and
then
and
we
get
that
information
and
don't
keep
it.
So
that's
really
exciting.
H
You
had
mentioned
a
few
things
around
creating
templates
for
like
policies
or
advisories.
You
talked
about
facilitating
data
exchange
and
you
mentioned
standards
bodies.
So
I
guess
my
big
question
is
in
terms
of
thinking
about
the
future
roadmap
of
this
group.
What
might
those
things
look
like,
for
example,
in
the
template
design?
Is
this
a
template
that
we
would
kind
of
create
and
make
freely
available?
Or
is
this
something
that
we
would
also
try
to
publish
or
formalize
through
a
standards
body?
H
B
So
for
the
templates
today
they're
a
much
smaller
focus
than
a
protocol
or
standard,
do
you
have
a
series?
Does?
Does
the
project
have
a
series
of
questions?
They
need
researchers
to
answer
so
that
they
could
move
forward
collaboratively
on
our
vulnerability
report.
So
I
think
this
is
something
we
can
publish
as
part
of
the
openssf
as
a
freely
available
template,
hey
here's,
some
pierce
recommended
examples
and
the
same
thing
with
a
vulnerability,
disclosure
and
handling
policy.
B
I
am
not
aware
of
any
either
linux
foundation
or
sff
participation
in
those
groups,
and
those
are
important
because
those
groups
are
where
the
really
big
decisions
are
made.
So
potentially
the
working
group
becomes
that
mechanism
that
we
can
get
that
representation
in
our
community
with
those
those
groups,
because
again
today,
I'm
in
those
groups
and
it's
vendors
and
there
is
no
no
one
looking
out
for
a
maintainer
or
small
project.
H
That's
a
really
interesting
point,
and
and
not
to
go
too
deep
down
the
rabbit
hole,
because
I
know
we
have
other
things
to
cover
today,
but
I
think
it's
very
interesting
like
when
we
were
writing
the
initial.
H
H
Standards
bodies
are
incredibly
political,
stressful
places
to
be
and
being
able
to
represent
that
with
some
force
behind
us
in
particular,
given
that
it's
a
vendor-driven
landscape
is
very
appealing,
so
that
I
I
would
just
highlight
that
as
a
very
interesting
thing
that
you've
brought
up
in
this
discussion,
because
I
to
me
like
having
done
standards
before
and
felt
the
political
weight
of
it
all.
I
guess
I
guess
like
hearing
that
that
you're
raising
this
as
as
a
direction
that
we
should
go
and
raising
that
there's
really.
H
No
one
representing
maintainers
in
in
those
groups
feels
like
a
place
where
we
could
potentially
have
some
heavy
hitting
impact
in
a
really
concrete
way,
which
is
really
exciting.
Thank
you
and
that's
all.
C
So
if
you
could
get
one
thing
from
the
open
source
community
or
from
from
our
contributing
companies
to
make
your
working
group
more
impactful,
what
would
it
be.
B
For
best
practices,
I
would
love
if
we
could
get
the
funding
request
model
created,
because
one
of
our
core
tools
is
the
fkf.
It's
a
test
suite
it
pulled.
It
does
a
lot
of
stuff,
but
it's
run
on
like
12
raspberry
pi's,
underneath
glenn's
desk
in
norway,
and
I
don't
think
that's
a
really
great
enterprise
class
infrastructure.
That's
going
to
support
us
long
term.
B
If
we
get
a
lot
of
uptick
of
adoption,
so
I
would
ask
the
attack:
can
we
get
that
process
worked
on
so
that
we
can
develop
our
business
case
and
come
forward
with
a
formal
request?
Hey
we'd
like
to
get
funding
to
put
this
in
aws
and
blah
blah
here's
what
we
think
the
cost
could
be.
So
you
know
there's
homework
on
us
to
do,
but
there's
things
like
that
in
particular
around
the
funding
for
some
of
these
tools
that
require
infrastructure
would
be
useful
for
the
vulnerability
disclosure
group.
You
want.
F
Me
to
I
can
give
a
quick
update
on
that
probe,
just
where
we
are
in
the
process,
which
is
which
is
not
as
close,
maybe
as
you
want,
but
we're
we're
working
on
it.
The
we
have
a
proposed
addendum
to
our
openness
step
charter
to
create
a
budget
committee.
F
We
have
a
couple
of
tweaks
left
in
that
and
then
we'll
have
the
governing
board
vote
on
that
and
then
we'll
get
a
budget
committee
started.
We'll
have
a
look
at
what
we
we
do
currently
have
some
fundings:
we'll
have
a
look
at
that
look
at
what
our
needs
are
and
then
also
that
committee
will
work
on
the
directed
funding
for
projects
for
tech
and
working
group
projects,
so
so
we're
working
on.
G
B
Yeah
and
that's
I
think
today,
12
raspberry
pies
is
okay,
because
we
have
not
done
a
pitched
marketing
effort
to
try
to
drive
adoption,
but
eventually
we
want
to
endorse
these
as
if
you're
an
open
source
developer.
Here's
an
awesome
set
of
free
tools
that
you
can
use,
and
I
don't
know
that
you
know
blend
cable
modem
can
handle
it.
B
B
Vulnerable
disclosure,
I
think
once
there
is
a
decision
on
kind
of
what
happens
with
the
vince
tool.
If
that's
what
we
want
to
use
there's
potentially,
I
would
need
to
work
with
the
pooling
group
to
see
if
they
would
agree
to
kind
of
maybe
participate
in
that
I
don't
know
if
there
would
be
funding
for
infrastructure
or
whatnot-
I
I
don't
know
yet,
but
once
we
have
our
white
paper,
it
would
be
great
to
whether
it's
a
press
release
or
something
in
the
next
town
hall.
B
B
C
B
B
I
would
love
to
have
more
maintainers
or
more
kind
of
large
projects
like
if
had
kubernetes
or
whatever
some
larger
project
representation.
That
would
be
helpful
because
I'm
there
marcus
from
say
shows
up
sometimes
occasionally
the
canonical
guys
do,
but
really
I
don't
see
a
lot
of
kind
of
maintainer
project
participation,
so
it
would
be
helpful
so
that
we
we
get
the
right
diversity
of
opinions.
So
it's
not
just
you
know
my
way
and
everyone
kind
of
rubber
stamps
it.
Okay.
D
C
B
Yeah,
okay,
yeah
for
sure-
and
you
know
I
know,
like
the
security
people-
that
they
already
have
some
of
this,
but
it'd
be
great
to
again
just
get
some
more
collaborations
more
opinions
on
it
and
then,
as
we
start
using
it,
it'd
be
wonderful
to
start
citing
some
of
these
communities
as
exemplars
for
other
smaller
developers.
H
Okay,
on
that
note,
maybe
just
to
raise
to
the
attack
an
idea.
So
we
have
all
these
different
working
groups
and
they
meet
pretty
frequently
because
they're,
you
know
very
much
in
the
weeds
of
working
on
doing
things
at
the
meetings.
I'm
wondering
if
it
might
be
useful
for
the
tac
to
come
up
with
some
like.
H
Where,
when
we
wanted
that
feedback,
we
could
have
representatives
from
like
a
number
of
large
projects
that
we
could
share
with
just
an
idea
that
came
to
mind
as
krop
was
talking
about
that.
A
Yeah,
it's
definitely
an
interesting
idea.
We
should
consider
how
we
could
just
kind
of
put
something
together,
informally,
and
then
you
know
when,
when
necessary,
we
have
questions
either
you
know
surveys
or
get-togethers,
and
things
like
having
that
group
of
go-to
people
would
be
actually
kind
of
useful.
I
think
so
awesome
idea.
A
A
Yeah,
thank
you
now.
This
was
really
really
really
interesting.
All
right
with
that
mike
scaveta,
you
are
up.
I
don't
do
you
want
to
present
or
do
you
want
me
to
try
to
share
the.
E
Yeah,
we
could
start
here
I'll
I'll
switch
over
at
the
right
time
to
just
do
a
show
show
a
screenshot
really
but
talk
a
little
bit
about
the
the
metric
dashboard,
but
it's
awesome
yeah.
So
hi
everybody.
I
am
not
craw,
but
this
is
my
favorite
working
group
yeah.
So
we
I'm
sorry
about
the
name.
E
I
know
the
name
is
like
super
generic.
It's
too
generic,
I'm
sorry
if
we
can
make
it
better.
That
would
be
great
the
purpose
of
the
working
group,
or
at
least
the
way
that
we
kind
of
described
it
was.
You
know,
understanding
the
threats
out
there,
collecting
data,
providing
recommendations
really
trying
to
be
hands-on
and
the
kind
of
the
connection
back
to
the
kind
of
core
stakeholders,
meaning
the
developers
that
use
a
project,
the
maintainers
of
the
project,
the
compliance
teams
that
need
to
attest
to
the
quality
of
lots
of
projects.
E
E
Let's
say
ecosystem
kind
of
looked
at
that
somewhat
methodically
talked
about
the
threats
that
can
be
injected
in
different
areas
made
a
bunch
of
recommendations
on
where
future
work
could
be
done
to
mitigate
those
risks,
and
some
ways
tried
to
try
to
rank
the
risks
as
as
best
we
could.
So
we
need
to
do
another
revision
of
that
paper.
We
haven't
really
talked
too
much
about
it,
but
especially
with
the
dependency
confusion
stuff
that
came
out.
E
E
E
E
C
A
C
G
E
All
right
cool,
so
this
is
this-
is
a
grafana
front
end.
This
is
again
it's
not
quite
a
raspberry
pi,
but
it's
like
my
you
know,
employee,
like
gratis
azure
subscription.
So
we
should.
We
should
at
least
put
on
a
raspberry
pi
somewhere.
We
can
get
you
a
raspberry
pi.
E
Just
sitting
in
a
starbucks
yeah,
so
so
what
we
have
is
I
mean
it's
a
you
know,
cards,
metaphor
and
all
that
the
important
thing
is
that
down
here.
All
of
this
data
for
the
open,
ssf
best
practices
comes
from
the
scorecard.
That's
not
scorecard
the
cii
best
practices
badge
stuff,
the
stuff
on
the
right
comes
out
of
the
scorecard
project
data.
E
E
You
know
imported
into
this,
the
ui
I'm
kind
of
struggling
with
the
the
just
the
ui
limitations
of
grafana.
But
you
know
there
are
a
good
number
of
projects.
This
should
be
everything
that
scorecard
or
the
cia
best
practices
collects
kind
of
and
that
I
can
get
to
in
bulk.
So
if
I,
my
favorite,
one
is
left
pad,
of
course,
so
you
know
left
pad,
doesn't
have
anything
for
the
cii
it
does
have.
E
We
were
able
to
calculate
some
stuff
for
the
scorecard
stuff
in
the
middle
security
reviews
was
experimental
I'll
get
to
that
in
a
sec.
So
this
is
just
one
view.
This
is
like
the
project
specific
view.
I
also
want
a
separate
view,
which
is
given
a
list
of
projects
or
given
a
you
know,
show
me
the
top
10
quote
best
projects
according
to
some
to
some
metric.
E
I
think
this
is
where
we
can
go
from
purely
objective
data
to
having
an
opinion.
So
the
objective
data
is
at
least
from
the
dashboard's
perspective-
is
that
the
scorecard
says
that
this
project
is
active
or
is
not
active,
but
it
says
that
they
do.
You
know,
do
pull
requests
in
in
the
right
way.
That's
from
our
perspective,
that's
being
objective.
When,
when
we
be
subjective,
it's
saying
you
know
there
are
14
string.
E
Padding
libraries
left
pad
is
the
best
of
the
14
because
they
because
it's
still
being
maintained
and
it
doesn't
have
any
static
analysis
findings,
whereas
somebody
else
may
say
well,
it's
actually
not
that
good,
because
it
doesn't
have
this
other
thing
and
you
can
have
differing
opinions
here.
We
haven't
gone
down
that
subjective
route
and
I
know
that
there
are
lots
of
dragons
there,
but
I
think
we
want
this
to
be
useful
to
people
and
one
of
the
problems
that
I've
seen
with
dashboards
is
you
can
give
a
whole
bunch
of
inform?
E
You
can
give
a
whole
bunch
of
data,
but
not
convey
any
wisdom
or,
or
you
know
anything
useful
to
the
to
the
reader.
So
I
want
to
try
to
avoid
that,
but
this
is
super
early
proof
of
concept.
Someone
asked
you
know:
what
do
we
need?
We
really
need
that
funding.
I
need.
I
need
a
you
know,
kind
of
people
that
can
work
on
this
more
or
less
full
time
for
a
while
to
to
kind
of
move
this
stuff
forward.
E
I
think
right
now,
that's
the
biggest
you
know
impediment
to
moving
things
forward.
Faster
is
just
that.
A
lot
of
these
things
take
a
lot
of
time
and
trial
and
iteration
and
things
and
it
it's.
You
know
we
just
need
folks
kind
of
dedicated
to
this
questions
on
this
before
I
go
on
to
the
next.
G
Sharing
questions,
but
just
a
quick
observation:
you
know:
what's
the
con,
there
was
a
question
earlier
about:
what's
the
relationship
between
the
best
practice,
the
best
practice,
the
ci
best
practices
and
the
scorecard
and
there
they
are
on
the
bottom
left
and
right,
respectively,
yeah,
so.
E
Perfect
ryan
feel
free
to
share
again,
but
until
then
the
the
next
kind
of
sub
project
that
we
were
working
on
is
the
secure
reviews.
E
Security
reviews
is
a
it's
intended
to
be
a
community
collection
of
security
reviews
that
have
been
done
against
open
source
projects.
E
So
some
of
these
are
ones
that
have
already
been
done
so
things
that
let's
say
trail
of
bits
or
cure53
or
ncc,
or
anybody
else
has
has
already
done
that
they
make
publicly
available.
We
can
link
to
that
and
say
hey
you're,
looking
for
something
on
zlib,
here's
a
trail
of
bits,
assessment
or
you're.
Looking
for
whatever
things
like
that,
we
also
want
original
reviews,
meaning
people
submit
a
pull
request
with
markdown
that
contains.
E
You
know
a
review
that
they've
done
of
a
piece
of
open
source.
We
try
not
to
be
overly
prescriptive
with
the
methodology,
but
we
do
ask
people
to
describe
their
methodology.
E
So
if
I
were
looking
at-
oh,
I
don't
know
whatever
x,
but
I
was
looking
at
it
purely
from
a
cryptography
perspective.
That's
totally
fine
and
I
can
submit
a
review
and-
and
I
just
say
this
is
only
concerning
the
you
know-
crypto
portions
of
this
code
or
I've-
I've
just
run.
E
E
So
people
submit
the
review,
it
goes
onto
the
site,
other
people
can
search
and
in
theory
we
can
expose
all
of
that
information
to
other
things
like
the
metric
dashboard,
but
also
to
the
package
managers
or
to
anybody
else
interested.
I
think
the
important
thing
is
that
that
that
these
things
are
available
and
used
and
kind
of
become
a
community
resource.
E
The
I
anticipate
the
question
of
how
is
this
different
than
the
vulnerability
disclosure
cve
stuff,
and
it's
it's
not
a
vulnerability
disclosure
vehicle.
We
make
it
super
clear
and,
like
you
know,
88
point
font
in
the
in
the
read
me
like
don't
submit
zero
days
to
us.
We
don't
want
zero
days,
we're
not
going
to
merge
them.
You're,
just
gonna.
E
Instead,
what
we're
looking
for
are
either
positive
reviews,
meaning
I
looked
at
this
thing
and
this
thing
is
safe
which,
to
my
knowledge,
doesn't
exist
anywhere
else
or
this
thing
is
dangerous
because,
let's
say
well
because
we
found
a
vulnerability
two
years
ago
and
the
author
hasn't
done
anything
about
it.
So
you
know
in
some
ways
that
is
kind
of
a
vulnerability
disclosure,
but
it's
it's
not
like
zero
day
in
the
world.
It's
it's
different.
We
have.
E
We
have
criteria
for
like
what
we
accept
or
elasticsearch
like
don't
expose
it
to
the
internet.
Things
like
that,
like
operational,
like
really
important
security,
best
practices
jennifer,
I
see
your
hand,
is
raised.
H
Yeah
I
I
love
the
idea
of
collecting
the
reviews.
The
one
place
where
I
I'd
put
forward
a
biased
opinion
is
the
idea
of
positive
reviews.
I
mean
in
in
the
ecosystem
of
vendors,
who
will
do
security
audits.
It
tends
to
be
the
less
reputable
ones
that
will
say.
Oh
yeah,
this
is
totally
secure,
don't
worry
and
what
is
more,
typical
is
to
have
like
not
something
so
normative,
but
rather
something
informative,
which
is
you
know.
The
scope
of
this
was
two
people
across
22
people
days.
H
We
looked
at
exactly
this
parts
of
the
repo
in
scope.
Was
this
part
of
the
architecture
out
of
scope?
Was
this
part
of
the
architecture
and
here's
the
findings
according
to
severity,
so
around
like
framing
something
as
positive
or
negative?
Like
yes
use
this,
don't
use
that?
I
would
I
just
want
to
put
on
the
table
that,
like
I
would
recommend.
We
not
take
that
approach,
because
the
reports
that
are
likely
to
enable
us
to
take
that
approach
are
probably
the
lower
quality.
D
H
Begin
with,
if
that
makes
sense,
but
I
I
don't
want
this
to
be
a
distraction
from
the
overall
effort
of
what
you're
doing
and
I
get
that
there
be
dragons
and
that
at
some
point
we
have
to
make
a
decision.
But,
like
the
one
place
where
I
would,
I
would
caution
us
and
if,
if
there's
one
place
where
I
could
push
back,
it
would
probably
be
this
where
it
might
make
sense
to
instead
talk
about
like
were:
are
there
any?
H
You
know
higher
critical
vulnerabilities
that
have
not
yet
been
patched
or
some
other
metric
of
like
this
is
okay
versus
this
is
not
okay.
Just
because
saying
that
something
is
is
good,
probably
actually
means
that
it
isn't
or
that
the
review
was
insufficient
to
tell
so
that's
just
my
kind
of
nitpicking.
E
Yeah,
I
I
I
totally
hear
you
so
so
there
is
a
a
review,
so
there's
a
review
process
that
goes
in
and
there's
a
quality
bar
that
we
described
and
without
I
don't
go
too
into
it,
so
I'll,
just
I'll
post
a
link
to
this
in
the
chat
as
well,
but
the
reviews
should
be
evidence-based.
It
can't
be.
You
know
I
like
project
x,
because
my
buddy
charlie
works
on
it
or
I
wrote
it
or
anything
like
that.
E
E
It's
it.
It
inoculates
you
from
what
whatever
you
know
and-
and
it
can't
really
be
a
zero
day.
E
The
the
the
the
problem
I
have
with
setting
too
high
of
a
bar
is
we'll
get,
will
basically
just
be
a
collection
of
commercially
supported
security
reviews
and
I
think
there's
there
would
be
value
in
that
too,
but
we're
talking
about
that
would
cover
approximately
zero
percent
of
the
of
the
ecosystem,
whereas
I
want-
and
I
think
I
think
the
the
value
in
a
lot
of
this
is,
if
I
said
you
know
the
end,
the
npm
is
odd.
Is
that
safe?
Has
anybody
looked
at
this
like
we
use?
E
You
know
we
use
100
million
of
these.
Like
has
anyone
looked
at
this?
The
answer
is
almost
always
no
and
changing
that
to
yeah
someone's
looked
at
it
and
they
said
it
was
fine.
Now
they
might
be
wrong
a
small
percentage
of
the
time
they
might
be
biased
and,
like
there's
all
sorts
of
these,
are
you
know
people
involved,
so
it's
not
gonna,
be
perfect
and
then,
and
for
the
ones
that
are
not
commercial
like
the
bar
is
gonna,
be
different.
E
I
think
that's
okay,
but
I
totally
hear
what
you're
saying
about
not,
but
certainly
about
like
the
lower
quality
vendors.
Just
getting
paid
for
for
a
gold
star,
I
think
the
the
solution
to
that,
though,
is
if
somebody
says
that
you
know
x
is
really
good,
because
because
awesomeness-
and
let's
say
they
trick
us
into
into
merging
the
pr
well,
somebody
else
comes
along
and
says
no
look
here
and
then
the
first
now
it's
it.
I
mean
it's
transparent,
it's
public!
E
B
I'm
sorry
I
gotta
write
my
code
in
to
log
into
github
are
any
of
my
team
participating
in
this
particular
project,
because
we
do
this
all
the
time
and
we
are
re-fining
our
current
opponent
review
process.
So
I'm
wondering
are.
B
Yes,
yeah,
we,
you
know,
we
manage
around
400,
000
components
and
versions,
so
we
have
some
subsection
of
that
done
like
this
yep,
but
we
have
a
process
for
trying
to
get
a
better
process,
but
maybe
I
let
me
go
poke
my
piecer
guy
in
the
ass
and
tell
him
to
get
some
people
to
start
showing
up
in
his
working
group.
That
would
be
absolutely
terrific.
As
an
example.
E
I
posted
the
pr
review
process
and
here's
a
link
to
the
quick
start,
which
is
just
the
form
that
we
anticipate
most
people
would
fill
out,
but
it
just
gives
you
an
idea
of
like
what
we're
looking
for
and
and
the
the
the
kinds
of
things
we
do.
We
ask
people
to
disclose
like.
Are
they
being
compensated
for
this
review?
Are
they
associated
with
the
project
things
like
that,
but.
E
So
I
I
think
over
the
next
year
six
months,
big
things
I
want
to
rev
the
rev,
the
the
white
paper
graduate
the
metric
dashboard
to
something
real
and
usable
and
see
this
kind
of
review,
screen,
review
thing
kind
of
become
a
community
and
be
sustainable
and
and
and
all
that,
but
but
to
do
that,
especially
the
middle
one.
The
metric
dashboard
resources
super
awesome.
H
Are
you
thinking
of
once
we
have
the
process
for
asking
for
resources
like
maybe
submitting
to
get
like
developers
to
help
build
the
final
version
of
it
or
do
you
have
in
mind,
you
want
it
yeah
cool.
E
Yeah,
I
I
think
a
developer
is
I
mean
it's
there's
just
as
much
time
needed
to
do
like
the
pm,
like
the
the
the
design
work
on
it
than
to
like
actually
click
the
buttons
to
make
the
thing
and
not,
and
both
of
those
are
bigger
than
a
bread
box.
So
I
kind
of
need
either
someone
who
can
do
both
or
two
people.
A
Awesome,
thank
you
guys,
so
we
have
one
minute
left.
I
hate
to
cut
this
out.
This
has
been
an
amazing
discussion.
I've
done
a
really
really
great
meeting
today,
so
just
to
kind
of
wrap
things
up,
it
seems
like
we've
definitely
had
the
objective
met
by
you
know
getting
everybody
collaborating
and
we've
got
some
future.
You
know
coordination
between
groups.
It
seems
like
this.
Clarification
was
useful
to
everyone.
So
before
we
make
everything
official
you
know
do
the
sign
off.
A
I
wanna
we'll
have
the
next
meeting
and
make
sure
that
we
don't
have
massive
conflicts.
You
know
between
those
next
three
working
groups.
I
don't
think
we
will,
but
let's
just
go
through
the
process
and
we'll
get
through
it
and
then
we'll
get
to
a
point
where
we
can
have
some
more
regular
sinks
with
working
group
leads.
A
So
if
you
guys
can
continue
to
end,
especially
in
two
weeks
for
the
next
working
group,
so
that
we
can
make
sure
that
we
don't
have
any
overlap
and
conflict
and
that
sort
of
thing-
but
this
has
been
a
great
discussion.
So
thank
you
guys
so
much
for
showing
up,
and
hopefully
we
can
keep
it
continuing
and
we'll
see
everybody.
Hopefully
here
in
two
more
weeks.