►
From YouTube: OpenSSF TAC Meeting (November 17, 2020)
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
Recording
now,
okay,
we
are
recording
all
right
so
with
that
asks,
if
you'd
like
to
take
it
away
and
introduce
us
to
cve
benchmarking.
B
I
would
love
to,
but
zoom
tells
me
that
host
disabled
participant
screen
sharing.
So
if
you,
if
host,
could
give
me
permissions,
that'd
be
great.
A
A
Okay,
it's
under
the
security
button,
apparently
bachelor
taken.
B
Right
so,
as
you
probably
all
know,
by
now
in
the
in
the
working
group
for
security,
tooling,
we've
been
working
on
an
initiative
called
cve
benchmark
cd
benchmarking,
and
I
just
quickly
wanted
to
talk
you
through
the
basics
of
it,
so
that
we
can
have
a
conversation
about
a
few
open
questions
in
a
moment
so
very
quickly.
Why
do
we
even
want
to
do
this?
B
Well,
the
question
to
ask
ourselves
is
really:
why
don't
we
want
to
use
real
data
and
the
problem
was
previously:
it
was
fairly
infeasible
due
to
a
lack
of
data,
and
now
it's
a
lot
better.
On
top
of
that,
the
alternatives
to
using
real
vulnerabilities
for
benchmarking,
our
security
tools
are
not
so
great.
B
We
know
that
real
vulnerabilities
are
not
quite
the
same
as
synthetic
vulnerabilities
and
that
synthetic
benchmark
code
bases
that
I
use
very
often
quickly
get
out
of
date.
Last
but
not
least,
we
can't
really
measure
false
positives,
very
well
on
such
on
such
code
bases.
If
you
want
to
hear
the
full
story,
then
I
of
course
invite
you
to
to
join
the
the
black
hat
conference
early
december.
I
finished
my
recording
of
my
talk
yesterday,
so
it's
all
being
edited
as
we
speak.
B
So
where
are
we
now
with
this?
We
have
a
first
data
set
for
javascript
and
typescript,
with
just
over
200
cvs
in
it
that
data
set
consists
of
both
vulnerable
and
patched
code.
So
that's
really
two
commits
per
affected
code
base
per
cve
and
some
metadata
for
every
single
one
of
those
cpus.
That
tells
us
exactly
where
we
should
expect
a
security
tool
to
flag
up
a
vulnerability.
B
At
the
moment,
we
support
eslint
node.js
can
code,
codeql
and
fortify
for
that,
and,
like
I
mentioned
just
now,
I
recorded
our
black
hat.
Talk
for
this
together
with
my
colleague,
kevin
backhouse
yesterday,
and
it
will
be,
I
guess
broadcast
is
the
right
word
on
the
9th
of
december
at
so
a
picture
speaks
a
thousand
words,
I
think,
is
the
expression.
So
this
is
the
the
web
interface
of
the
the
reporting
tool,
I'm
just
showing
you
a
screenshot
again
for
the
for
the
interactive
demo.
B
You're
gonna
have
to
join
blackout,
but
it
shows
you
for
each
of
the
tools
in
five
different
columns
in
this
case
for
every
single
cve
in
the
data
set,
whether
a
tool
detected
the
cve,
whether
the
tool
then
recognized
the
patch
or
whether
it
did
neither
and
then
it
computes
a
relative
score
and
a
ranking.
Based
on
that,
I
mean
when
you,
when
you
see
it
like
this,
it's
all
fairly
simple
and
it's
taken
us
a
fair
amount
of
time
to
get
this
data
set
together.
B
Next
steps
on
this
all
to
be
determined,
but
the
ideas
go
in
sort
of
the
following
directions.
Of
course
we
want
to
get
feedback
from
the
community,
we'll
have
the
q
a
session
at
blackhat,
hopefully
some
contributions.
B
Maybe
people
reach
out
on
twitter,
who
knows
we're
thinking
of
running
and
hosting,
regularly
updated
dashboards
with
those
results
similar
to
the
dashboard
that
I
showed
just
now.
There's
a
few
tricky
problems
to
solve
with
licensing
some,
especially
commercial
enterprise,
vendors.
Don't
like
it.
When
you
publish
benchmark
results,
we
definitely
want
to
add
more
data
to
the
data
set,
and
that
includes
data
for
other
languages,
not
just
javascript
and
typescript.
B
We
also
look
to
extend
the
tooling
so
that
people
can
seamlessly
run
this
on
cloud
infrastructure
massively
parallel,
and
that
brings
me
to
the
open
questions
that
we
discussed
in
issue
number
35
in
the
attack,
repo,
there's,
there's
three
main
ones
here:
beside
a
license,
potentially
coordinate
any
media
outreach
if
we
want
to
do
any
around
black
hat
and
ideally
would
have
these
two
questions
answered
before
black
hat
itself.
B
A
few
days
before,
there's
one
open
question
about
the
ownership
of
the
repo
just
a
sort
of
technical
ownership
to
transfer
that
to
the
linux
foundation,
and
I
previously
suggested
that
we
do
that
after
I
recorded
the
talk,
but
the
team
are
still
in
process
of
actually
tweaking
some
of
those
repositories.
B
So
my
new
proposal
would
be
to
do
that
just
after
blackout
so
sort
of
around
the
9th
10th
of
december
or
a
bit
later
I
don't
really
mind
so,
let's
do
maybe
some
questions
and
then
get
to
maybe
answering
some
of
those
questions.
F
B
Yep,
okay,
so
the
in
this
screenshot
I
have
deliberately
and
also
for
black
hat
I've,
deliberately
taken
out
the
names
of
the
tools.
I
didn't
want
this
to
turn
into
a
vendor
pitch
of
any
sort.
I
didn't
want
to
give
anyone
any
advice
on
on
which
tools
they
should
be
using
or
shouldn't
be
using.
B
So
for
this
particular
comparison,
we
used
all
the
tools.
Currently,
where
did
I
put
the
list
of
tools
I
put
it
somewhere
here
we
go.
We
use
all
of
eslint
node.js,
gun,
codeql
and
fortify,
and
I
think
for
one
tool.
We
use
two
different
versions.
F
G
Hey
boss,
two
questions,
so
one
is
you
mentioned
that
so
this
tool
runs
against
a
a
data
set
of
real
cves
and
you
can
contrasted
that
to
running
against
synthetic
data,
and
so
I
wonder,
are
there
other
other
tools
similar
to
cve
benchmarking
out
there
that
run
against
synthetic
data.
B
Yes,
so
synthetic
data
out
there
there's
a
lot
of
deliberately
vulnerable
repositories,
a
very,
very
sort
of
famous
and
funny.
One
is
oh
wasps
juice
shop,
which
does
exactly
what
it
says
in
the
tin.
If
you're
allowed
to
pun,
it
sells
juice.
But
it's
not
actually
some
news.
B
It's
a
web
application
that
you
can
hack
and
you
can
then
test
your
own
tools
to
see
whether
they
would
have
found
all
of
these
cross-site
scripting
vulnerabilities,
sql
injection
vulnerabilities
and
so
on,
and
there's
many
of
such
deliberately
vulnerable
code
bases
on
github.
D
If
I
can
jump
in
and
add,
also
nist
has
a
whole
project
summate
that,
among
other
things,
has
a
large
set
of
mostly
synthetic.
There
are
a
few
real
ones,
but
it's
mostly
synthetic
test,
suites
the
big
subset,
something
called
juliet,
which
is.
H
B
D
Bunch
of
synthetic,
which
is
entirely
synthetic.
B
Yeah,
so
actually
the
julia
test
case
test
cases
make
an
appearance
in
the
black
hat
talk,
so
kevin
backhouse.
My
colleague
from
the
security
lab,
actually
shows
you
a
few
of
those
vulnerabilities
to
explain
what
the
problems
are.
I
mean,
of
course,
doing
these
synthetic
benchmarks
is
better
than
doing
nothing
at
all,
but
we're
basically
suggesting
that
this
is
even
better.
G
Okay,
another
question:
so
you
have
a
set
of
tools
that
that
this
works
with.
Are
you
allowing
others
to
you
know,
use
their
provide
their
own
tools
that
that
can
also
be
used
in
this
testing
or
even
if
they
don't
provide
them
and
make
them
public,
but
maybe
they
just
use
your
your
data
yeah.
B
That's
definitely
animation
on
this
page
over
here.
We
encourage
folks
to
to
write
their
own
tool
drivers
as
we
call
them.
Those
are
very
small.
I
mean
the
whole
benchmarking
framework
has
been
set
up.
Very
sort
of
it's
been
designed
to
support
exactly
the
use
case
that
you
mentioned
just
now.
It
takes
you
about
200
lines
of
code
to
write
a
new
driver
typically,
and
then
you
can
basically
integrate
whatever
tool.
You
would
like
to
benchmark
whether
it's
grep
or
a
commercial
tool,
or
you
name
it.
G
B
Of
course,
if
I
mean
if
you're
looking
to
wait
until
after
blackout
anyway,
then
I'm
happy
to
share
you
with
share
you
both
the
give
you
both
the
black
hat,
slide
deck
and
this
one
yeah
the
blackout.
One
is
a
bit
longer.
Obviously,.
G
I
B
D
I
I
Sorry
so
I
think
the
policy
that
we
have
says
apache
is
our
acceptable
license
and
we
could
ask
the
governing
board
for
an
exception.
Here
is
apache
going
to
be
fine
or.
B
There's
I've
gotten
a
few
different
sort
of
messages.
Actually,
the
faq
on
the
open
ssf
website
says
that
every
working
group
is
free
to
choose
their
own
license.
B
Indeed,
then,
in
the
in
the
issue
number
26,
we
discussed
that
there
might
be
a
single
license
for
all
repos,
I'm
not
entirely
sure
what
what
the
policy
is
or
whether
there
is
a
policy
at
all.
I
B
B
Yeah
I
I've
been,
I
think
I
only
just
saw
that
10
or
10
minutes
ago.
So
within
github
we
have
a
preference
for
mit
simply
because
literally
all
of
our
repos
are
rmit
licensed.
So
that
would
be
the
easiest
thing
from
our
side.
I've
asked
our
legal
team
for
for
an
opinion,
but
haven't
heard
that
quite
yet,
how
strong
is
the
preference
of
the
foundation
to
use
apache.
G
Yeah
so
I'll
jump
in
on
that,
so
we
haven't
yet
had
a
case
where
we've
taken
to
the
governing
board
to
ask
for
an
alternate
license.
So
you
know
I'm
happy
for
this
to
be
our
first
case.
For
that
I
don't
know
right
off.
If
there
will,
if
there
will
be
particular
concerns
it,
you
know
it
might
be
a
simple.
G
H
I
I
think
I
would
support
taking
this
if
that,
if
that
makes
sense
guys,
and
then
I
would
just
support,
having
also
just
clarity
here
in
general
right
if
there
are
multiple
licenses
that
are
okay,
then
let's
confirm
that
the
only
reason
we
would
not
do
this
is
the
timeline.
I
think
that
baz
has
here.
J
D
That
will
require
signatures
and
coordination
with
a
number
of
folks.
A
Yeah-
and
I
remember
the
original
discussions
around
choosing,
apache
was
kind
of
just
more
of
a
like
everybody
kind
of
went
well.
Apache
is
good
yeah,
I'm
good
with
that.
That
seems
good,
and
it
was
more
of
like
a
default
with
an
acknowledgement.
Yeah
there's
other
ones
like
mit
and
stuff,
and
it's
okay,
we'll
just
we
want
to
know
so
that
somebody's
not
out
there
choosing
gpl
or
something
for
a
project
and
introducing
some
comp
complications
there.
So
I,
my
guess,
is
that
this
is
probably
okay
but
yeah.
B
Yeah,
I'm
actually
speaking
to
our
legal
team
on
on
friday,
about
something
unrelated,
but
I
can
just
quickly
sort
of
shoehorn
this
in
is
it.
Is
it
too,
too
soon
to
hope
for
a
decision
by
say
the
fourth
of
december,
so
we
can
just
put
the
right
license:
files
in
the
repos
before
we
open
source
them.
G
So
our
next
is
on
the
3rd
of
december,
so
I
think
we
can
for
sure
have
a
decision
by
then
at
that
meeting.
Yeah.
A
K
I
would
agree
with
ryan
on
that,
especially
if
we're
okay
with
apache
as
as
stated
mit,
is
very
similar
in
spirit.
So
it
would
be
nice
to
just
be
clear
on
that
only
because
I
think
things
will
keep
coming
back
to
us
for
this
decision
and
probably
in
that
conversation,
we
may
also
want
to
talk
about
things
on
the
other
kind
of
end
of
the
spectrum
of
licensing.
What
we
want
to
do
around
folks
that
want
to
use
gpl,
because
it
will
inevitably
come
up
for
us.
G
Does
someone
want
to
take
the
lead
in
summarizing
and
then
sending
an
email
to
the
governing.
D
Board
on
likes
on
licenses
in
general,
or
about
these
two
issues.
G
Well,
we
so
we
should
definitely
cover
these
two
issues,
so
we
should
talk
about
mit
and
then
so
those
are
the
more
critical
ones
and
then
we
probably
want
to
address
the
broader
question,
but
we
could
do
that
separately.
So
we
could
we
could.
I
could
ask
for
two
different
volunteers.
If
that
helps.
D
I
mean
I'd
be
happy
to
to
write
up
something
for
the
governing
board.
I
mean
I,
I
suspect
the
issues
are
essential
to
saint.
You
know.
We've
got
two
different
projects.
One
is
proposing
mit,
which
already
has
an
mit
license.
Is
it
okay
to
approve?
There's
no
issue
from
the
linux
foundation's
point
of
view.
G
D
A
I'd
be
interested
to
see
it,
I
was
going
to
volunteer
to
draft
as
well,
but
I
I'm
not
a
member
of
the
governing
board.
So
then
it
might
make
conversations
difficult.
D
I'm
not
I'm
not
a
member
of
the
governing
board,
but
I
can
write
emails.
A
B
So
the
the
other
two
things
on
on
my
list
were
just
to
make
sure
that
we
talk
about
the
org
ownership
and
potential
media
outreach.
That's
the
only
things
I
wanted
to
make
sure
we
talk
about.
A
Let's
talk
about
ownership.
Actually,
I
know
someone
was
asking
what
the
repo
name
is
and
it's
not
in
ossf,
so
you
want
to
discuss
what
your
thoughts
were
around
there.
I
know
I
saw
a
couple
of
posts
about
it.
B
Yeah,
so
the
the
only
reason
for
it
not
being
in
the
ossf
org
itself
is
because
there
is
one
repository
for
every
cve
in
the
data
set.
So
that
means
that
today
we
have
212
repositories
for
just
one
perceive
e
plus
one
of
tooling
repository,
and
that
will
quite
quickly
grow.
If
everything
goes
to
plan
and
we
didn't
want
to
fill
up
the
the
ocf
with
all
these
loose
cve
repo's.
B
That's
correct,
yes,
what
we
do
is
we.
We
basically
create
a
fork
for
every
repository
in
the
data
set,
noting
that
not
all
code
that
we
have
cvs
for
lives
in
git,
some
of
it
lives
on
floppy
disks
and
some
of
it
links
on
on
on
on
subversion.
B
So
that's
why
we
wanted
to
create
a
mirror
of
it,
and
every
repository
is
basically
one
vulnerable
code
base
has
two
branches
on
it.
One
tagged
batched
and
one
tagged
vulnerable.
I
So
I
guess
what's
the
question
here
I
mean
this
approach
seems
fine.
I
think
we,
the
process
to
get
it
kind
of
transferred
over,
is
just
to
add
the
linux
foundation
or
lindsay
directly
to
the
org,
and
then
I
think
they
can
take
care
of
pulling
it
in
and
hooking
up,
automation.
H
Think
the
problem
is
the
problem
practically
is
that
we'd
be
adding
212
or,
however
many
repos
to
the
org,
so
the
average
user
who's
trying
to
come
and
read
about
the
ossf
now
has
212
random
repos
about
cvs,
lookout.
B
And
then
I
will
indeed,
after
black
hat
after
the
conference
is
finished,
put
the
the
right
permissions
in
place
and
then
someone
else
can
take
it
from
there.
What
I
want
to
prevent
from
happening
is
that
we
accidentally
have
a
glitch
in
the
in
the
next
two
weeks,
leading
up
to
black
hat,
meaning
that
we
can't
open
source
it
or
that
we
can't
actually
get
the
work
done.
So
I'd
rather
do
the
ownership,
after
black
hat,
rather
than
before,.
B
Cool
last
item
on
the
list
is
whether
we
want
to
do
any
type
of
media
outreach
from
the
open,
sf's
sort
of
point
of
view.
I'm
not
quite
sure
how
that
would
work,
and
I'm
hoping
that
someone
in
this
group
might
know.
A
There
has
been
discussion
of
that
as
of
yesterday,
so
there's
currently
and
k
and
others
feel
free
to
jump
in
and
add
details
here,
but
we
were
discussing
in
the
planning
committee
yesterday,
the
formality
of
the
process
of
reaching
out
and
doing
blog
posts
and
and
tweets,
and
things
like
that
and
so
right
now
I
believe,
there's
the
plan
is
to
form
a
marketing
committee
dan,
I
believe,
put
forth
a
proposal.
That's
gonna
go
out,
so
I
think
in
the
in
the
short
term,
probably
coordinating
with
kay.
G
Yeah
and-
and
I
would
just
recommend
we-
we
do
it
through
the
planning
committee-
well
we're
waiting
for
the
more
formal
process.
So
ultimately,
the
governing
board
has
responsibility
for
marketing,
and
the
planning
committee
is
just
a
good
place
to
kind
of
vet
things.
So
we
can
so
what
you,
what
you
can
do
and
what
we've
done
for
other
projects
just
to
you
know
help
along
the
way.
So
so
we
have
a
blog,
and
so
we
can,
you
know,
add
an
item
to
the
blog.
G
We
can
also
tweet
about
it,
and
then
we
can
send
an
announcement
out
to
the
announcements
at
at
our
open,
ssf
mailing
list.
So
those
are
the
kind
of
things
that
we've
done
for
marketing
before
and
you
could.
You
can
send
email
to
to
me
directly
and
I
can
coordinate
with
lindsay,
but
I'd
also
want
to
just
run
it
through
the
people
on
the
planning
committee
to
make
sure
everyone's
aware.
K
So,
if
I
can
add
to
this,
I
think
part
of
what
boss
is
asking
about
is
related
to
coordination
with
a
pr
firm.
So
typically,
when
giving
a
talk
at
black
hat,
for
example,
especially
when
releasing
a
tool
or
disclosing
major
vulnerabilities,
there
tends
to
be
embargoed
conversations
with
mainstream
or
special
tech
media
journalists,
so
like
usually
either
a
company's
in-house
pr
firm
or
an
organization's
external
pr
firm.
K
So
in
our
case,
I
guess
it
would
be
jennifer
clower,
who
did
the
press
releases
for
us
will
coordinate
with
journalists,
so
basically
they
serve
as
a
middleman,
to
communicate
the
overview
of
the
upcoming
research
to
interested
journalists
and
to
set
up
some
of
the
media
interviews.
So
I
think
I
think
one
of
the
questions
that
we
have
to
address
is:
do
we
as
open
ssf
have
like
funding
or
support
for
pr
beyond
the
press
releases
like?
K
Are
we
able
to
make
use
of
that
external
media
firm,
or
would
it
make
sense
for
the
authors
of
the
tool
to
work
with
their
company's
like
internal
pr
firm,
so
we
either
need
to
if
we
know
that
we
can
share
that
information
now
or
we'll?
Probably
just
have
to
ask
lindsay
about
what
our
options
are.
G
That's
is
it,
I
think,
so.
You've
got
some
information
in
the
in
the
issue.
Maybe
if
you
can
just
you
know,
send
a
quick
email
to
to
me
and
to
lindsay
and
then
we'll
sort
it
out
from
there.
G
B
Sure
thing
I
will
definitely
do
that-
probably
not
today,
more
likely
tomorrow,
the
day
after,
but.
H
B
Great,
and
indeed
I
mean
if,
if
we
decide
as
as
the
open
serve
as
an
organization,
we
don't
want
to
make
make
a
big
song
dance
about
this
and
that's
absolutely
fine
as
well.
It's
just
something
to
make
sure
that
we
coordinate
rather
than
yeah,
do
the
same
effort
twice.
G
I
think
we'd
like
to
so
we'll
we'll
proceed
on
that
assumption.
Sometimes
it's
working
yeah
we're
just
working
through
the
process
for
it.
B
All
right
any
more
questions
from
me,
because
I
can
leave
you
to
your
meeting.
If
that's
the
best
next
thing
to
do.
D
B
Yeah
and
thank
you,
everyone
for
your
support
in
this
one.
It's
been
yeah,
it's
been
really
great
to
work
with
you
all
and
the
other
partners
in
the
working
group.
B
A
Okay
with
that
we'll
carry
on,
let
me
share
the
agenda
here.
We've
got
coming
up.
A
Okay,
can
anybody
see
my
screen
now
all
right
so
again,
thank
you
bass
for
that,
so
real,
quick,
the
cii
best
practices
badge.
I
think
this
should
go
fairly
quickly.
I
think
everybody
saw
over
email
that
the
working
groups
actually
got
together
and
discussed
this
and
came
up
with
the
plan
themselves
and
we
fortunately
have
krog
here
today.
Robert,
are
you
still
on
the
way.
A
You
like
to
summarize
real
quick
for
everyone.
What
you
and
michael
scoveta
had
decided
to
do.
F
Yeah
we
had
a
chat
via
email
on
michael
and
zav,
and
I
and
we
agreed
that
the
infrastructure
piece,
the
actual
kind
of
dashboarding
component
best
lies
within
the
the
metrics
group
and
that's
not
a
task
they're
looking
to
grapple
with
yet
that's
kind
of
a
future
thing
and
then
the
actual
kind
of
developer,
good
practices
that
are
at
the
core
of
what
the
badging
project
is
about.
F
That's
going
to
be
not
curated,
but
we're
going
to
have
participation
from
the
developer,
best
practice
working
group
to
help
maintain
that
and
help
kind
of
steer
those
things
and
then,
at
some
point
in
the
future,
we'll
have
some
conversations
about.
Do
we
need
to
technically
move
repositories
around
or
you
know
what
do
we
need
to
do
to
help
the
metrics
project
kind
of
start
to
be
able
to
advertise
these
types
of
information
or
leverage
the
data?
That's
inside
the
repo,
so
yeah
good
discussion.
F
I
think
we
came
to
an
agreeable
and
logical
kind
of
separation
of
duties
here.
A
G
So
it's
confusing
to
to
me
at
least
about
the
kind
of
the
charters
of
the
two
groups,
and
so
the
charter
for
the
the
best
practices
group
seems
to
be
around
education
and
someone
has
a
keyboard.
That's
super
loud
and
okay
anyway.
So
the
charter
for
best
practice
is
around
education
and
training.
G
If
you
read
the
charter
and
then
the
charter
for
the
for
the
identifying
security,
that's
threats,
groupers
around
security,
metrics
and
providing
information,
and
so
I
I
I
it
just
feels
to
me
like
we're
not
being
clear
about
you
know.
If
something
is
a
metrics
related
project
it
feels
like
it
should
be.
In
the
group.
That's
focused
on
metrics
and
if
it's
you
know,
education
and
training,
it
should
be
in
that
group.
G
But
you
know-
maybe
that's
maybe
that's
just
me,
but
it
seems
like
it's
worth
just
having
that
conversation
as
well.
So.
G
Into
what
you
had
on
your
as
another
another
discussion,
topic,
ryan.
A
A
I
think
it
was
the
the
meeting
that
I
was
not
at
the
attack
mean
I
was
not
at
when
I
was
sick
was
when
the
groups
came
in
and
kind
of
discussed,
and
there
was
a
lot
of
comments
that
I
heard
in
there
that
were
that
people
who
had
gone
through
the
badging
program
actually
felt
like
it
wasn't
so
much
a
metric
gathering
of
they
were
getting
a
score,
proving
that
their
project
did
something.
A
But
it
was
actually
more
educational
for
them
that,
as
they
went
through
the
process,
they
were
learning
about
the
best
practices
that
they
were
supposed
to
be
doing.
And
so
my
understanding
of
that
was
that
that's
kind
of
why
that
aligns
a
little
bit
better
because
it's
defining
best
practices,
and
so
the
the
badging
program
is
doing
that.
But
then
there
is
a
data
piece
of
it
that
will
feed
to
the
metrics
dashboard.
A
But
as
far
as
owning
of
the
program
and
updating
what
those
best
practices
are,
it
seemed
like
the
groups
decided
it
made
more
sense
to
sit
within
best
practices,
but
then
that
data
will
get
fed
to
the
to
the
metric
group.
So
that
was
my
understanding
of
it
and
that's
that
to
me
helped
me
reconcile
the
two,
because
I
agree
with
you
initially
as
well,
but
that
kind
of
turned
the
turn
the
corner
for
me.
So
of
course,
other
people
curious
what
your
thoughts
are
and
how
you
guys,
even
if
there's
controversy
here.
C
Luke
here
I'm
perfectly
okay
with
the
proposal.
I
think
we
should
move
forward
with
this
and
let
the
guys
get
to
work.
A
So
I
think
it's
a
little
different.
Actually,
in
fact,
it
might
even
be
worse
than
what
you're
describing
in
the
sense
that
there's
one
repo
for
best
practices
as
far
as
they
have
a
training
programs
that
they
work
on
and
then
the
cii
best
practices
that
david
wheeler
is
in
charge
of
is
a
whole
separate
thing
entirely,
and
that
code
hasn't
even
moved
over
to
ossf
and
then
separately.
There
is
the
identifying
security
threats
working
group
and
they
have
a
repo
for
their
dashboard
project
and
their
metrics
project.
A
So
those
things
are
very
distinct
right
now,
but
I
think
code
wise.
It
does
make
sense,
but
as
krobe
was
mentioning
going
forward,
there
may
need
to
be
some
sort
of
integration
to
pull
some
of
those
things
together.
Code,
wise,
but
also
you
know-
I
haven't
worked
on
a
number
of
complex
projects.
It's
not
uncommon
right
to
have
one
sort
of
centralized
project
that
pools
for
multiple
repos
to
build
together.
So
you
have
the
full
package
and
keeping
them
separate
might
allow
people
to
focus
on
specific
areas
without
it
too
intimidating.
I
L
L
L
F
At
least
as
michael
described
it,
they
didn't
that
wasn't
the
highest
in
their
backlog
that
they
wanted
to
address
at
the
moment.
That
was
a
future
problem
they
wanted
to
tackle.
We
have
a
group
of
people
that
are
very
enthusiastically
participating
with
the
best
practices
to
help
curate
standards
and
requirements
and
kind
of
help
coordinate
training.
F
So
you
know,
there's
an
immediate
boost
there,
that
we
can
help
david
wheeler
kind
of
helped
curate
and
augment
what
the
best
practices
badge
program
is
encompassing,
and
we
agreed
that
at
some
future
point
if
it
makes
sense
if
the
metrics
team
wanted
to
take
ownership
or
needed
to
have
a
more
involvement
that
that
was
a
definitely
a
possibility,
and
all
of
this
ultimately,
from
my
perspective,
is
up
to
dave
wheeler,
if
you
know
he's
the
kind
of
the
leader
of
the
project.
If
he
wanted
to
see
that
happen
great.
D
Yeah
my
understanding,
what
this
really
means
is
that
I'm
I'm
leading
the
best
practices
badge
work
and
I
show
up
as
part
of
the
best
practices,
working
group
and
coordinate
with,
and
we
work
back
and
forth,
and
I
also
intend
very
much
to
work
with
the
metrics
group.
In
fact,
I've
already
done
that
dan
lawrence,
as
I've
previously
talked,
we
made
some
changes
to
best
practices
badge
to
make
sure
the
metrics
could
be
easily
extracted
in
ways
that
they
wanted.
D
C
A
Yeah,
I
completely
agree
with
that.
So
I
think
in
that
spirit
too,
like
I've
said
before,
like
working
groups
are
kind
of
arbitrary
lines.
Right
and
ownership
are
sort
of
lines
in
the
sand
that
are
blurry
at
best
right,
so
everybody's
working
on
these
projects,
but
I
think
we
should
organize
them
in
a
way
that
makes
sense
technically
and
if
that
works
great,
like
who
the
quote
owner
is,
is
less
relevant.
A
I
think,
if
we
all
agree
that
the
plan
so
far
for
the
groups
to
move
forward
makes
sense,
let's
just
let
them
go
and
do
that
and
I
think,
as
these
things
come
up,
the
working
groups
can
sort
them
out.
But
from
my
perspective,
as
attack
as
the
tag,
I
don't
feel
like
we
have
to
solve
that
for
them.
I
think
that's
up
to
the
working
groups
to
decide
unless
we
see
some
sort
of
conflict
between
the
groups
right
where
we're
duplicating
work
or
something
like
that.
Maybe
we
we
have
an.
H
D
M
A
I
don't
think
we
need
to
vote
personally.
It
sounds
like
everybody's
in
agreement.
I
think
the
working
groups
have
kind
of
made
that
decision,
which
brings
up
a
broader
question.
A
So
it's
sort
of
the
next
item
after
the
next
one,
but
that's
role
of
attack
and
process
discussion.
So
we
can
talk
about
that
real
quick
if
it
makes
sense.
My
personal
opinion
on
this
is
that
I
think
we
should
let
working
groups
decide-
and
I
think
I
said
this-
an
email
a
week
or
two
ago
as
well,
but
working
groups
should
be
the
ones
driving
the
change
and
the
tax
should
be
aware
of
it.
A
A
A
A
All
right,
so
the
next
thing
on
the
agenda,
the
technical
strategy
update
I'm
just
going
to
touch
on
this
real
quick.
So
I'd
like
to
try
and
leave
some
time
for
these
charter
template
discussions
at
the
end.
If
we
have
time
so,
I
sent
out
a
mail
last
week,
sort
of
detailing
where
I
think
our
strategy
will
go,
but
by
no
means
am
I
the
decision
maker
on
this.
Is
it
just
thoughts
on
paper
stake
in
the
ground
to
have
a
conversation,
so
I
identified
a
few
themes
on
that.
A
What
I'd
like
to
talk
about
is
what
do
what
does
attack
think
as
far
as
process
to
get
us
to
deciding
what
that
ultimate
strategy
should
be
for
the
next
year?
Are
we
happy
with
it?
How
detailed
do
we
want
to
get
so?
I'm
opening
this
up
for
for
conversation,
because
I
think
there's
a
lot
of
different
opinions
here
and
I'd
really
like
to
kind
of
hear
where
folks
are
are
at
with
their
thought
process,
and
then
we
also
have
a
press
release
coming
out
at
the
end
of
january.
I
So
I
read
the
mail
in
the
dock
and
a
little
confused
dave
and
I
emailed
a
little
bit
on
the
thread
about
it.
I
guess,
like
I'm,
a
little
confused
at
the
kind
of
structure
and
approach
there
like
we're,
proposing
a
bunch
of
work-
and
you
know,
there's
a
bunch
of
text
in
there
about
picking
things
to
work
on,
but
who's
going
to
be
working
on
these
things.
A
Oh
yeah
yeah;
no,
that's
definitely
not
the
intent.
So
let
me
clarify
that.
So
I
think
what
I
think
what
we'd
like
to
do
is
basically
start
with.
What
we
decide
is
the
strategy
right,
so
we're
going
to
focus
on
educational
type
projects
along
with
providing
metric
things
and
we'll
be
proactive
with
security
reviews.
You
know
that
type
of
stuff,
whatever
those
themes
are
so
as
attack,
we
can
decide
that's
kind
of
our
focus
for
the
next
year
and
then
that
document
that
david
graciously
put
together
is
really
like
a
backlog.
K
I
really
like
the
idea
of
based
on
some
of
the
things
outlined
in
this
document
us
having,
maybe
one
like
dedicated
session
of
the
attack,
where
we
talk
about
the
overall
space
in
which
we're
working
the
things
that
we
had
been
interested
in
achieving
when
we
initially
joined
this
group,
some
of
the
other
things
that
we
see
happening
that
are
related
in
the
industry
and
kind
of
just
mapping
the
territory
and
seeing
what
is
possible.
K
Certainly
people
should
be
kind
of
grassroots,
bringing
forward
things
they
want
to
work
on
with
us,
but
I
think
it's
definitely
not
a
waste
of
time
for
us
to
spend
an
hour
or
whatever
it
is
together
discussing
where
this
could
potentially
go
and
what
we
could
love
to
see,
because
one
thing
I've
really
learned
in
my
current
role
is
that
as
much
as
you
want
to
always
empower
sort
of
bottom-up
kind
of
raising
of
ideas,
there's
something
to
be
said
for
having
a
vision
and
painting
that
picture
for
people.
K
So
I
think
it
could
be
valuable
for
us
to
to
come
up
with
an
overall
idea
of
what
we'd
like
to
achieve
and
put
that
vision
out
there.
Perhaps
as
a
short-written
artifact
or
presented
at
a
town
hall,
or
something
like
that,
because
I
believe
it
can
inspire
people.
A
Thank
you,
jennifer
any
other
thoughts
or
opinions
on
the
approach
or
having
the
strategy
or
not
or.
H
I
like
having
a
strategy,
I
like
saying
here's
where
we're
trying
to
go:
we're
never
going
to
be
able
to
do
everything.
That's
in
that
document
like
anytime,
soon
exactly.
D
D
Yeah
to
be
fair,
it
says
that
right
at
the
beginning,
there
is
no
way,
but
I
think
there
is
a
reason
to
do
this
document.
For
no
other
reason,
then
I
think
some
very,
very
good
ideas
have
been
posted
by
many
different
folks
and
it's
easy
to
lose
sight
of
that.
So
I
think
nothing
else.
The
the
here
it
is
in
one
place,
and
now
you
we
won't,
those
ideas
won't
be
lost.
I
think,
will
be
comforting
for
a
lot
of
people
and
hopefully
inspirational.
I
Yeah
I
want
to
second
that
part.
I
guess
I
could
see
just
publishing
this
as
a
wish
list
or
like
a
list
of
unsolved
gaps
that
we've
identified
and
kind
of
publishing
that
as
an
artifact,
and
I
think
that
would
be
pretty
good
and
useful
for
people
to
see
and
maybe
get
inspired
by
and
jump
off
on
and
actually
start
working.
A
Well,
so
do
do
folks
want
to
do
we
want
to
keep
this
in
that
document.
Do
we
want
to
change
the
format
of
it
or
move
it
to
github
as
an
md
file
or
a
list
of
issues?
How
do
folks
really
want
to
because
the
document's
great-
and
I
don't
want
to
lose
any
of
the
details
in
there,
but
in
terms
of
making
it
maybe
more
approachable
for
people
to
find
work?
Are
we
comfortable
with
how
it
is
or
do
we
want
to
move
it
somewhere
else?.
E
I
think
we
need
to
move
to
a
place
where
each
one
is
separated
out
so
that
maybe
we
can
even
let
vote
on
it
on
it,
so
that
we
can
even
tie
back
to
the
funding
initiative.
We
have
right
if
a
organization
or
a
company
really
interested
about
idea,
they
could
maybe
come
forwards
to
fund
that
project,
so
I
think
keeping
somewhere
like
where
each
individual
is
a
a
separate
entity.
D
If
I
can
push
back
on
that
a
little
bit
the
problem,
is
it's
actually
going
to
be
quite
a
bit
of
work
to
create
a
whole
bunch
of
issues
one
for
each
of
these,
and
when
you
create
issues
of
course,
they
get
immediately
atomized
into
just
that.
One
issue:
you
don't
see
the
bigger
picture.
A
Yeah,
so
maybe
like
hybrid
kind
of
what
you
both
are
suggesting
of,
we
keep
this
document.
Maybe
we
change
the
structure
a
little
bit,
just
so
maybe
table
of
contents
or,
however,
we
make
it
more
approachable
for
people
to
find
things
and
then
like
what
you're
saying
david
and
what
jennifer's
saying
we
could
actually
proactively
pull
out
a
few
that
say
this
is
the
wish
list
for
our
strategy
for
2021.
D
I
A
So
it's
not
an
assigning
work
right.
It's
like
jennifer's
number,
it's
aspirational
right.
It
should
say
these
are
the
areas
that
we
would
like
to
see.
Work
happen
because
in
our
strategy
of
trying
to
target
these
things,
the
strategy
we
have
yet
to
decide
on
these
are
projects
that
would
help
further
bolster
that
strategy.
And
so
we
would
like
to
see
people
work
on
those
things.
A
But
again
it's
open
source
right,
so
anybody
can
work
on
it
or
not,
but
we're
not
we're
not
saying
somebody
has
to,
but
we
would
like
them
to
and
it
could
be
new
people
from
the
community,
see
that
and
say:
hey,
I'm
really
good
at
that
and
they'll
come
help.
Do
that
or
people
with
an
existing
working
group
say:
oh,
that
seems
related
to
something
I'm
doing
they
could
pull
it
in.
H
If
people
have
work
that
they're
currently
doing
they
can
so
that's
an
edit
to
the
file
and
link
out
to
that
work,
whether
that's
an
issue
in
one
of
the
repos
and
issues,
you
know
somewhere
else
et
cetera,
so
we
at
least
have
a
central
place
to
see.
What's
going
on
and
then
separately
around
the
idea
of
kind
of
like
priorities
for
2020,
that's
almost
to
me
sounds
like
a
blog
post
or
something
for
2021.
That
sounds
like
a
blog
post
or
something
like
that.
H
K
Yeah,
I
would
love
that
too
maya
because,
like
I
feel
that
we
haven't
spent
enough
time
on
this
kind
of
thing.
Yet
I
know
that
early
on
in
the
open
source
security
coalition,
like
that,
the
way
we
ended
up
with
the
six
groups
or
five
groups
that
we
ended
up,
having
was
at
the
very
beginning
before
any
of
us
had
met
each
other.
We
filled
in
a
survey
and
nico
and
hawa
were
great
at
kind
of
filtering
through
that
and
identifying
themes
and
things
like
that.
K
But
I
don't
know
if
we've
ever
since
that
time
really
stepped
back,
and
certainly
not
as
the
new
larger
group
that
we
are
now
step
back
and
had
a
real
conversation
about
what
we
want
to
achieve
and,
of
course,
like
a
lot
of.
It
is
implied
by
the
work
that
we
do.
But
I
mean
I
I
don't
know.
I
feel
like
a
lot
of
the
conversations.
We've
had
have
been
very
tactical
thus
far,
and
I
would
really
value
if
people
are
interested.
K
Obviously,
if
people
are
not
interested,
don't
let
me
waste
your
time
with
it
but
like
if
it
was
something
that
we
had
shared
interest
in.
I
think
it
would
be
a
valuable
way
to
spend
an
hour
or
whatever
amount
of
time
bringing
everyone
that
are
in
this
meeting
together
and
just
talking
about
you
know,
technical
and
strategic
things
we'd
like
to
achieve.
A
Yeah,
I
absolutely
agree,
and
that
was
very
much
the
intent
of
starting
off
with
that
email.
So
I
wanted
to
have
this
conversation
now
and
then,
if
we
can
evolve
or
work
on
this
over
email
in
the
next
two
weeks,
people
can
produce
documents.
How
we
want
to
do
that
and
then
in
the
next
hack
meeting,
absolutely
I'd
like
to
get
us
to
a
point
where
we
can
start
defining
what
that
strategy
is
either.
You
know,
distilling
it
down
to
a
phrase
or
a
paragraph.
A
You
know
whatever
people
are
comfortable
with
and
how
we
can
articulate
that.
But
I
think
that
that
is
the
right
thing
to
do.
We
look
at
what
the
existing
working
groups
are.
What's
the
themes
there
and
then
what
is
additional
work
that
we
might
want
to
go
and
then
that
performs
the
strategy?
Are
people
comfortable?
With
that?
Do
we
want
to
take
the
start
of
the
eol?
I
wrote
last
week
and
continue
the
conversation
on
there.
A
G
Let
me
if
I
can
just
chime
in
not
at
the
detail
level,
but
at
the
you
know
what
it
is
that
we
so
for
we're
on
a
cadence
where
we
every
three
months
we
are,
you
know,
planning
to
do
press
releases
and
town
halls
and
so
for
our
next
press
release,
I'm
hoping
that
we
can
have
a
technical
vision
that
so
a
document
that
we're
willing
to
present
kind
of
to
the
world.
That
says:
here's
the
open,
ssf
technical
vision
and
it
is
kind
of
a
longer
term
vision.
G
So
you
know
maybe
a
you
know.
We
want
to
talk
about
one
year,
but
also
you
know,
maybe
five
here:
here's
where
we
here's.
Where
we
see
the
openness.
Is
it
going?
Here's
our
vision
and
then
we
can
back
that
up
with
details.
But
my
my
request
from
you
know
what
we
want
to
present
publicly
to
the
world.
Is
you
know,
let's
talk
about
our
technical
vision.
H
H
G
H
G
Yeah,
so
the
the
next
press
release
is
the
end
of
january
and
the
we
need
to
have
things
buttoned
down
two
weeks
ahead
of
that.
So
I
mean
we
might
decide
that
that's
just
too
soon
and
we
can't
get
to
that
by
then,
but
but
that
would
be
our
next
opportunity
to
to
share
that
publicly.
A
So
I
think
we
should
try
to
try
to
make
that
date,
so
in
the
the
last
minute
that
we
have
here
real
quick,
I
think
I
think,
there's
some
good
ideas
here
of
how
we
can
move
forward.
Getting
the
document
into
markdown
that
people
can
kind
of
party
on
is
a
great
idea.
We
can
figure
out
how
exactly
we
want
to
do
the
strategy
part.
A
A
It
seems
like
there's
very
limited
discussion
over
email,
but
I
see
a
lot
of
people
like
to
comment
on
issues
and
there's
good
discussions
that
happen
there
on
github.
What
are
folks
preferences
as
far
as
being
able
to
move
through
this
comments
and
documents,
discussion
on
github
or
continue
attempting
to
use
email.
H
I
prefer
to
do
comments
and
documents
of
discussion
on
github.
What
I
find
hard
is
when
we
have
a
new
document
between
meetings,
and
I
have
no
idea
how
important
it
is.
So
maybe
if
such
a
such
a
thing
occurs
like
just
now,
we
all
talked
about
this
sounds
like
there
will
be
a
document
that
we
can
go
iterate
in
now.
I
know
to
kind
of
put
that
on
my
to-do
list
for
the
next
two
weeks,
so
that
makes
any
sense.
M
D
To
wait
till
conversion
to
markdown,
you
know
it's
it's
in
google
docs
now
you
can
just
start
understood,
understood.
H
A
Okay,
so
I
I
think
maybe
the
best
approach
then
is:
I
can
create
a
central
issue
on
on
github
in
an
attack
repo
that
identifies
the
strategy
I'll
copy
pieces
of
my
email
and
put
in
there
and
and
then
david's
document.
We
can
link
it
together.
We
can
have
conversation
on
there
and
then
we'll
come
back
in
two
weeks
and
hopefully
we've
made
progress
in
the
community
on
on
github
and
then
kind
of
go
from
there
they're
very
comfortable
with
that.
L
A
G
D
Right,
the
the
investment,
the
the
initiative
options
is
the
big
one.
The
strategies,
I
presume
is
going
to
be
a
short
one.
A
Yeah
definitely
like
I
said
it's
either
going
to
distill
down
into
a
catchphrase
or
or
maybe
a
paragraph
at
my
post.
I
hope
so
all
right,
we'll
start
with
that
and
we're
out
of
time.
So
we'll
start
with
that,
and
then
obviously
we
can
communicate
in
the
next
two
weeks
and
this
isn't
set
in
stone.
So
thank
you,
everybody
for
your
time.
I
really
appreciate
it.