►
From YouTube: End Users (November 10, 2022)
Description
Meeting notes: https://docs.google.com/document/d/1KQalBRzfRBvsqh73JUYfp1KG-AJdXcv2Z8LTIFoQP8c
A
B
Good
afternoon
to
you
I'm
very
good.
Thank
you
good.
Thank
you
very
good,
very
good.
We
don't
have
quality
on
the
agenda
today,
but
with
it
being
an
off-cycle
meeting.
I
am
not
sure
how
many
people
are
going
to
have
turn
up.
C
B
See
we
kind
of
need
to
progress.
C
So
for
the
Scott
summary
of
the
Scott
Workshop
I
didn't
prepare
very
much
I
would
just
you
know,
walk
the
people
a
little
bit
through
the
agenda
and
maybe
highlight
a
couple
of
talks
that
I
personally
found
not
worthy
exactly.
B
B
A
B
John
Jeff
as
usual,
if
people
wouldn't
mind
popping
into
the
notes
and
updating
it
with
attendance,
that'd
be
great.
B
Yeah
welcome
as
I
sort
of
briefly
mentioned,
because
it's
an
ad
hoc
meeting
we
usually
meet
on
Thursdays.
We
might
have
less
people
but
I
think
there's
quite
a
lot
going
on.
So
it's
worthwhile
I
don't
know
to
circulate
this
again.
B
B
B
All
right,
so
what
should
we
start
and
I
think
we'll
just
get
people
to
catch
up,
as
as
other
people
join
in
that's
all
right,
so
any
new
friends
I
think
Zach
exactly
you're,
probably
and
Jeff.
Do
you
want
to
introduce
yourselves,
gentlemen.
G
Yeah
sure
I
know
two:
my
name
is
Jeff
I
work
for
Center
side
work
with
Brian
Fox
directly
been
involved
over
on
the
education
Sig
and
the
best
practices
working
group
and
I
think
through
Brian
and
Jonathan.
There's
a
suggestion.
I
come
and
join
this
group
as
well,
because
I
think
some
so
much
stuff's
going
on
so
happy
happy
to
help
I
work
on
the
the
dev
advocacy
digital
advocacy
part
of
devrel
at
sonotype,
so
put
down
a
bunch
of
stuff
there.
So.
B
F
Jeff
y
hi
guys
I'm
Zach
I
work
for
check
marks.
Two
years
ago,
I
found
the
dustico.
We
will
focus
about
detecting
detectors
and
code
packages
around
the
supply
chain,
the
militia,
detecting
malicious
packages
in
check
marks
and
happy
to
join
before
that
there
was
actually
a
threat
analyst.
So
my
background
is
less
developer,
more
threat,
intelligence,
oriented
and
so
happy
to
join.
The
call
guys.
B
Thanks
so
much
guys
right
so
first
part
of
the
agenda
Henrik,
you
were
going
to
give
us
an
update
about
the
it's
scored.
Isn't
it
the
the
conferences.
C
Exactly
all
right,
yeah,
so
two
years
two
weeks
ago,
I
had
the
pleasure
to
attend
the
first
edition
of
the
Scott
Workshop.
C
It
was
co-hostess
with
the
CCS
conference
in
LA,
took
place
on
November
11th
and
it
was
co-hosted
with
the
CCS
co-located
and
John
was
asking
me
whether
I
can
quickly
walk
you
through
the
different
papers
or
provide
kind
of
a
recap
summary
of
my
my
takeaways
so
yeah
as
I
said
it's
the
first
edition
but
the
according
to
the
organizer
Santiago
Arias
Torres
from
I
think
Purdue
University
said
it
was
pretty
well
received,
so
they
received
many
submissions
and
they
plan
to
do
this
in
the
upcoming
years,
probably
also
with
ccs.
C
They
had
12
Workshop
papers
a
keynote
from
Trevor
Rosen
from
GitHub,
as
well
as
a
panel
session
with
adjusting
couples.
Xin
Mai
Sharma.
She
was
a
legal
person
from
the
University
of
Texas
Kathleen
Moriarty
Center
for
Internet
Security
and
Dinesh
Manoa
haran
into
maybe
you
know
some
of
those
guys
already.
C
So
my
my
summary
of
the
event
overall
I
must
say
it
was
rather
academic,
so
I
guess
there's
relatively
little
bit
systems
end
users
can
use
out
of
the
box
in
order
to
you
know,
apply
this
in
the
day-to-day
work
effort
securing
the
supply
chains,
so
myself,
I
was
present
with
two
sessions
and
the
one
I
presented,
or
we
presented
together
with
my
former
colleague
at
sap,
the
risk
Explorer,
which
is
this
taxonomy,
and
this
visualization
of
this
taxonomy
of
threats
for
subjected
bike
chains
and
the
second
paper
we
were
presenting
was
where
that
towards
detecting
malicious
Java
archives
using
different
characteristics.
C
We
would
find
in
the
pipe
code
of
download
downloadable
from
Haven
Central
or
the
like.
So
this
is
really
our,
so
the
risk
Explorer
is
relatively
mature,
and
maybe
you
have
followed
our
attack
that
John
created
and
this
effort
to
to
move
it
to
the
open
ssf.
This
other
work
on
Java
is
in
its
early
infancy,
I
would
say,
and
the
Epic
clinics
keep
on
working
on
this,
to
make
this
more
more
effective
right
for
for
the
other
talks.
Maybe
a
few
highlights
that
I
liked
a
lot.
C
The
keynote
was
from
Trevor
Rosen,
who
runs
the
package
security
engineering
team
at
GitHub,
I
think
it's
around
about
eight
people
and
what
I
liked
a
lot
was.
He
described
how
he
will
use,
or
they
will
use
six
store
in
order
to
have
secure
future
npm
deployments,
and
so
the
Mantra
he
repeated
a
couple
of
times
was
that
open
source
should
be
also
built
in
the
public.
C
Not
only
the
source
should
be
public,
and
so
we
were
showing
an
architecture
how
to
use
six
dot
together
with
his
npm
deployment
processes,
so
that
you
would
have
attestations
that
a
certain
npm
artifact
has
been
built
in
a
public
cloud
and
deployed
on
nkm,
using
this
full
chill,
I,
think
and
record
as
the
transparency
log.
So
that
was
a
very
nice
thing.
C
You
know
probably
he's
going
to
share
the
slides,
though
right
there
was
noteworthy
what
I
liked,
also
from
the
panel
discussion
that
which
really
stuck
with
me
is
the
statements
of
shin
Mai,
Sharma,
So
This
legal
person
from
the
University
of
Texas
was
making
a
case
for
making
software
vendors
liable
in
the
future.
As
for
other
engineering
professions,
she
was
expressing
some,
let's
say,
surprise,
maybe
or
we
were
he
was
advocating
with
a
selling
things
that
also
had
to
pass
software
engineers
and
software
vendors.
C
So
that
is
maybe,
if
ever
this
happened,
something
that
is
relevant
very
relevant
for
all
of
us
and
what
I
was
there
was.
Maybe
there
was
a
little
bit
of
a
provocative
question.
I
was
asking
her
whether
maybe
all
these
industry
efforts
and
support
of
the
open
ssf,
maybe
will
be
used
at
a
later
point
or
can
be
used
at
the
later
part
by
the
industry
to
say.
Well,
we
already
do
so
much.
Maybe
you
know
if
it's
not
on
the
liability.
C
B
C
Yeah
no
I
just
copied
the
program
to
the
chat,
and
so
there
you
have
the
and
I
guess
the
papers
are
not
available
for
download
here,
but
I
guess
on
Google
Scholar
or
somehow
you
find
them.
C
One
thing
that
I
found
interesting
was
a
good
talk.
The
first
one
actually
was
policy
transparency
and
this
guy
from
Google
research,
Andrew
YOLO
proposed
the
kind
of
a
language
formal
language
on
the
basis
of
data
one
or
the
other
data
lock
to
formulate
policies
in
regards
to
consuming
artifacts.
C
Let
me
just
quickly
go
over
the
programs.
I
also
liked
the
work
of
the
University
of
Genova,
that
was
in
the
technical
and
the
second
session,
which
was
about
automatic
security
assessments
of
GitHub
action.
Workflows
in
this
thing,
also
a
relatively
important
topic
that
they
addressed
I
think
they
had
a
handful
of
different
security
problems
that
they
would
be
able
to
find
and
badly
configured
GitHub
workflows.
C
Let
me
see,
and
what
I
also
liked,
maybe
I
can
conclude
with
this,
is
and
as
part
of
the
third
session
was
a
paper
called
Exorcist
Alternatives,
with
rental
analysis
to
detect
compromises
in
closed
Source
software
Supply
games.
While
many
people
look
at
the
open
source
it
takes.
This
guide.
Did
a
differential
analysis
of
closed
Source
malware
I
think
he
looked.
He
had
a
look
at
not
pizza,
CC,
Cleaner,
I
think
both
are
from
2000
attacks
from
2017,
and
it's
also
Sunburst
with
all
in
all
10
or
so
samples,
mostly
dla.
C
We
try
to
understand,
or
they
try
to
understand
from
the
University
of
Oxford.
Where
would
be
differences
from
a
benign
version
and
then
the
malicious
dla
that
would
have
when
malware
injected
in
terms
of
did
they
use,
obfuscation
or
no
obfuscation?
Was
there
additional
complexity
which
could
be
an
indicator
of
using
some
Pekka
logic,
so
that
was
that
was
also
a
very
nice
talk,
but
again
nothing
that
you
need.
Anybody
of
us
can
use
out
of
the
box,
I'm
afraid
right.
That
I
think
where
my
main
takeaways.
B
Yeah,
okay,
henric.
Thank
you
very
much
for
that.
I
think
I.
Think
a
lot
of
this.
At
the
moment
there
are
some
good
tools,
I
think
starting
to
come
through.
Oh
well,
there's
quite
a
lot
of
tools
starting
to
come
through
from
it
that
will
be
leverageable
from
an
end
user
perspective,
but
a
chunk
of
it
from
what
I
can
see
it's
still
r
d
and
if
everyone
else
has
seen
that
really.
But
it's
a
good
keep
up
on
some
of
this,
but
ultimately
I'll
get
to
a
tour.
B
B
Should
we
just
have
a
couple
minutes
telling
people
where
they
are
because
I
think
there's
also
a
request
for
assistance
on
some
of
that.
B
B
G
B
Let
me
hop
them
in,
should
we
should
we
take
a
look?
Do
you
want
to
screen
share?
We
just
have
a
quick
look
at
them.
C
I
can
screen
share
this
well.
B
While
we're
going
through,
let
me
sort
of
talk
to
it.
So
so
we
got
together.
A
couple
of
us
have
got
together
and
we
had
started
to
map
out
high
level
architectures
and
we've
and
Henry,
because
that
has
done
all
the
work
differently.
B
Now
remember
that,
the
last
time
we
were
talking
about
this,
we
had
decided
not
to
particularly
call
it
large
or
small,
but
in
the
absence
of
anything
else
at
the
moment
it
seems
rational
to
at
least
start
doing
this
and
and
somehow
come
up
with
a
third
one,
but
reviewing
these
architectures
and
also
looking
back
to
the
threat
model
that
we
published
before
all
of
the
data
that
we
had
in
the
threat
model
is
or
should
be
in
these
diagrams
just
at
a
more
abstracted
level.
B
So
so
my
thoughts
on
this
was
reasonable,
adding
adding
more
data
into
it
and
Rick.
Do
you
want
to
speak
to
the
slide?
Yes,.
C
So
I
started
living
with
I
think
on
the
track.
You
mentioned
three
or
four
organizations.
C
One
was
a
larger
development
organization
and
then
two
consumer
organizations
regular
one
and
a
regulated
one
like
a
hospital
when
I
started
yeah
with
development
organizations,
a
small
one
where,
basically,
everything
happens
in
the
cloud.
There
is
no
Legacy.
There
is
no
own
infrastructure,
they
only
have
everything
on
a
hosted
git
like
GitHub
gitlab.
C
They
use
also
cloud-based
GI
CD
systems
and
so
forth.
Model
development
organization
right
and
the
the
other
one
is
a
large
development
organizations,
also
with
heavy
internal
reuse,
components,
kind
of
a
lot
of
a
mixture
of
having
things
in
the
cloud
in
the
public
Cloud,
as
well
as
running
internal
Solutions
in
the
internal
cloud,
all
the
SAS
scanners
that
exist,
some
of
them
being
hosted
in
a
house
and
some
of
them
outside
right,
and
so
this
looks.
This
is
the
the
small
development
organization.
It
basically
continues.
C
The
thoughts
and
kind
of
a
sketch
I
mean
basically
distinguishes
the
source
code,
Version
Control,
System
the
build
system,
and
then
the
distribution
platforms,
distribution
platforms
could
be
anything
like
package
repositories,
application
marketplaces,
websites
wherever
people
basically
publish
the
thing
that
they
built
the
thing
that
they
provide
to
their
Downstream
users
and
those
distribution
platforms
is
also
the
term
that
we
have
used
to
denote
those
specifically
from
where
they
download
their
open
source
dependencies,
but
also
all
the
other
components
that
are
used
during
the
development
life
cycle,
basically
including
the
stuff
that
ends
up
on
developer
workstations.
D
In
this,
in
this
graph,
does
the
red
third
party
assume
also
closed
Source
proprietary
software.
C
Yes,
we
didn't
differentiate
it.
We
made
it
more
explicit
in
this
second
picture
and
then
with
one
of
the
one
of
the
comments
from
Don
that
we
should
include
it.
We
made
it
more
clear
here
where
we
have
commercial
third
party
on
the
top
and
then
open
source
on
the
button,
and
so
I
think
the
same
applies
also
to
this
small
development
organization.
I
just
didn't
copy
and
paste
the
same
boxes.
D
C
Yes,
yes,
okay,
that
is
maybe
a
better
term
yeah.
Okay,.
B
It
makes
for
a
difficult
diagram
to
perhaps
pass
for
a
harder
diagram
to
pass,
but
I
think
it
is
the
reality
in
that
there
are
multiple
bits
of
closed
source
code,
as
well
as
the
open
source
Pizza
that
are
going
to
be
in
these
distribution
mechanisms.
Right.
B
No
I
was
just
gonna.
Add
to
that
right.
I
mean
these
are
initial
views
on
and
I
think.
One
of
the
things
we
were
looking
at
doing
was
trying
to
put
together
some
assumptions.
So
it's
not
just
this
is
a
diagram,
but
this
would
be
an
assumption.
You
know
I
the
small
group.
You
know
five
to
ten
person,
company
building
some
functionality,
not
heavily
regulated
I,
think
it's
useful
in
addition
to
the
diagram
to
actually
have
some
starting
assumptions
to
guide
people,
what
we're
actually
trying
to
threat
model
learning.
B
What
the
example
is
right
down
to
the
well
they're,
not
building
anything
they're,
just
consuming
software,
because
I
think
that's
obviously
more
formal
companies
doing
that,
so
that
that's
definitely
work
to
come.
C
Yeah
and
so
I,
don't
know
whether
it
makes
sense
to
I
guess
it's
the
the
ideas
become
clear.
Looking
at
this
small
development
organization,
the
bigger
development
organization
just
adds
a
lot
of
additional,
basically
data
flows
and
systems
to
this
diagram
that
we
thought
maybe
cannot
be
connected
in
a
reasonable
way.
C
The
build
system
in
particular
right
so
maybe
notable
no
notable
differences-
is
to
have
internal
repositories
like
Nexus,
jproc
and
so
forth.
That
will
be
used
to
mirror
internal
application
dependencies.
Sorry,
internal
reuse,
components
as
well
as
external,
open
source
or
third-party
commercial
proprietary
component
and
then
other
notable
differences
are
this
inner
self
contributor?
So
this
here
the
idea
being
that
in
a
bigger
development
organization,
at
least
many
promote
inner
Source,
so
open
source
Concepts
to
the
inside
of
a
company
and
the
addition
of
this
inner
thought.
B
Jack,
you've
got
your
hand
up
to
a
new,
raise
the
question.
Yeah.
E
Just
some
black
shedding
I'd
suggest
private
repository
instead
of
internal
repository.
I
know
Shopify
with
his
Cloud
Smith,
which
is
not
sort
of
strictly
internal
to
us,
but
it's
private.
B
Great
if
I
may
also
add
one
of
the
things
that
we
were
debating
was
the
actual
names
of
products
we
probably
can't
put
names
of
products
in.
We
need
to
delete
them,
but
in
the
initial
sort
of
ideation
we
were
trying
to
make
sure
that
we
all
knew
what
we
were
talking
about,
but
I
think
it's
not.
You
know
we
are
going
to
have
to
delete
that
for
obvious
reasons.
C
Here
maybe
another
important
decision
that
we
that
we
had
to
take
at
some
point
in
time.
C
Of
course,
there
are
a
zillion,
a
zillion
ways
how
a
bigger
organization
would
would
you
know
the
development
environment
and
their
their
systems
in
the
landscape,
and
so
here
we
decided
to
basically
have
an
in-house
source
code
management
system
which
could
be
again
GitHub,
Enterprise
running
in
that
company
or
git
and
garage
in
combination
as
well
as
also
you
have
an
in-house
build
system
that
is
hosted
by
the
company
like
Jenkins
or
maybe
even
custom
built
build
environments,
but
that
wasn't
a
choice,
an
assumption
that
we
had
to
take
at
some
point
in
time,
I'm,
not
sure
whether
it
makes
sense
to
him
or
possible
or
whether
it's
even
possible,
to
avoid
you
know
variations
combinations.
C
B
C
And
maybe
one
maybe
also
one
notable
difference
when
you
look
at
side
star
and
kind
of
this
very
well
the
the
diagram
that
they
use
on
for
pointing
out
different
threats.
One
notable
difference
is
also
this
type
of
the
workstation
right.
So
the
the
system
of
the
developer,
having
Visual
Studio
code
or
whatever
is
IDE
with
plenty
of
plugins
down
below
it.
A
D
John,
if
you're
editing
might
want
to
change
that
title
in
the
red
block,
the
commercial
third
party
and
then
below
it
open
source.
How
about
just
the
third
party.
D
Most
most
proprietary
software
today
contains
open
source.
You
know
whether
it's
from
traditional
vendors,
traditional
vendors,
that
we
view
as
as
close
Source
such
as
Oracle
or
sap
sap,
has
huge
amount
of
Open
Source
in
their
products
right,
so
do
we
want
to
maybe
mention
that
where
does
that
get
taken
into
consideration
here,
because
it's
because
they're
coming
as
packaged
software,
it
doesn't
fit
below
where
open
source
under
the
open
source
box.
Let's.
C
Yeah
for
me,
what
is
what
is
really
downloaded
and
also
uploaded,
are
kind
of
binaries
and
quotes.
It
means
archives,
Zips
and
those
binaries,
of
course,
can
contain
third
open
source
itself.
So
if
I
download
yeah,
so
it
would
be
rebounded
repackaged
open
source
that
is
included
in
a
binary
binary
that
I
download
from
some
commercial
proprietary
third
party.
B
Does
that
make
sense
see
where
you're
going.
C
I
mean
it's
it's
in
some
way.
This
is
represented
right,
so
here
on
the
build
system.
Here
in
the
very
middle,
you
would
at
some
point
in
time
download
all
the
dependencies,
the
open
source
dependencies
that
are
required
to
build
a
certain
commercial
solution
which
is
then
yeah
embedded
into
into
such
an
archive
binary,
whatever
you
want
to
call
it
before
it
is
then
uploaded
on
the
commercial
software
provided
website
or
whatever
it's
application
store.
C
So
that
is,
that
is
how
I
would
reflect
kind
of
the
ReUse
and
bundling
of
Open
Source
by
commercial.
B
Just
thinking
in
the
interest
of
time,
perhaps
you
know
what
we're
really
looking
for
at
this
point.
Is
that
continued
next
ad
hoc
session,
so
we've
been
discussing
this
a
couple
of
times,
it'd
be
good
to
get
additional
members
feedback
into
this
remember
this
is
really
we're
going
to
the
sack
with
the
proposal,
but
assuming
that
that's
put
forward,
I
think
this
is
useful
material
anyway.
B
Moving
on
to
the
next
one,
but
unfortunately
Mitch
I,
don't
think,
can
join
us
today
on
the
ad
hack,
one
Mitch
had
offered
to
update
the
GitHub
Pages.
Obviously,
when
we
became
a
fully
fledged
working
group,
we
were
given
GitHub
and
all
sorts
of
other
great
stuff,
so
Mitch
has
offered
to
do
that
and
was
going
to
present
back
some
updates
to
the
group.
B
B
Okay,
next
thing
on
the
agenda
is
the
supply
chain
total
feedback
which
clearly
we
need
a
different
name
for
that.
But
this
was
a
proposal
I
made
last
session.
B
It
was
really
more
of
a
discussion
or
a
comment
for
discussion,
and
it
was
really
a
thought
around
how
we
could
get
together
as
a
group
and
collate
malicious
data
or
vulnerability
data
into
a
single
repository,
so
that
we
can
get
early
warning
of
perhaps
changes
in
the
attacks
that
the
the
industry
is
undergoing,
so
that
we
can
then
start
to
tune
what
we're
ingesting
from
our
end
users
and
members,
and
get
a
better
understanding
of
what's
going
on,
and
it
turns
out
that
at
the
same
time,
I
was
proposing
that
Andrew
you'd
highlighted
that
you
were
at
the
Lake
Tahoe
meeting
and
I.
B
Think
someone
from
Zach
your
organization
was
proposing
something
similar,
so
I'd
reached
out
and
asked
Zach.
If
you
wouldn't
mind
sort
of
sharing
some
of
your
thoughts,
and
maybe
we
can
have
that
wider
discussion
here.
Let
me
if
that's
reasonable.
F
Be
happy
to
so
first
of
all,
I
think
that,
again,
coming
from
the
same
experience
that
we
all
have,
we
need
to
understand
that,
of
course
everything
is
changing
right.
So
there
is
no
right
answer
which
will
be:
where
will
be
the
The
Perfect
protection,
because
the
and
the
attackers
are
always
changing
their
their
tactics
and
we
felt
that
we
need
the
open
source
Community
or
the
open
source
security
research
Community
to
come
and
help
us
so
for
every
publication
that
we
have.
We
try
to
do
two
things.
F
F
We
have
a
people
attacking
the
open
source
ecosystem
problem,
so
trying
to
understand
what
are
the
tactics
and
the
trends
that
we
are
seeing
and
giving
access
to
researchers,
because
one
of
the
things
that
I
I
do
see
is
that
in
other
places,
when
a
university
want
to
research
or
try
to
develop
a
new
kind
of
ml,
they
need
some
data
and
right
now
most
of
the
data
is
just
being
deleted
by
the
packet
repositories
we
pop
we.
We
report
on
a
large
number
of
packages
and
they
are
just
being
deleted.
F
F
Is
it
difficult
to
start
because
it
doesn't
have
any
data
to
try
to
train
his
model
or
anything
like
that,
so
we
have
made
large
contribution
to
backstabbers
and
I,
really
like
it,
but
I
do
think
that
yeah
I
think
we
are
the
biggest
contributor
there
and
but
I
do
think.
Maybe
something
a
bit
more
formalized
walking
is
a
community,
maybe
with
the
package
repositories,
maybe
sharing
some
metadata,
not
just
the
code
himself
could
be
useful,
because
this
is
basically
what
we're
doing
like
we're
we're.
F
Every
time
we
found
something
we
look
at
what
the
attacker
is
left
doing.
There
are
so
many
missing
gaps
in
so
many
cases.
The
same
attacker
is
doing
the
same
thing
in
pipei
in
npm
and
those
package
reports
don't
talk
together,
so
stay
undetected
for
a
very
long
time.
So
we
we
started
at
small.
We
basically
said
whenever
somebody
needs
some
kind
of
package
and
unfortunately,
right
now
they
are
deleted.
We
will
set
up
a
quick
portal,
we'll
happy
to
share
every
evidence
that
we
have
so
people
can
come
up
and
take
their
own
approach.
F
I
basically
want
a
bit
more
than
that
I
think.
Maybe
we
need
a
better
coordination
between
ourselves
coming
from
The
Av
industry,
we
used
to
share
samples,
not
the
signatures,
but
the
samples.
So
it
was
effective
for
all
of
us
to
have
the
same
database
and
sharing
stuff
but
even
started
with
again
let
the
open
source
ecosystem
help
us
protect
against
open
source,
give
him
the
tools.
B
E
Yes,
I
was
a
happy.
The
Happy
news
I
can
share
is
that
this
is
almost
an
identical
conversation
to
one
we've
had
in
the
securing
software
repositories
group.
Where
all
the
repository
folks
hang
out.
We've
also
had
researchers
come
there
and
say
exactly
the
same
thing.
Package
repositories
are
deleting
the
packages
as
soon
as
they're
identified
as
malicious,
which
means
there's
nothing
for
researchers
to
work
with.
E
So
it
is,
it
is
on
our
radar
to
set
up
such
a
repository
such
a
shed
place
where
researchers
can
be
vetted
and
then
allowed
access
to
that
information
to
those
to
those
samples.
E
E
Even
this
working
group
is
like
professionals,
so
to
speak,
so
I
am
very
interested
in
ensuring
that
we
are
on
the
same
page.
Our
view
is
that,
ideally,
that
repository
would
be
operated
by
the
openssf
as
a
neutral,
a
neutral
party.
That
also
has
a
great
deal
of
know
how
to
navigate
any
antitrust
issues.
E
There's
also
a
related
effort
to
set
up
General
data
collection,
so
things
from
things
as
simple
as
download
counts
and
dependency
counts
to
whatever
data
we
can,
we
can
gather
into
a
single
place
into
a
normalized
schema
into
a
into
a
Consolidated
schema
might
be
a
better
description
across
ecosystems,
because
we've
we've
also
realized
that,
like
similarly,
it
is
time
consuming
and
difficult
for
researchers
to
perform
across
ecosystem
research.
So
we
want
to
make
that
as
easy
as
possible.
B
Sounds
excellent,
I
I'd
like
to
add
to
that
point,
but
Andrew
you
had
your
hand
up.
Do
you
want
to
go
next?
Just.
D
Presenter
at
the
summit
had
mentioned
that
you
were,
the
check
marks
was
potentially
going
to
create
an
open,
a
database
of
Behavioral
attacker
information
and
open
source
that.
F
So
what
we're
doing
right
now
and
again,
this
is
more
on
the
ideation
state
right
now.
We
do
think
that
is.
It
is
beneficial
to
all
of
us
to
try
to
understand
and,
for
example,
every
report
that
we
have.
We
share
that
report
and
I
still
will
still
missing
the
taxonomy
like
for
for
miter,
there's
a
clear
taxonomy
to
describe
the
attacks
and
I,
don't
I.
Think
everybody's
like
calling
brand,
jacking
or
type
of
squatting
or
thing
like
that.
F
I
think
that
will
be
an
initial
step
before
submitting
that
and
but
I
do
think
that
this
is
something
that
this
is
like
the
next
steps.
Once
we
have
the
data
now
the
conclusion
and
what
do
we
have
so
we
are
working
on
that
and
it's
not
as
close
as
I
want
to,
because
there
are
like
missing
steps.
First,
we
collect
the
data
analyze.
The
data
find
the
attackers
find
the
ttps,
and
the
next
step
would
be.
F
Let's
try
to
to
share
it
in
a
similar
fashion,
because
what
will
happen
next
and
I've
done
the
same
process
with
the
normal
cyber
industry
is.
We
need
some
kind
of
a
sticks
format,
because
if
everybody
is
like
publishing
a
PDF-
and
you
need
the
human
to
read
that
and
to
understand
what
the
writer
meant
that
don't
that
won't
have
the
effect
that
we
want
yeah.
B
Zach,
if
I
could
jump
here
in
here,
so
a
couple
couple
of
things,
so
you
mentioned
the
taxonomy
there,
so
it's
great
so
as
part
of
this
group,
we've
adopted
the
taxonomy
that
Henrik
and
team
had
put
together
for
a
part
of
the
the
backstabbers
knife
presentation
and
such
and
we're
that's
one
of
our
proposals
to
the
tech
and
the
way
that
I'd
sort
of
framed
this
capability
of
collating.
B
All
of
this
data
is
a
way
of
maintaining
in
a
way
our
taxonomy
and
our
threat
models,
because
at
the
moment,
we're
interning
what
we
believe
the
market
is
or
the
the
threat
landscape
looks
like
we're
putting
together
our
architectures,
we're
understanding
our
mitigations
we're
defining
what
open
source
ossf
programs
we
need
to
back
and
where
salsa
and
ssdf
fits.
B
But
what
I'd
like
to
do
here
is
have
that
capability
up
front
where
we're
analyzing
the
threat
landscape
and
then
informing
and
validating
our
threat
models
and
our
taxonomy
as
we
go.
If
you
find,
for
example,
a
new
type
of
attack,
then
we
can
make
sure
that
well,
it's
it's
missing
from
taxonomy.
Let's
ensure
we
update
it.
B
This
is
kind
of
where
I
see
it
fitting
with
the
other
one
and
then
I
think.
My
third
point
of
feeling
well
is
that
I'd
like
to
a
little
hands
up,
but
I'd
like
to
Circle
back
and
figure
out
right.
How
do
we
move
this
forward
because
there's
a
lot
of
interest
just
from
this
group,
there's
Jack
you've
got
another
group
I
want
to
see
if
we
can
collate
that
going
forward
and
perhaps
get
together
with
these
other
people,
but
I'll
see
the
floor.
I
think
it
was
to
Henrik
I
think
was
next
up.
C
I,
don't
remember
the
order
of
who
raised
the
hand
first,
but
maybe
we
even
have
the
same
common
thought,
but
you
think
that
for
for
pointing
out
this
other
initiative
a
couple
of
weeks
or
maybe
even
months
ago,
I
came
across
an
open,
ssf
document
which
described
exactly
this
collecting
supply
chain
attacks
and
then
the
actual
samples
like
we
did
with
the
Specsavers
knife
collection.
C
The
problem
back
then
and
I'm
not
sure
whether
this
was
resolved
in
the
meantime
is
that
what
they
call
it
a
supply
chain
attack
also
included
the
attacker,
exploiting
known
vulnerable,
open
source
components,
which
I
think
is
not
a
good
idea
to
lift
up
in
one
packet
and
listen
to
whether
they
have
addressed
this
or
changed
the
scope
a
little
bit
in
the
meantime,
but
just
wanted
to
say
that
we
should
be
only
on
malicious
certain
parts
packages,
not
on
this
common
when
on
Imports
problem
of
non-brandability.
F
I
totally
agree
and
I
think
that
sometimes
the
the
taxonomy
is
vulnerable.
Malicious
is
malicious,
vulnerable
I
get
people
confused
and
it's
a
different
mitigation.
It's
a
different
risk.
It
is,
it
involves
a
different
technology
stack
to
solve
yeah
and
I.
Totally
agree.
That
is
some
of
the
I
would,
for
example,
I
have
no
problem
with
going
one
way
or
the
other
calling
malicious,
malicious
or
calling
malicious
vulnerable
just
be
concise
with
it,
because
most
of
the
malicious
package
being
discovered
are
being
aren't
being
Interactive
cve,
so
I
have
no
problem.
F
If
we
decide
it's,
it's
availability
and
let's
track
it,
but
the
problem
is
it's
it's
in
between
so
sometimes
refer
to
as
vulnerability,
but
most
of
them
don't
have
a
cve
meaning
and
that's
an
immediate
impact,
because
when
I
find
a
malicious
package,
it
was
downloaded
tens
of
thousands
of
time
and
I
got
it
reported
and
it
removed
all
the
past
victims.
I
am
getting
notified
because
this
is
Interactive
cve,
so
I
totally
agree.
F
This
is
some
of
the
confusion
that
sometimes,
when
we
try
to
describe
it,
there's
a
mix
of
what
maybe
we
should
track
it
to
cve
because
it's
convenient.
But
if
you
look
at
the
how
a
risk
how
CV
is
being
defined,
it
doesn't
fall
under
that
definition.
Yeah.
H
So
I
totally
agree
with
the
all.
You
said:
it's
a
it's
a
really
something
that
we
must
need
to
achieve
as
a
community.
What
I
wanted
to
raise?
It
is
a
bit
a
side
problem
with
that
with
which
I
encountered
I
think
there
is
also
a
little
bit
of
problem
when
researchers
want
to
notify
repositories
when
there
is
something
malicious
in
and
not
just
a
single
package,
but
really
like
100
packages.
H
So
when
we
will
manage
to
reach
situation,
which
a
lot
of
researchers
will
start
scanning
repositories,
I
found
really
cumbersome,
for
example,
in
npm,
for
example,
you
need
to
go
through
the
UI
and
then
you're
blocked
by
captures
and
in
pipei
you
need
to
send
emails.
I
think
it's
really
important.
Also,
and
it's
a
mutual
interest,
I
think
between
the
requisitories
and
researchers
to
come
into
a
unique
solution
where
researchers
can
just
drop
what
they
find
and
representators.
H
Then
we
will
go
through
the
findings
and
trading,
and
another
thing,
I
think
could
be
really
interesting,
is
to
motivate
researchers
in
the
community.
There
exists
back
Bounty
programs,
for
example,
for
finding
vulnerabilities,
but
I
I
never
saw
so
far,
but
probably
I'm
wrong,
something
similar
for
malicious
packages
and
I
think
trying
to
attract
the
community.
It's
it's
another
key
point.
In
my
opinion,
yeah.
F
A
F
Totally
agree:
I'm
I'm,
like
managing
hundreds
of
Email
exchange
with
package
repository
trying
to
understand
the
mean
time
to
remediation
the
mean
time
to
detect
and
that's
cure
for
some
I
want
to
give
a
big
shout
out
to
pie
pie.
Now
they
have
like
an
internal
tool
and
they
ask
us
every
time
you
submit
something.
It's
a
bit
with
these
tools
or
our
analyst,
which
is
a
volunteer,
doesn't
need
to
go
and
scan
the
entire
package.
F
So
the
that's
the
start
of
the
process,
but
definitely
some
kind
of
an
API
or
automation,
because
I
I
like
go
back.
What?
What
time
did
we
send
that
email
and
there
is
no
standard,
what
we
call
mttd
or
mttr?
So
sometimes,
if
you're
working
with
somebody,
you
will
get
it
resolved
quickly.
Sometimes
you
forgot
the
email.
Sometimes
you
have
to
remind
them.
So
we
need
to
to
do
the
job
to
make
their
job
easier
agree.
B
So
so,
in
the
interest
of
time,
just
just
want
to
make
an
additional
point
and
then
handle
Jacques,
but
I
I
do
think
that
we
need
to
raise
the
awareness
of
malicious
packages
much
higher
from
an
end
user
perspective,
in
that
we
are
tracking
vulnerabilities
and
people
are
talking
about
vulnerabilities
and
talking
about
supply
chain
security,
but
I,
don't
think
malicious
packages
has
quite
got
to
the
level
of
visibility
that
I
think
it
should
be
in
the
end
user
community
and
that's
something
I
think
we
need
to
take
on.
B
B
Maybe
I'll
take
an
action
to
reach
out
to
yourself,
Shack
and
figure
out
who
else
to
bring
to
the
table
table
of
a
meeting
and
invite
you
know
on
the
slack
Channel.
Anyone
who
wants
to
come
to
discuss
this
a
proposal
but
I
do
think
there's
something
there
and
we
are
a
little
bit
short
of
time
but
I'll
hand
it
to
yourself
check.
B
Okay,
Nora's
daughter.
Well,
thank
you
very
much.
A
really
good
conversation
there.
Looking
forward
to
that
one.
So
next
item
on
the
agenda
is
last
call
for
proposal
on
feedback.
B
The
link
is
in
the
notes
there
and
that's
effectively:
The
Proposal,
that
we
were
sending
to
the
tech
about
the
connected
initiative,
where
it
has
the
architecture,
the
threat
model,
figuring
out
where
salsa
and
ssdf
sit
and
then
an
ossf
and
then
back
up
to
this
piece
at
the
top.
So
I
had
briefly
reviewed
it
with
probe
and
a
couple
of
others.
If
anyone
has
any
additional
feedback,
if
they
can
put
it
together
in
the
next
two
days
or
so
otherwise,
I
will
reach
out
to
the
attack
and
get
that
scheduled.
D
So
so
John
I
tried
to
make
comments
today,
I
used
to
have
edit
access,
but
do
not
appear
to
do
so
anymore.
So
I'll
send
a
note
to
you.
Yeah.
D
D
B
Okay,
next
item
on
the
agenda,
we
had
Joshua
lock
from
the
salsa
group
reaching
out
about
taxonomy.
Did
anyone
see
that,
on
the
slack
Channel
I
think
he's
reached
out
to
General
as
well
any
thoughts
on
the
particular
taxonomy
I
think
it
was
package
maintainer
that
we're
looking
at?
We
do
have
a
taxonomy
and
Persona
document.
Anyone
got
any
thoughts,
packaging
ecosystem.
Thank
you.
Jack.
E
Surprisingly,
difficult
to
Define
it's
one
of
those
things,
that's
mostly
defined
by
examples
that
we
found
when
we,
when
we
talked
about
this
in
the
early
days
of
the
securing
software
repos
group,
what
it
should
cover
and
just
seeing
packaging
ecosystem
didn't
didn't
help
a
lot,
because,
for
example,
that
would
potentially
for
some
people
exclude
things
like
a
Docker
repository
which,
which
ought
to
be
covered
or
a
distrib.
You
know
distribution
like
Debian,
you
know
they,
they
distribute
software,
they
have
repositories.
Surely
they
belong
as
well.
E
So
it's
a
surprisingly
difficult
thing,
it's
easy
to
think
of
in
terms
of
source
distribution
for
particular
languages
or
particular
sort
of
ecosystems,
but
it
becomes
trickier
as
you
spread
out
from
there.
That
was
our
finding
time.
I've
I've
brought
that
also
to
the
attention
and
securing
software
repo
group
in
the
slack
Channel
and
I'll
probably
bring
it
up
at
the
next
meeting
as
well.
For
people
look
at.
B
D
B
Okay,
I
guess
I
want
to
tune
in
that
one.
If
people
have
some
thoughts
off
cycle
Wing,
we
can
come
back
to
the
sausage
team
on
that
one
I,
don't
think
it's
one
of
the
things
that
we
update
necessarily
in
our
persona's
document,
because
it's
more
of
just
the
taxonomy
of
the
system,
but
that's.
A
A
B
Right:
okay,
very
good,
next
item
on
the
list.
We
have
the
working
groups
list
and
then
we
can
bleed
into
the
update
from
other
groups.
If
anyone
has
any
I
appreciate
working
groups
popping
up
all
the
time,
are
there
any
that
people
feel
we're
missing
from
that
list
or
because
at
the
moment
it's
just
myself,
Randall
abdullah's
in
there
there's
a
number
of
different
working
groups.
We
don't
actually
have
the
thus
securing
repositories
working
group
check.
No
thinking
of
it.
B
B
I
guess
what
what
we're
asking
for
here
as
well?
Is
there
anyone
that
is
interested
in
sort
of
tagging
their
names
to
any
of
those
end
user
groups
to
provide
feedback
to
the
group?
Please
do
so
I'm
not
going
to
press
n
people
into
it,
but
I
think
it
would
be
beneficial
if
other
people
reach
out
to
some
of
those
groups.
That
would
be
useful
and
the
final
one
is
updates
from
other
working
groups.
B
So
has
anyone
got
any
feedback
from
other
groups
over
the
last
couple
of
weeks
that
it
would
be
useful
to
bring
any
selling
points
to
end
user
group
meeting.
E
Yeah
one
very
quickly
from
securing
software
Reapers,
which
apparently
is
my
job
today
is
we
put
our
shared
help
desk
proposal
to
Tech
and
take
one
of
more
details.
They
want
it
to
be
more
fleshed
out
before
they're
prepared
to
sort
of
put
their
stamp
on
it
and
send
it
up
to
governing
board.
E
I
would
say
mainly.
They
were
interested
in
more
details
of
like
the
day-to-day
functioning,
how
it
would
fit
Within
the
existing
organization
of
the
open
ssf,
because
the
proposal
was
you
know
like
full-time
professionals,
professional
or
professionals,
so
they
want
some
more
detail
there
and
they
also
wanted
to
see
what
the
Alternatives
were.
So
the
reason
I
bring
this
up
is
As.
We
make
proposals
to
Tech
that
may
include
funding
requirements
yeah.
We
should
make
sure
that
we
sort
of
cover
these
bases
to
get
through
more
smoothly.
E
B
B
That's
a
great
point
because
I
think
the
one
we
just
discussed
the
the
sort
of
supply
chain-
total
type
thing
that
definitely
is
going
to
require
funding
in
professional
full-time
staff.
So
great
feedback
reach
out
to
details.
D
Andrew
yeah
I
hope
a
couple
members
here:
I
will
not
be
able
to
make
the
TAC
meeting
tomorrow.
I
hope.
A
couple
of
the
members
here
will
be
John,
I.
Think
you're
planning
on
that
is
that
right,
yep,
okay,
so
two
pieces,
if,
if
they're
not
addressed
as
a
part
of
the
agenda,
I
think
it'd
be
good
to
understand
what
are
the
actual
next
steps?
Any
specific
next
steps,
especially
from
the
Sterling
tool
chain,
discussion
during
the
board
meeting?
That
would
be
one.
D
The
second
is
on
the
job
descriptions
for
the
four
or
five
different
positions
that
were
approved
during
the
board
meetings.
I
think
I
I
just
want
to
make
sure
that
those
are
are
being
moved
forward
and
that
there's
not
going
to
be
a
delay
until
the
beginning
of
the
year.
D
B
Great
Point
I
will
attend
and
I'll
try
and
make
sure
that
I
erased
any
other
feedback
from
anyone
and
any
other
groups.
Well
as
I,
say
I
think
quite
a
lot
were
postponed.
B
No
all
right,
we've
got
a
lot
of
proposals
going
on
at
the
moment.
I
appreciate
that.
So
thanks
for
adding
into
that
everyone,
we've
got
I,
think
two
of
them
really
roughly
to
go
to
the
attack.
Let's
get
this
route
to
start
with,
but
a
lot
of
action
going
on,
which
is
which
is
definitely
important.
Injury.
D
A
D
I'm
good
at
I
think
we're
making
some
progress
and
bringing
some
other
members
into
the
group.
I
know
this
was
a
bit
of
a
special
session,
so
hopefully
we
can
all
we'll
we'll
see
broader
participation.
Ralph
thanks
for
for
being
here.
I
think
we're
gonna
see
hopefully
over
the
next
month
or
so
I
had
commitments
from
Boeing
and
Uber
to
participate,
but
they
probably
won't
do
so
until
the.
B
Definitely
yeah
there's
a
lot
of
people
that
are
talking
about
this
just
on
the
sort
of
periphery
and
people
are
trying
to
join.
So
it's
good
to
see
all
right.
Well,
thanks,
very
much
everyone.
Hopefully
Thanksgiving
was
good
and
sorry.
I
had
to
move
it,
but
I
think
there's
quite
a
few
things
we
needed
to
catch
up
on
before
the
next
one
in
December.
So
thanks
have
a
great
week.
Everyone
bye
now
bye-bye.