►
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
A
B
Hi
and
welcome
everybody
to
this
webinar,
my
name
is
I'm
the
devrel
for
scribe
security
I've
been
a
long
time
programmer
in
a
relatively
short
time
Deborah,
and
we
have
a
very
distinguished
yes
with
us
this
evening,
say
hello
or
I
will
say
hello
for
you:
who's,
the
head
of
software
supply
chain
security
at
check
marks
prior
to
check
mark
exactly,
was
the
co-founder
and
CEO
of
plastico
the
SAS
based
solution
that
detects
malicious
attacks
and
back
doors
in
open
source
software
Supply
chains
that
startup
was
later
acquired
by
check
marks
in
August
of
21..
B
Awesome,
as
the
title
of
this
webinar
says,
we're
going
to
be
talking
about
lesser
known,
vulnerabilities
in
GitHub
to
those
of
our
viewers
who
don't
know
I'm
guessing
there's
not
a
lot
of
you
out
there.
Github
is
one
of
the
more
popular
SCM
platforms
around
SCM,
meaning
source
code,
Management
systems
or
Source
management,
not
just
source
code
currently
or
at
least
as
of
last
June.
It
reported
over
83
million
developers
and
more
than
200
million
repositories.
That's
a
lot
of
repositories,
including
at
least
28
million
public
repositories.
B
That's
you
know
not
counting
all
the
private
things.
The
things
that
you
don't
know
about
can't
see.
Github
is
also
widely
used
to
build
and
distribute
software
using
their
own
tools,
their
own
CI,
CD
platform
actions,
workflows.
I
would
like
to
start
by
asking
Safi.
How
can
we
understand
or
help
us
understand?
What
is
the
scope
of
software
supply
chain
vulnerabilities
or
how
would
you
define
actually
your
job
as
the
head
of
software
supply
chain,
security
and
checkbooks?
Are
you
in
charge
of
all
software
supply
chain
everywhere
on
the
planet
or
is.
A
Success
is
the
kind
of
cooperation
we're
doing
right
here,
because
basically
I
do
think
that
the
only
way
we
can
move
forward
is
if
everybody
will
work
together
and
of
course
nobody
can
do
everything.
My
focus
is
basically
and
being
more
focused
about
the
open
source
packages
and
and
basically
I
I'm,
not
a
developer
I'm,
a
cyber
guy.
A
So
basically
I
just
ask
myself:
okay,
you've
seen
all
those
great
open
source
projects
and
people
are
using
them
all
the
time,
who's
vetting
the
code
again
coming
for
a
more
suspicious
background
and
tracking
and
hunting
down
cyber
criminals
and
advanced
attackers.
I
thought
myself.
Is
there
a
way
for
the
bad
guys
to
exploit
the
trust
in
this
system
and
try
to
poison
our
software
supply
chain?
So
there
are
many
moving
parts
and
to
that
problem
there
is,
as
you
said,
not
just
the
open
source
packages,
but
a
local
code
and
GitHub
actions
cicd.
A
There
are
multiple,
multiple
angles
to
that
attack
and
basically,
what
me
and
my
team
is
doing-
is
tracking
attackers,
poising,
open
source
packages
and
stopping
them
and
part
of
what
we're
doing
is
research
about
ways.
They
can
actually
hijack
and
modify
legitimate
package
and
one
of
those
techniques
I'll
be
presenting
later
today.
B
So
so
the
the
follow-up
question,
because
you
said
you
know
a
lot
in
poisoning
packages
can
be
a
lot
of
things.
What
was
the
Catalyst
for
starting
to
look
at
GitHub?
Specifically?
What
got
you
started
looking
into
GitHub
as
a
source
of
potential
problem?
Not
just
for
the
vulnerability
we're
going
to
talk
about
today,
but
just
in
general.
A
So
basically,
GitHub
contains
a
large
percentage
of
the
open
source
package
in
the
world
which
are
stored
on
GitHub
in
multiple
ways.
So
thinking
from
the
attacker
point
of
view,
if
would
if
I
would
like
to
attack
a
package?
Where
are
the
package
placed
and
most
of
the
packages
are
in
GitHub?
So
a
lot
of
time?
We
take
the
attacker
mindset
and
then
we
just
follow.
B
Well,
since
we
teased
our
I
think
our
viewers
enough,
let's
talk
about
what
you
found
a
couple
of
months
ago,
you
reported
a
vulnerability
called
Rico
jacking,
because
I'm
not
sure
all
of
our
viewers
are
familiar
with
the
term
or
the
vulnerability
or
the
attack.
Why
don't
you
tell
us
about
it?.
A
Okay,
so
let
me
share
a
couple
of
slides
I've
prepared-
and
this
is
to
be
honest,
one
of
the
coolest
vulnerabilities
we
ever
found.
Anybody
can
exploit
that
you
don't
need
to
write
any
code
or
Shell
Code
or
buff
oil
flow.
It
is
more
of
a
design
issue
that
we
found.
Let
me
just
share
my
screen
block
and
tell
me
if
you
can
see
my
presentation.
A
What
is
reproducting
great
so,
basically,
as
you
said,
repo
jacking
is,
is
a
technique.
You
can
use
to
do
a
softer
supply
chain
attack
and
it's
quite
trivial
to
exploit,
and
the
end
of
this
attack
actually
allows
me
to
inject
remote
code
into
a
lot
of
different
projects
and
high
import
projects
from
companies
like
Google,
GitHub,
Facebook,
kubernetes,
basically,
a
lot
of
them.
So
there
are
a
lot
of
vulnerabilities
out
there,
but
most
of
them
are
closed
and
I.
A
Don't
care
and
I
guess
that
this
is
a
bit
different,
because
this
vulnerability
can
affect
our
audience
and
basically,
we
are
seeing
attacker
abusing
this
vulnerability.
Just
earlier
this
year
we
saw
a
PHP
package
with
more
than
two
and
a
half
million
installation
compromised
and
added
malicious
code
using
this
repo
jacking
technique,
and
this
is
just
one
of
those
cases
that
we
have
seen.
A
So
this
vulnerability
is
interesting
because
it's
been
exploited
in
the
wild
and,
let's
try
to
understand,
maybe
about
who
is
vulnerable
and
how
can
I
protect
myself
so
basically,
and
there
are
two
conditions
to
be
susceptible
for
repo
jacking,
the
first
one
is:
your
code
needs
to
be
directly
referenced
from
a
GitHub
repository,
meaning
you're,
using
a
code
that
is
sources
GitHub,
and
we
said
like
before.
A
lot
of
the
code
out.
A
A
So,
first
of
all,
we
talked
about.
My
code
need
to
be
referenced
from
a
GitHub
repository.
What
do
I
mean,
as
you
mentioned
before,
we
are
familiar
with
Version
Control
System,
like
GitHub
gitlab,
bitbucket
and
package
managers,
so
the
difference
is
is
in
many
cases
that
we
use
code,
we
not
automatically
go
into
GitHub.
In
many
cases
we
go
into
package
managers
package
managers
like
npm
for
JavaScript
and
for
doubt
and
Pi
Pi
for
pi,
for
Python
and
in
those
cases
I'm
not
going
directly
to
the
source
code.
A
I'm
actually
going
I
would
say,
like
an
application
store
and
take
my
code
from
there.
But
there
are
languages
and
go
is
a
an
example
of
those
languages
that
actually
you
take
the
code
directly
from
the
source.
It's
not
just
go.
It's
go
and
Swift
and
PHP
and
in
those
languages
you
don't
go
and
install
a
package
from
a
package
manager.
Actually,
you
can
see
in
the
in
the
screen
that
I'm
showing
you
you
actually
go
directly
to
GitHub
directly
to
a
specific
repo,
a
specific
project
and
take
the
code
from
there.
A
Basically,
and
in
this
design
of
go
PHP
and
Swift,
the
attacker
doesn't
need
to
touch
the
package.
He
needs
to
touch
the
repo.
So,
from
the
attacker
point
of
view,
seeing
and
understanding
that
we
thought
to
ourselves,
how
would
an
attacker
would
feel
How?
Could
an
attacker
could
take
control
of
that
URL
because,
basically,
if
he's
taking
control
of
that
URL
is
basically
handing
you
the
code
he
wants.
A
A
A
Although
they
have
this
like
a
bit
terrifying
message:
yeah
I'm,
gonna
change,
my
username,
that's
okay,
and
when
you
change
your
username,
you
don't
think
that
anything
has
changed,
because,
basically,
what
happens
in
order
to
preserve
functionality,
GitHub
will
set
up
an
automatic
redirect,
for
example,
Barack
suppose
I'm
using
github.com
Barack
your
great
project,
and
you
change
your
name
to
Barack
one
in
my
code
when
I'm
actually
referencing
your
old
username,
everything
will
still
work
because
I'm
going
to
the
old
username
and
automatically
getting
a
redirected,
a
new
username.
A
So
everything
is
working
as
expected.
You
don't
think
that
nothing
has
changed.
I,
don't
know
you
think
to
yourself,
I,
don't
know
why
GitHub
gave
me
this
warning.
Everything
is
still
working
but
and
there's
always
a,
but
the
the
reason
that
they
allowed
the
old
username
to
continue
to
exist
is
that
existing
references
will
continue
without
breaking,
but
the
old
username
is
now
free.
A
So
although
it's
working,
it
is
possible
for
another
attacker
or
another
developer
to
claim
that
all
the
username
once
I
I
claim
that
all
the
username
people
are
actually
referencing
me.
And
now
there
is
no
redirect
people
are
asking
me
actually
thinking
that
they
are
always
they
always
use
the
old
username
get
redirected.
Now
it's
not
redirected,
they
don't
see
what's
happening
and
now
I
can
serve
them.
A
My
own
malicious
code,
so
basically
the
mixture
of
a
rename
and
which
actually
opens
the
code
that
I'm
actually
serving
or
people
getting
me
for
a
hijack
or
what
we
call
repo
jacking,
because
I
can
like
Jack
I
can
steal
your
repo
account.
This
method
is
actually
used
to
hijack
all
references
and
to
solve
malware
or
I
would
say
malicious
packages.
A
So
you
you
probably
thinking
to
yourself
I've,
never
changed
my
username
a
view.
Is
that
a
real
problem,
or
not
so
just
looking
at
the
Go
ecosystem?
This
is
the
number
of
package
that
we
found
today
that
they
are
susceptible
for
reprojecting
and
if
you
can
see
there
are
a
lot
of
very
popular
projects
out
there
that
their
original
developer
at
one
point
decided
to
change
his
username.
A
So
they
are
possible
attacks
targets
for
an
attacker
and
I
know
that
I'm
talking
about
go
and
because,
but
again
this
isn't
specific
for
go.
We
found
the
same
with
Swift
and
PHP,
so,
basically
language
that
they
decided
there
will
be
no
package
manager.
There
will
be
no
python
or
npm.
They
will
actually
go
directly
to
the
source
control
system.
A
If
you
are
able
to
take
control
on
the
source
control
system.
In
this
case
GitHub,
you
can
directly
interfere
with
what
you're
doing,
and
this
is
exactly
what
I
actually
talked
about
and
we
saw
earlier
this
year.
So
what
we
actually
saw
is
there
was
a
package
and
it
was
quite
popular
to
be
honest
at
one
point,
the
the
GitHub
account
closed
this
account
or
could
have
renamed
this
account.
So
although
the
URL
was
still
active,
it
was
hap.
It
was
open
for
anybody
else
to
grab
it.
A
So,
basically
with
reprojecting,
you
don't
need
to
write
any
fancy,
Shell
Code
or
anything
like
that.
You
need
to
find
somebody
who
have
changes,
email
account,
changes,
GitHub
account
and
that's
quite
easy.
You
just
follow
the
redirect
and
you
can
just
register,
is
all
GitHub
account
and
then
try
to
take
over
his
old
repo
name.
Now
there
are
Protections
in
place
because
GitHub
realized
that,
and
they
decided
to
add
a
protection
against
this
use
case,
but
their
protection
actually
applies
only
in
specific
cases.
They
actually
says.
Okay,
we
have
a
popular
repository,
namespace
retirement.
A
In
this
case,
we
will
not
allow
the
combination
of
a
username
and
a
very
popular
repo
name,
but
this
protection
is
only
applied
to
specific
projects
and
the
metric
when
GitHub
decides.
If
that
repo
will
be
protected
or
not
is
basically
if
that
project
had
more
than
100
clones.
In
the
week
leading
to
the
rename
that's
cool,
the
problem
is
for
me
as
a
developer,
going
to
a
repo
I,
don't
see
this
metric,
so
there
is
no
visible
way
to
see,
am
I
protected
or
not
so
I'm
using
a
a
repo.
A
A
Visibility,
am
I
protected
or
not
against
repo
jacking,
not
only
that
their
popular
repository,
namespace
retirement
mechanism,
the
protection
mechanism,
I,
wouldn't
say
it's
bulletproof,
like
everything
in
open
source,
because
my
team
actually
found
two
vulnerabilities
that
allow
me
to
buy
best
this
protection
and,
to
be
honest,
another
researcher
just
found
another
vulnerability
in
that.
So
even
if
it
is
protected,
it's
not
Bulletproof.
A
So
when
there
is
a
rename
there
is
a
possibility
of
somebody
hijack
the
old
username.
So
what
do
we
say
to
to
our
listeners
to
our
audience?
Okay,
I
understand
you
rename
could
lead
to
something
bad.
How
can
I,
detect
and
prevent
this
GitHub
is
offering
protection,
but
it's
not
bulletproof.
It's
not
automatic,
basically
I
would
say
and
that's
an
easy
mitigation
and
reference
the
updated
package
URLs
to
avoid
the
risk.
A
A
The
question
is:
how
do
I
know
if
one
of
the
packages
I'm
using
actually
add
its
its
developer
name
change,
can
I
see
that
and
we
actually
developed
an
open
source
tool
for
the
community
called
chain
checking
and
basically
and
I'm,
going
to
show
you
like
a
short
video
It's
called
The
Chain
Checker.
It
monitor
package
that
can
be
taken
over
and
alerts
the
ecosystem,
and
basically,
what
happens
is
that
you
can
quite
easily
run
this
tool
as
part
of
your
CI
CD
or
once
in
a
lifetime.
A
It's
checking
the
open
source
package
that
you
are
using
I'm
gonna
change
and
add
a
a
report
that
is
actually
susceptible
for
repo
jacking.
The
Falcon
Plus
running
this
script
again
I
can
see
oh
I'm
using
a
package
which
is
in
this
case
a
go
package
which
could
be
a
PHP.
A
It
could
be
a
swift
that
is
susceptible
for
repo
jacking
and
I
better,
like
change
the
url
to
the
correct
URL,
so
I
won't
be
vulnerable
to
repo
jacking
attacks,
so
this
is
basically
in
one
of
the
things
around
GitHub
that
although
we
reported
and
it's
been
exploited
in
the
wild
this
year,
a
couple
of
times
I'm
not
sure
that
the
entire
audience
knowed
about
that,
and
that's
why
I'm
so
appreciative
of
a
few
letting
me
come
coming
and
just
talking
about
that
so
open
source
software
is
powerful
tools,
use
them
carefully.
A
B
It
was
very
definitely
very
engaging.
I
would
like
just
to
add
that
the
the
incident
which
you
mentioned
is
linked
in
the
show
notes.
So
if
our
viewers
are
interested
in
the
the
case
study
or
or
exactly
what
happened,
just
find
the
link
and
you'll
get
to
the
article
talking
all
about
it.
A
A
funny
anecdote
about
that
basically
and
the
guy
who
poisoned
the
the
package
actually
added
code.
That
says
when
the
package
is
running,
please
take
take
the
AWS
keys
and
send
them
to
me
when
it
was
discovered
by
the
way
I
think
he
panicked
a
little
because
after
a
couple
of
days
he
went
on
medium
and
he
actually
says
guys.
It's
me
I'm
a
ethical
hacker
really,
although
I
stole
your
sensitive
keys,
I
never
meant
to
use
them
I'm!
Sorry,
please
forgive
me
and
the
funny
thing
is.
A
And
again,
since
that
we
actually
found
more
vulnerabilities
in
there
and
I
think
that
we
need
to
consider
this
mechanism
of
rename
and
redirect
not
safe
until
GitHub
will
actually
show
us
what
is
protected
or
not
because
right
now
you
you
can
guess,
maybe
it's
protected.
Maybe
it's
not
you're,
not
gonna,
go
and,
and
try
and
hack
all
those
repository
to
find
out
for
yourself.
A
B
Well
earlier,
because
you
know
we
talked
a
lot
a
little
bit
before
we
got
to
this
webinar,
we
mentioned
how
GitHub,
as
a
rule
as
a
whole,
is
not
built
for
security.
It
was
actually
created
to
enable
sharing
and
and
easier
developer
work.
So
if
you
build
something
to
enable
easier
sharing,
putting
security
and
stop
gaps
and
stop
measures
and
permissions
on
top
of
it,
there's
there's
bound
to
be
gaps.
We
actually,
you
actually
mentioned
some
problems
with
the
UI
or
user
experience.
B
Actually
on
GitHub,
where
green
colors
that
denote
safety
are
used
where
they're
not
supposed
to
how
easy
it
is
to
basically
hijack
the
trust
system
or
the
potential
system
for
developers
as
in
yes,
of
course,
I'm
working
with
this
big
company
and
my
code
is
in
this
big
repository
and
I
have
lots
of
stars
and
lots
of
comments.
I
am
awesome,
but
it's
all
a
lie.
A
Yeah,
so
so
I
think
that
GitHub-
and
we
mentioned
before,
is
a
place
to
store
codes
which
is
great
but
I.
Think
GitHub
also
has
a
social
engine,
a
social
social
angle,
to
it
it's
people's
thoughts,
people
and
get
recognition
and
writes
their
own
profile
and
things
like
that,
so
people
actually
using
GitHub
also
as
some
kind
of
a
reputation
system.
So
when
they're
taking
code
from
somebody
they
want
to
make
sure
on
GitHub.
This
guy
is
legit
and
active
and
verified,
and
all
of
that
so
I
have
a
different
lecture.
A
Not
for
this
WebEx
but
I
hope
you,
you
invite
me
again
calling
five
easy
ways
to
still
develop
a
reputation
and
then
and
then
we
saw
that
a
lot
of
the
metrics
that
are
actually
being
shown
on
GitHub,
like
activity
number
of
contributors
stars
and
even
the
place
that
you
walk
here,
not
necessarily
as
verified
as
you
think
they
are
so
I.
A
I,
really
don't
like
the
the
concept
of
and
developers
should
do
better
job,
because
developers
are
working
very
very
hard
and
we
need
to
to
make
sure
that
we
do
everything
that
we
can
to
help
them.
Make
them
work
easier.
So
again
we
are
releasing
the
tools
we
are
helping
the
community
but
I
think
only
if
the
community
will
work
together,
it
will
be
able
to
tackle
those
problems
and
show
that
what
we
are
seeing
is
actually
legit
and
stopping
attackers,
because
attackers
are
actually
abusing
this.
A
We
are
seeing
in
the
latest
couple
of
months
attacker
actually
abusing
this
reputation
system,
building
fake
developer
accounts
in
order
to
gain
more
impact
to
their
attacks.
I
actually
had
one
attack
I
think
last
month
that
was
so
successful
that
the
repo
hosting
that
attack
was
a
trending
project
on
GitHub
wow
yeah,
and
it
was
a
very,
very
nice
because
people
started
asking
him
okay,
you're
trying
to
push
us
to
to
install
this
package.
B
A
A
We
think
the
attacks
will
only
worsen
and
we
are
seeing
that
like
every
other
week
and
it's
important
for
the
companies
in
working
in
that
releasing
tools
and
I
really
like
your
git
get
tools
will
be
to
mentioned
later,
but
we
are
using
that
internally
because
we
really
like
the
output
is
going
is
giving
us-
and
it's
actually
part
of
our
automatic
checks
that
we
run
like
every
week
and
so
giving
back
to
the
community
is
the
only
way
that
we
can
secure
the
open
source
office
system.
Yeah.
B
Both
of
us
do
so
letting
people
know
keeping
them
informed
about
the
potential
problems
and
just
opening
their
eyes
to
how
insecure
things
are,
as
opposed
to
how
secure
they
seem
is
an
important
step
in
the
process,
and
speaking
of
that,
I
would
like
to
share
another
vulnerability
that
our
head
developer,
Mikey
Strauss,
discovered
last
year
actually
very
early.
Last
year
we
reported
this
in
March.
It's
called
Cash
poisoning.
B
Now
a
lot
of
our
viewers
are
probably
using
GitHub,
because
that
was
the
how
we
described
this
webinar.
So
if
you're
using
GitHub
to
build
and
push
your
software,
you
are
probably
familiar
with
the
workflow
system
in
which
you
can
run
things
sequentially
or
in
parallel,
essentially
you're,
putting
together
a
series
of
steps
that
describes
some
sort
of
action,
a
bunch
of
tests,
compilation
whatever
it
is
you're
describing
it's
eventually
done.
However,
you
describe
it
now.
B
Each
workflow
is
individual
in
order
to
protect
the
the
process.
Github
has
defined
that
each
of
these
workflows
must
be
a
completely
different
environment.
However,
sometimes
products
of
one
workflow
are
needed
to
be
used
in
another,
sometimes
the
resources,
sometimes
the
the
output.
So
there
has
to
be
some
sort
of
mechanism
in
place
to
enable
that
sharing
a
cache
is
one
of
those
mechanisms.
B
Well,
you
can't
really
I
mean
you
could
probably,
but
it
wouldn't
be
realistic
to
expect
each
workflow
to
download
all
the
packages
necessary
for
the
compilation
and
testing
of
your
code
and
doing
it
each
and
every
time
when
the
first
time
you're
doing
npmi
or
npm
install
it
could
take
depending
on
the
size
of
all
your
dependencies.
It
could
take
minutes.
So
it's
not
really
logical
to
do
that
for
each
individual
workflow.
So
the
workaround
is
to
have
a
cache.
B
Essentially
if
there
are
a
lot
of
packages
or
a
lot
of
libraries,
any
other
sort
of
thing
needed
across
workflows
GitHub
allows
you
to
put
it
all
in
the
cache
now.
Obviously
you
you
basically
request
in
your
workflow,
give
me
access
to
my
cash.
If
it's
not
there
or
if
it's
different
than
what
you
expect,
you
download
it
for
the
first
time
at
the
end
of
that
particular
workflow,
you
save
it
to
the
cache
and
every
other
time
you
need
the
cash.
You
will
ask
for
the
cash
it's
there,
you
get
it.
B
Everything
is
great,
except
if
I'm
in
a
particular
workflow
something
happens
and
for
whatever
reason
that
cache
is
different
than
what
you
expect.
Let's
say,
there's
a
dependency
confusion,
a
very
common
thing
in
the
npm
sphere,
somebody
simply
changed
or
upped
the
number
of
a
particular
version,
and
suddenly,
when
you
ask
the
cash
there's
a
difference,
you
get
the
new
cash
with
the
slightly
bigger
number
on
that
particular
package.
B
But
the
beautiful
thing
here
is
that,
once
that
cache
is
saved,
it
is
now
updated.
It
is
now
saved
every
other
workflow,
every
other
repository
every
other
time.
You
are
calling
for
the
cache
you'll
get
the
poison
one
you'll
get
the
slightly
different
one,
and
unless
and
until
there's
a
need
for
a
new
cache
to
be
created,
every
call
for
that
cash
will
get
the
bad
one.
B
There's
a
link
to
the
article
discussing
that
this
discovery
in
the
show
notes,
I,
encourage
you
to
go
and
check
it
out.
It's
really
really
cool
and
interesting,
because
it's
interesting,
we
thought
really
hard
about
how
we
can
advise
people
to
protect
themselves
against
it.
Obviously
we
told
GitHub,
but
we
got
the
you
know
expected
answer
that
sharing
cash
between
workflows
is
not
a
bug.
It's
a
feature,
there's
nothing.
They
want
to
do
about
changing
that,
because
it's
a
really
really
needed
feature.
B
There's
no
reason
to
to
you
know
work
around
it
if
you,
if
they
told
us
if
you're
worried
about
people
getting
into
your
workflow
or
changing
your
cash
or
your
code,
well,
basically
use
our
security
system
or
protections
permissions
just
make
sure
that
the
workflow
that
is
writing
to
the
cache
is
as
protected
as
it
could
be.
B
That
is
a
great
answer,
and
it's
always
true
that
you
should
make
sure
that
the
workflow
that
is
able
to
write
things
or
change
things
in
your
environment
or
your
repository
is
as
protected
as
possible
in
terms
of
permissions,
but
it
doesn't
actually
solve
the
problem.
We
do
have
a
suggestion
that
is
also
using
open
source
or
R
tool
to
cryptographically
sign
a
a
repository
or
a
cache
and
then
check
or
verify
the
signature.
But
it's
not
it's
not
Ironclad,
and
it's
not
easy.
B
We
do,
however,
have
an
open
source
tool
which
mentioned
earlier.
It's
called
get,
which
is,
which
is
I,
think
a
cool
name.
It
evaluates
your
GitHub
security
as
a
whole
and
allows
you
to
basically
look
at
your
either
your
organization
or
your
private
GitHub
account
and
see
where
there
are
gaps.
It
gives
you
a
report
which
you
can
constantly
run
over
and
over
again,
you
can
even
automate
the
running
of
the
reports.
B
It
basically
looks
at
four
major
groups
of
potential
security
problems
in
your
GitHub
Access
Control
permissions,
Branch
protection
and
modification
tracking,
and
the
modification
tracking
is
the
really
cool
and
interesting
part,
because,
admittedly,
get
gat
is
an
outside
tool.
Can't
really
prevent
anybody
from
accessing
anything,
but
it
will
allow
you
to
put
certain
repositories
or
libraries
or
basically
any
thing
that
you
want
to
protect
with
a
specific
list
of
users
that
are
allowed
to
access
that
particular
repository
or
library.
B
B
This
is
an
example
of
the
reporter,
just
at
least
just
the
beginning
of
the
report.
I
encourage
you
to
check
out
this
really
cool
Tool.
The
link
to
gitkat
is
in
the
show
notes
like
I
said,
and
we
also
wrote
a
really
comprehensive,
a
really
comprehensive
course
for
the
Linux
Foundation
about
git
Gap,
because
essentially,
when
we
wrote
it,
we
found
out
that
we're
not
just
writing
a
course
about
KitKat.
B
B
The
link
to
the
course
is
in
the
show
notes
now
that
I've
talked
about
my
open
source
tool
and
Safi
discussed
his
open
source
tool,
and
we
told
you
that
you
know
GitHub
was
not
built
for
security
and
you
should
be
aware
and
keep
your
eyes
open
on
what
you're
clicking
or
using
or
incorporating
into
your
code
or
your
Repository.
B
Exactly
what
else
can
you
tell
us
about
how
to
be
aware
and
be
careful?
You
did
say
it's,
not
it's
not
a
virus.
It's
open
source,
but
open
source,
as
we
know,
is,
is
extremely
highly
used
everywhere,
so
other
than
basically
looking
which
again
would
they
could
tell
you
lies
what
other
thing
can
you
do
to
make
sure
that
you're
not
falling
victim
to
fishing
or
type
of
squatting
or
dependency
confusion
or
any
other
of
a
myriad
of
other
possible
vulnerabilities?
That
could
mean
that,
whatever
safe
code,
you
thought
you
were
building.
A
Protecting
complex
system
is
a
thing
that
we've
done
again
and
again
in
different
places
inside
the
network
inside
other
places
and
Twitter
the
the
the
the
problem
that
you
described
with
the
attack
it's
for
me,
it's
like
what
we
used
to
call
elevation
of
Privileges
and
lateral
movement
facing
okay.
If
nothing
embed
will
ever
happen,
that's
okay,
but
if
something
bad
will
happen,
you
can
take
that
access
and
do
like
lateral
movement
across
different
workloads
and
you
can
get
more
permissions.
A
So
the
concept
of
a
don't
let
bad
stuff
happen
in
the
first
place
and
you're
protected
hasn't
proved
itself
very
effective
against
the
attacker.
This
is
why
we
we
are
seeing
now
with
that.
We
are
talking
about
zero
trust.
Not
all
workloads
should
should
share
the
same
cache
right.
Maybe
there
are
different
classification.
A
So,
as
I
said,
the
the
pla
the
platform
was
built
by
developer
for
developers,
but
I
think
that
we
need
to
evolve
as
way
the
attackers
will
evolve
and
will
use
those
design.
Those
design
and
I
wouldn't
say
it
flows,
but
those
design
and
decisions
to
get
an
access
in
one
workflow,
poison,
the
cash
and
just
then
move
to
other
workloads
other
parts
of
your
backending
server.
A
I
would
suggest
that
and
again,
what
we
are
doing
right
now
is
that
we
are
publishing
a
lot
of
our
reports
and
what
we're
seeing
with
the
open
source
ecosystem,
so
I
would
actually
do
encourage
people
to
go
to
medium
or
LinkedIn
or
Twitter
to
get
the
latest
on
those
reports.
We
are
working
together
with
the
open
ssf
to
get
some
kind
of
a
deny
list.
So
for
me,
that's
the
basic
one
of
them.
A
Think
that
I'm
fighting
is
people
think
that,
if
I'm
using
what
we
call
the
vulnerability
scanner
to
scan,
mainly
a
code,
it
will
detect
malicious
packages
and
I
did
an
interesting
and
I
can
I
can
understand
why
right
vulnerable
militias,
it's
the
same,
but
sadly
it's
not
true.
I've
just
done
an
experiment.
Couple
of
weeks
ago,
I've
scanned
nine
thousand
malicious
packages
that
were
vetted
and
reported
against
one
of
the
best
open
source
vulnerability
database
out
there.
Can
you
guess
how
many
results
from
the
non-founds
that
I
get
these
package
isn't
legit.
A
Please
check
the
tools.
We
have
a
couple
of
Open
Source
tools
out
there
in
our
website
and
you
and
your
website
to
check.
Is
this
package
legit
or
not?
And-
and
we
are
working
very
hard
to
get
those
tools
better
automated,
because
I,
don't
think
developers
need
more
information,
they
just
need
a
verdict.
So
most
of
the
things
I,
don't
give
you
a
lot
of
information,
but
the
developer
can
look
at
the
code
and
decide
he
doesn't
want
to
look
at
the
code.
A
He
just
want
to
get
his
job
done,
so
we
are
working
and
what
Microsoft
is
called
tier
free
to
build
the
denialist
for
malicious
packages
to
we
are
actually
building
some
kind
of
an
AV
for
open
source
packages,
so
we
will
do
all
the
hard
work
and
you
just
like
can.
Can
you
know
that
the
package
that
you
are
using
are
safe?
Vulnerable
is
one
thing.
Sadly,
malicious
doesn't
fall
right
now
under
this
category.
A
B
Definitely
I
would
like
to
add,
because
that's
recently
in
the
news
that
the
increasing
usage
of
basically
AI
or
or
chat
Bots,
to
write
code
check
code,
it's
not
doing
anybody
any
favors
beyond
the
fact
that
a
lot
of
the
AIS
out
there
are
being
trained
on
open
source
repositories
and
there's
no
guarantee
that
those
repositories
were
written
safely.
To
begin
with,
there's
a
problem
that
again
because
of
developers
tendency
to
trust
big
corporations,
big
names.
B
If
an
AI
gave
them
a
piece
of
code,
they
tend
to
think
it's
safe,
it's
secure,
it
might
really
really
not
be.
It
might
even
be
written
really
bad.
B
It
could
work
I'm,
not
saying
it's
not,
it
doesn't
work,
but
it
might
be
written
only
in
such
a
way
that
it
would
enable
you
know
Bad
actors
to
quite
easily
get
in
there
and
do
something
bad
I
I
just
saw
recently
that
open
AI
has
tried
really
really
hard
to
add
ethical
limits
on
chat
GPD,
but
in
exactly
the
same
place
in
which
I
saw
the
report
and
I
was
like
Yay.
There's,
it's
not
going
to
write
any
more.
B
You
know
phishing
campaigns
and-
and
you
know
basically
malware-
that
will
require
you
to
pay
ethereum
to
open
your
account
on
the
very
same
place.
There's
you
know
responses
and
the
very
first
one
was
yeah.
I
was
able
to
convince
him
to.
Let
me
write
a
reminder
for
my
brother
to
pay
me
20
ethereum,
so
it
only
all
it
makes
is
basically
makes
the
bad
guys
more
creative
to
get
the
tools
they
need
to
write
their
code.
B
You
they
don't
even
need
to
be
coders
anymore,
like
you
mentioned
earlier,
because
people
are
building
the
tools
for
them
to
write
the
code.
That
will
hurt
us
so
being
aware
being
vigilant,
opening
your
eyes
being
careful
of
permissions,
of
what
you
do
with
what
code
is
extremely
important,
no
matter
where
you
host
your
code
or
how
you
compile
it,
where
you
save
your
images
or
your
final
products,
where
you
ask
people
to
download
them
from
all
of
it
is
hackable
and
and
basically
not
inherently
safe.
B
Of
course,
there
are
ways
to
try
and
make
things
safer,
but
you
know
you
need
to
work
at
it.
It
doesn't
come
naturally
and
any
big
company
that
tells
you
we
got
it
trust
us,
it's
fine.
Everything
is
safe,
don't
just
don't
it
doesn't
look
like
we
have
too
many
questions.
I
guess
we
were
really
convincing
in
explaining
what
we
wanted
to
explain
so
exactly
before
we
end
this
session.
Do
you
have
anything
you
would
like
to
add
to
our
viewers.
A
No
thank
you
for
your
time.
Guys,
I
think
that
it's
it's
up
to
us
and
you
to
educate
the
other
people
developers
around
you
and
guess
that
people
tuning
in
to
this
WebEx
are
what
we
call
early
adopters
and
Fort
leaders.
You
understand
the
problems,
so
I
really
want
to.
Thank
you
for
your
time,
not
listening
to
me,
but
also
I.
Think
that
you
basically
we
are
all
ambassadors
of
there
is
a
problem.
We
need
to
work
together
to
fix
that.
A
So
thank
you
specifically
Brock
for
having
me
on
and
I
hope,
I
wasn't
too
bad
and
that
we
learned
something
in
this
session
and
feel
free
guys
to
reach
out
under
social
or
look
at
our
medium
blog
post,
because
there
is
a
lot
of
stuff
going
on
and
and
we're
always
happy
to
share
and
to
give
knowledge
and
to
help
others
working
together
to
keep
the
ecosystem.
Safe
is
basically
a
armor
to
my
team's
motto
and
also
have
a
tissue
for
that.
B
Awesome
I'm
pretty
sure
that
at
least
one
of
the
questions
will
probably
going
to
be.
Where
can
we
get
those
t-shirts,
so
you
better
find
a
way
to
make
them
public
and
I
would
really
like
to
thank
saki
for
his
time
and
his
awesome
explanation
and
the
fact
that
they
found
this
vulnerability
in
the
first
place,
because,
if
they
hadn't
it
would
still
be
going
on,
it
probably
still
is
in
some
way
but
I'm
sure
that
his
team
will
find
out
all
the
variables
to
plug
those
holes
so
again,
Safi.