►
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
Well
back
when
I
worked
in
an
office,
the
team
I
worked
with,
we
would
all
go
out
together
for
lunch,
so
it
was
an
important
bonding
experience.
I
don't
have
that
anymore,
working
at
home
yeah!
That's.
B
So
I
was
chatting
with
Jonathan
earlier
on,
so
he's
off
on
vacation
apparently
I'm
not
sure
what
the
Abdullah
will
be
able
to
join.
Let's
see
and
I.
B
B
A
A
Find
it
it
can
get
kind
of
dry.
B
Well,
maybe
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
did
I.
A
C
A
Actually
I
have
a
meeting,
but
today
about
the
CRA
we're
talking
about
the
EU
cra.
B
In
I
already
open,
ssf
was
basically
complaining
about
their
first
draft
and
then
I
saw
some
emails
going
around
or
maybe
slack
challenge
where
there
was
an
open
letter
or
a
response
formulated
by
the
open,
SSS
yeah.
A
A
A
So
that's
we
feel
that's
a
good
thing.
It's
just
you
know
with
the
open
source.
It's
a
little
strange
since
you
know
what
it's
not
necessarily
somebody's
job.
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
the
government
heavily
leverages
open
source,
especially
like
just
talking
to
some
folks
in
Ireland,
some
Public
Utilities
folks,
and
they
have
a
a
lot
of
very
close
relationship.
So
it's
I.
B
B
Like
it's
just
the
two
of
us
for
for
today,
so
maybe
we
just
sort
of
thought.
B
A
B
Then
maybe
let
me
walk
you,
so
what
we
will
be
looking
at
is
slide
number
four
right,
because
we
are
still
missing
a
little
bit
of
input
on
from
a
smaller
development
organization,
on
how
kind
of
a
generic
architecture
can
look
like
for
small
organizations
and
so
with
John
and
Abdullah,
especially
with
John.
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
its
develop
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.
A
Yeah,
there's
there'll
be
a
lot
of
variety.
There
I
agree.
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
They,
of
course,
also
release
open
source
components,
so
in
that
case
they
would
end
up
on
Pi
Pi
or
maybe
other
package
repositories
or
package.
Various
trees.
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
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
developed
by
that
organization.
B
You
also
have
inner
Source
contributors
that
yeah
follow
this
open
source
approach,
but
from
within
they're
on
the
project,
company
and
I'm,
not
sure
whether
this
is
at
least
at
sap
when
I
when
I
worked
there.
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
How
it's
true
for
the
other
homemade
or
third-party
solutions
that
also
run
in-house
in
such
organizations
that
are
used,
maybe
to
store
credentials.
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.
A
C
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.
You
know.
I
should
share
this,
probably
right
now
that
you
can
also
edit
this.
Let
me
just
do
this
so
assumptions
were
basically
some
roles
or
actors
and
internal
systems
are
not
linked.
D
A
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
So
the
the
goal
basically
would
be
that
whatever
is
downloaded
or
consumed
by
the
user
is,
let's
say,
untempered
secure
and
then
whether
it
met
whether
it
gets
messed
up
at
the
user's
workstation
is,
of
course,
also
a
problem,
but
one
outside
of
the
scope
of
the
diagram
of
the
exercise.
So.
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.
B
A
A
B
That
is
the
idea,
so
basically
the
the
this
taxonomy
that
your
daughter
and
I
developed
both.
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
I
love
the
diagrams.
This
is
also
a
good
face
diagram.
It
just
gave
a
new
camera
to
the
I'm,
a
database
guy
by
the
way,
I
love
chips
too,
but
the
security
is
very
interesting
and
but
without
a
deep
knowledge.
The
diagram
is
a
great
way
for
me
to
understand
the
landscape
so
yeah.
This
is
good.
D
One
thing
I
would
say
that
just
looking
at
one
area
that
I
I
just
joined
different
kinds
of
community
meetings,
I
know
for
like
financial
industry
banking,
especially
so
the
inner
source
is
Big,
because
it
cannot
share
a
lot
of
technology
outside
the
firewall
because
of
legal
as
well
as
not
understanding
the
details
here
so
yeah.
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
A
And
we
probably
also
want
to
potentially
document
that
in
the
scope
that
we're
not
currently
focused
on
the
Enterprise
contribution
back
to
open
source
at
this
point,
that
could
be
a
future
thing
if
you're
interested.
B
B
A
B
All
right
scope
so
in
a
source
contributions
or
amount
of
scope
in
the
beginning.
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
publisher
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.
B
A
Like
we're
not
you're,
not
worried
about
co-locating
trusted
and
untrusted
workloads
and
someone
running
a
side,
Channel
attack
to
siphon
off
data-
we're
not
that's
not
part
of
our
problems.
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
our
threats,
I
would
you
know,
pause
this
for
the
moment
and
include
this
at
a
later
point
in
time.
If
it
ran
on
AWS,
then
that
would
be
in
scope
right
away.
A
So
do
we
agree
that
the
assumption
is
that
all
the
infrastructure
is
inside
the
wall,
so
to
speak,
it's
all
inside
some
type
of
protected
data
center,
or
will
there
be
potentially
elements
that
do
run
on
public
resources.
B
B
A
A
So
you
would
expect
Network
isolation.
You
would
expect
Enterprise
identity
management.
You
would
expect
log
management
and
log
monitoring.
B
All
right,
okay,
yeah,
we
have
some
I
mean
we
have
the
own
IDP.
We
already
have
this
okay,
but
these
are
more.
What
we
mentioned
on
the
top
are
more
different
systems.
You
would
expect
and
Network
those.
A
Personas
would
manage
them
like
there
would
be
an
Enterprise
database,
so
no
one
is
spinning
up
their
own
copy
of
mariahdb
outside
of
the
managed
dbas.
So
we
would
expect
there's
some
net
available,
protected
Network
internal
services.
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
So
would
we,
what
would
you
consider
a?
A
Let
me
give
you
a
couple
scenarios:
a
developer
downloads
and
updated
Upstream
Library
and
there's
a
regression
there's
no
API
or
API
compatibility
and
it
breaks
the
application,
and
so
your
availability
is
down.
How
would
you
consider
that,
in
this
scenario,
it's
a
mistake
rather
than
an
attack?
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
And
then,
what
about
infrastructure
misconfiguration
somebody
misconfigures
something
and
gives
broader
access
than
they
intended?
What
would
you,
how
would
you
consider
that,
as
part
of
the
the
attack
here.
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
Right,
if
it's
anything
else
for
the
let's
say,
initial
assumptions,
scope,
assets.
A
I
I'd
like
to
did
we
do
this
every
week
or
every
other
week.
I,
don't
recall.
B
Week
to
make
some
progress
on
this
I
would
be
happy
to
have
this
once
a
week,
because
I
feel
it
was
a
two-week
cycle.
It
would
be
again
taking
us
10
minutes
to
get
into
it.
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
clip
is
basically
it
is.
They
come
with
different
degrees
of
attackers
interfering
with
existing
project
resources.
What
do
I
mean
with
this?
B
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
react
components
are
shared
right,
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's
no
real
kind
of
yeah.
B
You
don't
attack
any
any
existing
resources
other
than
maybe
the
user
base.
That
used
the
legitimate
package
in
the
past,
but
and
then
on
the
very
top.
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.
B
So
these
are
the
first
child
notes,
although
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.
That
I
was
forget
about
this,
and
so
here
when
it
comes
to
subverting
a
legitimate
legitimate
package,
attackers
can
either
look
and
inject
something
into
the
source
code
repository,
maybe
using
hypocrite.
B
Merge
requests
become
a
maintainer
or
contribute
as
maintainer
Maybe
by
reusing
leaked
credentials
or
by
you
know,
using
kind
of
hijacking
accounts
in
other
ways
or
by
exploiting
vulnerabilities
in
the
versioning
control
systems
there
and
so
forth
same
thing
here
on
the
Tech
attacking
during
the
build
you
could
for
shared
build
systems,
run
a
malicious
build
in
order
to
compromise
shared
resources.
B
Yeah
we
back
then,
when
we,
when
we
created
this
with
Pierre,
Georgia
and
I,
we
thought
this
is
the
only
way
of
making
this
huge,
taxonomy
consumable,
because
otherwise
you
you
may,
if
you
read
through
the
paper,
it's
nice
to
have
it,
but
then
it's
not
really
not
really
usable
right
and
on
the
top
at
the
bottom.
B
Here,
the
third
one
is
kind
of
injecting
it
in
when
in
the
distribution
infrastructure-
and
this
is
that
is
including
again
vulnerabilities
in
npm
and
Pipi,
and
there
are
every
now
and
then
but
also
cdns,.
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
Good,
all
right,
good
back
to
back
to
the
architecture,
I'm,
not
sure
whether
maybe
we
spent
a
few
minutes
on
agreeing.
How
do
we
want
to
describe
and
model
those
threads
or
do
you
prefer
that
I
look
something
up
and
take
take
it
from
some
template.
A
B
A
I
I
guess,
for
today
we
could
start
there.
I
think
we'll
probably
spend
a
lot
of
I.
Think
there'll
be
a
lot
there'll,
be
a
Target
Rich
environment
for
us
to
have
discussions.
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
Bleeding
edge
untested,
unverified
components
if
you're
testing
out
something
if
you're
experimenting
and
if
you're,
especially
if
also
you're,
doing
your
hobby
project
as
well.
Exactly.
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
I
just
said,
the
bottom
of
the
diagram
that
under
deploy
is
part
of
the
criminal.
Sorry
about
the
background
get
up,
such
as
what
is
called
git
options.
I'll
put
it
in
the
chat.
B
B
You
mean
so
so
this
is
related
to
operating
your
source
code
management
system
deployment.
D
Sorry,
there's
somebody
mowing
around
here:
yes,
should
it
be
yeah,
it's
just
not
mentioned
at
the
bottom
of
the
diagram,
the
in
the
deployment,
that's
one
of
the
isilian
scope
or
not.
B
Yeah,
but
wouldn't
it
so,
how
would
the
data
flow
look
like?
Wouldn't
it
also
go
through
the
build
system?
Somehow.
B
All
right,
good.
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
And
I
think
you've.
The
same
probably
holds
true
to
like
small,
like
micro
code
Snippets
I
I
did
a
small
script.
I
have
a
small,
plug-in
and
I
agree.
It's
probably
very
ponderous
to
go
through
your
enterprise
software
approval
process
for
a
small
snap
in
for
your
IDE.
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
A
B
Yeah
all
right,
let
us
try
to
write
this
down,
so
we
had
this
first
one
kind
of
misconfigured
package
managers,
the
other
one-
was
basically
a
lack
of
bypassing
non-existing
approval
processes
or
bypassing
existing
approval
processes
for
Ides,
IDE,
plugins
and
other
development
tools.
Right,
yes,.
B
Well
then,
that
is
high
prior
then
thank
you
for
joining.
There
was
a
a
very
nice
conversation
hope
to
see
you
next
week.
If
you
can
change
the
schedule,
or
maybe
it
is
already
on
a
weekly
basis,.
A
B
B
B
Hi
Victor,
so
you're
still
here,
right,
yeah
I'm
still
here,
not
sure
whether
we
will
be
thrown
out
of
the
the
zoom
in
a
second
or
not
okay.
So
basically.
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
I,
just
try
to
I
will
read
through
the
to
the
through
the
documents
you
shared.
For
me,
it
seems
to
be
part
of
this
part
of
the
let's
say,
part
of
the
proprietary.
It's
a
code
and
code
in
a
wider
sense,
including
configuration
deployment
configuration,
and
so
that
is
very
well
in
scope.
For
me,
if.
B
D
Yeah
I
think
it
maintained
not
only
the
this
the
actual
code
itself,
but
also
state
of
the
actual
implementation
instances.
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.
B
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.
B
C
B
Accounts
bringing
Services
down
or
something
yeah.
D
This,
too,
is
specific
to
the
two
products
that
posted
there,
the
Argo,
CD
and
and
flux
and
yeah
see
whether
so
what
those
two
products
do
is
part
of
this
picture
here.
B
Okay,
let
me
read
through
this
I,
don't
know
what
rocd
does.
B
Right,
great
good
anything
else,
you
want
to
add
now.
D
D
B
B
No,
no
sorry,
it's
the
other
way
around
I'm
confused.
It's
10
o'clock
in
the
morning
so
then
have
a
lovely
day.
B
Yeah
I'm
sitting
here
in
Europe,
so
it's
six,
it's
four
o'clock
in
the
afternoon:
okay,.