►
From YouTube: OpenSSF Vulnerability Disclosures WG (January 25, 2022)
A
A
A
A
I
found
Jonathan's
two
issues
and
we
will
get
started
for
today.
Welcome
to
the
inaugural
of
vulnerability
disclosure
working
group,
a
very
special
APAC
friendly
time
zone
call
I
am
probe
I'm.
The
working
group
lead
for
this
and
several
other
open
ssf
projects.
A
Information
about
our
working
group
can
be
found
not
only
at
the
top
of
this
meeting
agenda
linked
to
our
git
repo,
a
link
to
our
slack
Channel,
there's,
also
a
link
to
the
open,
ssf
YouTube
channel.
Every
meeting
of
the
openssf
is
recorded
and
is
publicly
available.
So,
if
you're
ever
curious
about
any
of
the
activities
of
any
of
the
working
groups,
sigs
or
projects,
typically,
that's
a
great
place
to
start
and
kind
of
get
up
to
speed.
A
With
current
activities
of
the
group,
we
had
some
requests
from
my
friends
from
Google
who
I
believe
managed
the
osv
project
to
have
to
start
this
time
start
this
call.
A
So,
as
is
tradition
and
all
the
working
groups,
we
go
around
and
introduce
ourselves
so
again.
I'll
start
I'm,
probe
I'm.
The
working
group
lead
for
the
vulnerability
disclosure
working
group
I'm.
Also
the
chair
for
the
open
source
security
and
Center
Response
Team
Sig,
developer,
best
practices,
working
group,
education,
Sig,
the
diagram
where
Society
say
I'm,
a
representative
of
the
technical
advisory
committee
and
I
also
participated
in
the
public
policy
committee
and
the
new
governance
committee.
A
I
work
at
Intel
I'm,
a
secure
director
of
security
Communications
here
and
I,
get
to
play
with
open
source
stuff
for
fun.
I've
been
engaged
in
open
source
for
about
a
open
source
security
for
about
a
decade.
I
used
to
work
at
Red
Hat
with
the
product
security
team
and
I've
been
able
to
carry
on
with
my
work
here
at
Intel
to
continue
my
engagement
with
the
open
ssf
so
with
either
of
you,
gentlemen,
like
to
introduce
yourselves
and
say
hello,.
B
Okay,
so
stop
myself
so
I'm
a
marketer
from
the
Minnesota
Japan
and
some
people
having
this
Asian
friendly
time
zone,
so
that's
an
intuition
to
join
and
to
understand
what
they're
doing
and
actually,
the
only
two
companies
joining
the
open
SSS
from
at
this
time
from
Japan.
Maybe
are
three
three
companies
and
we'll
start
discussing
about
how
to
contribute
the
entire
open
source
activities,
and
this
is
my
I-
have
to
understand
the
this
working
group
because
then
not
many
working
reproductive.
B
So
your
staff
and
the
discretion
staff,
and
also
the
best
practice
stuff,
is
the
most
active
yeah
yeah.
Currently
working
so
I
want
to
understand
what
you're
doing
and
I
want
to
find
a
way
to
how
to
contribute
to
this
stuff,
but
actually
I'm.
There
like
either
I'm
a
cheap
company,
so
I'm,
not
specialist,
so
still
in
the
very
early
learning
cup.
But
we
try
to
encourage
my
team
and
also
the
Japan
companies
so
to
contribute
more
to
the
Open
Season.
So
that's
that's
about
it
yeah.
Thank
you.
A
Excellent
welcome
we're
very
glad
to
have
you
and
that
very
much
was
noted
that
we
have
okay
engagement
with
Europe
and
Asia
in
particular,
is
kind
of
a
gap
for
us,
so
we're
hoping
to
improve
that
this
year.
So
welcome
I'm,
glad
you're
able
to
participate.
C
Hi
so
I'm
on
our
office
and
I'm
from
the
U.S,
so
I
I.
Sorry
I
spoke
with
you
like
over,
because
we
are
organizing
this
virtual
Summit
for
open
source
maintainer.
So,
but
never
like
formally
met
with
you.
So
I
don't
know
like
how
do
I
refer
to
you.
Should
I
call
you
Christopher
or
am
I.
C
Coming
okay
but
yeah,
so
I'm,
the
CEO
of
of
a
static
analysis,
tool,
company,
we're
building
a
better
tool
that
detects
bugs
that
other
pools.
Miss
also
does
that
with
dramatically
low.
False
positive
I
have
participated
in
this
group
some
time
ago,
but
not
presented.
I
mean
in
the
past
few
weeks,
especially
since,
like
Jonathan
joined
in
Alpha
Omega
project,
and
he
was
like
pushing
something
in
this
particular
group.
I
was
planning
to
attend,
but
then
yeah
because
of
the
timing.
C
There
are
two
meetings
that
will
be
organized
every
every
month
like
there's
one,
that's
the
U.S
time
the
regular
time
and
then
there's
this
one.
In
addition,
so
the.
A
Regular
working
group
meet
twice
monthly
and
that's
during
early
morning
hours,
so
we
have
a
lot
of
European
participants,
so
we
are
able
to
pick
up
them
and
then
this
call,
depending
on
participation,
we're
going
to
start
off
with
monthly
and
as
we
go
along.
If
we
have
a
lot
of
interest
we're
welcome.
We
can
ratchet
that
up,
so
we
can
have
more
frequent
calls
with
this
time
zone
and
potentially
even
adjust
it
further
back,
but
just
of
the
people
that
participated
in
the
survey.
C
So
so
what
we
are
doing
is
so
we
are
working
with
the
I'm,
mostly
working
with
the
identifying
security
threats
and
the
alpha
omega
groups,
and
we
are,
we
have
built
a
triaging
dashboard
of
like
we
have
run
on
the
top
for
now
on
the
top
1000
python
projects
in
the
pipi
repository.
We
are
considering
expanding
on
that,
and
then
there
is
a
triaging
dashboard
that
we
have
created
where
we
then
manually,
tries
those
vulnerabilities
and
then
submit
those
reports
and
I
was
like
involved
in
this
like
email
slack.
C
Storm
I
mean.
Is
that
if
that's
a
problem
yesterday
like
about
like
what
what
are
the-
and
this
is
something
that
so
in
the
past
couple
of
weeks,
we
have
submitted
about
20
something
manually
vetted
bug,
fixes
bug,
slash
potential
vulnerabilities
for
some,
like
some
of
the
projects
that
we
were
scanning,
and
we
have
also
gotten
similar
response
and
they're
like
seeds
and
deceased
like
never
come
and
and
because
ours
was
submitted
through
the
open
refactory
handle.
C
So
it
appeared
like
people
thought
it
was
a
bot
or
something
it
was
not
like
they're,
a
human
who
are
behind
it,
but
we're
also
trying
to
understand
what
is
like.
Jonathan
Jonathan
is
looking
at
a
depth
first
approach
like
looking
at
a
particular
vulnerability
that
is
maybe
found
in
many
places,
and
how
do
you
create
an
automated
PR
for
doing
that?
C
We
are
doing
it
on
a
first
approach
as
in
we're
looking
at
what
is
our
tool
finding
or
what
other
tools
are
finding
then
do
that
triading,
manually
reporting
and
working
with
that
so
not
not
going
in
the
automated
route.
Yet
we
got
the
same
heat
or
similar
heat
about
like
drive
by
PRS
or
like
automated
box
submitting
stuff,
and
but
the
good
news
is
like
us
out
of
the
20
that
we
submitted,
there's
I,
think
six
or
seven
that
have
already
been
accepted.
C
But
the
the
point
is
like
I,
I
want
to
learn
and,
and
now
I
think
it's
it's
better
to
like,
come
to
this
group
more
that
that
kind
of,
because,
as
we
are,
collaborating
with
people,
it's
a
it's,
a
security
is
still
in
the
end,
a
human
activity
as
well
like
how
do
we
collaborate
with
the
maintainers
to
make
it
easy
for
them
to
appreciate
and
and
get
there
and
we'll
make
mistakes
and
they'll
make
mistakes?
It's
fine,
but
what's
the
best
way
to
collaborate,
this
I'm
here
to
learn
about
this.
So
that's
that's.
C
Why
I
got
like
I
saw
this
and
I.
Just
I
saw
your
text
and
I
on
on
slack
and
I
thought
like
I'll,
just
join
and
great
start
learning
throughout.
A
The
day
yes
and
he's
referring
to
issue
123
that
Jonathan
likeshan.
A
Recently
we
just
issued
this
week.
Yes.
C
He
dragged
me
into
this:
I
mean
I'm,
not
necessarily
doing
the
automated
PR,
but
we
are
like
we
are
looking
at
it,
as
I
said
like
we
want
to.
Both
of
us
are
passionate
about
getting
these
bugs
fixed
that
are
out
there.
There
are
even
like
low
hanging
fruits
for
for
his
cases
like
because
there's
a
tool
that
found
all
of
this.
It's
a
old
vulnerability,
five
or
six
years
old.
Yet
tens
of
thousands,
tens
of
thousands
of
projects
are
probably
still
vulnerable
or
or
weak.
C
So
how
can
we
do
a
security
hardening
so
he's
very
passionate
from
from
their
time?
I'm,
not
basically
too
much
subscribed
on
the
rewriting
and
because
my
background
is
on
building
refactoring
tools,
and
so
I
know
how
hard
writing
good
refactorings
are
and,
and
so
part
of
the
reason
that
slack
storm
happened
was
because
of
somebody
doing
massive
like
amount
of
PR's,
but
then
the
codes
were
not
compiling,
and
so
that
creates
an
extra
annoyance
and
and
so
on.
A
And
that's
it's!
A
Jonathan
has
engaged
with
our
group
for
a
while,
but
in
his
previous
roles,
it's
it's
a
very
delicate
situation.
In
general,
the
working
group
I
posted
a
link
to
our
git
repository,
which
is
also
on
the
agenda,
and
it's
at
the
top
of
our
slack
Channel
I
would
encourage,
if
you're,
not
part
of
it,
to
join
our
primary
viewpoints
that
we're
trying
to
address
would
be
upstream
maintainers
and
developers.
A
That's
primarily
the
the
constituents
that
we
work
for
we're
trying
to
provide
tooling
for
to
make
their
jobs
easier.
A
We
do
also
want
to
address
and
try
to
help
educate
the
security,
research
or
the
finder
Persona,
because
you
know,
as
as
you
folks
are
finding
things
and
Reporting
them.
We
want
to
make
sure
that
we
have
a
positive
experience
with
the
maintainer
community.
We're
also
going
to
be
addressing
the
consumer
standpoint
so
like
think
about
an
Enterprise
like
a
bank
or
an
insurance
company
or
a
retailer
that
embeds
open
source
projects
in
their
platforms,
or
they
have
vendors
that
Supply
them
open
source
platforms.
A
So
we're
looking
to
also
try
to
provide
education
for
the
consumer
Persona.
So
they
understand
how
vulnerabilities
are
managed
and
how
they're
shared
and
ultimately
communicated
so
that's
kind
of
the
high
level
things
we're
trying
to
address,
and
we
do
this
through
white
papers
or
educational
materials.
We
do
it
through
some
tooling
again.
A
big
part
of
the
kind
of
the
Genesis
of
this
call
is
there's
a
group
that
puts
out
it's
called
osv.
A
It's
open
source
vulnerabilities,
it's
a
database
of
Open
Source
vulnerabilities,
so
we're
looking
to
try
to
help
better
incorporate
them
within
the
work
within
the
open
ssf.
So,
ideally,
you
know
through
these
columns
through
these
calls
will
be
able
to
have
that
communication
and
then,
like
Jonathan's
issue,
he
just
filed.
That's
an
interesting
problem
that
we
could
definitely
talk
about,
and
you
know
be
a
sounding
board.
A
You
know
make
a
forum
that
we
can
maybe
get
developers
and
researchers
in
the
same
room
and
try
to
maybe
hammer
out
some
good
ideas
and
best
practices
to
help
advise
people
that
this
is.
If
you
want
to
conduct
these
behaviors,
these
are
good
ways
and
they're
going
to
have
more
positive
outcomes
than
just
the
the
drive-by,
which
is
a
very
common
comment.
We
get
from
a
lot
of
maintainers.
C
So
when
we,
let
me
just
share
one
experience
so
as
we
were
like
submitting
these
three
hours,
they
were
two
things
that
so
when
people
rejected
our
our
review
of
our
requests,
we
got
actually
two
kind
of
responses.
One
is
like
the
security
polarity
that
we
posted
it's
not
so
their
attack
service
is
not
there
or
the
or
it
was
sometimes
our
mistake.
A
few
times
there
were.
C
Our
mistakes
were
of
identifying
something
as
tainted,
but
it's
actually
not
like
in
one
case,
the
we
identified
that
there's
a
request
that
is
coming
it's
from
the
request,
HTTP
request,
so
it
should
be
tainted
or
marked
as
tainted,
except
that
in
that
particular
application.
C
That
request
is
coming
from
GitHub
commit
data
which
is
because,
like
GitHub
does
a
wedding,
so
so
there's
no
speed
attack
Etc
cannot
be
there
in
the
comment,
I
mean
that's
something
that
we
we
can't
know
unless
we're
deeply
involved
in
that
project,
or
in
another
case
we
posted
a
log
injection
and
say
like
well,
our
logs
are
unstructured,
so
we
don't
care
what
gets
put
on
so
no
problem
of
long
enough
again,
something
that
we
cannot
know
about
that.
C
And
then
people
got
annoyed
like
we
don't
know,
but
I
mean
we
we
get
it
I
mean
we.
We
don't
have
the
time
to
do
like
industrial
I
mean
we
can't
be
participating
in
that
project
to
understand
and
then
report,
because
we
also
want
to
fix
things
quickly
if
possible
and
and
point
things
out,
but
then
there's
the
other
side,
which
was
curious.
So
this
is
one
where
there
were
mistakes
from
our
part,
and
people
didn't
appreciate
that
I
I
totally
get
them.
The
other
side
was,
the
fix
was
valid.
C
The
bug
was
valid,
but
it
was
just
rejected,
because
people
thought
it's
a
robot
doing
it
and
and
yeah.
It's
not
like
a
vulnerability.
It
was
more
a
benign
kind
of
stuff
like
in
a
couple
of
places
where
there
were
some
logical,
short
circuits
in
code
that
our
tool
identified.
We
reported
that
that's
valid,
no
doubt
about
it,
but
then
people
said
well.
I
will
just
reject
it
because
it's
coming
from
from.
So
how
do
we
come
out
of
that?
C
That
stigma
and
Jonathan
was
suggesting
that
perhaps
posting
that
from
a
personal
GitHub
account
as
opposed
to
like
app
open
refractory
handle
that
actually
tremendously
helps
because
people
have
a
different
opinion
towards
that.
But
again
I
mean
that
these
are
some
stuff
that
we
are
learning
and
I
just
want
to
share,
because
you
might
be
familiar
with
that,
but
I
mean
this
is
just
anecdotal
evidence
that
I'm
bringing
in
from
this
experiment.
We
are
running
I've.
A
This
is
a
tension.
I've
dealt
with
a
long
time
throughout
my
career
at
red
hat,
and
you
know
currently
the
best
practices
working
group.
Last
year
or
2021.
We
had
a
project
called
the
Great
NFA
distribution,
where
we
tried
to
give
away
a
multi-factor
tokens
to
the
critical
project
maintainers
and
projects
and
I
know
exactly
how
that
response
goes.
A
If
you're
lucky
to
get
a
response,
if
you're
lucky
enough
to
talk
to
a
person
that
it
a
lot
of
these
maintainers
can
be
paranoid
and
not
trusting
and
I
definitely
get
the
Jonathan's
approach
of
going
from
a
human
perspective,
hey
I'm,
a
real
person.
This
is
a
person
putting
this
and
not
a
bot,
but
yeah
I
think
we
definitely
have
something
we
can
collaborate
on
and
put
some
guidance
together
and
possibly
incorporate
it
into
one
of
our
work
products
to
help
coach
security,
researchers.
A
Here's
some
techniques
that
you
can
take
as
you're
trying
to
report
these
vulnerabilities
that
you
could
be
more
successful
and
and
I
think
that
that'll
be
a
there's
going
to
be
a
very
robust
and
interesting
conversation
around
the
vulnerability
at
scale,
reporting
topic
so
I'm.
Looking
forward
to
that
over
the
next
couple
weeks
and
to
kind
of
talk
about
our
working
group,
we
have
we're
divided
up
into
a
couple
different
teams
that
work
on
different
things.
A
One
of
the
items
we're
working
on
is
called
the
open
source
software
security
incident
response
team.
Last
year,
the
foundation
put
out
a
mobilization
plan
that
they
said
here
are
10
items.
We
feel
that
if
there
was
investment
in,
they
could
substantially
improve
the
security
profile
of
Open,
Source
software
and
communities
and
Supply
chains.
So
one
of
those
sections,
I
believe
was
section.
Five
was
the
idea
of
creating
an
incident
response
team.
So
one
of
our
it's
a
Sig,
a
special
interest
group,
a
group
of
us
get
together
and
we
talk
about.
A
How
could
we
create
a
a
security
team
for
Upstream
and
that
plan
is
currently
under
review
by
the
TAC
and
ultimately,
if
they
once
we
make
some
changes
and
edits
that
they
propose
it'll,
go
up
to
the
governing
board
for
potential
funding
and
what
this
would
mean
and
there's
a
a
vast
volume
of
information.
A
If
you're
curious
about
this,
we
could
talk
more,
but
I
have
a
lot
of
information
posted
in
our
git
repo
and
our
notes
about
what
we've
talked
about,
what
our
goals
are,
and
then
we
have
the
re-proposal
of
the
plan
for
security
incident
response
and
another
Avenue
for
this,
like
issue
123
is
potentially
maybe
Upstream.
Maintainers
might
be
more
amenable
to
like
the
open,
ssf
being
a
vehicle
to
convey
these
vulnerability
reports
and
again
I.
Don't
know
that
that
would
be
accepted
by
the
group.
But
that's
that's.
A
A
potential
option
we
can
discuss
is
if
this
cert
is
formed.
Maybe
that
cert
helps
coordinate
and
manage
that
communication
between
the
researcher
and
the
maintainer
and
there's
a
a
lot
of
detail.
The
plan
is
broken
up
into
three
parts
of
how
we
can
build
the
right,
tooling
and
infrastructure
recruit
the
team
and
then
talks
about
some
of
the
processes
that
we
envision
the
piece
or
this
cert
could
follow.
So
that's
one
of
our
work
items.
A
This
is
how
you
can
react
to
security
researchers
or
other
parties,
reporting
vulnerabilities
and
flaws
to
you
and
how
you
can
follow
good
practice
in
coordinating
the
the
triage
remediation
and
ultimately,
patching
and
disclosure
of
these
issues.
So
that
was
our
first
guide.
It's
been
in
existence
for
almost
two
years
now,
I've.
A
And
then
you
know
based
off
the
feedback
we
got
on
those
two
guides:
we're
going
to
be
we're
just
now,
creating
a
new
work
item.
Where
we'll
be
talking
about
how
Downstream
consumers
can
understand,
Upstream
vulnerability,
coordination
places,
they
should
monitor,
and
you
know,
behaviors
they
should
take
to
protect
themselves
if
they
use
which
they
probably
do
if
they
use
open
source
software.
So
things
like
understanding,
you
know
it.
What
is
your
support
agreement?
Do
you
have
a
supplier
that
supplies
this
software
to
you?
A
Are
you
directly
pulling
it
from
upstream
and
kind
of
talk
about
the
differences
there
so
just
providing
some
advice
for
consumers
on
how
best
to
protect
themselves
and
manage
their
risk
with
open
source
vulnerability
management?
It's
we
also
are
now
based
off
of
those
guides.
One
of
our
members
from
Google
is
looking
at,
create
trying
to
create
some
automated
tooling
to
go
in
concert
with
those
guides,
so
that
you
know
we
tell
we
advise
maintainers.
A
You
should
have
a
security
like
a
vulnerability
disclosure
policy
and
you
should
have
a
security
MD
file
that
describes
what
you
do
and
vulnerabilities
come
in,
so
we
potentially
could
create
a
canned
template
that
is
very
easy
for
them
to
update
and
use
for
their
own
kind
of.
You
know
Fork
that
and
use
that,
for
their
own
purposes,
we
potentially
could
provide
tools
through
GitHub
actions
or
I,
can't
recall
what
the
analogous
tool
is
in
gitlab,
but
basically
provide
some
scripts
to
allow
some
of
the
automation
handling,
like
maybe
creating
vulnerability.
A
A
We
have
the
open
source
vulnerability
team,
which
is
a
database
kind
of
parallels,
nvd
or
GSD,
but
they're
trying
to
collect
all
the
information
about
vulnerabilities,
reported
within
open
source
and
right
now,
it's
related
to
a
couple
different
communities
and
I
think
through
these
calls
in
this
time,
we'll
be
able
to
potentially
help
expand
the
use
of
that
and
potentially
get
that
integrated
into
more
communities
and
better
integrated
within
the
kind
of
the
the
cve
slash,
vulnerability,
identifier,
ecosystem
and
then
just
yesterday
we
have
a
new
project
we
might
be
taking
on
within
the
industry.
A
There's
a
proposal
for
a
new
security,
vulnerability,
advisory
piece
of
information.
It's
called
Vex
vulnerability,
exchange
and
I've
got
some
links
in
a
call
from
yesterday
I'll
repost
in
this
call.
But
basically
the
idea
is,
as
a
software
maintainer
is,
you
know,
writing
up
their
security
advisory
and
going
public
with
their
patch
by
providing
a
couple.
Additional
pieces
of
information
in
the
Vex
format
we
can
describe
to
Downstream
consumers
is,
is
the
software
affected?
A
A
So,
if
the,
if
your
maintainer
had
replied
back
with
more
of
a
automated
Vex
response
that
potentially
could
have
given
you
more
information
about
why
that
vulnerability
wasn't
exploitable
and
Vex
kind
of
goes
in
partnership
with
a
another
industry
thing
called
s-bombs
software
bill
of
material,
which
is
getting
a
lot
of
talk
in
the
US
and
the
EU
actually
I
believe
the
EU
will
be
passing
some
legislation
making
s
a
version
of
s-bombs
kind
of
the
law
of
the
land
in
the
European
Union
this
year
and
I
have
heard
similar
talks
in
Australia
and
I
believe
other
Asian
countries.
A
So
while
it
started
in
the
US,
you'll
see
things
like
s-bomb
becoming
more
globally
focused
and
we
think
by
kind
of
jumping
early
on
to
Vex,
we
can
help
get
ahead
and
help
a
consumer
who
has
a
software
bill
of
materials,
which
is
a
list
of
components
inside
the
software
they
use
and
Vex
can
say
you
know
this
component
is,
has
a
vulnerability
but
you're
not
affected.
This
other
component
has
a
vulnerability,
but
you
are
affected
and
here's
how
to
get
the
patch.
So
it's
just
an
augmentation
of
the
advisory
and
vulnerability
information.
A
C
A
And
so
that's
the
kind
of
the
current
working
activities
we
have
on
the
docket
and
then
yesterday
Jonathan
filed
the
two
issues
one
is
around.
He
wants
to
get
a
group
together
to
talk
about
how
we
can
kind
of
collaborate
on
solving
the
problem
of
reporting
vulnerabilities
at
scale.
You
know
you
find
you
run
a
scanner
and
you
find
dozens,
hundreds,
thousands
of
vulnerabilities
in
a
project.
How
best
can
you
get
that
reported?
A
And
then
he
also
there's
a
smaller
project.
He
proposed
issue
122,
which
is:
could
we
please
help
them
write
a
security
policy
for
the
alpha
omega
project,
which
I
think
Madison
Oliver
from
GitHub
and
I'll
probably
grab
that
and
just
help
him
write
it?
Okay?
A
C
I
mean
this
looks
pretty
comprehensive,
I
mean
and,
as
I
said,
I'm
still
like
finding
my
way
through
this
particular
group
I
previously
joined
this
one
for
a
couple
of
meetings,
but
then
because
I'm
in
the
like,
as
a
as
a
tool
vendor,
there's
more
alignment
with
the
alpha
make
at
the
other
group.
So
that's
fine
and
there's
always
like
a
finite
amount
of
time
that
you
have
so
that's
why?
But
now
that
I
mean
we
are
reporting
it
to
to
people
not
necessarily
vulnerabilities,
there's
bugs
there's
security,
hardening
things
and
and
so
on.
C
But
but
then
then
these
issues
now
are
becoming
Center
Stage
as
far
as
I'm
concerned,
because
how
do
we
effectively
do
that
without
creating
a
lot
of
fiction
and
also
I
guess
reputation
of
our
company?
That's
also
a
state
I
mean
if
people
perceive
us
as
Bots.
That's
not
a
good
good
perception
that
you
want
to
have
right.
So
so
it's
it's
from
that
perspective.
D
C
Know
Medicine
by
the
way
and
so
yeah
and
it's
nice
to
meet
you
meet
with.
A
And
to
address,
like
the
Japanese
perspective,
just
late
last
year
we
had
our
inaugural
open
ssf
day
in
Japan,
which
I
didn't
have
the
opportunity
to
attend,
but
I'm
told
I
talked
with
David
wheeler
he's
one
of
the
open
ssf
employees.
I
was
told
from
him
that
it
was
pretty
very
well
attended.
We
got
a
really
good
response
from
the
Japanese
Community,
like
we
announced
our
training
from
the
best
practices
group
has
been
translated
into
Japanese
and
available
for
native
speakers.
A
So
I
think
that
was
so
successful
that
you
will
continue
to
see
that
again
in
2023
and
I
think
there's
definitely
going
to
be
more
Outreach
around
the
globe
and
I.
Think
APAC
and
Africa
are
two
reasons:
regions
we
don't
have
a
lot
of
Engagement
with,
but
we'd
really
like
to
get
more
feedback
and
opinions
from
that
those
parts
of
the
world.
Okay,.
B
That
was
very
nice
and
many
from
this
you
today
talking
about
the
current
employment,
it's
a
open
source
developers
and
maintenance
and
unfortunately,
the
most
of
the
attendee
was
a
consumer
of
the
open
source
of
stocks,
but
to
be
very
curious
about
understanding
the
how
to
calculate
that,
because
formally
in
the
main,
10
15
years
ago,
so
many
things
open
source.
They
are
dangerous
things,
but
when
people
start
thinking
about
this
is
an
incorrect
understanding
and
they
need
to
unfree
understand
how
to
manage
this.
B
Attacking
the
exposing
the
such
kind
of
information,
how
to
fix
them
in
short
term
here.
So
just
kind
of
study
is
a
real
penetrating
the
many
companies
and,
of
course,
actually
I'm.
A
chip,
company
and
I
have
been
contributing
some
devices
so
that
might
related
standard
abundant
potential
by
an
empty
things,
but
in
general.
So
the
many
because
you
know
the
many
people
start
using
their
tons
of
the
open
source
combined
and
they
don't
understand.
Where
is
the
most
critical
part?
B
So
we
should
understand
the
the
overview
of
such
kind
of
the
open
source
landscape
and
we
need
to
prioritize
which
part
to
start
with.
So
this
is
because
actually
I'm
working
with
the
creation
is
a
real
expansion,
Japan
managers
and
to
encourage
the
peoples
from
the
IIT
Industries
and
the
Telecom
industry
to
jump
into
this
activities.
So
I
think
that
is
a
very
nice
start
point
and
we
need
to
keep
the
some
kind
of
a
momentum
to
the
increase
in
the
visibility
in
Japan
and
Asia.
Yeah
agreed.
A
And
not
to
discourage
you
from
participating
here,
I
would
love
for
you
to
continue
to
participate,
but
two
additional
areas
you
might
want
to
try
to
monitor.
A
There
is
an
end
user
working
group
and
it's
led
by
gentlemen
out
of
the
UK
Jonathan
Meadows
and
they're
focused
on
consumers
of
Open
Source.
So
they
are
a
lot
of
Europeans.
So
I
don't
expect
that
meeting
time
will
change,
but
you
definitely
can
monitor
the
output
and
watch
the
working
group
calls
because.
D
A
D
A
Have
a
whole
other
part
of
the
mobilization
plan
where
we're
creating
more
training
and
there
will
be
training
for
maintainers,
but
also
things
like
development
managers,
Auditors
people
that
are
responsible
for
reviewing
companies
that
use
open
source
and
then
also
open
source
consumers.
So
that
would
be
another
potentially
useful
stream.
Just
to
keep
an
eye
on
to
Monitor
and
I
do
think
the
best
practices
group
probably
will
start
a
APAC
focused
call
as
well,
probably
the
second
half
of
the
year.
So.
B
B
A
And
if
you
need
any
literature
or
any
information
about
the
foundation,
don't
hesitate
to
reach
out
to
me,
I'll
be
glad,
share,
presentations
or
links
to
help
you
kind
of
share
the
message
with
those
constituents
there.
Thank
you
very
much.
Yeah
you're
very
welcome,
sir.
A
So
there
any
other.
Do
you
feel
like
talking
about
the
docket
of
work?
We
have?
Is
there
anything
that
either
of
you
would
be
interested
in
learning
more
about
or
potentially
you
know,
bringing
back
to
this
call
to
have
more
further
conversations.
I
know
that
the
vulnerabilities
at
scale
is
definitely
of
interest,
but
are
there
any
of
the
other
topics
we
talked
about,
that
might
be
of
interest
to
bring
a
guest
speaker
or
bring
that
debate
or
conversation
to
this
particular
call.
Next
time.
A
C
C
A
We
tend
to
see
some
folks
from
Academia
in
a
couple
of
the
working
groups-
it's
not
quite
as
in
we'd,
like
better
engagement
with
you
know,
folks
from
all
parts
of
the
spectrum,
but
it
tends
to
be
most
students
when
you're
going
for
your
your
Masters
or
your
dissertation
for
your
doctorate.
They'll
have
to
have
some
project
so
they'll
generally
come
and
listen
to
us
and
things.
I've
had
a
lot
of
presentations
with
students
presenting
their
work
and
ideas.
A
All
right,
I
know
next
time
we
will
have
I
know
of
it
several
friends
from
Australia
that
will
be
joining
the
call.
But
beyond
that
please
share
the
word
we
are.
We
really
want
this
call
to
grow
and
have
many
participants
and
kind
of
be
able
to
get
your
feedback
and
I.
You
know
ideas
on
things
that
we
need
to
be
working
on
and
help
address
issues
in
your
communities.
A
Awesome
well,
if,
if
you
is
there
anything
else,
you'd
like
to
discuss,
if
not,
we
can
adjourn
yeah.