►
From YouTube: OpenSSF Town Hall #2 (February 22, 2021)
Description
Learn more here - https://openssf.org/
A
B
Hey
everyone
and
good
morning
from
seattle,
washington
and
we're
here
for
the
second
open
source
security
foundation,
open
ssf,
town
hall,
meeting
we'll
go
ahead
and
get
started.
We've
got
quite
a
few
attendees
who
have
joined
us,
I'm
sure
we'll
have
some.
You
know
a
few
more
we've
got
a
few
housekeeping
things
we'll
we'll
take
care
of
at
the
start.
Here
to
let
you
know
we
will
be
recording
this
meeting
and
the
recording
has
already
started
on
to
our
housekeeping
items.
B
Please
go
ahead
and
use
from
the
webinar
the
q
a
button,
so
we
have
an
image
here
that
shows
you
where
that's
at
and
we
may
be
batching
up
some
questions
and
and
answering
them.
You
know
at
the
end
of
sections
when
presenters
speak,
we'll
try
to
get
through
all
the
questions.
We
think
we
have
plenty
of
time
for
that.
B
Solar
winds
has
been
a
you
know,
a
huge
attack
that
came
up
in
december
since
our
since
our
last
town
hall
meeting,
and
there
are
some
of
our
working
groups
and
certainly
at
the
tac
and
the
governing
board
level.
There
we've
been
having
some
discussions
about
how
what
happened
there
influences
how
we
think
about
and
prioritize
some
of
our
work
in
open
ssf.
B
I
need
to
start
us
off
today
with
a
sad
note
and
a
happy
note.
The
sad
note
is
that
we
will
be
our
current
project
manager.
Lindsey
gendreau
will
be
moving
from
her
role.
She's
been
amazing,
so
supportive
and
helpful,
and
always
cheerful
and
so
she'll
be
moving
on
from
supporting
us.
She
is
remaining
at
the
linux
foundation,
where
she'll
be
working
on
events
for
our
sister
project,
the
cloud
native
compute
foundation.
B
Thank
you
lindsay
very
much
and
we
will
miss
you
a
note
on
that.
The
next
event
for
the
cloud
native
compute
foundation
is
a
security
event
and
that's
cloud
native
security
day.
Europe
which
is
coming
up
in
may
so
that
might
be
an
event.
Folks
from
our
organization
will
be
interested
in
event
in
attending.
So
please
take
a
look
to
re.
Replace
replace
is
not
the
right
word.
I
don't
think
we
can
totally
replace,
but
our
our
new
program
manager
is
carly.
B
B
B
The
audio
equality
was
occasionally
spotty
last
time.
Hopefully
that
will
be
better.
If
you
see
or
hear
issues
with
that,
please
let
us
know
drop
a
note
into
the
chat.
We
have
switched
our
platform.
We
were
using
the
regular
zoom
platform
and
this
time
we're
on
the
webinar
platform,
which
is
completely
web-based
and
more
accessible
to
people
on
a
wide
range
of
operating
systems,
and
then
the
other
thing
we've
done
this
time
is
shorten
our
meeting
time
to
60
minutes.
B
B
So
now
on
to
some
of
the
fun
things
about
the
momentum
that
we've
been
having,
so
we
are
only
six
months
old
and
we
have
gone
from
at
founding.
We
had
19
member
organizations,
and
now
we
have
36
and
that's
continuing
to
grow.
We
have
a
few
more
that
we'll
be
announcing
in
the
coming
weeks
we
have
grown
from,
I
think.
Initially
we
had
close
to
100
indiv.
Maybe
it
was
50
60,
individual
participants.
B
Since
the
beginning,
we've
had
60
000
website
visits
and
we
at
our
last
event,
we
announced
our
edx
course,
which
is
on
the
fundamentals
of
developing
secure
software,
and
you
know,
since
that
course
was
introduced.
We
have
grown
to
nearly
24
hun
2400
course
registrants.
So
it's
fun
to
see
the
interest
in
in
that
as
well.
B
B
B
More,
we
are
an
open
public
group
and
we
encourage
everyone
to
get
involved.
We
do
have
members,
but
you
don't
need
to
be
a
member
to
get
involved.
We
have
six
working
groups
and
a
couple
of
other
committees,
so
you
know
anyone
can
participate
in
any
of
those
from
the.
You
can
learn
more
about
all
of
those
and
learn
also
about
finding
out
when
the
meetings
are
and
how
to
join
the
mailing
list,
and
all
of
that
is
available
from
our
open
ssf.org
website
from
our
get
involved.
Page.
B
And
the
last
thing
I'll
mention,
because
this
is
fun,
we
do
have
a
an
open,
ssf
store
where
you
can
get.
You
know,
swag
and
and
such
and
you
know
things
t-shirts
and
decals
and
cute
things
like
our
our
open,
ssf
plushie,
and
that's
it
for
me
with
an
overview,
and
you
know
things
that
have
been
going
on
now,
we're
going
to
turn
over
and
have
david
wheeler
talk
with
us
about
solar
winds
and
some
lessons.
We've
been
learning
from
that.
A
Sure,
all
right,
so
we
thought
the
solarwinds
orion
subversion
has
been
in
the
news
all
over
and
because
of
that,
we
thought
it
might
be
useful
to
go
quickly.
Discuss
that-
and
at
least
you
know,
kind
of
queue
up.
Thinking
about
lessons
learned
that
we
can
learn
from
this.
The
subversion
involving
solar
winds
involved,
a
company
called
solarwinds
software
called
orion.
It's
not
open
source
software,
it's
closed
source
software,
but
nevertheless
we
want
to
learn
from
events
like
this.
A
The
fundamental
concern
that
raised
a
lot
of
the
news
was
that
malicious
functionality
was
introduced
by
some
outside
actor
in
march
2020.
It
was
not
detected
until
december
2020
and
it
had
really
devastating
impact.
The
way
that
solarwinds
orion
is
typically
deployed
a
lot
of
larger
organizations
is,
it
has
the
keys
to
the
kingdom
and
so
being
able
to
get
access
and
control
that
led
to
basically
subversion
of
entire
organizations.
A
So
so
the
question
is:
what's
the
underlying
cause
here?
What
was
particularly
interesting
and
why
it
made
the
news
was
because
the
attack
was
fundamentally
a
subversion
of
the
build
environment,
which
is
a
much
much
less
common
kind
of
attack.
As
I
think,
almost
everybody
here
knows
software,
when
you
develop
it,
you
modify
source
code,
but
before
you
can
actually
run
it,
you
run
it
through
typically
some
sort
of
packaging
system,
compilers
of
minifiers
that
sort
of
thing
and
the
attackers
subverted
that
process.
A
The
build
process,
in
particular
the
there
was
a
particular
malware
program.
That's
now
called
sunspot,
it's
a
little
process
that
ran
on
the
build
environment
and
watched
if
something
called
msbill.exe
was
run.
If
it
was,
it
checked
if
orion
was
being
compiled
and
if
so,
it
quietly
modified
the
source
code
being
compiled,
compiled
at
build
time
to
insert
the
actual
attack
that
we've
that
is
now
called
sun,
burst.
A
A
There
were
other
attacks
around
the
same
time
that
added
to
the
confusion,
there
was
actually
an
unintentional
vulnerability
that
was
being
exploited
by
a
different
attack
that
was
actually
inserting
changes
into
the
system
after
it
had
been
deployed.
That,
frankly,
is
a
much
more
common
kind
of
attack
and
there's
some
other
attack
called
raindrop.
I'm
not
going
to
talk
about
that
in
part
because
there's
it's
there's
still
seem
to
be
uncertainties
about
it.
A
It's
important
to
note.
This
is
not
the
only
time
that
the
source
code
is
different
than
the
packaged
executable.
Okay,
people
have
had
various
kinds
of
attacks
that
do
this
kind
of
thing.
You
know
npm's
module
es,
let's
scope
involved,
an
npm
account
that
was
subverted,
and
so
in
that
case,
the
package
that
was
sent
out
was
not
the
same,
did
not
match
the
source
code
in
github.
Same
happened
with
npm
module
event
stream,
where
it
had
a
new
owner
who
added
new
malware.
A
A
The
interesting
thing
to
note
about
these
kinds
of
things
where
you
know
the
build
system
is
subverted
or
there's.
You
know
something
where
the
source
code's
different.
Is
that
a
lot
of
these
sources?
Security
measures?
Don't
work
against
this
kind
of
thing,
so
things
like
hey
we're
going
to
have
lots
of
people
review
the
source
code
that
doesn't
help
when
the
problem
is
after
the
source.
Code's
developed.
Something
happened
to
produce
the
final
program
that
everyone's
using
a
similarly
digital
signing
doesn't
help,
because
this
really
was
the
generated
program
that
was
being
distributed.
A
Slide
so,
in
short,
we
need
to.
We
need
to
learn
from
build
time.
Subversion
attacks
in
the
short
term,
hardener
build
environments
from
attacks
campaign
to
enable
developer,
2fa,
really
multi-factor
authentication
for
anybody
who
has
control
of
these
systems
in
the
longer
term.
The
only
technique
I'm
aware
of
that
can
really
detect
these
kinds
of
problems
is
verified.
Reproducible
builds.
This
is
where
you
can
regenerate
for
bit
for
bit
from
the
source
code
and
verify
that
it
actually
works.
A
It's
also
important
to
note
that
we
still
need
to
counter
other
attacks,
because
attackers
will
try
the
easiest
approaches
first,
so
we
still
need
to
make
it
easier
to
use
tools
and
interfaces
securely.
We
still
need
to
educate
our
developers.
We
still
need
to
use
analysis
tools
and
digital
signing
and
so
on
all
right
and
lots
of
references
down.
A
B
D
All
right,
hello,
everyone,
I'm
ryan
hayden
and
I'm
the
chair
for
the
technical
advisory
council
and
we've
been
busy
the
past
few
months.
What
we
work
on
primarily
is
with
oversight
for
various
technical
initiatives
within
the
open
ssf,
which
essentially
means
that
you
know
we
make
sure
that
everybody's,
coordinated
and
and
working
towards
kind
of
common
goals-
and
we
don't
have
duplication
of
efforts-
and
you
know
that
sort
of
thing.
D
So
we
approve
and
facilitate
that
collaboration
through
the
technical
initiatives,
otherwise
known
as
working
groups,
and
then
we
assist
with
identifying
funding
and
resourcing
requirements
with
the
governing
board.
So
for
those
that
aren't
familiar,
all
the
funding
and
budgeting
goes
through
the
governing
board,
but
the
tac
can
kind
of
help.
You
guys
navigate
that
and
we'll
coordinate
with
them.
We
do
have
a
representative
from
the
tac
that
sits
on
the
governing
board.
D
So
I'm
not
going
to
word
by
word,
read
this
to
you
guys,
but
the
highlights
are
you
know
that
we
envision
a
future
where
participants
in
the
open
source
ecosystem
use
and
share
high
quality
software
with
security
handled
proactively
by
default
as
a
matter
of
course,
this
leads
to
four
things
such
as
guidance
developers
can
learn.
They
have
educational
guides
and
tooling
at
their
disposal.
D
Automation
via
tooling
and
continuous
assurance
work
we'll
develop
reports
that
you
know,
developers
and
researchers
and
people
with
a
vested
interest
in
open
source
projects,
can
read
about
and
identify
known
security
issues
within
a
project,
and
then,
additionally,
you
know,
most
importantly,
resolve
right.
Community
members
can
provide
information,
notifications
about
defects
and
and
work
towards
actually
resolving
those
and
and
provide
solutions
to
that.
D
D
So,
in
addition
to
the
the
the
vision,
we've
also
been
developing
a
list
of
potential
future
work-
that's
not
currently
covered
by
working
groups.
So,
for
example,
there,
as
we
all
know,
there's
a
ton
of
things
we
could
go
tackle
within
the
open
source
security
ecosystem
and
we're
not
going
to
get
to
it
all
this
year
or
even
next
year.
Right,
so
we're
been
putting
together
sort
of
a
giant
backlog.
D
It's
a
huge
document
right
now,
but
eventually
that'll
turn
into
github
issues
that
we
can
kind
of
pull
off
and
those
can
serve
as
inspiration
for
future
working
groups.
So
folks
want
to
look
through
that.
You
know
they
can
see
some
of
that
information
and
decide
if
they
want
to
contribute
and
maybe
even
spin
up
a
new
technical
initiative
for
it.
D
Currently
you
can
find
on
the
github,
repos
and
then
sort
of
our
next
thing
that
we'll
be
doing
is
reviewing
the
charters
of
the
existing
working
groups.
So
that's
just
more
of
a
formalization
process.
I
don't
anticipate.
There
should
be
too
much
controversy
or
changes
affected
there,
but
we
do
want
to
make
sure
that
every
working
group
going
forward
does
have
a
public
charter
that
it's
documented
participants
are
able
to
easily
find
out
what
license
is
being
used.
You
know
that
sort
of
thing
so
we'll
be
going
through
that
shortly
as
well.
D
So
ways
that
you
can
get
involved,
our
meetings
are
open
to
everyone.
So,
even
though
the
tac
has
you
know
official
representatives,
we
have
tons
of
participants
that
are
not
official,
but
we
definitely
value
all
of
that
input.
So
every
or
every
other
tuesday
at
8
am
pacific
time.
Our
next
meeting
will
be
on
november
or
november.
That
is
definitely
not
accurate.
We
haven't
updated
that
so
it's
actually
tomorrow,
so
february
23rd.
E
All
right,
good
morning,
everybody
from
the
rainy
pacific
northwest,
my
name
is
mike
scaveda.
I
lead
the
identifying
security
threats
working
group.
The
mission
of
our
working
group
is
to
enable
stakeholders,
meaning
developers,
users
upstream
developers,
compliance
teams,
whoever
to
have
an
informed
confidence
in
the
security
of
the
open
source
projects
that
they
use
next
slide.
Okay,
so
we've
really
done
it.
E
We
kind
of
have
two
pro
two
big
projects
in
in
in
motion
at
the
at
the
moment.
First,
one
is
a
metric
dashboard.
We've
been
talking
about
this
since
the
formation
of
open
ssf.
I
think
I
presented
this
in
in
november
as
well.
The
purpose
of
this
is
to
collect,
curate
and
communicate
metrics
for
open
source
projects.
E
E
We
also
collect
a
little
bit
of
data
from
from
github
as
well.
It's
it's
mostly
proof
of
concept,
but
it
the
the
intent
of
the
project
right
now
is
to
show
what's
possible
and
to
have
have
something
to
argue
about
in
terms
of
what
is
the
right
metric
here
and
is
is
what's
the
best
way
to
convey
the
most
useful
information.
E
So
this
project
is
on
github
and
if
you
go
to
the
next
slide,
you
can
see
a
screenshot
of
it.
This
is
the
the
default
grafana
backend.
The
the
data
on
the
bottom
left
is
basically
check.
Well,
all
the
things
on
the
bottom
are
check,
marks
for
pass
and
x's
for
fail,
and
bottom
left
is
the
as
the
the
title
suggests,.
F
E
E
The
second
project
that
we've
done
is
called
a
security
reviews
project.
The
point
here
is
to
create
a
community
collection
of
secure
reviews
done
by
a
human
in
some
way
of
against
open
source
projects.
This
is
not
a
vulnerability
disclosure
mechanism.
This
is
not
an
alternative
to
cves
or
anything
like
that,
but
it
provides
one
thing
which
is,
which
I
think
is
unique,
which
is
a
positive
indicator
of
the
security
quality
of
a
component,
the
negative
indicators
you
can
find
in
vulnerability
reports.
E
We
think
there's
value
there
too,
but
most
importantly,
if
you're
using
a
component
foo-
and
it
doesn't
have
any
vulnerabilities
like
how
would
you
differentiate
between
no
known
vulnerabilities
and
no
vulnerabilities?
And
the
idea
is
that
if
someone
looks
at
it
and
they
say
nope,
this
thing
looks
good,
that's
a
positive
indicator.
It
usually
gets
lost
within
organizations
that
do
this
work.
It
usually
doesn't
get
shared.
We
want
to
collect
that
and
share
that
so
you'll
have
you'll,
have
some
information
that
you
know
as
to
the
security
quality
of
a
of
a
thing.
E
E
So
we
have
a
little
bit
of
progress
this
this
project
launched
about
a
week
and
a
half
ago.
So
thanks
to
the
open
source
technology
improvement
fund
for
donating
a
review
for
the
linux
kernel
response
process,
we
included
an
external
review
done
against
zlib.
Thank
you
to
dylan
bala
for
for
contributing
a
few
reviews
of
a
few
npm
packages,
and
we've
contributed
a
a
few
hundred
vulnerable
packages
to
the
dependency
confusion,
attacks
and
give
a
little
bit
more
information
on
how
those
things
work.
E
So
again,
this
is
an
open
project,
ossf
security
reviews.
Next
slide.
This
is
just
the
repo.
That's
not
very
interesting.
Go
next
slide
yeah.
So
if
you
want
to
get
involved
more
consider
security
review
join
our
slack
channel
come
to
the
next
work
group
meeting
our
next
meetings.
I
think
next
wednesday,
the
link
to
the
work
to
the
working
group
page
is
there
or
contact
me
we're
also
on
the
open
ssf
community
calendar.
F
Hi,
this
is
ryan
ware.
I
want
to
talk
about
security,
tooling,
go
ahead
and
move
on
on
the
next
slide.
I
want
to
say
thank
you
to
simon
bennett's.
Simon
has
been
the
this
work
group
lead
up
until
now,
and
he's
done
a
great
job
he's
planning
on
continuing
to
to
participate,
but
you
know,
but
he
will
be
irreplaceable
as
a
lead.
Hopefully
I
can
fill
his
shoes
and
want
to
thank
him
for
all
the
work
he's
done.
F
So
the
mission
of
this
particular
working
group
is
to
identify
and
build
universally
acceptable,
developer-focused
tooling,
to
help
the
open
source
community
secure
their
code.
There's
a
wide
variety
of
of
implications
from
that
one
of
the
things
that
I
want
to
make
sure
people
understand,
though,
is
wait.
We
can't
just
just
create
tools,
you
know
we.
We
can't
simply
just
create
tools
and
throw
security
tools
at
developers.
F
F
They
generally
won't
be
doing
much
to
to
incorporate
them,
and
so
one
of
the
things
that
we'll
be
looking
at
in
the
coming
weeks
is
how
how
do
we
help
developers
integrate
these
tools?
What
are
the
b
cams?
How?
How
do
we
help
help
them
move
along,
so
they
understand
when
they
get
a
pull
request.
They
can
understand
the
security
implications
of
what
they're
taking
in
next
slide.
F
F
There's
also
the
the
cve
benchmark
data
set
and
tooling
that
was
presented
at
black
hat
eu.
The
data
set
itself
is
handcrafted
metadata
for
over
200
javascript
cves,
including
fix,
commits
tooling,
to
benchmark
security
tools.
Does
it
detect
the
vulnerability?
It
doesn't
recognize
the
patch?
Those
are
things
that
that
they're
looking
at
in
this
and
if
you
want
to
know
more
there's
a
a
long
discussion
currently
going
on
in
tech
issue,
number
453,
there's
a
link
here,
please
feel
free
to
to
jump
in
and
share
your
thoughts.
F
F
If
you
would
like
to
get
involved,
we
definitely
need
lots
of
help.
There's
still
lots
of
work
to
do
with
the
cve
benchmark,
help
us
make
it
the
best
benchmark,
hook
up
and
benchmark
your
own
security
tools
with
the
benchmark,
and
we
need
to
add
much
more
cve
metadata
into
what
we
have
the
security
tools,
collateral
and
best
practices.
F
We
need
to
be
able
to
share
information
on
what
tools
are
available
documentation
on
how
to
easily
incorporate
those
tools
and
how
tools
can
best
fit
into
developer
workflows.
We
also
want
to
know
more
about
tools
that
your
organizations
have
been
using
and
may
have
created
and
want
to
open
source
and
how
they
can
help
the
communities
out
there.
F
F
G
Hello
from
beautiful
snow
kissed,
columbus,
ohio-
I
am
krobe.
I
have
the
great
pleasure
of
being
the
working
group
lead
for
the
developer
best
practices
group.
As
you
can
see
from
our
awesome
mission
statement,
our
goal
is
to
help
provide
open
source
developers
with
best
practices,
recommendations
and
then
give
them
an
easy
way
to
learn
and
apply
these
recommendations
next
slide.
Please.
G
We're
all
about
developers
like
my
friend
with
the
awesome
hair,
there
has
to
say
next
slide:
we've
organized
ourselves
in
kind
of
three
core
themes,
we're
looking
at
trying
to
identify
good
practices
and
tools
that
open
source
developers
can
use
and
integrate
into
their
security
work,
nextly
we're
looking
to
provide
education
and
promote
learning
of
these
activities,
these
good
secure
coding
techniques
and
kind
of
highlight
mistakes.
We
want
people
to
avoid,
and
then,
lastly,
we're
looking
at
how
to
encourage
people
to
adopt
these
good
practices
and
tools
in
their
community
or
their
particular
projects.
G
Awesome
work,
we
kind
of
see
that,
as
the
head
end
feeding
a
lot
of
the
other
good
practices
that
filter
down
in
the
middle.
We
have
our
hub,
the
skf,
which
is
our
secure
knowledge
framework.
This
is
a
tool
that
helps
developers,
identify
security
issues
in
their
projects
or
kind
of
help
them
go
through
labs
and
testing
now
related
to
that.
Well,
you
know
once
you've
identified
some
good
practices
and
you've
had
a
little
bit
of
time
to
learn
and
test
out
your
knowledge.
G
Ideally,
this
is
it's
an
automated
tool.
It
runs
and
helps
you
make
good
trust
decisions
and
kind
of
under
evaluate
the
posture
of
the
security,
the
project
you're
thinking
about
incorporating
next
slide,
please
on
just
a
particular
slide
all
about
the
edx
course.
There
are
three
classes.
We
have
just
kind
of
a
general
kind
of
security,
101
course,
and
then
we
get
into
courses
that
talk
about
how
to
implement
some
of
these
techniques
and
then
how
to
verify
them
and
get
into
some
more
higher
level
classes.
G
So,
overall,
we've
been
working
to
help
craft
a
set
of
user
personas
to
help
us
identify
problems
that
exist
within
open
source
software
development,
and
this
is
something
that's
shared
with
a
couple
different
other
working
groups.
But
ideally,
once
we
start
talking
the
same
language,
we're
talking
about
an
open
source
maintainer
or
a
security
researcher
or
finder
that
helps
us
kind
of
zero.
In
on
what
those
pain
points
are,
and
we
can
start
to
make
more
corrective
actions.
How
do
we
make
those
interactions
smoother
kind
of
looking
at
the
project
as
a
whole?
G
David
put
in
some
great
information
about
the
number
of
edx
classes
that
people
have
signed
up
for,
I'm
really
excited,
and
I
would
strongly
encourage
anyone
that
either
is
a
developer
or
works
with
developers
check
this
out
free
coursework
and
if
you're
interested,
they
even
offer
a
small
for
a
small
fee
of
certifications.
You
can
say
I'm
a
certified
open
source
ologist.
G
G
Hey
everybody:
it's
probe,
I'm
the
new
working
group
lead
for
the
vulnerability
disclosures
group,
which
I
think
is
one
of
my
favorite
working
groups
to
be
in
next
slide.
Please,
the
vulnerability
disclosures
group
is
we're
looking
to
improve
overall
security,
open
a
source
software
ecosystem
by
helping,
develop
and
advocate
well-managed
vulnerability,
reporting
and
communication
next
slide.
So,
basically
we're
looking
to
try
to
help
make
the
discovery
and
fixing
of
security
issues
much
simpler.
G
A
couple
of
things
we're
working
on.
We
were
working
on
those
aforementioned
personas.
We
have
a
very
detailed
set
of
pain
points
between
these
different
persona
groups.
Our
newest
project
is
a
vulnerability
disclosure
white
paper,
we're
working
on
to
help
document
good
practice
and
that's
that
the
guidance
around
vulnerability
management
next
slide,
please
from
a
persona
perspective
this
basically
for
someone
who
helps
you
understand
the
problems
in
a
process.
From
a
certain
perspective,
a
documented
perspective
of
an
individual
group
or
constituency
like
maintainers
finders
suppliers,
consumers
and
coordinators.
G
Each
one
of
these
groups
has
different
goals
and
motivations
and
they
have
different
methodologies
of
potentially
how
they
interact.
So
it's
important
to
kind
of
take
that
into
perspective
as
you're
looking
at
a
problem
as
complex
as
coordinating
vulnerability
disclosure
information
next
slide,
please.
G
G
Our
next
project,
as
I
mentioned,
is
a
white
paper,
and
this
is
where
we're
going
to
try
to
capture
all
this
really
good
practice.
This
vulnerability
disclosure
is
widely
documented
in
the
industry,
not
so
much
in
open
source,
so
we're
trying
to
coalesce
all
these
really
good
practices,
whether
it's
a
very
standard
dodgy
standard
like
iso
or
something
like
a
little
more
agile,
like
the
dpz
team,
just
released
a
new
guide,
so
we're
looking
at
creating
this
if
anyone's
interested
participating.
G
I'm
writing
the
pr
right
now.
We
would
love
your
help
on
crafting
this
good
practice.
Next
slide,
just
like
every
other
group,
great
ways
to
get
involved.
We
meet
every
two
weeks
on
monday
at
8
a.m.
Pacific,
and
we
have
the
same.
We
have
slack
channel.
We
have
an
email
list.
Our
videos
are
generally
recorded
when
I
remember
to
hit
the
button
and,
if
you're
interested
in
helping
improve
vulnerability
disclosure
between
open
source,
maintainers
security,
researchers,
suppliers,
coordinators,
any
of
these
different
personas,
please
consider
joining
us
and
sharing
your
knowledge.
B
Thanks
group,
amazing
hat-
and
I
guess
we're
gonna-
have
to
find
out
from
you
where
you
got
that
and
see
if
we
can
get
it
added
to
our
web
to
our
store
at
our
open,
ssf
website
very
fun.
I
also
just
want
to
give
a
quick
plug
for
the
edx
community
course.
I
actually
sat
down
and
took
the
court.
All
three
of
the
courses
over
the
holidays
didn't
take
very
long,
great
information
and
I'm
now
a
certified
secure
development
fundamentals.
A
Thank
you
very
much
sad.
I
cannot
compete
with
krobs
hat,
but
I
do
have
the
open,
ssf
plushie,
which
I
will
put
here
in
pride
of
place.
So
unfortunately,
dan
lawrence
and
kim
kim
lewandowski
aren't
able
to
be
here
right
now,
so
I'm
going
to
do
my
best
to
fill
in
for
them.
So
I'm
going
to
talk
first
about
digital
identity
at
a
station
and
the
fundamental
problem
that
this
particular
working
group
is
trying
to
deal
with
is
that
on
the
internet,
nobody
knows
you're
a
dog.
A
Now,
perhaps
we
don't
care
if
you're
a
dog
but
we'd
like
to
know,
wait
a
minute.
You
say
you're
that
person
who
contributed
the
last
time.
Are
you
really?
I
don't
know?
How
can
I
confirm
that
and
so
moving
on
to
the
objective,
the
objective
of
this
working
group
is
to
enable
open
source,
maintainers
contributors
and
end
users
to
understand
and
make
decisions
on
the
provenance
of
the
code
they
maintain
produce
use.
A
So
if
you
follow
that
link
in
the
presentation
which
I
believe
will
be
out
later,
you
can
see
some
of
the
threat
model,
information
and
the
links
there
point
off
to
different
presentations.
We've
had
about
the
linux
kernel,
the
links,
colonel
the
lf,
actually,
funds,
various
work
to
help
the
linux
kernel
developers
manage
identity,
there's,
of
course,
in
toto
and
tough
there's
some
self-serving
identity.
Work.
That's
gone
on.
Various
organizations,
including
hyperledger
nodejs,
has
its
own
release,
process,
which
they
are
of
course
concerned
about
identity.
A
We've
had
several
presentations
about
integrating
get
signing
with
ssh,
there's
been
quite
a
bit
of
work,
which
we
we
think
is
on.
I
I
personally
think
is
on
the
road
to
something
very
positive,
but
there's
work
to
be
done
on
this
and
also
pki
jensen.
You
can
follow
the
links
and
see
more
so
I
think
it
was
both
kim
and
dan
and
I
think
maybe
some
others.
A
So,
if
you're
interested
in
getting
involved,
please
do
so
it
meets.
We
meet
every
two
weeks.
The
next
meeting
is
march
3rd.
That's
wednesdays!
We
meet
every
other
wednesday
from
noon
to
1
eastern
time.
Just
for
whatever
your
time
zone
is.
You
can
of
course
see
the
invite
on
the
open.
Ssf
calendar
is
true
for
all
the
open,
ssf
events
got
a
repo
there's
a
mailing
list,
various
notes
and
so
on.
A
I
think
that's
my
last
slide.
Okay
and
let
me
move
on
securing
critical
projects.
Unfortunately
kim
also
isn't
able
to
be
here
so
I'm
going
to
fill
in
for
her
next
all
right.
The
problem
that
this
particular
working
group-
I
think,
frank,
franco
this
this
cartoon-
I
I
think,
explains
a
lot
of
the
you
know.
This
is
a
well-known
xkzt
cartoon
and
like
many
cartoons,
it
does
a
spectacular
job
of
explaining
simply
a
real
problem.
A
We
have
lots
of
complex
digital
infrastructure
that
we
depend
on,
and
yet
it
often
ends
up
depending
on
some
very,
very
shaky,
not
necessarily
well
supported
components
in
there
next,
and
so
our
mission
is
to
improve
the
security
of
the
most
critical
open
source
projects.
Next
now
I'm
going
to
be
talking
about
what
we've
been
doing
since
the
last
town
hall
meeting
the
last
holland
hall.
A
We
mean
we
noted
that
in
fact,
linux
foundation
harvard
has
actually
been
funding
harvard
to
do
quite
a
bit
of
this
work
and,
of
course,
you
know,
they're
still
they're,
very
much
participating
this
working
group
and
so
on,
but
some
of
the
other
things
that
have
gone
on
were
we
in
this
working
group.
Since
the
last
town
hall
meeting,
there's
a
small
project
called
criticality
score,
which
attempts
to
create
a
simple
criticality
score
for
an
open
source
project
based
solely
on
quantitative
data,
can
gather
rapidly
codes
on
github.
A
You
can
see
what
that
what
that
looks
like
another
package
called
package
feeds
and
what
package
feeds
does
it
basically
tries
to
it
basically
monitors
the
repos
for
certain
language
level,
package
managers
and
tries
to
gather
some
basic
data
about
them,
and
you
know
oh
look,
what's
happened
more
recently.
You
can
then
take
that
data
and
analyze
it.
For
example,
there's
another
project
called
package
analysis
which
analyzes
open
source
packages
for
malicious
software.
A
You
know
basically
takes
the
package
feeds
data
to
say,
hey,
there's
something
new
here
and
then
package
analysis
tries
to
analyze
it
now.
I
do
want
to
warn
you
any
any
tool
that
tries
to
detect
malicious
software.
There's
no
guarantee
you're
going
to
find
it.
In
fact,
a
really
good,
really
good
adversary
is
going
to
be
good
at
evading
these
kinds
of
things,
but
not
all
adversaries
are,
you
know,
are,
are
very
capable.
A
So
what
I
would
say
is
right
now
smoke
is
focused
more
on
the
the
pikers,
the
the
amateurs,
but
you
know
what
we
don't
want
to
be.
We
want
to
detect
the
attacks
from
the
amateurs,
so
while
this
I
just
want
to
characterize
this,
because
this
is
not
solving
the
problem
completely,
but
it
is
helping
reduce
the
risks
which
is
in
many
cases
all
you
can
do,
and
it
certainly
is
as
a
help.
A
We've
had
a
number
of
presentations
from
different
folks,
the
isrg
defend,
which
does
some
malware
detection
and
we've
also
had
a
presentation
by
chris
lamb
on
our
reproducible
builds.
The
idea
by
reproducible
builds,
as
I
mentioned
earlier,
with
solar
winds,
is
being
able
to
do
check
on
build
system
security
or
build
environment
security
by
enabling
the
verification
of
a
build
being
able
to
rebuild
some
software
and
verify
that
it
produces
the
same
bits
as
you
already
have,
and
that
way
it's
much
much
likely
that
the
build
system
build
process
build
environment
were
subverted.
A
Oh
okay,
get
involved.
There
we
go.
There
is
one
more
slide.
Okay,
so
please
get
involved
excellent,
we're
on
slack
we're
on
email.
We've
got
a
github
repo
next
meeting
is
thursday
february
25
from
noon
to
1
eastern
time
we
would
love
to
see
you
there
just
go
to
the
get
github
page
and
you
can
find
all
the
meeting
details
and
so
on
from
there.
B
We
do
have
time
for
q
a
so
we've
been
answering
some
questions
as
they've
been
coming
along
in
the
q,
a
section
we've
been
able
to
answer,
I
think,
all
of
those
so
far
offline-
and
I
don't
know
lindsay-
is
it
possible
to
do
we
want
to
open
up?
And
you
know
let
people
have
verbal
verbal
questions
if
there
are
any
for
a
few.
H
Minutes
we
can
do
that
if
you
do
have
a
question
that
you
would
like
to
ask.
You
can
use
the
raise
hand
function
and
I
can
take
you
off
of
the
mute
portion
of
the
webinar.
So
if
you
have
a
question
you
can
use
the
raise
hand,
and
you
can
also
still
use
the
q
a
feature
if
you
feel
more
comfortable
with
that
great
thanks
lindsay.
B
Yeah,
so
we're
happy
to
take
questions
about
you
know
any
anything
about
the
open
ssf.
You
know
where
we're
going,
what
you
can
expect
in
the
future,
any
any
other
technical
questions.
You
know
things
that
we're
currently,
including
in
our
charter,
things
that
we
might
include
in
charters
for
for
various
groups.
H
A
See
what
you
say
go
ahead,
fair
enough.
Okay,
I
mean,
I
think,
there's
at
least
two
working
groups
in
particular
that
have
already
discussed
this.
The
critical
projects
working
group,
in
fact,
has
already
had
a
presentation
specifically
on
verifiable
builds
because
you
know
if
some
software
is
especially
critical.
One
of
the
things
that
can
be
done
to
harden
it
up
is
to
enable
verifiable
builds.
A
A
You
know
the
working
groups
more
than
occasionally
a
working
group
works
on
one
piece
another
on
another,
for
example
the
metrics,
the
security
threats
group
gathers
in
metrics
that
have
been
developed
from
tools
from
other
working
groups,
and
that's
perfectly
fine.
So
it's
it's
I
you
know,
I
don't
think
it
has
to
be
in
either
or
and
kane.
Now
you
can
tell
me
I'm
all
wrong
and
here's
the
correct
answer.
Well,.
B
I'm
not
saying
you're
wrong.
What
I'll
say
is
that
there's
another
option
so
and
the
other
option
is
we
can
start
a
new
working
group
looking
at
verifiable
builds
so
there's
nothing
that
says
we
you
know
have
to
stop
at
six
working
groups.
If
we
feel
like
there's,
you
know
enough
to
do
there
that
it
justifies
another
group
way.
Certainly
you
know.
If
someone
wants
to
make
that
proposal,
we
should
bring
it
up
to
the
tack.
You
know
we
have
the
the
attack
process
of
creating
new
working
groups,
and
so
we
can.
B
H
D
Yeah
definitely
so
I
was
actually
to
comment
on
the
previous
question
too.
I
was
going
to
second
your
your
option.
As
far
as
having
its
own
dedicated
working
group
for
reproducible
builds,
I
can
definitely
see
that
being
a
large
enterprise
that
might
that
have
the
need
for
its
own
group,
but
as
far
as
getting
involved,
all
of
our
the
meeting
invites
are
published
online.
So
you
can
go
to
our
shared
open,
ssf
calendar,
that's
accessible
from
the
github
ossf.org
as
well,
and
just
join
the
meetings
to
start.
D
You
know:
that's
definitely
the
first
place
kind
of
see
where
the
group's
at
and
what
they're
doing
where
they
need
help
if
there's
code
and
lists
in
the
repos,
but
definitely
start
with
the
meetings
and
then
you
know
join
in
on
slack
and
have
conversations
everybody's
very,
very
receptive
to
to
newcomers.
So
please
jump
in
get
involved.
You
know
we're
more
than
happy
to
help.
H
H
I
So
I'm
interested
in
trying
to
integrate
communities
between
civilian
and
military,
I'm
currently,
a
military
cyber
security,
professional
and
one
of
the
projects
that
we're
pushing
is
dod
levels
open,
source
projects.
Now
my
question
is:
how
would
I
enable
you
guys
to
come
and
invite
and
talk
about
the
awesome
stuff
that
you're
doing
right
now?
What
are
what
is
the
best
communication
route.
B
Oh
great
question:
so
we
do
have
an
outreach
committee
and
there
is
in
our
github
web
in
our
github
site.
You'll
see
if
you
kind
of
scroll
down
through
the
various
projects
and
committees.
There's
one
that's
called
the
outreach
jennifer
fernick
is
leading
that
I'm
not
sure
if
I
don't
think
she
she
might
not
be
able
to
jump
in
here.
B
But
if,
if
you
you
know,
go
look
for
that
and
then
reach
out
from
there
to
jennifer,
there
are
a
couple
of
others
that
are
involved,
and
we
can
definitely
do
that.
We're
very
interested
in
getting
the
word
out
about
openness
is
up
so
we'll
round
up
some
folks
too,
to
work
with
you
to
set
up
a
presentation.
A
B
Slides,
okay,
great
we'll,
go
ahead
and
and
wrap
up
then.
So,
thank
you
all
for
being
here
for
participating
for
your
questions.
It's
you
know.
It's
been
it's
really
an
honor
for
all
of
us,
working
in
open
ssf
to
be
here
and
to
be
working
with
each
other
and
and
just
to
you
know,
feel
the
enthusiasm
and
know
that
the
work
that
we're
doing
is
important.
It's
you
know
important
in
every
it's
important
the
world
over.
B
It's
important
for
every
company,
for
every
for
every
country
and
and
we're
all
here
to
to
you
know,
to
gain
momentum,
pool
our
resources
and
and
make
things
happen.
So
if
folks
here
want
to
get
involved
or
know
anyone
else
who
might
want
to
get
involved,
we've
mentioned
a
couple
of
times
the
get
involved
page
on
openssf.org.
B
From
that
page,
you
can
find
links
to
our
working
groups
to
our
github
site
how
to
join
mailing
lists
to
our
calendar.
You
know,
we've
got
also
got
links
to
our
twitter
tweet
and
also
for
blog
posts
that
we've
written
and
our
slack
channel.
So
it's
all
there
take
a
look
at
that
site
and,
as
I
mentioned
earlier,
we
would
love
to
have
you
fill
out.