►
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
B
All
right,
but
I
know
we
have
this
thing
that
I'm
not
sure
this
is
the
same
in
other
languages
eat
like
a
king,
I
think
at
in
in
the
morning,
eat
like
I,
think
kind
of
a
duke
or
something
at
lunch
and
then
eat
like
a
beggar
in
the
evening
kind
of
giving
most
importance.
In
contrast
to
what
you
said
to
the
to
the
breakfast.
A
B
B
B
A
B
Well,
maybe
yeah
yeah
I,
don't
know
I
guess,
depending
on
on
on
which
parts
you
work
on
I,
think
in
especially
in
the
US.
There
were
very
heated
discussions
about
computer
ships
where
they
are
produced.
Indeed,
what
kind
of
did
what
diligence
they
need
to
go
through
when
you
import
them,
and
so
that
sounds
pretty
exciting
to
me.
Yeah
it
I.
A
C
A
A
B
A
It's
weird
because
I
work
with
a
lot
of
folks
in
the
UK
and
Ireland,
and
you
know
those
organisms.
Those
entities
have
a
pretty
good
understand.
There's
a
lot,
a
pretty
robust
partnership
between
government
and
open
source,
where
you
know
the
government
heavily
leverages
open
source,
especially
like
just
talking
to
some
folks
in
Ireland,
some
Public
Utilities
folks,
and
that
they
have
a
a
lot
of
very
close
relationship.
So
it's
just
I.
B
B
A
B
We
felt
more
comfortable
and
also
me
formerly
working
for
sap.
We
felt
more
comfortable
writing
the
one
up
for
the
large-scale
in-house
development
yeah
and
so
just
to
walk
you
quickly
again
through
this
diagram.
Basically,
you
see,
on
the
very
left
hand,
side
kind
of
the
developer
right
working
on
his
Workstation
developing
code
locally,
pushing.
B
B
Don't
know
but
I
mean,
then
we
we
keep
it
like
this
okay,
so
we
have
basically,
on
the
left
hand,
side
right.
You
have
the
developer
of
such
a
large
scale
development
organization
sitting
at
this
developer
at
his
workstation
developing,
pushing
code
to
a
source
code
management
system
from
there
it
is
brought
to
some
in-house
build
systems
based
on
Jenkins
or
technon,
or
maybe
some
other
build
systems,
got
nose,
sure
and
then.
B
So
this,
and
this
generalization
I
think
would
be-
will
become
tricky
at
some
point
in
time.
Anyhow,
then,
basically,
the
blue
arrows
indicate
the
flow
of
proprietary
code
right
from
the
source
code
management
to
the
build
system
to
the
private
internal
binary
repository
repositories
such
as
Nexus
or
jfrog,
and
from
there
it
will
be
uploaded
to
some
distribution
platform,
could
be
some
Marketplace
a
website
of
that
organization,
but
sometimes
even
commercial
organizations.
B
A
A
B
No,
this
is
basically
the
lower
part,
I
would
say
where,
rather
than
just
making
a
downloadable
artifact
available
to
users
as
I
described
before
in
this
case
you
would
basically
operate.
The
organization
is
operating
the
solution
itself,
so
it
goes
to
this
QA
staging
process
and
then
ends
up
in
production,
and
so
there
would
be
this
portal
page,
so
the
user
opens
in
his
browser.
So
this
is
the
lower
part
right:
okay,
okay,.
A
A
B
All
right,
so,
basically,
the
lower
part
is
where,
where
the
proprietary
or
the
solution,
software
development
organization
is
operating.
This
solution
kind
of
cloud
cloud
service
solution,
while
the
upper
part
is
more
for
on-premise
software
that
has
to
be
made
available
that
is
downloaded
and
deployed
locally
by
by
users
on
premise
right,
that
is
the
blue
arrows
and
then
at
the
top.
B
We
basically
have
in
red
and
is
the
open
source
code
or
third-party
code
that
is
basically
coming
from
the
internet
and
which
is
downloaded
and
which
runs
on
all
those
different
systems
right
both
on
the
on
the
builds
build
system
on
the
source
code
management
well,
actually,
source
code
management,
maybe
in
not
so
much
maybe
here
is
kind
of,
but
then
definitely
on
a
workstation
on
the
build
system
and
also
third
party
open
source
and
open
source
dependencies.
Libraries
are
downloaded
and
basically
mirrored
on
the
Nexus
and
other
private
binary
repositories.
B
So
this
is
this
is
kind
of
the
flow
of
Open
Source
and
third-party
code
right
and
then
basically,
this
is
any
any
question,
but
maybe
on
the
top
right.
These
are
so
kind
of
the
stakeholders
or
personas
interacting
with
those
systems
are
the
develop,
on
the
very
left
hand,
side
the
user
on
the
very
right
hand,
side,
which
is
somehow
downloading
or
consuming
the
application
developer.
B
The
other
kind
of
roles
of
personas
that
relate
are
the
ones
on
the
top
right
people
working
on
vulnerability
management,
reliability,
Engineers,
all
the
system
and
service
administrators
that
configure
build
Services
source
code
management
system,
private
repositories
and
many
other
pieces
that
are
also
connected
here
and
but
we
didn't,
we
didn't
feel
it
is
right
to
really
connect
them
to
all
those
systems,
because
we
would
have
so
many
edges
in
this
diagram.
This
would
explode
everything
and
then
kind
of
the
same.
B
The
configuration
management
database,
a
solution,
the
different
all
those
static
and
dynamic
application
security
tools.
That
would
be
invoked
during
the
the
build
system
or
by
the
build
system,
and
so
we
felt
maybe
do
not
connect
everything
in
order
to
to
keep
that
image,
manageable
and
consumable.
B
Yeah,
let
me
just
write
down
those
I'm
just
writing
on
on
another
screen.
I!
Guess
you
don't
see
that
window,
but
doesn't
matter
I
will
share
this
document.
Yeah,
remember
I
should
share
this,
probably
right
now
that
you
can
also
edit
this.
Let
me
just
do
this
so
assumptions
where
basically,
some
roles
or
actors
and
internal
systems
are
not
linked.
D
B
I
we
didn't,
we
we
had,
we
started
dedicated
slides
to
for
the
for
the
user.
I
would
not
want
to
model
also
the
user's
workstation,
because
the
I
mean
for
me
the
whole
threat.
The
whole
idea
is
basically
supporting
development
organizations
to
not
be
compromised
by
malicious
third-party
code
consumed
throughout
the
whole
development
process.
B
B
A
And
then
that
would
also
exclude
things
like
an
Enterprise
ldap
source
of
identity.
If
an
attacker
gets
in
and
compromises
that
then
has
access
to
all
the
endpoints,
the
developer
can
get
to
so
yeah.
That
would
exclude
a
whole
set
of
other
things,
and
we
should
note
that
we're
not
that's
not
part
of
this
yeah
yeah.
A
A
B
Yeah
yeah
happy
to
hear
this
so
yeah.
The
idea
is
basically
to
use
this
as
an
input
to
this
whole
threat.
Modeling
exercise
right
and
so
basically
the
taxonomy
is
showing
all
the
different
ways
to
for
attackers
to
compromise
open
source
components
that
are
then
consumed
by
such
development
organizations
right.
D
B
Right
I'm
not
sure
whether
we
have
the
same
understanding
of
inner
Source
here.
So
in
my
mind,
this
is,
if
you
have
big
corporations
with
I,
don't
know
hundreds
of
development
teams
that
consume
each
other's
artifacts
and
components
that
you
have
I,
don't
know
a
development
team
working
on
the
other
side
of
the
globe
could
still
propose
and
make
contributions
to
the
components
done
by
a
different
development
team
of
the
same
organization.
So
the
idea
being
applying
open
source
principles,
two
internal
development
teams,
so
I'm
not
sure
whether
we
share
the
same.
That's.
D
Right,
so
what
I
mean
is
for
those
companies?
There's
no
I
think
you
mentioned
earlier
country
contributing
to
open
source
because
those
companies
they
they
probably
are
for,
like
a
broker
from
a
bank
to
contribute
to
open
source.
There's
a
lot
of
obstacles
yeah.
This
could
be
helped
understand
the
security
aspect
of
it.
B
B
B
A
B
Right,
we
also
already
had
and
just
feel
free
to
jump
in
and
add
to
what
I
brought
down
here
right.
We
also
did
with
in
a
previous
meeting
with
John
and
Abdullah.
We
came
up
with
a
couple
of
assets
to
to
protect
right
and
the
ones
that
we
basically
decided
on
is
basically
the
kind
of
the
source
and
the
binary
code
of
the
development
organization.
B
The
development
process,
so
this
holds
true
in
particular,
for
not
in
particular
for,
for
example,
for
the
staff
in
the
workstation
right
all
those
API
tokens.
God
knows
what
you
have
there
and
which
is
often
accelerated
webinitious
software.
We
also
thought
to
basically
have
the
systems
as
such
as
an
asset,
because
we
do
not
want
to
have
any
of
those
systems:
mining,
cryptocurrencies
for
providers
or
attackers.
Let's
say
on
any
of
those
machines
and
I
think
there
were
some.
Some
cases
indeed
were
I
think
it
was.
A
B
Out
in
the
cloud
I
think
to
some
extent
by
since
we
choose
or
chose
to
use
this
in-house
Bridge
system,
we
kind
of
got
around
this
problem
right,
so
there
will
be
also
shared
workloads,
kind
of
build
jobs
running
in
parallel
on
a
shared
machine.
But
since
we
excluded
in
inside
uprights
I
would
you
know
pause
this
for
the
moment
and
include
this
at
a
later
point
in
time.
If
it
ran
on
AWS,
then
they
would
be
in
scope
right
away.
B
B
A
A
B
A
D
I'm,
a
database
guy
and
what
I'm
interested
in
database
security
and
recently
is
zero
trust
security.
It
sounds
like
to
be
able
to
have
a
zero
trust.
They
are
have
to
take
into
account
of
Hardware
slash
firmware
security,
for
example.
If
have
a
device,
that's
authenticated,
whether
it's
laptop
or
even
iot
device
after
authentication,
even
if
the
token
like,
if
even
if
you
use
PC
Inspire
the
security
token
is
still
active,
that
firmware
could
reset
and
become
a
malicious
infected.
Endpoint.
A
B
A
Well
and
then
I
think
the
we're
focused
in
on
specifically
like
application
software,
somebody,
it's
a
library,
it's
a
binary.
It's
some
other
component,
we're
ingesting
to
make
this
Enterprise,
so
we're
making
a
on
a
customer
sales
platform.
So
we
sell
something
we
sell
widgets
and
this
development
team
is
making
this
web
Cloud
platform
and
they're
they're
downloading
openssl
or
you
know
some
open
source
database
and
those
are
the
components
I
believe
that's
in
scope.
A
We're
not
necessarily
worried
about
the
fact
that
I'm,
a
bad
developer
and
I
want
to
embezzle
a
penny
off
of
any
transaction.
We're
not
talking
about
like
Insider
threat,
we're
not
worried
about,
like
the
nation
state,
spy
chain,
side,
Channel
kind
of
things
we're
just
focused
on
somebody
tampers
with
the
open
source
software
and
we
ingest
it
into
this
protected
kind
of
Walled,
Garden.
All
right,
yeah.
B
There
would
there
would
also
be
my
view,
but
I
find
it
super
interesting
to
see
what
of
what
we
discuss
and
we'll
discuss
applies
to
Firmware
as
well
or
not,
and
what
is
different,
so
I
I
would
I
would
exclude
it
for
the
beginning,
but
it
would
be
nice
to
kind
of
keep
in
the
back
in
the
back
of
the
head
and
work
out.
Differences.
B
And,
and
maybe
the
last
asset
that
we
we
came
up
with,
is
as
soon
as
you
started
as
soon
as
you
mirrored
or
downloaded
third
party
code
onto
any
of
the
internal
systems,
they
also
become
kind
of
in
a
set
because
what
you
have
downloaded
and
what
you
will
consume
throughout
the
development
process
must
not
be
tampered
with
by
maybe
other
components.
So
a
typical
scenario
could
be.
For
example,
you
have
a
in-house
build
system.
A
B
It
depends
on
the
in
whether
there's
intent
and
so
indeed
take
technically.
There
may
be
no
difference
between
vulnerability
accidentally
introduced
in
an
open
source
component
and
a
vulnerability
introduced
on
purpose,
and
so
here
the
intent
makes
lets
you
distinguish
it
and
then
then,
if
it's,
the
only
difference,
I
I
think
this
so
intentionally
included.
Vulnerabilities
should
be
in
in
the
scope.
I
find
I
find
this.
If
I
wear
an
attacker
I
would
find
this
a
very
promising.
Yes,
a
tech
vector.
A
B
B
I
think
yeah
I
think
this
is
relevant.
Okay,
because
if
you
download
malicious
open
source
packages,
they
can
very
well
look
around
sneak
around
and
misuse
and
exploit
any
misconfigured
or
vulnerable
internal
system.
So,
even
if
we
exclude
Insider
threads
in
the
beginning,
it
is
still
I
would
say
it
is
still
in
scope.
Okay,
so
which
is
which
is
nice,
because
with
this
we
cover
a
lot
of
things
that
also
matter
for
the
for
The
Insider
threads,
so
in
scope
is
as
well
misconfigured
and
vulnerable
systems.
B
B
A
A
B
A
So
so
I'll
take
the
action
item.
I
will
re-review
the
taxonomy
document
and
then
look
at
the
the
large
Enterprise
diagram
here
and
I'll.
Come
back
with
a
couple,
more
questions
about
scope
and
I.
Think
maybe
next
time
we'll
have
Abdullah
and
Jonathan
that'll
be
able
to
that
helped
build
it.
So
I
think
they
will
have
it
a
good
informed.
B
Comment
I
could
I
could
also
walk
to
you
again
quickly
through
the
through
the
taxonomy,
in
order
to
explain
how
we
build
it
and
why
we
build
it
that
way.
I'm
not
sure
you
were
reading
yourself
through
the
document
in
the
past.
Maybe
you
have
used
the
the
UI,
but
so
let
me
just
drag
this
over
I'm,
not
sure
whether
you
see
still
now
the
this
tree
I.
B
Right,
okay,
so
this
is
basically
a
copy
of
the
the
same
visualization
that
we
did
back
then
at
sap,
and
so
the
idea
is
basically
with
this
the
tech
tree.
We
wanted
to
basically
show
all
the
different
attack
vectors
at
the
disposal
of
attackers
and
other
two
share
and
distribute
malicious
code
and
have
it
executed
on
basically
at
Downstream
consumers
systems,
and
so
the
high
level
goal
of
this
Tech
tree
is
to
conduct
an
open,
so
a
supply
chain
attack.
B
You
have
here
for
every
every
node
of
the
attack
tree
an
explanation
and
basically
the
three
different
sub
goals
in
order
to
reach
this
high
level
goal
where
to
in
the
middle.
Here
we
have
all
those
name,
confusion,
attacks
where
you
have
type
of
squatting,
brand,
checking,
combo
squatting
and
the
like
right
at
the
bottom.
We
have
where
you
subvert
an
existing
package
with
all
its
infrastructure.
B
B
It's
a
third
attack
sub
goal,
which
is
to
basically
create
and
advertise
a
malicious
package
from
scratch
right.
The
difference
why
we
came
up
with
this
split
is
basically
it
is.
They
come
with
different
degrees
of
attackers
interfering
with
existing
project
resources.
What
do
I
mean
with
this?
If
an
attacker
is
wanting
to
infect,
for
example,
react
he
would
need
to
interfere
either
with
its
source
code
repository
with
its
build
system
or
with
the
package
repository
where
a
react
components
are
shared
right.
B
So
we
really
need
to
interact
with
those
existing
resources
which
is
different
from
the
other
nodes
because
for
name
confusion,
attacks.
There
are
no
such
resources.
You
just
create
a
new
component
with
a
name
that
is
not
existing.
There
is
no
and
you
just
deploy
it
on
npm
or
pipe.
Your
eye
got
nowhere
and
there
is
no
real
kind
of
yeah.
You
don't
attack
any
any
existing
resources
other
than
maybe
the
user
base
that
use
the
legitimate
package
in
the
past,
but
and
then
on
the
very
top.
B
This
is
again
the
least
degree
of
interference
with
existing
project
resources,
where
you
just
develop
something
for
maybe
a
couple
of
months
or
years
before,
to
create
a
user
base
and
then
use
this
for
spreading
malicious
codes
at
a
later
point
in
time.
So
these
are
the
first
child
notes
on
the
child
nodes
on
the
first
level,
and
then
it
is
spreading
out
mostly
here
at
the
bottom
and
I
think
this
is
where
also
yeah,
no
full
stop.
B
Or
dangling
references,
for
example,
kind
of
you
have
expired
domains.
You
can
re-register
them
these
kind
of
things
or
a
mask
legitimate
packages.
Here
you
have
the
basically
also
the
dependency
confusion,
which
is
the
fourth
bullet
here
and
all
these
things.
So
this
is
this
is
something
that
happens
in
the
distribution
process.
B
B
A
B
A
B
A
B
Well,
for
me,
it's
more
I
mean
one
one
problem
I
could
imagine
is
that
you
have,
even
if
for
bigger
corporations
they
by
now,
they
all
have
I
would
say
some
governance
on
how
which
components
are
selected.
What
are
the
quality?
What
kind
of
quality
criteria
have
to
be
met
in
order
to
have
a
component
part
of
the
application
developed
and
shipped
by
this
organization-
and
this
is
this-
is
all
nice
and
and
required,
but
the
thing
on
one
big
problem
I
see
is
that
this
is
just
the
components
part
of
the
applications.
B
This
is
not
what
and,
and
what
the
developer
is.
Downloading
is
a
lot
more.
You
have
all
these
Ides,
IDE,
plugins
and-
and
even
though
maybe
you
know,
he
will,
of
course,
also
download
the
components
to
develop
locally.
What
will
be
shipped
by
this
organization,
but
on
top
of
that
maybe
all
kind
of
other
dependencies
just
for
trying
something
out
for
developing
his
hobby
projects.
That
is
also
developing
on
his
work
station
and
so
I.
That's
that's
why
I
basically
included
this
top
Arrow
right?
A
B
Yeah
and
and
what
I
find,
for
example,
maybe
a
good
example,
even
if
you
maybe
you
even
for
a
component
that
you
that
is
part
of
the
application
that
is
mirrored
internally
in
order
to
consume
the
component
from
the
mirror.
You
probably
need
to
configure
your
local
package
manager
right.
So,
if
you
use
Maven,
you
will
need
to
instruct
Maven
to
use
that
mirror,
which
is
managing
all
the
stuff
for
you,
but
I'm
not
sure
that
all
the
developers
configure
this.
A
B
D
B
D
D
B
A
C
B
Yeah
but
I
guess
this
in
the
first
place.
This
holds
true
for
again,
for
example,
Maven
Java
components
right
I'm,
not
sure
whether
such
a
thing
is
even
existing
for
IDE
plugins
and
just
recently
heard
of
a
couple
of
malicious
Visual
Studio
code
plugins.
That
is
not
something
that
I'm
not
even
sure
that
yeah,
whether
this
is
kind
of
governed
and
regulated,
and
whether
there
are
some
policies
around
what
IDE
plugins
can
or
cannot
be
installed
by
developers.
Some
organizations
may
have
this.
Others,
probably
don't
yeah.
A
B
Yes,
but
I
guess
no
yeah
and
then
it's
up
to
every
organization
deciding
whether
it
can
or
cannot
take
the
risk
of
avoiding
to
go
through
this
time
consuming
approval
process
and
which
puts
a
lot
of
load
on
those
teams
working
on
the
approval
process.
Those
poor
guys
have
I
mean
in
in
companies
like
sap
and
Microsoft
and
Apple,
and
all
those
big
I,
don't
wanna,
imagine
the
number
of
components
they
would
need
to
green
list
and
Blacklist.
D
B
C
A
B
B
A
B
B
B
D
The
information
the
links
to
that
those
two
parlors-
that's
a
s
yeah,
so
I'm-
also
new
to
a
lot
of
this
since
I'm
at
the
you
know,
database
guy
for
a
long
time
yeah.
But
but
this
information
is
very
interesting
because
I
mean
for
newcomers
to
security
where
to
start
you
know
where
the
security
threat
come
from.
There's
a
big
question
mark
so
having
diagrams
definitely
is
very
helpful.
B
B
B
D
C
B
This
interaction
could
also
be
exercised
by
a
malicious
component
that
is
running
on
the
workstation
and
maybe
anywhere
else
as
long
as
it
has
access
to
the
to
the
respective
interfaces
of
the
the
QA
production
runtime
yeah
yeah.
This
is
kind
of
for
me.
This
would
be
I
wonder
whether
this
is
impact
right,
because
the
impact
of
running
them
consuming
a
malicious
package
running
it
internally.
The
impact
could
be
not
only
to
to
kind
of
change
Maybe
to
become
part
of
an
application
shipped,
but
also
to
really
just
change.
D
B
Okay,
so
I've
noted
this
down,
basically
kind
of
as
a
comment
from
you
to
clarify
whether
git
office
in
the
score
in
the
scope
or
not,
and
maybe
to
consider
this
as
impact
in
the
sense
that,
once
you
have
a
malicious
component
entering
your
infrastructure,
it
could
crawl.
Basically,
your
production
or
your
your
services
and
then
tamper
with
those.