►
From YouTube: OpenSSF Identifying Security Threats WG (March 15, 2023)
Description
Meeting notes: https://docs.google.com/document/d/1AfI0S6VjBCO0ZkULCYZGHuzzW8TPqO3zYxRjzmKvUB4/edit
B
A
A
A
Welcome
everyone
to
the
March
15th,
identifying
the
security
threats
working
for
meeting
I
will
be
your
host,
at
least
for
the
first
half
hour.
I
need
to
bounce
at
at
30
minutes
past.
But
it's
the
conversation,
if
there's
more
stuff,
to
talk
about
I'll,
just
hand
it
over
to
you
Luigi.
If
that
works
and
we'll
just
keep
going.
A
B
Now,
one
month
ago,
I
joined
I
attended
a
hack,
a
group
meeting
where
I
proposed
proposed
to
to
have
an
organizational
level
security
policy
security
we
can
call
has
we
prefer,
because
it
is
a
requirement
for
for
the
security
insights.
In
particular,
we
need
we
need
to
have
a
security
contact,
an
email
and
a
general
equipment
address
and
better.
If
we
have
also
linked
to
a
security
policy,
then
just
explain
hey.
If
you
find
something
contact
these
or
follow
this
procedure,
I
started
to
write
a
document.
B
It
is
a
draft
I
have
already
shared
in
the
channel
disclosure
disclosure
and
I
have
received
some
comments.
A
good,
very
good
feedback
I
can
share
I
shared
also
in
the
channel
in
our
Channel
and
in
the
Security
Site
insights.
Channel
I
I
mean
I'm
tired
to
finish
to
close
the
last
comments
and
feedback
and
probably
according
to
the
suggested
that
I
received
I
need
to
add
a
short
paragraph
paragraph
where
I
just
explained
how
we
communicate
with
the
receptor.
B
B
This
should
be
the
policy.
Everyone
that
have
this
link
can
comment.
I
hope,
I've
shared
the
right
one
yeah
the
name
is
Justice
I
mean
the
name
for
the
police
is
security
policy.
Quite
genetic
I
want
to
be
sure
that
we
don't.
We
don't
create
conclusion
or
misunderstanding
with
the
other
policies
that
we
are
writing.
So
the
policy
when
open,
ssf,
ssf
members
find
one
rabbit,
is
another
project.
B
I,
don't
know
the
informal
name
is
for
me.
The
project,
zero
policy,
but
yeah
Jonathan
is
working
on
that.
So
I've
changed
the
name
in
security
policy.
I,
don't
know
if
it's
good.
For
now
it
is
just
a
temporary
name
and
then
someone
else
I
can
approve
it.
There
are
some
open
comments
and
we
don't
have
still
an
email
but
friends
to
say
that
in
two
three
days
he
can
me
give
me
updates
about
this
and
having
an
email
should
not
be
a
problem.
B
We
can
also
reuse,
in
my
opinion,
that
one
of
the
Linux
Foundation
email,
if
they
have
I,
think
so
it
is
just
a
generic
email
where
we
should
receive
report
that
cannot
be
opening
in
GitHub.
In
particular.
The
pressure
that
I
have
suggested
is
to
open,
send
because
now
GitHub,
private
private
issue,
more
or
less
I,
don't
know
if
we
have
the
GitHub
account
configurable
configurated
in
the
right
way,
but
yeah.
So.
D
A
B
I
mean
yeah
I,
agree
technically,
I
agree
something
that
I
want
to
propose
to
the
talk
at
the
moment.
This
is
a
sort
of
organizational
level
proposal
policy.
But
during
the
talk,
the
meeting
with
the
tag
group
and
also
in
the
Channel
people
say:
maybe
we
don't
want
to
have
a
security
policy
for
every
rapper,
or
at
least
maybe
some
rapper
prefer
to
have
a
different
policy,
a
different
process.
Technically,
you
can
override
the
policy,
even
if
consider
better,
to
have
one
that
is
for
the
entire
organization.
B
B
B
A
second
I
forgot
it
the
point
we
can
enable
it
but
yeah,
but
technically
this
policy
should
be
a
generic
policy
for
open
ssf
and
even
if
I,
think
and
agree
that
probably
a
search
system
has
a
report
about
the
product
open
source
project
that
we
have,
and
this
is
the
main
goal
honestly,
if
someone
found
a
different
vulnerability,
maybe
I
don't
know
a
nasty
bucket
already
to
open
ssf.
That
is
all
public
that
should
not
be
public
I
prefer
that
contact
us.
B
A
A
B
A
B
Do
this
yeah
it's
a
a
human
task,
definitely
something
that
human
can
do
yeah,
and
this
is
all
from
my
from
my
for
me
all
the
updates
that
I
have
at
the
moment
I'm
blocking
on
this,
because
after
that
we
have
a
security
policy.
I
can
continue
to
match
that
pull
request
about
Security
in
size,
but
it
is
good
that
we
are
working
on
this.
So.
A
A
B
A
David
welcome.
We
were
just
chatting
I.
Think
the
one
Viewpoint
that
that
we
were
just
chatting
about
before
you
joined
was.
Does
it
make
sense
to
enable
private
vulnerability
reporting
on
every
open,
ssf
GitHub
repo,
and
we
think
the
answer
is
yes,
so
Luigi's
gonna
post
that
to
tack
but
I,
don't
know
if
you
had
strong
feelings.
Why
that
wouldn't
be
a
good
idea?
That
seems
like
a
slam
done
easy
easy
one.
E
D
E
E
B
E
In
fact,
for
the
best
practices
badge,
we
have
a
pull
request
not
merged
in
yet,
where
we're
going
to
refer
to
that
vulnerability,
reporting
process
as
something
that
folks
can
enable
nice.
Not
you
know
we
require
people
have
a
way
to
report.
It
doesn't
have
to
be
that,
but
we
are
planning
to
point
to
that
as
a
way
to
implement
it.
Yeah.
A
E
Right,
the
obvious
way
to
do
that
is:
have
it
as
a
scorecard's
measure.
Yes,
I
think
they're
probably
going
to
be
reticent
as
long
as
it's
considered
experimental,
but
the
way
we
can
help
is
why
don't
we,
the
open,
ssf,
add
it?
Yes,
it's
experimental,
but
we'll
get
experience.
And
after
that,
then
we
can
put
it
in
scorecards
I.
B
Yeah
yeah
I
think
that
having
a
sort
of
experimental
information
that
maybe
don't
change
for
now
the
the
average
or
the
the
value
and
the
result
of
scorecard,
but
give
you
more
information,
it
can
be
a
nice
feature
and
yeah
I
can
ask
if
they
want
to
implement
this
I.
Don't
I,
don't
know
if,
for
now,
GitHub
I
have
a
still
I
mean
have
a
way
the
API
to
know
if
this
feature
is
enabled
or
not
I
think
so,
but
not
totally
because
it
is
a
payment.
A
Cool,
so
the
only
thing
I
wanted
to
share
and
I
shared
this
through
a
couple
different
channels,
but
the
Assurance
assertions
work
that
I
presented,
I,
don't
know,
I,
don't
know
some
sometime
in
the
past
now
has
a
website
where
I'm,
collecting
and
showing
the
data.
So
you
are
welcome
to
peruse
that
and
feedback,
both
good
and
especially
critical
feedback.
Please
send
it
either
direct
to
me
or
is
an
issue
or
slack
or,
however,
for
the
purpose
of
of
this
is
to
here.
A
A
A
Some
of
it
is
metadata
that
you
know,
frankly,
already
exists
in
other
places,
but
some
of
it
is
new
stuff.
So
the
fact
that
clam
AV
ran
against
the
contents
of
left
pad
and
found
zero
infected
files
is
a
is
a
good
thing,
and
what
that
really
means
is
that
the
there's
a
policy
that
requires
that
no
virus
or
malware
be
detected
and
that
you
can
so
so
the
evaluation
of
that
policy
requires
an
assertion
of
type
summer
here:
clam
AV,
I,
guess,
yeah
I
think
it's
this
one.
A
So
putting
this
putting
this
all
together,
it
allows
you
to
express
your
expectations
for
the
security
quality
of
a
piece
of
Open
Source
as
evaluated
by
certain
tools.
We
will
provide
tools.
People
can
bring
their
own
tools,
they
can
bring
their
own
policies,
they
can
ignore
our
policies
and
create
their
own.
A
So
if
all
you
cared
about
were
like
what
are
critical
vulnerabilities,
well,
you
only
look
for
those
policies
and
if
you
want
to
integrate
into
your
own
thing,
well,
there's
an
API
for
that
and
you
can
just
integrate
this
and
do
whatever
we'll
probably
have
a
full
like
database
dump.
If
you
wanted
to
just
do
the
whole
thing,
what
else
we've
got
API,
docs
and
ability
to
request
new
packages?
This
doesn't
do
anything
at
this
point,
but
it's
it's
there.
A
A
A
I've
been
chatting
with
Oliver
a
bit,
we
do,
we
do
need
to
align
we're
chatting
in
two
areas.
One
was
a
collect
collecting
now
known
malicious
packages
as
they
are
taken
down,
either
to
either
as
physically
a
repository
of
malicious
packages
for
researchers
or
just
as
the
metadata
for
tools
to
kind
of
consume
and
and
expose
that
was
that
was
one
and
the
other
one
was.
A
C
So,
regarding
the
open
source,
maintainer
Summit,
we
have
had
the
summit,
but
then
the
enthusiasm
level
have
dropped
a
little
bit
in
following
up
on
on
the
like
on
the
notes
that
we
had
and
basically
making
a
presentation
out
of
that
I'm
I'm
still
coordinating
with
people
I
was
expecting.
That
would
have
something
by
the
end
of
March.
It
might
be
pushed
by
another
15
days,
or
so
at
least.
A
C
Time
yeah,
we
did
have
like
post
event,
event,
survey
and
I
mean
out
of
politeness
or
whatever
I
mean
people
were
overwhelmingly
positive
and
they
actually
wanted,
like
majority
of
the
results,
I
think
where
that
they
wanted
like
or
twice
every
year
or
something
like
that,
something
similar,
but
but
then
then
I
mean
yeah,
there's
obviously
Logistics
Etc.
That
needs
to
be
figured
out
at
least
like
for
now.
C
Our
goal
is
to
go
through
the
like
the
read
set
of
notes
that
we
have
like
made
in
the
in
the
two
meeting
rooms
and
then
make
some
sense
out
of
it
and
then
make
a
blog
post
also
probably
present
present
to
Tech
or
something
I
I.
Don't
know,
I
mean
that's,
but
it
looks
like
that.
There's
some
interesting
observations,
Etc
that
are
there,
and
so
so
we
will
have
a
good
report.
It's
just.
When
do
we
have
it?
It's
like
they're
having
commitment
from
people
at
this
point
is
difficult,
but
yeah.
A
C
Was
we
had
16
plus
eucenia,
so
16
maintainers,
and
so
eight
in
each
room?
It
was
well
I
mean
and
even
then,
like
we
had
the
55
minute
or
65
minute
session,
and
not
everybody
ended
up
talking
that
much
anyway.
So
I
think
like
between
10
to
20
each
sorry,
10
people
like
five
to
ten
people
in
each
room
is
a
good
setup.
Now
the
question
is
depending
on
the
people
attending
in
future,
we
can
probably
like
create
more
rooms.
C
A
A
C
C
There
are
values
in
having
like
people
from
different
backgrounds
like
JavaScript
people,
with
C,
CC,
plus,
plus
people
and
and
so
on,
in
the
same
room
as
in
maybe
there's
good
exchange,
but
I
mean
that
could
be
also
deterring
in
in
some
cases
so
that
that,
like
aligning
the
rooms,
maybe
the
diversity
is
good,
because
we
want
to
have
different
ideas,
but
then
that
might
cause
unnecessary
conflicts
or
or
like
the
people
are
not.
Everybody
are
on
the
same
page.
C
A
E
I
drop
at
least
yeah
quick
comment
on
that.
I
think
that
if
we're
going
to
go
in
depth,
it
might
be
helpful
to
divide
by
ecosystem,
because
otherwise
you
know
someone
who
the
folks
who
are
writing.
Javascript,
you
know
say
you
know:
server-side
libraries
are
not
necessarily
I
have
a
lot
in
common
with
somebody
who's
writing.
You
know
rust
or
whatever
so
I
think.