►
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
A
A
B
B
A
A
B
A
And
so
I
think
Victor
and
I
will
say
yeah.
Maybe
we,
what
we
can
do
today
is
really
go
and
go
through
the
lists.
Go
concentrate
on
one
of
the
systems,
maybe
the
workstation
and
come
up
with
all
the
possible
problems
that
result
from
the
consumption
of
malicious,
potentially
malicious,
open
source
components
on
on
the
workstation.
Maybe
it's
even
making
sense
to
go
through
the
list
or
just
come
up
with
a
number
of
examples,
and
we
already
started-
and
maybe
we
can
just
continue
here.
A
B
I
don't
mean
the
keyword
workstation
so,
for
example,
I
I
considered
your
the
graph,
the
taxonomy
database
right
so
they're,
the
the
yeah
just
on
the
screen.
There's
development
right,
that's
probably
related
to
the
developer,
workstation
and
then
the
second,
the
the
the
second
green
name,
confusion
package.
A
That
is
definitely
one
thing
that
is
related
to
the
workstation,
so
create
name
confusion
here.
The
idea
is
that
attackers
basically
give
names
in
one
or
another
way,
similar
to
packages
that
are
well
known
or
that
are
used
commonly
used,
and
so
what
the
the
the
common
example-
and
maybe
let's
just
focus
on
this
since
you
have
picked
this
example
and
one
example-
is
of
course
the
the
type
of
squatting
that
all
of
us
have
have
heard
about
in
the
last
couple
of
years.
A
But
then
there
are
a
couple
of
other
comparable
techniques
right,
so
I
think
there
have
been
numerous
cases
where,
for
example,
malicious
actors.
They
were
just
pre-pending,
AWS
Dash
in
front
of
a
package
name
just
to
make
it
look
like
it
came
from
from
from
Amazon
right
and
just
be
kind
of
the
established
trust,
and
let
me
just
click
on
it:
the
establish
trust
into
the
package,
just
by
pretending
it
comes
from
AWS.
A
A
A
These
are
all
different
systems
within
that
development
organization,
and
in
particular,
here
the
workstation
is
yeah
belonging
to
a
software
developer,
I
I
wouldn't
want
to
because
it's
we
discussed
those
malicious,
open,
source,
consumption
or
and
open
source
packages
in
the
context
of
developing
software,
so
I
wouldn't
want
to
have
to
describe
the
workstation.
You
know
of
a
of
a
guy
working
for
the
HR
or
legal
department
in
a
company.
That's!
This
is
not
so
interesting.
I
find.
E
I
would
urge
you
not
to
use
the
word
workstation,
because
there
is
an
actual
technical
definition
of
what
a
workstation
is
like
like
there
are
like
actual
physical
workstations
that,
like
some
people
are
issued
like
if
you
work
in
Creative,
you
know
like
you
have
the
like.
They
have
specific
graphic
cards
for
workstations
that
allow
you
to
render
a
bunch
of
stuff.
So
there
is
a
specific
technical
definition
of
workstation,
so
I
would
urge.
E
A
A
C
E
A
So
of
course,
attackers
can
create
such
name
confusion
also
in
other
marketplaces.
This
is
not
restricted
to
this
command
line
package
managers,
let's
say
and
I'm,
not
sure
whether
the
attacks
the
there
were
some
malicious
Visual
Studio
code,
plugins
found
in
the
wild
a
couple
of
months
ago,
I'm
not
sure
which
of
those.
If
any
of
those
techniques
they
were
using
because
I
mean
does
anybody.
Remember.
A
A
I'm
not
sure
which
technique
was
used,
I
mean
brand
checking
and
type
of
spotting
and
combo
squatting.
These
are
just
alternatives
on
how
you
manipulate
a
name,
a
legitimate
name,
in
order
to
trick
users
into
installing
it
I'm,
not
sure
which
one
of
those
confusion
techniques
was
used
for
this
Visual
Studio
code
plugins.
It
would
be
nice
in
fact,
I
think,
to
have
examples
for
the
different
for
the
different
threads
here.
What
they
materialized.
E
E
Might
that
statement
might
not
be
taken
with
the
best
light
in
the
packaging
communities,
because
with
the
packaging
communities
would
tell
you,
is
that
there's
a
reason
that
we
offer
everything
openly,
because
you
should
verify
before
installing
anything
we're
not
a
community
where
no
package
Community
as
far
as
end
user
packages
will
actually
ensure
security
as
Homebrew
likes
to
say
they
like
to
say
it
in
the
sense
of
like
it's.
Just
not
our
purview,
we're
a
last
line
of
defense,
so
I
would
recommend.
E
Maybe
there
you
reword
that
as
far
as
blaming
it
on
a
misconfiguration,
you
should
definitely
like
verify
things
before
you
install
them.
At
least
I
could
tell
you
from
Portage
and
Homebrew,
which
are
the
two
communities
I'm
a
part
of
that
both
of
them
would
agree
with
you
there
that,
like
what
we
offer
is
Simplicity,
but
it's
not
like
an
end-all
be-all.
You
should
definitely
be
familiar
with
what
you're
installing.
A
I
I
I,
I
I,
understand
what
you
mean,
but
I
think
what
you
say
is
Safeguard
or
a
counter
measure
right.
So
what
we
described
first
are:
these
are
the
problems.
These
are
the
things
that
can
go
wrong
and
then
later
on,
we
come
to
what
you
should
do
differently
and
what
we
can
do
about
it
right
and
so
I
agree.
You
should
only
install
what
and
verify
before
you
install
anything,
but
for
me
this
is
something
that
comes
at
a
later
point,
because
it
is
a
control
since
we
didn't
go
over
those.
A
This
is
I,
think
two
bullet
items
that
we
have
created
like
two
weeks
ago
or
so
I
can
maybe
say
a
sentence
about
this.
This
is
thing.
This
is
something
that
basically,
if
you
have
a,
if
you
have
a
package
manner
like
like
Maven
or
pip
in
bigger
corporations,
they
should
be
configured
to
download
open
source,
as
well
as
internal
packages
from
an
internal
trusted.
E
A
E
That's
a
very
good
question:
I
think
everyone
has
their
own
version
of
how
to
answer
that
question
because,
like
npm
would
answer
with
package
lock
at
probably
as
part
of
their
answer
with
Portage,
they
would
probably
answer
that
is
just
shell
scripts.
So
if
you
know
shell
scripting,
you
should
be
able
to
like
understand.
What's
going
on
and
further
on,
you
should
be
fairly
easy
to
modify.
If
you
know
some
simple
bash
scripting
now
brew
has
their
own
DSL,
it's
pretty
straightforward.
E
So
that's
what
I'm
saying
that,
like
the
there's
there's,
there
have
been
problems
in
the
past,
for
example
with
packages
especially
like
on
The
Homebrew
Cask
side,
where
there
have
been
applications
that
have
been
bought
by
other
companies
with
nefarious
intent
that
started
installing
spyware
and
stuff
like
that,
and
then
it
becomes
an
issue
because
users
say.
Why
did
you
install
this
on
my
computer
and
it's
like?
Because
we
don't
have
it?
We
don't
carry
an
opinion
on
what
you
installed.
E
You
should
know
what
you're
installing
we
we
basically
just
carry
it
and
it
passed
our
verification
checks,
because
what
we
verify
is
that
it
actually
came
from
the
vendor
and
it
legitimately
came
from
the
vendor.
But
what
happens
when
the
vendor
becomes
toxic
itself
and
the
vendor's
just
pushing
out
bad
updates
that
are
completely
valid
because
as
a
package,
it's
completely
valid,
but
it's
just
the
vendor
went
and
got
bought
out
by
some
spyware
company.
A
So
I
think
there
should
be
so.
The
one
part
of
the
verification
is
just
to
check
the
Integrity
of
the
binary.
You
have
downloaded
right.
Is
it
what
you
install
really
what
is
hosted
and
what
has
been
published
by
the
respective
publisher
and
the
other
part
which
goes
well
beyond
that
and
I
think
you
mentioned
this
in
regards
to
shell.
Script
is
really
looking
at
the
code
and
trying
to
understand
what
it
does,
which
is,
of
course,
only
possible
for
very
small
dependencies.
E
And
that's
actually
the
to
be
honest
with
you
Henrik.
That
was,
that's
actually
always
been
the
best
big
discussion,
because
kind
of
the
whole
part
of
Open
Source
was
like
okay.
Well,
you
should
do
this
with
all
open
source
that
you
should
verify
it
before
you
install
it
make
sure
it
meets
your
needs.
E
If
not,
you
can
modify
customize
it
whatever,
whatever
whatever
but
yeah
like
a
lot
of
people,
that's
just
not
possible
and
that's
one
of
like,
for
example,
you
look
at
wire
guard
and
that's
one
of
the
selling
points
of
wireguard
that
you
could
sit
down
and
audit
it
in
an
afternoon.
You
could
read
the
whole
thing
and
understand
what
it
does
when
you
go
to
like
open
VPN.
You
can't
do
that
in
an
afternoon
it
it's
taken
people
months
to
understand
half
of
what
it
does.
E
So
that's
always
been
an
argument
like
that,
like
this
is
great
in
concept,
but
in
application
does
it
really
work
and
I
could
tell
you
firsthand
that?
Yes,
I've
seen
people
make
it
work,
but
I
have
also
seen
a
lot
of
people
struggle
with
it,
but
there
are
parts
of
it
that
I
grew
agree
with
and
I
do
agree
with
the
fact
that
don't
be
installing
stuff.
Just
because,
because
I've
seen
a
lot
of
things,
I've
seen
vendors
go!
Oh
wait!
Let
me
just
update
this
package,
really
quick.
E
Nobody
will
notice
people
notice
and
they
could
definitely
throw
things
off.
So
I
would
definitely
say
like
before
you
install
anything
make
sure
you
know
what
you're
installing,
even
if
that
is
pulling
up
like
I'm
sure
may
even
I
don't
work
as
much
in
Maven,
but
I'm
sure
Maven
has
in
the
most
package.
E
Managers
have
them
and
you
could
at
least
figure
out
what
binary
words
coming
from
and
if
at
least
it
passes
the
sniff
test,
because,
basically
that's
what
your
package
manager
will
do
is
just
verify
that
it
came
from
the
vendor,
and
sometimes
it's
very
legitimately
comes
from
the
vendor.
It
is
the
vendor
became
toxic.
A
I
think
where
we
will
see
a
difference
also
is
I
mean
here
we
speak
of
this
development
organization
that
is
not
in
a
highly
regulated
environment,
so
I,
guess
the
the
verification,
steps
and
the
the
concrete
activities
performed
differ
on
kind
of
your
risk
appetite
and
whether
you're
subject
to
regulations
or
not
true,
all
right
so,
and
this
can
be
anything
from
a
sniff
test.
Looking
up
how
many
stars
the
project
has
up
until
using
whatever
starts
and
dust
tools
on
those.
A
B
E
Know
s-bomb
is
a
very
highly
polarized
Topic
in
the
actual
community
at
large,
like
for
us,
as
as
security
people.
It's
a
solution,
but
I,
don't
know,
and
I
can't
tell
you
that
I
could
tell
you
that,
like
I'm,
a
part
of
a
lot
of
conversations
in
the
Greater
Community
and
I
can
tell
you
that,
like
no,
it's
not
it's
not
something
it's
not
as
unifying
as
you
would
think
inside
of
the
communities,
because
Homebrew,
for
example,
I
could
tell
you
their
position
firsthand.
E
Is
that
they're
not
going
to
implement
it
unless
open
ssf
is
willing
to
invest
like
the
money
effort,
time
energy
that
it
would
cost
them?
Which
is
a
lot
of
money,
because
we,
for
example,
we
we've
talked
to
them
about
it
and
yeah
it
just
I.
Don't
I,
don't
foresee
that
happening
at
any
point
in
the
future
and
that
if
that's
not
going
to
fly
for
Homebrew
like
it's
not
even
worth
talking
about
Portage
and
that's
the
other
thing
Victor.
E
If
you
really
want
to
know
where
that
conversation
goes,
that
conversation
goes
down
a
path
that
open
ssf
is
really
insensitive
to
the
fact
that
security
has
existed
long
before
openssf
was
ever
a
thing
and
there
are
multiple
generations
of
security
and
that
different
people
have
implemented
the
security
in
different
ways.
And
now
you
coming
here
with
s-bomb
and
your
newest
Shiny
Toy
doesn't
really
solve
anything
because
I
already
solved
that
problem.
And
if
you
don't
like
it,
then
that's
not
my
problem.
That's
how
most
communities
react.
If
you
want
an
honest
truth,.
E
A
All
right,
good,
so
and
I
think
we
we
remain
stuck
at
the
first
one
right,
so
maybe
another
sentence
of
the
second.
The
second
was
basically,
if
even
if
you
have
maybe
an
approval
process
within
such
an
organization
that
controls
what
developers
are
supposed
to
install
on
the
developers,
one
possibility
of
courses
that
they
just
completely
ignore
it
and
install
it
from
from
other
sources
directly,
basically
bypassing
any
any
approval
processes
right,
the
name,
confusion.
The
other
thing.
E
E
Would
say
that
it
highly
depends
on
the
ecosystem
that
you're
a
part
of
and
what
that
ecosystem
offers
and
making
sure
that
your
developers
stay
within.
If
you
want
to
call
it
that
ecosystem,
even
though
an
npm
world
that
wouldn't
be
correct,
because
npm
has
like
yarn,
npm
and
pmpm,
and
then
you
have
things
like
Dino
and
you
see
like
even
with
me
and
like
with
at
SKF.
E
We
have
issues
like
that
where
developers
are
like
hey,
you
know
like
I
built
this
and
I
built
it
in
Dino,
because
I
thought
Dino
is
cooler
than
node
and
and
yeah.
You
know
like
it's,
it's
so
I
would
say
that,
like
you
know,
definitely
staying
within
like
understanding
what,
where
you're,
working
and
using
the
tools
correctly
because
like
for
example,
mpm
is
very
powerful.
If
you
want
to
make
like
make
sure-
or
you
want
to
maintain
that
Integrity
of
your
code
base
like
they
do,
offer
a
lot
of
tools.
E
But
this
is
where,
like
at
Apple,
we
used
to
say
we
have
to
make
security
transparent,
because
if
you
make
security
too
complicated,
then
your
employees
will
actively
works
against
you
to
like
bypass
your
security.
So
I
would
say
that
understanding
like
the
tool
that
your
company
is
using
and
make
sure
you're
using
that
tool
and.
C
E
D
D
D
A
Oops
yeah,
for
me,
I,
mean
I.
Think
when
we
were
writing
this
down.
We
rather
sort
of
you
know
these
are
the
video
now
I.
Think
I
feel
for
tools
are
very
often
extensible
right.
So
even
if
you
say
you're
going
to
develop
with
Visual
Studio
code
and
then
you're
going
to
develop
with
I,
don't
know
npm
or
so
then
you
need
to
further
constrain.
What
is
what
can
be
installed
in
this
context?
What
is
what
are
the
plugins
allowed
or
not
allowed,
but
I
agree.
There
is
a
little
bit
of
an
overlap
here.
C
A
A
A
I
think
this
one
here,
the
this
data
flow
tool
where
stuff
is
downloaded
from
a
private
repository.
This
gives
raise
to
a
problem
where
maybe
things
that
have
been
mirrored
and
maybe
have
been
vetted
and
so
I've
been,
are
available
in
this
private
repository.
They
can
be
also
altered
once
there
have
been
mirrored,
and
so
basically
there
would
be
the
downloads.
A
A
Right
so
this
would
be
something
that
is
kind
of
affecting
this
data
flow
number
five
right,
so
maybe
the
the
this
would
be
yeah,
yeah,
basically
insufficient
or
incomplete
vetting
processes.
Right.
You
just
do
a
superficial
review,
which
is
not
deep
enough
all
right.
So
then
I
I
basically
deleted
this.
C
A
A
A
A
So
let's
say,
let's
say:
let's
say
the
vet
I,
don't
know
package
full
version
1.1,
but
they
don't
without
any
without
actually
saying
where
they
get
it
from
and
what
would
be
the
digest
and
so
the
mirror
process,
which
is
technically
maybe
some
some
independent
process
just
downloads,
this
version
from
1.5
from
somewhere
else,
and
so
they
have
waited
the
wrong
thing.
Basically,.
D
A
The
top
so
the
develop
and
advertise
distinct
malicious
package
from
scratch.
Here
the
idea
was
it's
actually
quite
a
high
effort
compared
to
to
this
name.
Confusion
attack
is
that
an
open
source
project
is
set
up
from
scratch
that,
with
some
useful
functionality,
the
people
make
some
effort
to
advertise
it.
It
is
adopted
and
the
malicious
behavior
is
only
added
at
a
at
a
later
point
in
time
right.
So
it
is
fine
and
legitimate
for
quite
some
time,
and
then
it
is
turned.
A
A
A
A
Does
it
look
at
just
every
patch
or
every
minor
version,
or
every
major
version,
and
so
I
guess
here?
The
threat
is
that
the
vetting
process,
if
it
is
in
place,
is
just
looking
at
the
subset
of
the
versions,
and
so
such
a
malicious
package
can
can,
of
course,
inject
the
malicious
behavior.
Also
at
any
other
point
in
time.
D
C
A
A
A
A
So
you
you
can
basically
I
think
it
was
an
npm
I'm,
not
sure
whether
they
changed
this
so
that
you
could,
for
whatever
package
you
have
created
I
think
you
can
reference
other
GitHub
repositories,
and
so
you
would
basically
get
the
stars
and
the
four
count
of
that
GitHub
repository,
even
though
your
source
code
of
what
you
have
deployed
doesn't
relate
to
that
GitHub.
So
this
is
a
technique
for
kind
of
promoting
such
packages.
A
A
A
B
A
C
B
A
Yeah
but
so
I
agree.
This
is
definitely
a
problem
and
I
think
there
are
numerous
articles
recently
about
whether
those
GPT
models
produce
vulnerable
or
non-vulnerable
code,
but
I
think
here
we
are
not
mistake.
We
wanted
to
really
focus
on
on
really
on
a
text
not
on
kind
of
accidental
vulnerabilities
being
introduced
or
shared
or
otherwise.
B
That's
a
real
good
example.
If
I
say
if
I
talk
to
chat,
DBT
or
or
what
is
called
that
that's
cool
wine
I
say,
can
you
write
me
a
code
to
how
to
interface
to
chat,
GPT
version,
four
right
running
a
code
and
it
just
run?
It
will
run,
create
an
example
code
that
have
a
a
weakness
there
and
then,
because
it's
charity
BT.
They
probably
reuse
that
code
everywhere
and
that
become
a
weakness
that
attacker
can
be
aware
of,
then.
D
B
Yeah,
the
attacker
could
feed
the
chat,
gbt
the
the
gbt
and
is
basically
looking
for
examples
on
the
on
the
internet
right.
So
they
can
see
that
with
the
wrong
information,
so
chai
TPT
can
be
attracted.
That
way,
and
also
the
use
of
machine
learning
is
also
interesting,
because
machine
learning
is
just
an
algorithm
right
back
propagation,
all
that
so
it
can
be
used
for
protection,
but
at
the
same
time
it
can
be
used
to.
You
know,
install
wrong
information
as
attack.
D
C
A
A
B
Because
one
thing
I
find
interesting
is
I'm
actually
looking
for
some
interesting
information
about
a
particular
Professor.
Actually
I
was
looking
at
the
chai
gbt
and
the
Google,
the
Google
one
tativity
didn't
give
any
answer.
Google
did
so.
It
looks
like
Google.
Probably
did
some
internet
crawling
and
find
that
information
where
chatibility
did
not
so
that
it
really
depends
on
the
you
mean
to
be
able
to
answer
those
questions.
It
got
read
that
information
from
somewhere.
A
No
I
used
it
in
the
past
for
performing
malware
assessments
and
that
worked
pretty
well
as
well,
so
I,
basically
extracted
code
snippet
for
malicious
packages
and
asked
whether
it
should
describe
the
behavior
and
come
up
with
a
risk
score,
whether
it's
malicious
or
not,
and
that
worked
pretty
pretty
good.
I
must
say,
least
in
in
the
later.
In
the
later
versions,
foreign.