►
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
A
A
B
A
A
B
A
B
B
What
we
do
is
we
are
working
on
on
security
products,
so
basically
I'm
a
product
manager
in
in
our
team
yeah.
Basically
we're
working.
We
are
working
on
on
supply
chain
software
supply
chain
security
platform,
specifically
I'm
interested
in
the
salsa
thermal,
which
is
what
brought
me
here
in
the
first
place.
B
B
I
came
from
from
the
back
door,
basically
yeah,
that's
that's!
Basically
my
story
and
yeah
I
was
just
starting
to
to
educate
myself
about
this
house
of
farmwork,
which
is
format.
Iso
is
the
only
software
supply
chain,
dedicated
or
cicd
dedicated
a
framework
security
framework
out
there,
which
is
the
most
mature
from
all
the.
A
Rest
yeah
I
think
it
is
I,
think
it's
very
I
like
it.
Also
it
is
a
little
bit
or
maybe
it's
just
the
parts
that
I
didn't
see,
but
sometimes
I
have
to
feel
like
it's
a
little
bit
high
level
right,
so
they
describe
requirements
on
a
high
level,
which
of
course
is
a
good
thing.
But
then
breaking
this
down
to
concrete
Technologies
is
maybe
not
straightforward,
but
I
understand
this
cannot
be
all
covered
by
by
the
high
level
salsa
framework,
so
I
kind
of
see
the
trade-offs.
Where
do
you?
A
Where
do
you
start
and
where
do
you
stop,
and
it
makes
makes
a
lot
of
sense
what
they
have
done?
Maybe
you
can
look
into
the
software
component
verification
standard
from
the
obasp,
which
is
also
a
nice
effort
in
this
space.
It's
not
only
about
supply
chain
attacks,
but
also
about
this
problem
of
using
components
with
known
vulnerabilities,
but
there's
also
a
lot
of
meat
and
value
in
this.
This
other
framework.
B
Yeah
I
can
relate
with
what
you
are
saying.
Definitely
this
is
one
aspect
that
is
lacking
right
now
from
from
salsa
and
and
actually
I
see
this
as
a
challenge
that
we
need
to
solve,
and,
and
actually
this
is
what
brought
me
to
to
engage
in
in
these
meetings.
I
don't
know
if
this
meeting
specifically
is,
is
gonna.
You
know
this
is
one
of
the
goals
of
it,
but
you
know
I'm
trying
to
figure
out
where
I
can
I
can
have
my
take
and
and
to
share
my
knowledge.
B
A
Okay,
the
the
so
the
idea
of
this
effort
is
that
John,
Meadows
and
other
people
from
the
end
user
work
group
found
that
from
an
end
user
perspective,
it
would
be
very
helpful
to
have
a
kind
of
General
architecture
of
different
software
organization.
Software
development
organizations
of
different
sizes
run
a
thread
modeling
on
such
generic
infrastructures
development
infrastructures
as
a
means
to
explain
to
end
users
how
and
where
all
the
different
solutions
and
initiatives
and
Technologies
provided
by
the
open,
ssf
fit,
because
there's
so
much
work
going
on
on
openssf.
A
A
All
right,
of
course,
yeah,
okay,
so
so
I
come
from
I've
been
working
for
a
number
of
years.
On
this
whole
topic
of
Open
Source
supply
chain
security,
I
started
back
in
2012.
There
was
a
great
article
from
Jeff
Williams
called
the
unfortunate
reality
of
insecure
libraries
that
triggered
me
back
then,
and
in
the
first
I
would
say
five
six
years.
It
was
all
about
the
problem
of
using
components
with
non-vulnerabilities
and
so
I
developed.
A
A
A
A
B
A
Sometimes
this
is
this
is
what
we
need.
I
I
same
here
kind
of
I
I
know
what
thread
thread.
Modeling
is
all
about.
I
also
participated,
but
I
never
really
moderated.
One
and
I
think
this
moderation.
Experience
is
something
that
we
will
need
going
forward
yeah,
but
but
yeah.
Let
me
share.
Let
me
share
a
link
here.
B
A
A
A
All
right-
and
so
basically
here
what
you
see
in
the
beginning,
I've
written
down
some
kind
of
objectives
and
then
it
and
then
the
large.
What
we
thought
is
a
generic
high
level
architecture
of
of
a
development
infrastructure
of
a
large
scale,
software
development
organization
and
what
you
see
here
is
basically
the
the
different
systems,
starting
from
the
workstation
to
Version
Control
Systems,
build
systems,
internal
private
Registries,
up
until
public
distribution
platforms
and
between
those
systems.
A
From
the
different
systems
and
stakeholders
right
and
then
we
started
basically
defining
what
are
the
assets
kind
of
the
initial
assumptions
and
scope
and
so
forth,
and
we
stopped
the
last
time.
I
attended
the
session
that
was
two
weeks
ago,
looking
at
the
flows
of
third
particles,
so
we
and
I
we
basically
looked
at
each
of
the
data
flows
and
described
a
little
bit
in
more
detail.
What
is
the
source?
What
is
the
sink
of
the
data
and
what
is
the
purpose
of
the
specific
flow?
A
A
No,
no,
no,
no!
No!
No,
we
didn't
we
didn't.
We
didn't
draw
any
trust
boundaries
yet
for
me,
so
we
we
kind
of
discussed
this,
and
we
came
to
do
this
conclusion
that,
for
the
time
being,
we
do
not
want
to
also
cover
Insider
threats,
yeah
and-
and
this
is
and
but
and
a
consequence
of
excluding
Insider
threats.
A
I
think
is
that
the
trust
boundary
can
be
drawn
between
which
basically,
the
outside
of
the
trust
boundary
is
the
distribution
platform
such
as
open
source
distribution,
platforms
for
source
code
or
binary
packages,
Pipi
GitHub
and
so
forth,
or
even
proprietary
distribution
platforms
such
as
download
servers,
also
from
a
commercial
third-party
providers.
So
all
that
is
out
and
basically
everything
else
is
in
the
trust,
boundary.
B
A
Yeah
so
I
think
I
mean
here.
We
talk
of
the
example
architecture
we
came
up
with
is
that
of
a
large-scale
in-house
development
right,
so
this
would
be
bigger,
Software
Corporations,
with
hundreds
and
hundreds
of
developers,
and
and
for
those
guys
there
should
be
people
responsible
for
the
secure
design
of
their
internal
development
infrastructure,
and
so
that
would
be
one
important
if
not
the
most
important
target
audience
of.
A
Yeah
I
would
say
security
architecture
of
the
built
environment,
so
the
company
that
I've
been
working
for
before
sap
they
had
a
I
mean
there.
It
was
a
highly
specialized
organization
right.
You
had
a
you
had
a
you
had
a
Central
Security
team,
and
then
you
had
teams
operating
security
tools
and
then,
of
course,
you
had
security
Architects
within
the
application,
development
teams,
and
so
from
my
perspective,
it
should
be
the
people,
the
security
architect,
architects,
of
that
build
and
development
infrastructure.
A
Individual
development
teams
I
think
some
depends
a
little
bit.
I
think
it
will
depend
on
the
the
safeguards
from
openssf
that
we
will
use
to
mitigate
the
different
threads
identified
and
some
of
those
safeguards
will
be
for
developers
and
others
for
the
architecture
of
such
infrastructures
and
some
others
will
be
development
teams.
But,
of
course,
even
though
maybe
the
users
of
those
safeguards
are
those
individuals,
I
just
said,
there's,
there's
probably
some
guidance
also
required
in
order
to
top
down,
make
the
people
aware
of
it
and
tell
them
how
to
do
it.
B
A
Thank
you
so,
and
that
and
that,
and
that
again
depends
on
the
specific
organization
whether
there
is
a
Central
Security
team,
taking
care
of
producing
such
guidance
and
such
requirements,
or
whether
this
is
all
distributed.
It's
difficult
to
make.
You
know,
make
some
assumptions.
You
know
software
development
organizations
look
like
they
seem
to
be
all
different
in
a
good
way.
Let's
say
yeah.
C
Hey
okay,
good
morning
enrich
Victor,
so
actually,
last
week
you
didn't
had
a
conversation
with
Grove
so
I.
Basically,
the
the
the
actual
attack
vectors
that
you
have
considered
in
this
diagram.
I'm
I
was
nervous.
That's
why
Crow
pointed
to
your
taxonomy
white
paper,
the
great
great
paper,
by
the
way
very
useful
one
thing
I,
think
be
useful
to
for
this
discussion,
because
that
white
paper
has
a
lot
of
information,
but
I.
Is
there
a
like
a
spreadsheet?
A
We
understood
that
it
is
difficult
to
consume
in
a
PDF
and
archive,
and
so
we
created
this
online
tool
so
I
can
and
in
this
online
tool
you
can
basically
explore
the
attack
tree
and
on
each
attack
Vector
in
the
tree.
You
will
get
a
description
and
references
to
either
academic
works.
I
can
I
can
just
browse
you
through.
C
B
C
A
C
B
A
Is
basically,
this
is
basically
an
interactive
online
Tool.
This
one
here
is
hosted
at
Endo
Labs.
It
is
basically
the
same,
as
was
as
the
one
that
was
originally
developed
by
sub
security
research.
They
also
maintain
and
run
this
in
parallel
kind
of,
and
here
we
basically
see
this
attack
tree
right,
and
so
the
root
node
of
the
tech
tree
is
the
highest
level.
The
high
level
goal
of
conducting
in
an
open
source
supply
chain
attack,
meaning
to
inject
and
spread
malicious
call
code
to
Downstream,
open
source
consumers.
A
And
then,
if
you
drill
down
for
each
of
those
the
tech
vectors
the
nodes,
you
will
basically
see
all
those
nodes
represent
alternative
ways
to
to
accomplish
the
respective
super
goal
right.
So
here
you
have
all
those
name,
confusion,
attacks
like
type
of
squatting
and
so
forth,
and
then
here
it's
getting
bigger
and
bigger.
You
could
inject
malicious
code
into
the
sources
of
a
legitimate
package
during
the
build
or
by
tampering
with
the
distribution
mechanism
and
for
each
node.
A
C
Yeah
I
think
you
actually
share
this
at
that
time.
I
just
didn't
pay
attention,
I
guess.
So
my
question
is
either
if
I,
this
is
very
nice
for
drill
down,
but
if
I
want
to
see
a
whole
list,
especially
which
part
of
the
cicd
pipeline,
this
particular
attack
actually
is
related
to.
Is
there
such
a
unless.
A
C
A
C
A
You
think,
if
you
think
of
it
here
the
create-
let's
take
this
one,
the
all
the
name,
confusion,
attacks,
type
of
squatting,
brand,
checking
and
so
forth.
Right.
This
is
something
that
is
relevant
for
the
developer
workstation.
They
would
typically
install
something
locally,
maybe
to
just
play
around
and
create
a
proof
of
concept.
A
So
all
this
matters,
but
then
also
here
when
it
comes
to
injecting
into
sources
also
here
the
developer
laptop
matters,
because
if
you,
for
example,
install
kind
of
install
a
malicious
plugin
that
could
change
the
source
code
of
the
project
you're
working
in
and
make
you
commit
something
malicious
into
the
into
the
source
code
repository
again
or
maybe
you
have
a
weak
configuration
of
your
workstation
that
would
allow
some
attacks.
So
this
is
this
is
yeah,
it's
not
so
easy
to
filter
this
yeah.
C
So,
let's
say,
if
I
fixed,
also
one
just
a
release,
so
I
say:
okay.
Software
is
interesting.
I
I
like
to
understand
salsa
more
in
the
meantime,
I'll
use
this
tool
that
this
technology
tool,
as
well
as
a
diagram
you're
developing.
So
how,
from
here,
how
do
I
find
this,
which
one
is
related
to
the
build
phase?
In
other
words
related
to
salsa,
elicited
a
type
actors.
B
A
C
A
A
I
mean
no
no
or
let
me
let
me
phrase
it
a
little
bit
different
and
I
think
this
is
an
important
distinction.
I
mean
this
is
what
this
are:
the
attack
vectors
targeting
the
environment
of
the
open
source
project.
So
if
I
speak
here
of
inject
during
the
build
of
the
little
legitimate
package,
so
this
would
be
the
build
of
the
open
source
project.
It
is
not
the
build
of
an
application
developer
depending
on
that
package
right.
So
this
is
also
I
think
this
is
important
to
understand.
A
A
Need
to,
and,
and
so
the
effort-
and
that
is
part
of
the
whole
exercise-
is
to
use
this
taxonomy
and
and
and
and
derive
some
threats
for
the
end
user.
The
application
developer
basically-
and
it
could
very
well
be
that
let's
say
some
of
the
some
of
the
controls
to
be
implemented
by
application.
Developers
are
the
same
ones
independent
of
how
the
malicious
code
ended
up
in
the
in
the
open
source
package
in
the
first
place.
A
C
A
C
A
Yeah
yeah
I
would
be
happy
to
receive
I
mean
when
we
built
this
like
one
another.
What
do
we
have
it's
one
year
ago,
a
little
bit
more
than
that?
Maybe
we
we
paid
attention
to
have
proper
descriptions
and
and
really
make
do
our
best
to
have
all
definitions
well,
aligned,
so
but
I
would
be
happy
to
receive
your
feedback.
In
particular,
we
created
also.
We
ran
a
user
survey
both
with
the
experts
in
supply
chain
security,
as
well
as
with
developers
in
order
to
get
their.
A
A
The
core
database
is
basically
around
300
something
up
papers
and
from
from
scientific
and
great
literature,
as
well
as
a
text
I.
Think.
Overall,
the
statistics
are
I,
don't
know
where,
but
I
think
we
have
more
than
100
attacks
real
world
attacks,
that
we
relate
to
the
different
vectors
and
then
another
200
something
papers,
blog
posts
and
stuff,
and
there's
a
and
for
that
matter
we
have
here
basically
the
the
ref.
You
find
all
that
in
in
the
references
right,
but
I
don't
have
okay,
it's
a
little
bit
more.
In
the
meantime,.
B
A
A
It's
focused
on
in
particular,
open
source
supply
chain
attacks,
so
we
do
not
I
mean
there
is
a
good
overlap,
I
think,
but
some
of
the
particularities
relate
to
open
source
components
in
particular,
but
I
think
we
also
included
solar
winds
and
a
couple
of
other
attacks
on
Commercial
software
providers.
But
the
initial
goal
was
really
mainly
on
open
source
projects
and
how
they
are
attacked.
B
A
I
mean
yeah
what
yeah
it's
true,
but
I
mean
every
every
open
source
package
that
is
packaged
and
made
available
on
pipei
and
so
forth.
They
need
to
go
through
a
build
process
somehow
somewhere
either
on
the
developer
computer
or
on
a
Jenkins
system
or
God
knows
here,
and
so.
This
is
why
it
also
matters
for
for
open
source
packages
right,
and
this
is
why,
which
is
why
many
of
the
threads
apply
both
to
commercial
software
development
organizations
in
the
same
way
as
they
apply
to
open
source
projects
right.
A
A
How
well
am
I
covered
in
terms
of
mitigations
and
so
forth,
and
the
other
thing
we
we
also
thought
is
that
this
can
be
used
actually
to
scope
penetration
tests.
You
basically
go
to
a
penetration
test
and
say,
and
this
and
this
and
this
and
this
here
you
can
play
and
here
the
other
things
don't
please
please.
This
is
out
of
scope
of
the
pen
test.
A
Right
and
and
this
whole
and
maybe
then
to
close
the
loop
to
the
threat,
modeling
Workshop
John
Meadows.
He
was
doing
a
threat
model
himself
for
his
first
company,
basically
for
their
own
internal
infrastructure,
and
he
was
using
this
taxonomy
already
in
order
to
basically
locate
threads
in
their
internal
infrastructure,
and
we
wanted
to
redo
this
in
a
broader.
You
know
in
the
broader
Community,
with
more
inputs,
yeah.
A
A
So
all
the
the
real
world
attacks.
It
would
be
nice
if
somebody
could
just
enter
the
name
of
a
malicious
package
or
so,
and
then
we
can
basically
basically
locate
the
vector
that
was
used
in
order
to
conduct
that
specific
attack
on
you
know
to
spread
this
specific
malicious
package,
but
yeah,
but
ideas.
A
B
A
No
I'm
not
aware
of
any
other
tool,
I
think
what
is
different
here
is
we
really
wanted
to
take
the
attacker
perspective.
The
other
works
such
as
salsa
or
software
component
verification
standard,
they're,
more
take
the
the
defender
perspective
and
yeah.
So
no
I,
don't
I,
don't
know
of
any
other
tune.
A
A
B
C
A
That
is
exactly
the
exercise
that
we
are
going
to
do
I
hope
in
the
yeah
as
soon
as
possible.
It
turns
out
it
kind
of
takes
some
time
to
run
through
this
through
this
diagram
and
fill
those
fill,
those
tables
or
so,
and
until
we
get
to
the
actual
threat
modeling
where
we
will
go
through
those
attack,
vectors,
yeah,
I,
don't
know
it's
just
I
think
this
is
but
I
think
it's
important
to
kind
of
do
this
together.
A
I
do
not
want
to
sit
down
and
then
just
propose
something,
and
then
maybe
some
people
just
kick
it
off
without
really
properly
reading
or
good
nose,
and
so
I
would
that's
why
I
yeah
want
to
primarily
progress
during
during
those
meetings.
But
then
again
there
are
you
know
some.
Some
people
are
not
there
and
Summits
take
place
and
God
knows
what
the
life
happen.
Life
happens.
C
Yeah
I
know
if
they're
experts
like
like
a
necro
public,
can
give
examples
of
For
Me
Maybe.
Maybe
it
can
be
reversed
instead
of
waiting
at
the
end
to
try
to
match
the
Threat
Vector
into
the
diagram.
My
at
least
for
me
it'll
be
helpful
to
kind
of
even
not
formally
just
go
through
it.
So
this
is
the
attack
Vector
of
your
build
phase,
and
so,
let's
drill
down
and
this
fit
into
this
box.
C
That
will
float
into
that
box
of
why
it
is,
and
this
way
you
can
even
Post
in
a
channel
I,
don't
know
which,
whichever
Channel
you,
okay
yeah,
so
that
channel,
if
you
can
post
like
beforehand.
This
is
a
topic
for
today
we're
going
to
drill
down
into
build
so
review
everything
under
that
build
thread
model
and
get
familiar
with.
What
attack
Vector?
That's
in
there
and
add
anything.
C
A
C
A
A
C
Yeah
for
me,
it's
easier
to
follow
the
attack
treat
graph
database
because
it's
more
in
one
category
right,
because
here,
if
I
say
build,
that
build,
might
include
multiple
entries
from
that
that
tree
there
that
vector
database.
But
if
I
go
to
the
attack
Vector
database
I
can
just
drill
down
everything
in
that
one
branch
and
I
can
tell
whether
it's
part
of
a
build
git,
the
you
know
the
production,
whichever
it
is,
it's
either
that
way.
I
think.