►
From YouTube: OpenSSF TAC (January 10, 2023)
Description
Meeting minutes: https://docs.google.com/document/d/18BJlokTeG5e5ARD1VFDl5bIP75OFPCtzf77lfadQ4f0/edit#heading=h.9m0zi4b0wnne
B
A
A
A
B
C
D
A
D
A
Very
fair,
if
you
have
anybody
in
your
sphere
or
anybody
else
in
this
call,
has
anybody
in
their
sphere
that
happens
to
have
a
schmoo
ticket
or
is
willing
to
poke
their
poke
their
or
you
know,
shake
their
tree
of
Social
Circles
to
see
if
they
can
shake
out
a
shmukon
ticket?
The
alpha
omega
team
would
be
greatly
appreciative.
E
E
B
E
John
Meadows
on
the
list
so
we'll
we
will
punt
the
end
user
working
group
topic
to
later
in
the
agenda
probe.
I
think
you
had
mentioned
a
couple
of
these
briefly
before
we
went
on
holiday
as
being
fyi's,
but
there
are
two
updates
or
I
guess
two
proposals,
rather
that
you've
been
wanting
to
bring
into
this
group
I
will
hand
it
over
to
you
right.
B
We
spoke
a
month
ago,
I
requested
the
tax
feedback
on
these
two
proposals.
The
first
proposal
is
funding
to
re-home
the
current
private
and
public
OSS
Security
mailing
lists.
They
have
been
in
existence
in
some
form
or
other
since
2008,
and
that
is
how
most
of
traditional,
open
source
coordinates
and
informs
around
vulnerability.
B
So
he
proposed
two
different
scenarios,
essentially
one
where
we,
the
foundation
potentially
would
fund
new
equipment
and
connectivity
and
then
where
he
would
solar
would
continue
on
with
some
administrative
functions.
And
then,
if
we
were
interested
in
expanding
the
services
and
capabilities
of
the
list,
he
included
some
additional
additional
request
for
funding
for
for
those
efforts,
if
the
foundation
desires
to
increase
the
utilization
and
services
that
the
lists
offer.
E
B
B
B
So
he
at
this
point,
is
not
interested
in
direct
assistance
in
operating
the
list.
He
that's
part
of
the
fee
that
he
would
continue
on
to
help
maintain
the
lists,
but
as
we
continue
to
earn
his
trust,
we
potentially
could
be
able
to
help
provide
people
to
assist
with
the
maintenance
in
the
list
or
evangelism
of
the
list.
So
it's
just
basically
at
this
point.
He
wants
money
for
equipment
and
connectivity
and
then
a
a
maintenance
fee.
E
I
guess
my
my
only
question
under
those
sorts
of
constraints
would
be,
should
this
be
put
out
as
a
an
opportunity
for
the
foundation
to
fund
or
an
opportunity
for
a
particular
Foundation
member
I
mean
we
have
many
members
that
actually
do
create
Hardware
as
part
of
their
business,
so
as
a
worthy
donation
to
to
something
versus
it.
Being
kind
of
something
that
has
to
come
out
of
run
rate
budget
would
be,
would
be
a
question.
I
guess
I
would
have
in
terms
of
like.
E
B
E
H
From
an
open,
ssf
staff
point
of
view,
there's
not
really
any
burden
here,
because
what
I
see
being
proposed
is
simply
and
ask
for
funding
that
would
go
to
to
somebody
else
to
do
the
hard
work.
So
there's
not,
as
I
see
a
kind
of
an
impact
on
us,
except
for
tracking
the
spend
or
or
kind
of
just
like
the
the
administrative
glue,
but
but
not
to
run
the
servers
ourselves
or
run
any
operations,
or
anything
like
that.
So
supportive
of
that.
H
You
know
from
a
from
a
from
your
point
of
view
and
then
our
job
once
once
you've
you've
come
to
that
our
job
at
my
job
as
like,
open,
ssf
GM
and
our
job
is
Staff
as
well
as
folks
like
Bob
and
and
then
on
the
on
the
governing
board
is
decide.
Do
we
want
to
try
to
Source
this
from
some
bucket
of
funds?
B
And
and
I'll
note
before
we
move
to
Justin,
he
was
very
receptive
to
the
idea
of
you
know
if,
like
our
next
proposal,
is
the
open
source
security
cert,
he
was
very
receptive
to
that.
The
his
lists
becoming
a
key
component
to
the
Outreach
and
communication
post
coordination,
so
he's
very
open
to
expanding
the
use,
and
you
know
the
reach
of
the
lists,
and
you
know,
comments.
Welcome
Justin.
I
I
mean
it
seems,
an
incredibly
inefficient
usage
of
funds
to
stand
up
and
on-prem
email
server,
because
we
have
one
maintainer.
That's
paranoid
and
I
know
that's
a
bit
of
a
spicy
take
but
like
I
I
feel
like
there
are
more
efficient
ways
for
us
to
use
our
money
to
have
higher
impact
than
spending
on
an
incredibly
expensive
email
server.
When
there
are
things
that
this
organization
could
do
that,
no
other
organization
is
well
placed
to
do
foreign.
G
Justin
is
right,
but
I
think
the
thing
I
would
try
to
keep
in
mind
is
an
enormous
amount
of
like
Linux
kernel
and
kind
of
the
low-level.
Distro
stuff
is
coordinated
by
this,
and
it's
all
going
through
Russia
right
now
and
that's
like
a
terrifying
Prospect
and
so
you're
100
correct,
but
the
reality
is
also
very
dire.
I
think
at
the
moment,
so
I
think
that's
something
we
need
to
think
about
as
well.
I
I
mean
there's
I,
don't
think
perfect
world
yeah.
B
And
he
has
problems
with
connectivity.
You
know
the
internet
pipe
to
the
facility
is
not
always
super
stable.
There
are
problems
with
external
people
connecting
because
of
block
lists,
for
example.
So
there's
a
lot
of
connectivity
challenges
for
people
trying
to
get
to
the
list
because
of
where
the
location.
E
J
K
C
E
E
The
bleeding
in
a
sense
but
looking
forward
I,
think
again,
is
it
within
the
charter
of
our
our
organization,
more
broadly,
or
what
a
member
organization
be
happy
to
stand
up
and
help
to
to
do.
This,
I
think
is
maybe
an
interesting,
further
discussion,
but
I
think
to
to
Brian's
Point
around
the
attack
does
not
make
funding
decisions.
The
tax
simply
makes
recommendations
around
things
are
worthy
or
not,
and
so
I'd
like
to
keep
the
discussion
focused
around
on
that
point,
Abhishek.
L
So
I
wanted
to
discuss
Justin's
point
a
little
bit
more,
because
I
feel
slightly
the
same
way,
which
is
what's
a
long-term
solution
to
this
problem
like
other
than
moving
the
infrastructure.
If
he
does,
let's
say
some
additional
work
to
Port
these
vulnerabilities
to
let's
say
a
better
schema
like
osv
schema
or
puts
them
in
GitHub
security
advisories.
That
might
be
a
long
term
win
which,
which
would
see
as
part
of
this
journey
like
if
it's
just
let's
say,
moving
infrastructure
from
one
place
to
another.
I,
don't
see
it
as
a
good
way.
E
C
E
D
B
D
The
time
thank
you
for
confirming
that
that
matches
what
I've
done
in
other
Communities,
going
back
to
openstack
days,
where
we
had
similar
private
and
then
public
lists.
I
can
quite
well
understand.
Solo
designer's
concerns
about
putting
this
on
a
cloud
using
donated
infrastructure
using
the
hardware
that
someone
else
bought
and
then
gave
to
him.
All
of
those
would
be
red
flags
if
I
were
running
such
a
list
myself
and
there
are
challenges
and
repeat
what
I
wrote
in
chat
with
running,
truly
zero
knowledge
based
email
in
certain
places.
D
So
yeah
I
think
this
is
an
important
thing.
Important
part
of
the
open
source
ecosystem
I
think
it's
from
a
foundation
perspective.
It
doesn't
sound
like
it
will
require
much
of
our
pool
to
do
this
right.
It
doesn't
require
significant
staff
time.
It
does
require
us
talking
about
it
being
aware
of
it.
It
might
be
a
thing
that
we
can
say:
hey,
look.
We
are
helping
open
source
as
a
whole.
D
In
this
way,
and
really
all
we're
doing
is
connecting
the
right
resources
to
a
person
who
needs
it
right
now
and
it's
a
pretty
good
media
op.
If
we
want
to
turn
this
into
a
media
Optimum,
the
attack
isn't
making
decisions
based
on
media
awareness,
but
maybe
not
media,
but
at
least
in
open
source
circles.
We
did
a
good
thing.
H
F
This
is
just
really
quickly.
I
I
agree
that
I
think
that
this
needs
to
be
sort
of
Taken
Offline
that
they're
not
going
to
solve
it
here.
I
mean
all
the
respect
to
the
the
attack
here.
Do
I
think
that
it
would
be
good
to
try
to
find
a
long-term
solution
to
you
know
differentiate
between
what
you
want
to
actually
technically
solve,
first
and
whether
again,
not
necessarily
the
tech
here
itself
making
decision,
but
a
person
others
to
decide
that
you
know,
can
you
have
a
conversation
with
this
person?
F
B
H
B
F
H
B
B
E
So
here's
what
I
would
ask
for
curve
I
know
you've
written
up
the
the
issue
in
GitHub
I
guess,
if,
if
you
would
wouldn't
mind
taking
this,
the
stab
at
that
proposed
note
that
we
would
send
to
the
governing
board
effectively
framing
the
conversation.
This
is
what
the
essential
recommendation
is.
I
think
we
can
have
a
sounds.
E
E
E
K
K
As
you're
trying
to
do
that,
I'll
talk
through
anyway,
so
really
one
of
the
things
that
we
trying
to
do
through
the
end
user
group
is
trying
to
identify
how
to
mitigate
supply
chain
attacks
and
how
to
discuss
them.
And,
what's
clear,
is
actually
it's
the
second.
It's
the
other
document
Andrew,
if
that's
possible,
and
one
of
the
problems
we
have
is
we're
calling
things
different
things
and
it's
difficult
to
figure
out
which
which
attack
to
mitigate
with
what.
K
So,
what
we're
trying
to
do
is
pull
together
a
common
taxonomy
and
that's
one
of
the
things
that
we
started
to
discuss
as
a
group
and
what
we
found
was
that
Henrik
and
Pierre
Giorgio
who
joined
the
the
call
here
have
actually
created
a
paper
based
that
was
describing
the
taxonomy
of
supply
chain
attacks.
We
reviewed
this
and
it
looked
to
be
a
really
useful
construct
to
help
us
explain
what
supply
chain
attacks
were
in
the
wild
and
how
we
could
actually
mitigate
them.
K
So
our
proposal
is
that
we'd
adopt
the
taxonomy,
bring
it
into
the
end
user
group
and
help
to
maintain
and
grow
it
and
perhaps
distribute
that
through
the
OS
server
to
identify.
This
is
how
we
can
talk
about
specific
supply
chain
attacks.
Now,
in
addition
to
that
taxonomy,
they
also
have
the
paper
that
is
referenced
there,
but
a
online
Explorer
tool,
which
is
quite
a
useful
visualization
of
that
taxonomy.
That
I
think
people
may
have
seen
before
and
there's
potential
to
bring
that
into
the
group.
K
The
original
developers
Henrik
and
his
previous
company
are
certainly
supportive
of
contributing
that
back
over
to
us,
so
that
that
could
be
something
that
we'd
look
to
pick
up.
But
the
main
point
here
is
to
adopt
that
taxonomy
and
then
we'd
be
able
to
use
that
within
our
documentation,
certainly
within
the
end
User
Group
throughout
the
ossf
I
think
to
make
sure
that
we're
talking
about
the
same
thing
when
we're
talking
about
these
different
attacks,
now
I'll
post
briefly,
that
before
I
highlight
the
usage
of
that
as
we
move
into
the
architecture.
K
K
K
The
second
document
I
think
it
may
come
into
a
bit
more
of
an
easier
picture
to
understand.
So
that's
the
taxonomy
we
suggest
we'd
adopt.
But
if
you
go
to
the
second
document,
Andrew
yep,
there
we
go
now.
The
reason
for
one
of
the
reasons
for
looking
at
this
tax
on
me
is
it's:
it's
challenging
for
us
in
the
end
user,
groom
too
and
I
think
multiple
working
groups
to
figure
out
how
to
develop
an
end-to-end
supply
chain
solution
because
not
really
got
an
understanding
of
how
the
different
components
fit
together.
K
Right
I
think
we've
got
lots
of
different
working
groups,
doing
some
great
work,
but
for
an
end
user
to
actually
solve
some
of
these
problems.
We
don't
understand
how
to
plug
these
things.
Together,
it's
difficult
to
talk
about
it
and,
as
I
said
earlier,
it's
it's
not
easy
to
understand.
Even
what
threats
are
coming
against
that
architecture
and
what
we're
trying
to
mitigate.
K
K
We'll
get
there
in
a
minute,
but
there's
a
diagram,
basically,
where
we're
suggesting
we're
going
to
put
together
a
couple
of
architectures
in
the
group
to
show
this
is
what
an
end
user
looks
like
whether
it's
a
small
company,
a
regulated
company,
a
hospital
for
example,
and
then
we're
going
to
apply
that
taxonomy.
We
just
showed
to
figure
out
look.
These
are
the
attacks
that
are
in
the
in
the
threat
landscape.
At
the
moment.
K
These
are
the
attacks
where
end
users
are
suffering,
and
this
is
where
they
hit
that
particular
architecture,
and
then
from
that
we
can
identify
right.
So,
given
that
we
can
figure
out
where,
within
the
issf,
the
different
projects
that
we
have
the
different
standards
that
we
have
the
map
to
prevent
and
mitigate
those
attacks
and
threats,
so
we
can
show
where
salsa
fits
within
that
particular
architecture.
K
We
can
show
where
the
S2
SF
fits
and
it'll
just
help
us
align
for
an
end
user
perspective,
I
think
as
a
way
to
group
what
we're
actually
trying
to
do,
how
we're
trying
to
mitigate
those
threats
and
which
projects
are
going
to
be
useful
and
where
it
sort
of
ties
the
thing
together,
Andrew,
it's
really
quite
I,
think
instructive.
If
we
can
get
to
that
picture,
just
literally
10
lines
down,
if
you
can
page
down
in
that.
K
I
can't
quite
get
there.
Oh
there
we
go
there,
we
go.
So
let
me
let
me
explain
that
again,
just
so,
you
can
see
that
picture.
So
the
suggestion
is
we'd
create
a
couple
of
different
architectures
for
end
users.
We'd
take
that
taxonomy
and
threat
model
the
these
architectures.
So
we
understand
where
these
threats
are
and
then
we'd
be
able
to
see
right.
These
are
the
threats
coming
in
and
this
is
how
salsa
would
mitigate
those
threats.
This
is
how
ssdf
mitigates
those
threats.
K
K
D
D
D
K
So
that
I
mean
Henrik
is
on
the
call.
He
can
explain
it
in
more
detail,
perhaps
than
I
but
effectively
that's
the
association
between
the
different
taxonomy
and
attacks,
so
you'd
have
the
aggregation
at
the
top
or,
on
the
left
hand,
side
and
the
specialization
as
you
go
through
to
the
right
to
the
may,
be
compromising
package
being
one
of
those
components
and
further
on
to
the
right.
You'll
have
each
of
the
individual
specialized
attacks
to
give
you
more
detail
and
that
visualization
is
quite
useful.
K
It
allows
people
to
browse
those
particular
attacks
and
understand
where
that
choke
point
is
so
you'll
find.
Actually,
if
you
look
at
prevalence
data,
so
I've
actually
done
some
research
looking
at
the
last
seven
years
of
attacks
and
mapping
that
to
the
taxonomy
and
you'll
see
where
it
actually
fits
in
that
taxonomy
and
where
the
choke
bond
is
further
to
the
left.
So
what
you
can
identify
is
actually,
if
you
mitigate
a
control
point
further
on
the
left
of
that
text,
enemy
you'll
actually
mitigate
a
whole
host
of
those
subsequent
attacks.
K
D
Does
and
my
follow-on
is
to
in
your
proposal
to
the
tack
sort
of
looking
at
the
the
structures
and
terminology
Mexican
you're
proposing
this
paper
is
wonderful
and
new
to
me.
I'm
curious
how
much
mapping
of
that
complex
lexicon
onto
existing
openssf
work
and
work
streams
and
products
has
been
done
or
are
you
proposing
to
do
if
that
would
require
personal
trust,
renaming
things
we've
already
named.
K
That's
a
great
Point,
flavor
and
I
think
certainly
going
forward
as
we
discuss
it
within
the
end
of
the
user
group.
It's
useful
to
have
that
commonality
and
mapping
it
to
that
taxonomy
I
think
there's
a
separate
adjunct
point
of
whether
we
want
to
go
through
the
ossf
and
align
that
I
think
that's
a
a
great
question
for
debate.
Go
to
stop
somewhere.
It's
just.
K
E
M
K
K
They
say
well
what
where
do
I
go?
You
know
how
you
know:
what
is
the
threat
and
how
do
I
mitigate
it?
They
can
see
from
that
documentation
where
to
actually
connect
it
back
up
to
I
I,
think
those
are
the
the
visible
deliveries
link,
I
I
think
the
the
value
we
get
out
of
it
is
the
ability
to
talk
about
the
value
from
these
different
projects
and
capabilities.
We
can
now
state
Point,
Blank
salsa,
mitigates
these
threats
and.
C
C
J
J
Some,
you
know:
I've
got
colleagues
in
absec
and
infrasek
who
have
been
watching
and
following
supply
chain,
stuff
and
I
share
stuff
with
them,
and
they
share
stuff
with
me.
But
there
are
also
a
lot
of
folks
in
the
first
second
app
SEC
who
do
not
follow
this
as
part
of
their
day
job
and
when
I
start
talking
to
them
about
it.
They're
like
it's
humongous.
J
Where
do
I
begin?
How
does
it
fit
together?
What's
the
big
picture,
we
don't
really
have
that
I
have
to
sort
of
like
try
to
break
it
down
for
them.
Salsa
focuses
on
this
part,
and
you
know
SS
S2
C2
focuses
on
this
part.
I
mean
I.
Did
a
reading
list
for
a
Blog
article,
that's
coming
out
recently
and
I
like
sliced,
so
much
stuff.
It's
got
like
90
of
what
we
know
just
completely
excluded,
because
it's
too
overwhelming
and
what
I
wish
I
had
was
something
where
I
could
be
like.
C
N
Yeah,
maybe
I
wanted
to
add
a
little
bit
on
what
Jonathan
said
earlier
on.
So
when
Kia
Giorgio,
myself
and
the
other
co-authors
of
the
paper
developed
this
taxonomy,
we
really
thought
it
would
be
a
good
idea
to
have
this
taxonomy
take
the
form
of
an
attack
tree
right.
This
is
why,
on
the
very
left
hand
side
you
have
the
high
level
goal
of
the
attacker
and
then
the
further
you
go
down
the
tree.
N
You
could
basically
pick
a
safeguard
and
see
which
would
which
are
the
attack,
vectors,
partially
or
completely
mitigated
by
the
by
the
respective
selected
Safeguard,
and
so
one
of
the
future
deliverables
I
see
would
be
going
through
all
the
open,
ssf,
Solutions
and
projects,
and
we
find
this
safeguards
part
and
map
it
to
to
which
are
the
addressed
attack.
Vectors.
O
O
So,
first
of
all,
we
started
by
categorizing
reviewing
the
Literature
Grade
researcher
scientific
literature,
to
create
this
taxonomy,
but
I
think
I
mean
one
of
the
main
goal
of
having
this
taxonomy
is
a
bit
like
in
the
direction
of
the
mighty
attack
framework.
You
know
like
to
explain
and
classify
and
detail
the
possible
techniques
to
conduct
supply
chain
attacks.
O
How
how
the
current
history
explained
to
us
how
to
conduct
these
attacks
so
yeah
just
wanted
to
share
a
bit
the
goal
that
was
behind
that
and
I
think
this
should
be
a
community
effort
to
maintain
this.
This
this
knowledge
base
that
could
help
in
better
reason
about
detection
techniques,
counter
measures,
but
also
to
spread
awareness
among
the
the
maintainers.
E
P
Yeah
I
think
this
is
a
great
effort.
I've
I've
been
chatting
with
others
about
this,
but
there
are
a
lot
of
other
very
closely
related
efforts
in
the
cntf
and
elsewhere,
and
so
I
wonder
if
also
a
lot
of
Outreach
is
needed
to
be
done
to
pull
this
together,
because
it
feels
like
we're
otherwise
going
to
have
a
like
a
a
pretty
disjoint
collection
of
things
that
are
probably
also
going
to
be
fairly
opinionated,
which
is
something
that
we
want
to
avoid.
K
I
I
cannot
take
from
a
technical
perspective.
Do
that
other
than
manually.
Thank
you,
yeah
I
guess
to
turn
to
address
some
of
those
points.
I
I,
guess
you
know
what
what
success
looks
like
on
this
is
you
know,
we've
checked
with
a
couple
of
end
users
and
industries
already
or
quite
quite
a
lot
actually,
and
it
really
does
provide
that
look.
This
is
where
the
threats
are
coming
from.
K
This
is
what
you
need
to
be
concerned
about,
and
this
is
where
you
can
start
to
look
at
for
a
solution
going
forwards,
whether
that's
within
this
group
within
cncf,
but
at
the
very
least,
provides
the
ability
to
talk
about
what
you
you
need
to
be
aware
of.
At
the
first
part,
the
threats
that
are
coming
in
and
how
to
discuss
them
and
then
I
think
to
Justin's
point.
There
are
multiple
different
groups
within
this
and
within
cncf,
where
we
can
look
at
right
now.
K
We've
got
an
architecture,
a
threat
model
and
the
taxonomy
you
can
discuss
it.
It
might
not
be
a
single
solution
of
how
to
mitigate
it,
but
at
least
you
can
talk
about
where
to
look
so
it
would
be
at
least
that
sort
of
road
map
where
people
could
navigate
this
space
I
think
if
I
may
just
want
one
last
point
is:
is
maintenance
on
this?
In
that
we're.
K
M
B
You're
welcome
my
first
point:
full
disclosure
I
am
a
participant
in
the
end
user.
Working
group
and
I've
been
a
sounding
board
for
Jonathan
on
some
of
these
materials,
so
I
am
biased,
but
I
would
ask
Jonathan
directly.
While
we
have
the
tack
here
specifically.
What
are
you
asking
the
TAC
for
we
allow
our
working
groups
a
higher
degree
of
flexibility
to
kind
of
manage
their
own
projects.
So
specifically,
what
would
you
like
from
the
tack
around
these
artifacts
and
the
group
in
general.
K
So
I
think
very
specifically
on
the
taxonomy
agreement
that
it
would
be
appropriate
to
adopt
that
taxonomy,
specifically
within
the
end
user
group,
and
we
can
look
to
host
the
the
website
within
the
ossf.
That's
number
one.
Secondly,
approval
that
we
can
start
an
initiative
and
and
I'd
like
to
get
some
guidance
on
how
we
would
initiate
that
initiative
to
pull
together
the
architecture,
do
the
threat
models
appropriately
and
then
work
to
align
the
the
different
solutions
to
that.
K
C
D
E
P
Okay,
yeah
and
I
and
I'd
also
say
that,
especially
how
this
interacts
with
other
groups
probably
needs
to
be
clarified.
That
was
one
point
I
was
was
like
hoping
to
hear
more
about
because
there's
an
awful
lot.
That's
that's
gone
many
steps
in
this
direction
by
different.
You
know
other
groups
and
that
the
part
of
that
I
I
was
hoping
to
hear
a
little
more
said
about
how
that
would
how
that
interaction
would
go.
K
So
what
we're
trying
to
do
in
the
end
he's
a
group
is
that
Outreach,
it's
part
of
our
charts
or
two
Outreach
to
other
groups.
We've
actually
got
members
from
end
User
Group
within
the
other
working
groups,
contributing
directly
into
them
and
also
within
the
cncf.
So
it
is
written
into
the
child
to
do
that
Outreach
and
to
ensure
that
we,
you
know,
provide
bi-directional
feedback
into
this
and
the
end
user
group
in
general.
K
Whether
it's
the
the
the
cncf,
the
tank
security
piece,
the
work
supply
chain
group
within
the
tank
that
I
kicked
off
some
time
ago
or
the
the
Integrity
group
we
have
here,
or
indeed
the
diagram
Society.
So
it
is
actually
part
of
our
Charter
but
I
think
we
need
to
build
the
architecture
first
to
show
what.
P
I
mean
I
I
worry
a
little
bit
about
like
scoping
and
building
that
architecture
and
stuff
without
having
that
interaction
in
some
ways,
because
I
I
think
in
a
lot
of
the
threat,
modeling
and
other
efforts.
There's
the
tendency
for
people
to
only
see
part
of
the
elephant.
I'm
not
saying
that
I'm
immune
to
that
either.
But
I
think
there's
lots
and
lots
of
real
world
examples
about
things
coming
out,
apparently
from
Left
Field
that
have
happened
to
major
companies
that
are
often
missed
in
a
lot
of
these
analyzes
yeah.
K
Great
point
right
and
with
those
architectures
we're
building
it
with
some
of
those
companies
and,
like
example,
companies.
So
they
are
the
elephant
right
and
it's
trying
to
pull
out.
You
know
what
would
go
into
those
architectures
by
literally
talking
to
those
individuals
themselves
right-
and
you
know,
with
your
your
expertise
from
a
threat.
Modeling
standpoint
that'd
be
invaluable
as
well
well
with
others,
but
also
they
would
be
the
actual
consumers.
E
Do
we
feel
like
that
essentially
what's
being
described
here
in
kind
of
your
your
sequential
plan
of
taxonomy,
let's
align
both
internally
within
the
open
ssf
as
well
as
externally,
with
the
groups
that
Justin
I
think
was
mentioning
as
well
as
yourself
to
those
end.
Artifacts
that
you
described
is
that
in
essence,
does
that
deliver
on
the
on
that
ask
from
the
governing
board.
E
In
your
opinion,
are
there
gaps
from
others,
because
I
think
that's
a
really
critical
conclusion
that
if
we
can
come
to
and
seem
to
get
consensus
around
I
think
that's
a
very
powerful
message.
But
I
don't
want
to
presume
that
if
folks,
don't
naturally
have
that
alignment
or
have
concerns
or
questions
there,
so.
K
So
I
see
this
as
connecting
to
that
directly
right.
This
provides
the
this,
provides
the
requirements
of
what
we're
trying
to
fix
and
shows
what
people
are
trying
to
protect.
So
we
can
talk
about
it
and
then
discuss
and
figure
out
what
tool
chain
we
need
to
put
in
place
to
mitigate
those
threats,
and
until
we
build
out
that
architecture
and
threat
model,
we
don't
necessarily
understand
what
we're
actually
trying
to
build
within
the
tool
chain.
C
K
E
Yeah,
just
just
to
throw
out
I'm
John,
unified,
you
and
I
have
talked
about
this,
so
I
also
share
that
opinion
as
well.
I
think
that
is
this
is
this
is
a
maybe
a
stone
that
I
knew
not
the
most
correct
way
to
frame
it,
but
we
get
a
lot
of
Leverage
out
of
this
sort
of
investment
both
in
terms
of
where
we
are
as
a
foundation
as
we're
as
we're
as
well
as
where
we
want
to
go.
E
But
again,
it's
I
think
this
is
a
point
that
is
important,
that
if
folks
don't
understand
it
now
or
in
you
know
the
near
term,
it
is
something
that
I
would
like
to
get
clarity
on,
because
if,
if
this
is
going
to
serve
that
purpose
as
a
trend
of
driving
a
rally
and
cry
consistency
in
how
we
talk
about
how
to
represent
the
foundation,
this
is
something
the
attack
needs
to
be
supportive
of.
So
so,
if
folks
have
comments
now,
that'd
be
great.
E
If
not,
then
I
would
ask
folks
to
also
take
a
take,
an
action
item
to
look
more
deeply
at
the
documents
that
that
John
and
the
working
group
has
shared
here
in
terms
of
next
steps.
I
don't
see
any
hands
going
up
so
in
terms
of
next
steps
on
this
I
think
I
would
agree
with
Ava
I.
Think
time.
Boxing
this
to
the
next
attack
meeting
is
a
agenda
item
to
say:
hey
we've
had
two
weeks
to
go.
Look
at
this
checkpoint
around.
E
Do
folks,
understand
kind
of
the
sequence
and
activity
here
and
using
that
is
also
a
forum
to
to
do.
Some
communication
out
to
other
working
group
leads
around
hey.
This
is
what's
been
being
discussed.
This
obviously
impacts
the
supply
chain.
Integrity
group,
the
best
practices
group,
many
of
the
activities
that
we
have
going
on
so
I
want
to
make
sure
that
we
we
handle
the
the
comms
on
this
to
the
broader
community
in
an
appropriate
way
here
as
well.
So
does
that
sound
amenable
is
the
next
step.
E
E
Is
where
again
using
the
communication
vehicles
that
we
have
around
mailing
lists
and
meetings
and
making
sure
that
we
are
amplifying
you
know
this
work
as
much
as
possible
and
being
inclusive
around
opinions,
but,
like
all
things
in
open
source,
those
who
show
up
with
code
or
or
you
know
the
pen
ultimately
get
the
shape
things.
So
I
think
this
is
a
making
sure
that
we
are
doing
a
correct
call
for
participation.
E
Here
is
certainly
important,
but
also
we
do
want
to
make
progress,
and
that
is
kind
of
a
theme
that
did
come
out
of
the
governing
board
meetings.
Late
last
year
was
you
know
we
have
a
lot
of
good
organic
activity
going
on,
but
we
need
to
to
evolve
that
and
accelerate
that
in
many
different
ways.
So
I
do
think.
In
my
opinion,
the
answer
to
that
question
Ava
is,
is
really
around
Communications
and
cfps,
and
making
making
sure
folks
are
aware
that
this
activity
is
happening.
N
Yeah,
maybe
coming
back
to
getting
the
community's
feedback
on
the
completeness
and
correctness
of
the
taxonomy,
it's
worthwhile
to
mention
that
we
ran
some
questionnaires
where
we
had
like
15
people
and
I.
Believe
a
couple
of
you
may,
a
few
of
you
may
have
been
participating
in
this
questionnaire
back
then,
where
we
wanted
to
have
yeah
and
collected
your
feedback
on.
Is
it
properly
structured?
What
are
the
names?
Is
everything
covered
that
you
can
imagine,
and
a
good
number
of
the
feedback
was
also
reflected.
D
And
Henrik
I
appreciate
that
Clarity
I
in
no
way
mean
to
to
disparage
the
work
or
imply
that
it
didn't
have
tremendous
expert
input.
What
I'm
pointing
at
here
and
I
hate
to
be
the
one
proposing
bureaucracy
again
or
perceived
as
such,
but
it's
is
the
the
in
the
import
and
the
impact
of
the
open
ssf
blessing
this
taxonomy
publicly.
D
If
we
want
that
to
have
the
sort
of
catalytic
impact
that
it
could
have
across
the
industry
in
open
source,
then
a
consensus
building
process
where
we
reach
out
to
the
cncf
tag
security
we
reach
out
to
other
groups.
We
bring
them
to
our
table
and
we
work
through
that
process
with
them
to
get
consensus.
That
process
that
builds
their
buy-in
on.
D
This
is
important
and
far
more
important
than
us
just
planting
a
flag
and
saying
here's
what
we
have
said
take
it
or
leave
it,
because
if
we
do
that,
my
concern
is
other
groups
will
say
well,
we've
put
two
years
of
work
into
our
thing:
we're
not
going
to
change
I
would
rather
I.
Think
all
of
us
agree.
We've
talked
about
this
at
length
that
we
build
a
set
of
tools
and
terminologies
that
can
be
used
whole
cloth
across
as
much
of
open
sources,
if
not
all
of
it
as
possible.
D
So
I'd
rather
I
think
this
is
a
really
important
thing
to
to
work
on
it's
important
enough
and
actually
I
began
doing
this
myself
years
ago
and
then
dropped
the
ball
on
it.
But
it's
it's
the
kind
of
thing
that
I
don't
think
we
can
rush
in
the
next
two
weeks
and
have
attacked,
give
a
thumbs
up
and
say.
Yes,
we
believe
this
taxonomy
as
written
is
the
one
we
should
adopt.
I
think
this
is
worth
starting
up
a
process
that
might
take
longer
than
two
weeks.
D
P
I
I
couldn't
agree
more
with
what
Ava
said
and
a
lot
of
what
I'm
gonna
was
gonna
say
would
be
duplicative,
so
the
I
will
also
say
that
I
had
a
round
of
feedback
and
I
I
think
others
probably
have
also
and
I
think
there
are
definitely
things
that
are
not
perfect
or
could
be
improved
in
what
is
currently
there
and
I
don't
mean
this.
As
a
like,
you
know,
hey
look,
there's
some
part
of
the
elephant
you
didn't
see.
Therefore,
the
whole
effort
is
flawed
way.
E
M
E
If
folks
in
heard
me
saying
we
should
rush
to
approve
in
two
weeks,
that's
not
what
I
was
proposing.
It
was
more.
Let's
take
the
time
to
go,
read
the
document
form
our
own
opinions
and
bring
those
opinions
back
at
the
next
meeting.
If
we
do
find
that
folks
say
directly
accurate,
it's
worth
trying
to
work
on
a
communication
strategy
to
bring
the
right
Folks
at
the
table
and
ultimately
evolve.
E
E
Coming
back
with
feedback
and
saying
we
can't
endlessly
stay
in
a
review
cycle
stage
for
another
12
months
on
this,
we
do
need
to
to
make
forward
progress,
so
I
think
we're
trying
to
strike
an
appropriate
balance
of
inclusion,
making
sure
that
we
do
have
the
right
Folks
at
the
table,
but
ultimately
recognize
that
this
will
be
an
iterative
process
going
forward,
and
so,
let's
make
an
internal
judgment
on.
Is
this
directionally
accurate
and
try
to
iterate
and
make
it
better
over
time?
I
think
is.
P
They
were
trying
to
do,
but
were
only
beta
releases
and
were
accidentally
pushed
that's
one
example
of
something
that
I,
don't
think
is
captured
by
the
taxonomy
and
I
think
doing
an
exercise
like
that
will
cause
lots
of
other
things
like
that
to
surface
where
you'll
see
that
you're.
You
know
that
some
part
of
the
elephant
is
in
the
shadow
right
now
and
we
need
to
draw
it
out
in
the
light.
E
This
is
a
good
starting
point
to
jump
off
from
and
it
seems
as
if,
from
my
perspective,
we
have
the
interviews
or
working
group
here
saying
standing
up
and
saying:
hey.
We
have
the
the
engagement
and
the
willingness
to
to
help
Shepherd
this,
which
is
I,
think
a
again,
a
critical
part
to
this
as
well.
So
I
think
the
tech
owes
the
that
working
group
it's
time
and
attention
on
coming
to
that
assessment,
at
least
in
the
short
term.
On
again
directional
accuracy,
John
may
have
better.
C
E
K
K
I
I
would
just
add
that
that
I
did
go
through
the
there's.
Some
data
set
from
inqutel
with
supply
chain
attacks
and
I
did
look
at
mapping
that
directly
to
taxonomy
and
it
was
reasonable,
but
absolutely
it
needs
to
be
validated
by
other
people
and
incrementally
reviewed,
so
I
I
think
I.
Welcome
that
to
Echo
previous
comments
from
Justin
and
Ava.
So
thank
you
for.