►
From YouTube: Securing Software Repos (EMEA Friendly June 1, 2022)
A
A
C
B
B
A
B
A
F
B
Welcome
so
yeah,
the
focus
of
this
working
group
is
mostly
on
package
managers,
ecosystems,
software
repositories
and
that
kind
of
thing
finding
ways
to
secure
them
and
and
relevant
stuff
in
there.
Next
thing
you
should
do
is
review
action
items
from
our
last
meeting.
The
first
is
that
this
is
our
new
emea
friendly
time
we'll
be
at
this
time.
Every
other
meeting.
F
I'm
sorry
for
being
late:
I'm
laurentide
cardli,
I'm
a
academic
researcher
in
software
security
and
open
source
doctor
security,
among
other
things,
I've
been
working
in
various
working
group
of
the
ossf
trying
to
find
the
best
place
which
connects
the
best
with
the
type
of
research.
I
do
we've
been
doing
a
lot
of
research
recently
on
security
of
npm
packages
and
pipe
and
other
similar
ecosystems.
So-
and
I
think
a
colleague
of
mine
drew
davidson
from
ku
has
been
in
in
one
of
two
of
those
meetings
previously
so
yeah.
F
F
G
F
A
A
F
F
B
Okay,
just
to
go
back
to
the
agenda,
so
yeah
reviewing
actions
from
last
time.
This
is
our
new
emea
friendly
time.
This
meeting
will
be
at
this
time.
Every
other
time
we
meet
zach
was
going
to
write
a
doc
to
describe
means
to
counter
demean
expert
attacks,
and
he
did
that
and
I
think
that's
all
of
our
actions.
So
next,
I
think
I'll
have
zach
just
talk
to
us
a
little
bit
about
that
doc
and
where
it's
at.
C
We
are
mostly
happy
with
this
stock.
There's
one
final
component
that
we're
still
interested
in,
which
is
there
might
be
sort
of
active
monitoring
repository
operators,
can
do
in
order
to
to
sort
of
get
ahead
of
some
of
this.
This
is
necessarily
going
to
be
an
imperfect
defense,
but
you
know
we
might
be
able
to
catch
some
of
this
before
it
happens.
C
That
said,
some
of
some
of
that
some
of
those
techniques
are
a
little
bit
sensitive
because
as
soon
as
they're
known,
you
know
how
to
sidestep
them
becomes
very
very
easy
again.
It's
not
not
sort
of
our
last
line,
defense,
hopefully,
but
it
should
catch
a
number
of
things,
and
so,
if
you
are
a
repository
operator
and
you
are
implementing
or
are
planning
to
implement,
some
of
these
things
do
get
in
touch
with
me
and
we're
gonna.
C
We're
gonna
have
a
meeting
to
discuss,
and
sadly
I
like
to
keep
everything
as
open
as
possible,
but
due
to
the
sense
of
nature.
Some
of
this
is
gonna,
be
behind
behind
closed
doors,
we're
hopefully
going
to
come
up
with
some
some
public
public-facing
version
of
that.
That
basically
tells
you
if
you
want
to
use
some
of
these
techniques
and
buy
into
this
effort,
how
that's
going
to
go.
C
F
C
That's
a
great
question:
I
will
actually
not
try
to
answer
that
directly
and
and
turn
it
over
to
some
of
the
folks
who
do
operate
these
repositories,
who
might
have
a
better
idea
of
what
the
scale
like
what
fraction
of
your
users
are
advantageous
and,
and
so
and
sorry
I
know
that's
this
pejorative
sounding
term.
I
have
a
vanity
domain.
C
D
D
I
wasn't
sure
the
the
backing
of
the
framing
of
this
document
and
the
outcomes
some
of
it
was
relevant
and
some
of
it
wasn't
in
terms
of
what
I
wrote
I
I
mean
I
could
share
it
with
you
or
and
share
with
the
broader
group
as
well
and
and
just
kind
of
kind
of
get
your
sense
as
to
how
this
relates
to
document
you're,
putting
together
so
specific
concerns
or
areas
that
seem
to
maybe
not
be
aligned
where
you're
focused
largely
on
identity.
Using
you
know,
domains
to
assume
an
identity.
D
You
know
as
a
bad
actor
right
and
then
we
also
use
domains
to
register
or
or
potentially
re-register.
You
know,
access
recover
access
right.
You
know
validate
control
of
a
namespace
in
dns
or
other
services
right,
so
I
wasn't
trying
to
interleave
some
of
those
concerns,
because
you
know
you
know
proving
that
you
have
access
to
a
namespace
somewhere
else
is
sort
of
sufficient
to
you
know,
demonstrate
access.
You
know
approve
access
to
a
namespace
in
maven
central
right.
D
C
Yeah,
that's
that's
a
great
point.
I'll
tell
you
what
I
think
java
is
a
little
bit
unique
here
now,
whether
it
should
be
unique
or
whether
whether
they're
more
likely
to
move
in
that
direction
is
its
own
question.
My
recommendation
there
is,
is
you
just
share
that
document
with
me?
I
am
going
to
read
it.
I'm
going
to
enjoy
reading
awesome
your
lead,
we
can
merge,
we
can
cross-reference.
C
D
G
Jonathan
excuse
me
so
this
is
a
bigger
problem
problem
when
jfrog
was
around
and
helped
letting
you
publish
artifacts
to
jcenter
one
of
the
attacks
that
I
always
bounced
around
my
head.
So
I
I
formerly
worked
at
gradle
and
I
was
also
thinking
about
attacking
the
java
ecosystem
as
a
security
researcher
prior
to
working
cradle.
G
There
was
a
potential
race
condition
between,
like,
I
think
that
they
checked
to
make
sure
that
artifact
was
not
published
in
maven,
central
and
json,
or
mirrored
or
acted
like
a
proxy
like
at
a
superset
proxy
of
maven
central.
And
if
you,
if
you
were
to
race-
and
you
were
to
see
okay,
somebody
published
something
on
jcenter,
you
could
like
buy
the
domain
and
like
publish
that
same
package
to
maven
central
and
like
have
this
like
domain.
G
You
could
like
under
write
another
package
in
another
in
another
artifact
server,
and
I
presume
that
their
this
vulnerability
doesn't
really
exist
anymore,
because
jcenter
stopped
accepting
new
packages,
but
I
presume
that
this
same
sort
of
class
of
vulnerability
may
exist
in
other
ecosystems,
where
there
is
not.
You
know,
a
single
central
repository
that
hosts
artifacts,
with
maybe
dual
central
repositories
like
potentially
the
yarn
ecosystem
and
the
npm
ecosystem,
or
something
like
that
like
I
don't.
B
E
E
It's
very
friendly.
This
is
not
like
you
know,
a
negative
process
at
all.
It's-
and
this
is
all
designed
to
help
ideally
learn
some
things
from
maintainers
in
really
high
pressure
situations
to
create
better
structures
for
critical
software
processes,
critical
open
source
software
production
and
and
also
just
to
help
maintainers
over
time
with
best
practices.
E
E
A
E
B
I
I
I
Verification
tools,
10
years
from
now
would
be
able
to
read
that
metadata
and
if
specs
had
changed
or
things
had
changed
that
the
tools
would
still
be
able
to
verify
artifacts
that
were
signed
today
at
any
point
in
the
future.
So
anyway,
I'll
I'll
leave
it
at
that.
If
patrick
and
everybody
have
anything
that
they
want
to
add,
they
can
but
we're.
A
D
Yeah,
I'm
trying
to
understand
a
little
bit
as
well,
so
I
know
you
know
we
think
of
a
component.
You
know,
as
you
know,
here's
you
know
one
isolated
thing.
You
know
it's
got
a
palm
file
and
here's
what's
built,
but
when
a
release
happens
there
could
be
multiple,
maybe
dozens
or
hundreds
of
these
components.
You
know
these
small
gaps
or
whatever,
as
part
of
the
broader
release
right
and
so
what
you're
suggesting
is
that
at
the
component
level
there
isn't
just
one
file.
There
there's
many
files
there.
A
lot
of
those
are
signed
right.
D
I
D
And
we
do
those
models
of
separate
kind
of
components,
largely
from
a
from
a
operational
perspective,
right,
even
central,
and
so
that's
kind
of
what
we
that
that's
our
unit
of
measurement
right.
You
know
at
that
level,
it's
not
like
there's
an
r
file,
that's
everything
right
or
a
gz
file
like
what
are
the
systems?
D
Have
that
compile
there's
a
number
of
files
that
that
can
be
8,
10
12
20,
some
number
of
files
in
each
one
of
those
modules,
but
that's
the
unit
we
consider
and
we
have
some
internal
manifest
and
that
sort
of
thing
around
that,
so
we
publish
about
50
000
of
those
on
a
weekly
basis.
Right,
though
those
at
a
gav
level,
you
know
I
don't
know
what
that
translates
to
when
it
comes
to
broad
releases.
D
And
and
the
concern
isn't
necessarily
about
the
generation
of
the
signatures,
I
think
it's
more
on
the
validation
right,
so
we
talk
about
how
many
people
are
actually
downloading
and
using
validate
them.
I
think
that's
really,
where
more
of
the
pressure
probably
is
right,
I'm
telling
one
component
I've
got
to
validate.
You
know
20
signatures
for
every
single
component.
You
know,
and
all
that's
going
straight
to
six
store
that
that
that
seems
like
a
non-starter
to
me.
You
know,
so
I
think
that's
probably
more
the
concern.
I
Yeah,
it
will
boil
around
like
what,
in
any
of
the
repositories
that
may
be
receiving
these
large
number
of
files.
Central,
I
think
apple
mentioned
that
debian
does
something
similar.
We
could
collapse
it
down
to
like
one
record
entry.
It
would
just
you
know
how
is
that
introduced
in
order
to
do
verification
in
the
future
or
even
now,
so
anyway,
it
can
be
it's
a
sidebar
discussion
and
we
can
probably
yeah.
It
is
totally
yeah.
B
So
I
will
say
one
thing
that
we
did
for
the
six
store
python
client
is,
we
add,
support
for
assigning
multiple
files
to
it,
which
is
something
that
cosine
doesn't
currently
do
right
now,
because
we
wanted
to
be
able
to.
You
know
like
build
a
python
release
and
sign,
and
it's
only
a
couple
files.
So
I
don't
think
we
have
the
same
sort
of
concerns
here
about
that,
but
I
am
kind
of
interested
in
the
question
of
like
well
what
should
be
reused
like.
B
Obviously
we
don't
want
to
make
the
user
go
through
the
oauth
flow
over
and
over
again,
so
that
should
identity
should
be
reused.
But
then
you
know
you
could
optionally
reuse
the
certificate
or
you
could
request
a
new
certificate
each
time
and
I
don't
think,
there's
clear
answers
about
what
the
best
practices.
I
B
D
D
I
G
One
other
thing
that
may
be
good.
I
I
just
realizing
that
I
don't
think
there's
a
representation
of
jace
jetpack
in
this
group,
and
I
will
reach
out
to
him
and
make
him
aware
of
this
group
than
that
he
should
consider
joining
as
well,
because
he's
jetpack
is
not
always
looked
upon
highly
in
the
ecosystem,
but
is
also
a
growing
fundamental
part
of
the
supply
chain
of
the
japanese
system.
Anyways,
and
so
I
will
reach
out
to
them
as
well.
B
Great,
it
sounds
like
some
actions
here,
maybe
are
for
jason
to
pull
together
some
folks
that
are
also
interested
in
this,
but
I
think
coming
out
of
this
some
idea
of
best
practices
for
signing
multiple
things,
like
a
document
that
describes
that
maybe
also
like
an
issue-
I
guess
there
already
is
an
issue
for
for
falsio
but
yeah.
Maybe
some
more
discussion
on
that
feature
request
or
to
review.
B
Okay,
moving
on
and
somewhat
related,
actually
I
have
an
early
draft
of
a
workflow
for
signing
the
c
python
releases.
So
to
be
clear,
this
is
maybe
a
little
bit
outside
the
scope
of
this
work
group,
but
the
see
python,
which
is
the
like
reference
implementation
of
python,
the
the
maintainers,
are
interested
in
signing
the
releases
with
six
store
and
similar
to
what
we
were
just
talking
about,
there's
multiple
artifacts,
that
they
need
to
sort
of
sign
all
at
the
same
time.
B
B
G
Pg,
I
don't
remember
who
was
the
one
that
originally
created
this
survey?
Was
that
brandon?
Are
you
still
here
anyways,
so
there's
a
the
the
survey
of
land
languages,
packaging,
managing
manager,
ecosystem
security,
ecosystems,
which
is
like
a
giant
spreadsheet
with
a
bunch
of
questions
on
it?
I
from
a
couple
of
meetings.
I
come
back
a
couple
meetings
back.
G
I
added
a
couple
of
questions,
so
this
is
mostly
around
like,
like
there's
a
bunch
of
questions
about
like
what
features
does
the
thing
out,
but
this
is
more
about.
Like
has
an
audit
ever
been
performed
on
the
security
of
both
the
client
that's
being
used
in
the
packaging
ecosystem
and
the
server
in
the
packaging
system?
G
So
it
includes
questions
about
clear
box
testing
which
is
formerly
known
as
white
box
testing,
but
is
kind
of
the
name
is
not
similar
to
dropping
master
and
may
and
converting
to
main
it's
white
box
testing.
I
think
is
also
going
that
similar
way
so
clear
box
testing
is
the
term
so
asking
about
clear
box
testing
of
the
server
software
that's
being
used
to
host
the
artifact
server,
clear
box,
testing
of
the
client
and
then
questions
about
pen
has
a
pen
test
ever
been
performed
against.
G
A
lot
of
organizations
get
pen
tests
of
their
software
before
they
ship
it
to
customers,
because
customers
are
buying
it
and
they
have
an
obligation
financially
to
to,
like
the
customer,
says.
Well,
we're
not
going
to
buy
your
software
unless
you've
gotten
a
pen
test
done,
but
because
you
know
packaging,
managing
ecosystems,
the
software
is
all
free.
G
There's
never
been
that,
like
gate
to
purchase
as
a
part
of
the
process
that
that
is
forced
a
a
security
audit
or
a
pen
test
or
something
like
that
to
occur,
and
so
it
is
my
understanding
and
belief.
I
don't
know
this
is
true.
That's
why
I'm
hoping
to
put
this
out
in
the
survey
is
to
ask
hey
ecosystem.
Have
you
as
organizations
ever
had
these
happen?
G
And
let's,
let's
try
to
get
some
feedback
on
that,
and
then
we
will
better
understand
the
gaps
of
the
security
of
the
of
the
these
supply
chain.
Components
that
we
all
rely
upon
and
all
these
really
myriads
of
companies
are
relying
upon
every
single
day
any
questions
or
concerns,
or
insights
or
yeah.
D
Yeah,
so
I
mean
essentially
if
the
organization
is,
for
instance
like
sock
too
compliant
and
that's
where
the
environment
is
or
whatever
isn't
it
doesn't
that
sort
of
suggest
yes
for
these,
or
I
mean
this,
is
sort
of
a
subset
of
a
lot
of
those
requirements
and
sort
of
compliant.
You
know
from
compliance
perspective,
so
are
you
just
looking
to
kind
of
generally
like
get
give
a
taste
of
what
all
these
ecosystems
are
doing
and
kind
of
expose
that.
F
G
C
D
I
think
I'll,
I,
I
think
I'll
I'll
give
this
more
thought.
I'm
trying
to
understand
what
the
the
goal
is
when
collecting
this
information
and
how
this
interrelates
to
other
security
compliance
programs
that
are
in
place
that
are
basically
more
detailed
and
nuanced
you
know,
and
and
so
just
trying
to
send
the
value
behind
this.
To
a
certain
extent,
right,
I
don't
know,
there's
a
level
specificity
with
these
questions.
That
is.
Is
it
nuanced
or
general
enough
to
maybe
really
I'm
just
trying
to
grok
this
a
little
bit
further
right.
D
G
Right
so
I
don't
presume
that,
like
I,
I
could
be
completely
wrong,
but
I'm
under
the
understanding
that
pi
pi,
for
example,
is
not
supported
by
it's
like
financially
by
an
organization
right.
So
I
don't
believe
that,
and
there
are
other
packaging
ecosystems
that
are
not
financially
supported
by
other
organizations
like
they're,
not
for
profits
or
there's
like
volunteer
groups
that
are
running
those
things
and
so
they've
never
gotten
stock
compliance.
G
I
know
that
gradle,
for
example,
doesn't
have
soft
compliance
right
like
it's.
I
think
you
know.
That's
that's,
I
think,
probably
generally
public
information
yeah
like
it's
it's
like,
so
I
think
that
trying
to
say
like
do,
stock
compliance
is
like
way
too
far
of
our
high
potentially
of
a
bar
that
we
want
some
of
these
organizations
to
clear
beyond,
like
we
just
want
to
make
sure
that
certain,
like
baseline
security,
like
audits,
have
been
occurred
against
the
stuff.
The
context
that
I'm
coming
from
is
like
I
found
when
I
this
is
2019.
G
I
found
a
bunch
of
vulnerabilities
in
gradle
and
they
grow
a
plug-in
portal.
They
were
like
low-hanging,
fruit,
like
cross-sites
or
crossfit,
request,
forgery
and
other
stuff,
like
clearly,
nobody
had
audited
it.
It
audited
the
plug-in
portal
at
all,
right
and
and
and
so
trying
to
it's,
both
a
like
hey
like
have
this
happen
and
okay.
We
need
to
figure
out
a
way
to
finance
this,
to
make
sure
this
actually
occurs
right
because
it
hasn't
happened
yet.
G
D
Yeah,
but
but
but
this
this
is
a
small
subset
of
overall
security
controls
right
and
it
seems
to
be
kind
of
cherry-picking
around.
You
know
this
particular
audit
or
red
team
audits
or
whatever
versus
you
know,
process-based
controls
and
and
other
things
that
are
equally
important
right.
So
I
I
guess
everything
hey
we're
going
to
dump.
I
again,
I
I
have
to
think
about
a
little
bit
more.
G
Right-
and
I
I
I
am
totally
okay
with
agreeing
on
that-
I
think
that
the
perspective
that
I
so
I
read
through
the
document
and
read
through
the
set
of
questions,
and
they
were
all
focused
on
like
security
controls
that
were
implemented
in
the
technology
and
in
the
packaging
system.
But
none
of
them
like
actually
tried
to
address
like
hey
like
have
you
done
any
vulnerable
like
have
you
actually
like?
Had
anybody
do
an
assessment
of
the
software
to
see
if
there's
any
vulnerabilities
present
right
like
there's?
G
Never,
there
is
no
like,
like
audit
of
the
software,
to
see
if
it
was
secure
itself,
like
sure
that
has
these
features
but
like
if
those
features
can
get
bypassed
because
there's
a
vulnerability
present
like
that's,
not
really
a
security
feature
right.
So
those
are
like
you
know
sure
you
say
you
have
this
feature.
Can
you
have
you
validated
that
right,
like
those
are
the
kind
of
questions
sure
you
like?
G
You
know
you
say
you're
secure
as
an
organization
or
company
have
you
had
a
red
team
that
come
has
come
in
and
tried
to
assess
that
to
see
if
they
could
break
into
your
infrastructure
or
software,
or
you
know
stuff
like
that,
like
like
demonstrate
that
great
you,
you
say
that
you've
done
these
things.
Do
you
have
a
like?
Have
you
have
you
had
an
out
outside
firm
perform
the
test
to
say
this
is
what
they
say
is.
G
A
The
problems
being
discussed
in
the
chat
like
where
we're
a
volunteer-led
or
open
source
group
who
would
who
would
fund
it
and
if
they
funded
it,
would
they
actually
fund
fixing
it?
Would
they
only
fund
identifying
the
problems?
What
do
you
do
if
you
don't
have
a
corporate
ceo
who
can
sit
down
with
lawyers,
to
look
at
a
document?
How
do
you,
how
do
you
get
a
report
of
vulnerabilities,
some
of
which
are.
C
G
If
you
say
explicitly,
we've
never
had
these
things
performed
right.
We've
never
had
an
audit
like
this
performed.
The
openssf
can
then
say
all
right.
Well,
this
is
a
pretty
large
gap
that,
like
most
modern
software,
that's
being
sold
to
like
millions
of
people
that
are
being
relied
upon
every
single
day
is
like
critical
software.
These
are
gaps
that
we
should
be
filling
in
and
we
can
throw
the
money,
that's
being
funded,
it's
being
provided
at
the
open
sf
to
let
that
audit
be
performed
against
pi
fi.
G
G
G
J
B
H
We
can
like
to
say
that,
but
my
experience
doing
with
maintainers
the
last
time
we
did
this
is
is
the
time
they
discovered
they
didn't
like.
Knowing
when
all
that
happened
was
they
got
yelled
at
all
the
time
and
checklists
and
compliance
documents,
and
did
you
get
your
badge
for
your
security
audit
or
something
is
all
of
that,
and
none
of
it
helps
what
helps
is
actually
paying
developers
to
write
code,
as
audits
discover
problems.
G
Yes,
but
I
think
that
identifying
that
the
problem
is
real,
like
I
think
the
problem
is
real,
but
I'm
asking
the
audit
like
that
this
document
we
get
that
information
into
this
document
so
that
we
like
can
say
verifiably.
This
is
a
problem
and
the
open
ssf
should
be
I'd,
be
throwing
money
at
fixing.
This
problem.
J
H
Open
source
developers
never
occur.
My
experience
is
open
source
developers
and
maintainers.
Don't
worry
about
that
they're
they're
far
downstreams
do
like
corporations.
We
all
work
for
some
of
some
of
our
some
of
our
security
people
have
occasionally
expressed
that
concern
at
my
employer.
We've
gotten
to
move
past
that,
because
getting
it
fixed
is
more
important
than
having
it
not
discovered,
there's
probably
a
problem
with
other
companies,
but
it's
as
I
said,
it's
not
really
something
that
maintainers
worry
about.
D
Yeah
and
just
to
fill
you
in,
I
think
it
was
contentious.
I
was
just
asking
jonathan
to
expand
a
little
bit
on
on.
You
know
what
the
expectation
was
around
this
right.
You
did
a
great
way
of
explaining
this
jonathan
and
I,
I
think,
you're
getting
a
broader
view
of
this
and
and
where
these
gaps
are,
is
really
important.
So,
thanks
for
thinking
about
it,.
G
G
This
is
an
actual
real
problem
in
the
in
the
supply
chain
of
all
these
ecosystems
and
try
to
actually
throw
resources
or
motivation
or
energy,
or
something
at
like.
We've
identified
this
problem,
let's
figure
out
how
to
fix
it
now,
because
I've
been
on
the
other
side
of
trying
to
say,
like
hey
like
this
is
important.
We
should
be
doing
this.
J
I
can,
I
can
say,
at
least
for
ruby
and
ruby
central,
which
is
sort
of
like
the
the
organization
that
manages
and
supports
rubygems.log
for
shopify.
We
have
an
announcement
coming
up,
probably
not
until
july,
so
I
have
to
be
vague.
I
don't
want
to
preempt
it,
but,
like
this
exact
problem
is
on
our
radar.
G
I
am
asking
if,
like
these
questions,
are
asking
a
very
specific
question,
especially
including
a
link
to
the
like
report
from
the
the
pentest
company
for
the
company,
that
the
companies
that
may
have
had
these
reports
is
the
are
the
questions
like
going.
I
there.
I
part
of
the
question
about
like
asking
for
a
link
to
the
report.
I
presume,
may
tickle
some
or
may
potentially
upset
some
legal
people
on
the
other
side
of
this
organization
inside
these
organizations
is.