►
From YouTube: Code Review Weekly Workshop - Sep 30, 2022
Description
In this session, we deep dive into dependency updates and security and how this pertains to code review.
- https://github.com/ossf/scorecard
- https://youtu.be/gJGbS8UELGw
A
B
B
This
is
changing
like
like
there's
so
much
known
that
someone
who
cares
about
the
product
can
be
concerned
about
so
I'd
love
to
you,
dived
into
how
some
flags
for
what
and
that's
my
big
question
to
you
would
be
what
is
like
a
good
litmus
test
for
adding
a
new
dependency
of
knowing.
Is
this
pretty
good
and
is
the
like
maturity
of
the
project
and
the
maturity
of
the
release?
Like
is
like
we
as
git
lab?
B
A
A
B
A
Unfortunately,
so
so
many
many
companies
so
well
companies,
yes,
but
even
less
so,
like
small,
like
benevolent
dictators
for
life,
don't
require
don't
request
CVS,
they
don't
request
CVS
and
especially
not
for
the
lower
severity
issues.
A
lot
of
a
lot
of
companies
and
groups
only
request
to
be
used
for
super
critical
stuff.
But
what
if
that
low
severity
issue,
is
just
used
in
a
specific
condition
at
gitlab?
That
makes
it
super
critical.
So
so
we
want
to
have
the
latest
versions
we're
looking
for
activity
in
the
in
the
dependency.
A
A
So
you
want
some
sort
of
activity
and
once
again,
like
those
are
open
source
projects
and
one
day
that
person
might
decide
I'm
not
maintaining
this
anymore.
So
it's
ideally,
this
would
be
a
kind
of
ongoing
process
where,
like
we
have
some
sort
of
monitoring
over
that
and
but
right
now
the
best
we
can
do
as
a
code.
Reviewer
is
to
look:
is
this
being
maintained
now
so,
like
any
comments,
any
if
it's
a
gem,
you
go
on
Ruby
jams
like
how
what
does
the
release
cycle
look
like?
Oh.
A
Well,
I
I
prefer,
from
the
security
side
a
gem
that
has
like
one
purpose
and
does
almost
only
that
or
sometimes
like
rails
and
stuff,
like
that,
you
have
those
Frameworks
out
there.
But
if
you
like,
you
want
an
XML,
parser
nokogiri
does
that
does
it
other
stuff?
But
it's
like
it's
pretty
just
a
tool
for
that
job.
Sometimes
you
have
gems
that
just
do
so
many
things
and
it
allows
you
to
Pivot
in
like
a
hacker
that
finds
a
a
certain
vulnerability.
A
It
could
use
a
feature
of
that
gem
that
we
don't
use,
but
it's
there
and
it's
used
to
increase
the
severity
of
the
of
the
of
the
vulnerability.
It
happened
with
another
server-side,
rendering
thing
I
think
it
was
for
the
wikis
again,
but
like
some
sort
of
CSS
server
side,
parsing
ended
up
an
arbitrary
file
read
like.
Why
did
this
read
files
so
so,
like
the
person
is
like
yeah
I'm,
just
doing
this
CSS
style
sheet
and
here's
your
secrets,
the
RB
files,
yeah.
B
A
B
A
Yeah,
it's
really
when
we
gotta
from
the
reviewer
perspective,
especially
like
appsec.
We
have
like
varying
developer
experience.
I've
been
a
developer
for
a
long
time,
but
not
all
of
us
have
and
some
like
I
think
I
have
a
decent
feeling
for
how
long
something
would
take
for
us
to
implement.
Sometimes
we
don't
so
I
think
it's
just
a
conversation
to
have
like
yeah
I
get
that
I
think
this
dependency
is
literal
15
seconds.
But
here
are
the
things
like
the
maintenance
we
pick
up
in
long
term
like
what
happens.
A
B
A
I
think
the
discussion
should
happen
in
the
Mr,
just
just
with
the
author
and
I
think,
every
time
I've
needed
to
have
this
conversation.
It
just
worked
out
in
VMR
pretty
well,
and
sometimes,
if
it's,
if
it's
just
like
a
specific
function
inside
a
package
that
does
way
too
much,
we
could
like
there
are,
depending
on
the
licensing
and
everything
we
could
extract.
That,
and
maybe
forking
is
the
solution.
I
don't
think
we've
had
to
well.
A
We
we
did
have
to
fork
in
the
past,
but
maybe
not
for
that
reason,
but
like
just
Fort
and
basically
delete
everything
we
don't
need.
That
could
be
a
way
forward.
So
it
has
its
drawbacks
because
yeah
like
we
might
miss,
updates
to
do
upstream
and
everything
it's
a
it's
complicated,
yeah
and
especially
but
I.
Another
sign,
I
guess
something
that
would
push
towards
the
re-implement
ourself,
always
going
back
to
that
left
pad
like
left
bad,
wasn't
just
something
simple
done
as
a
package
it.
It
pulled
a
bunch
of
dependencies
too
like
why.
A
So
so
it
was
like
you
get
that
huge
tree
of
dependencies
so
and
you
need
to
care
for
those
as
well
and
nowadays
it's
not
just
it's
not
just
a
vulnerability
in
your
product.
If
one
of
those
is
compromised,
it
could
compromise
our
pipelines
and
we
have
a
bunch
of
very
sensitive
API
keys
and
those
and
stuff
like
that.
So
we
have
detection
like
package.
A
Hunter
is
supposed
to
detect
that,
but
we've
seen
you've
seen
like
someone
who
is
aware
someone
who's
targeting
us
could
could
evade
package
Hunter,
potentially
just
detect
it
and
yeah,
and
fire
and
other
environments
are
not
Ci
or
something
like
that.
We've
seen,
we've
seen
the
opposite.
Actually,
there
was
a
a
rust
package
that
was
malware
that
fired
only
in
C
in
gitlab
cicd.
It
was
targeting
someone
using
gitlab.
A
B
B
B
B
Space
is
to
the
left
of
the
string.
That
algorithm
is
probably
not
going
to
change
yeah
there's
those
those
situations
where,
especially
if
you
just
get,
if
you're
getting
closer
to
the
like
pure
algorithm
side-
that's
like
yes,
this
makes
sense,
let's
just
own
this
and
now
deal
with
dependencies,
because
then
the
fact
that
this
thing
will
change
is
very
unlikely.
But
yeah
there's
a
pro
there's
a
lot!
That's
going
on!
So
it's
it's
a
it's
good
to
bring
up
the
discussion
of
Mrs
and
I.
B
Think
that's
the
main
takeaway
that
I
hope
most
of
our
code,
people
doing
code
review
can
feel
empowered
to
do
is
just
starting
the
discussion
based
on
that
feeling
of
like
let's
just
start
talking
about
it,
then,
and
not
just
not
just
stuff
it
and
feel
like
well.
I
guess
you
know
I
guess
this
was
already
talked
about,
so
we're
just
gonna
keep
going
and
yeah
I
I
hope
that
does
get
to
happen.
C
Got
another
one
million
dollar
question
on
this
kind
of
I'm
kind
of
chosen
up
on
you,
so
we've
just
been
speaking
about
what
kind
of
issues
would
justify
a
third-party
library
and
what
kind
of
issues
we
rather
solar
cells.
Let's
move
ahead,
one
more
step,
and
let's
imagine
for
a
second,
that
we
are
working
on
a
problem
which
absolutely
requires
a
surprise
that
I
will
read
because
it's
just
too
complex
or
whatever
it
might
be.
C
A
C
A
Yep
I
added
a
link
in
the
agenda
just
now
we're
trying
it
there's
a
project.
It's
been
going
on
for
a
while.
This
is
not
ready
yet,
but
there's
a
Mr
dependency
review
bot
project.
That's
going
on
that
would,
when
you
add
something
that
kind
of
fetches
the
metadata
and
builds
a
trust
score
about
each
film
each
vulnerability,
each
dependency
there's
also,
if
you
want
something
a
little
more
formal
I,
have
to
find
a
link.
Give
me
one
second,.
B
A
B
B
A
Which
is
open
source
software
phone
application,
I
think
they
have
a
another
and
I'm
pretty
sure
the
buff?
Actually,
the
bot
I
mentioned
leverages
that
they
have
this
core
card
project
and
a
bunch
of
criteria
is
basically
to
to
look
at
the
the
health
and
of
the
project,
and
they
have
like
all
the
things
that
we
kind
of
that
our
gut
feelings.
A
So
the
the
list
looks
like
just
yeah:
do
they
like,
basically
their
their
CI
and
just
review
everything
best
practices
could
do
they
even
do
code
review
like
look
at
their
PRS
and
it's
just
just
one
person
commit
and
merge,
and
is
there
any
review
going
on?
Do
they
have
contributors?
What
do
their
CI
workflow?
Do?
They
do?
Fuzzing
was
a
license
Etc.
This.
A
I
think
we
would
score
well,
so
there's
something
it's
kind
of
a
yeah.
We
probably
would
to
be
honest
because
we
have
a
lot
of
extremely
good
practices
and
one
thing
one
thing
that
many
people
the
first
one
thing
that
people
tend
to
think
is
a
red
flag
but
could
be
a
green
one
is
existing
vulnerabilities
that
were
well
patched
vulnerabilities,
but
when
you
go
in
the
repository
and
like
let's
say
on
GitHub,
they
have
the
security
Tab
and
you
have
the
advisories
if
they
see
that
they
never
had
any
security
advisory.
A
They're
like
hey,
hey,
this
is
safe,
but
actually
no.
This
is
just
they
don't
discount
security
issues.
So
so,
if,
if
there's
a
list
of
some
issues,
this
is
not
a
red
flag.
For
me,
this
is
oh
cool.
They
are
transparent
about
their
security
issues
and
you
can
actually
see
how
the
security
issue
was
handled.
A
How
did
they
like?
How
was
it
reported
to
them?
Do
they
even
have
a
process
to
report
security
issues?
I,
don't
know,
I
don't
mean
a
bug.
Bounty
program
I
don't
expect
that
of
a
random
open
source
dependency,
but
I
want
a
process
to
reach
out
to
that
person
and
so
having
disclosed
security
issues
for
me
is
a
huge
green
flag.
Actually
yeah.
B
A
One
of
the
biggest
like,
if
you
have
a
list
of
CVS
every
year,
one
of
the
companies
that
has
the
largest
amount
of
CVS
is
gitlab.
So
you
know
it's
just
because
we're
very
transparent
and
we
request
to
be
even
for
the
smallest,
tiniest
silly
security
issue,
but
we
believe
that
every
single
security
issue
should
be
should
have
an
advisory,
and
then
our
users
can
decide
themselves
if
it's
if
it
justifies
an
upgrade
or
not.
A
We
have
to
we
request
another
CV.
If,
if
the
vulnerability
in
the
package
was
exploitable
in
GitHub,
got
it
yep
that
makes
sense.
Okay,
that's
usually
our
process
got
it
like
if,
if
there
was
a
issue
with
reading
files
and
in
rails
and
we
had
to
upgrade
rails
and
release-
and
you
get
that
version
because
of
that
we
would
issue
a
CV
on
top
of
it.
A
It's
more
an
optional
it.
It
depends
on
if
basically,
it's
the
the
owner
of
the
project
that
requests
the
CV.
So
it's
all
in
good
faith,
yeah
and
then,
if
the
owner
of
the
so
this
there
are
some
politics
involved.
So
there
first,
the
owner
of
the
code
should
request
a
CV.
If
they
don't,
the
finder
of
the
security
issue
could
reach
out
to
the
miter,
which
is
the
organizations.
C
A
And
I'll
be
very
transparent,
I
have
it
was
a
fairly
minor
issue,
but
I
have
reported
security
issue.
It
was
a
denial
of
service
in
the
HTTP
in
the
jam
for
HTTP
request
called
x-con,
which
is
fairly
popular
and
they
fixed
it,
and
the
process
was
fine,
but
they
didn't
request
the
cve.
So
nobody
who
runs
the
dependencies
can't
knows
that
they
need
to
upgrade
and
they
don't
know
that
their
website
could
go
down
with
a
single
request,
but
I
was
like
requesting
a
CV
is
kind
of
a
pain
in
the
butt.
C
A
B
A
B
B
B
I'd
love
to
share
talk
about
dependencies,
I
love
to
share
this
issue
that
we've
been
wrestling
with,
which
is
kind
of
related
to
code
review,
but
kind
of
not.
But
it's
very
related
to
the
discussion
about
dependencies.
We
were
just
talking
about,
but
this
is
a
confidential
issue,
so
I'm
going
to
pause,
the
recording
is
everyone.
B
Specifically,
with
this
sandbox
attribute
on
an
iframe
and
I
like
that
idea
of
we're
able
to
use
dependencies,
but
we're
taking
extra
precautions
for
future
we're
future
proofing
ourselves,
because
we
we
don't
want
to,
we
realize
that
there
is
inherent
risk
with
the
way
this
dependency
does
things
and,
as
you
said,
anything
that
renders
runs
user
input
is
a
is
a
pretty
big
red
flag.
We
probably
want
to
sandbox
this
thing.
I.
A
A
There
was
one
for
Java
and
I
believe
he
did
it
for
HTML
server
sanitizer
on
in
Ruby
as
well,
and
you
just
I
think
he
had
a
computer
running
those
things
and
he
just
let
it
go
for
a
week
and
a
half
or
something
and
then
he
gets
a
notification.
And
then
oh,
this
thing
is
not
sanitized
and
he
has
like
the
most
massive
HTML
payload
and
then
he
he
works
it
and
figures.
That
was
the
minimal
thing
and
the
sanitizer
reads:
parses
the
HTML
and
things
I.
A
Don't
know
this
is
a
list
with
an
embedded
comment
or
whatever,
but
the
browser
parses
that
and
actually
does
not
parse
in
the
same
order
and
sees
his
credit
rag
instead,
and
so
that
was
supposed
to
be
text,
but
it
is
actually
parsed
as
a
tag.
So
so
that
sort
of
stuff
can
happen,
and
so
even
sanitizers
I
mean
at
some
point.
A
You
have
to
kind
of
trust
someone,
but
if
we
can
even
the
sandbox
at
this
point,
if
you
want
to
bypass
that,
you
need
like
a
bug
in
the
browser
that
way
those
do
exist,
but
we're
really
making
it
so
much
more
difficult
and
also
when
there's
a
bug
in
the
HTML
sanitizer,
we
have
to
update
a
library
and
ship
a
new
release
when
there's
a
bug
in
the
browser,
which
is
one
very
rare
and
two,
the
browser
is
updated.
Everyone's
browser
updates
with
them
ethically
and
we
don't
have
to
ship
any
release.
So.
B
B
B
That's
what
absolutely
wild
I
I
do
like
the
idea
and
I
think
generally
as
a
culture
bring
this
back
to
code.
Review
of
being
defensive
sounds
like
a
really
necessary
security
tactic
of
like
just
knowing
even
this.
This
works
today,
but
we
just
also
don't
know
like
issues
it
may
have
in
the
future
or
now
so,
the
whatever
steps
we
can
take
to
limit
the
blast
radius.
But
when
things
go
wrong
is
yeah,
a
really
good
culture.
We
need
to
be
promoting
and
asking
us
assume.
B
A
I
guess
there's
a
server
side
equivalent
to
those
sandboxes
mechanisms,
it's
so
much
more
complicated
but
like
when
there's
something
we
don't
trust
and
that's
something
we're
trying
to
to
look
into
for
we.
We
felt
about
that
when
we
ran
the
exif
tool
on
our
images
that
are
uploaded
and
stuff
like
that,
you
can.
A
These
are
words,
I,
never
pronounced
and
only
read,
but
you
know
the
the
change
root
tool.
Truth
you
can,
can
you
can
kind
of
change?
You
could
execute.
You
move,
you
copy
the
executable
in
the
place
and
you
you,
you
create
a
user
that
has
only
access
to
I,
don't
know
it's
like
some
sort
of
directory
inside
your
your
temp
files
or
whatever.
A
So,
if
there's
ever
an
exploit
in
that
and
they
get
file
and
command
execution
on
the
system,
they
are
running
as
a
user
that
has
access
to
nothing
sort
of
like
something
in
a
container
like
our
Runners,
like
you
have
common
execution
by
Design
on
our
Runners,
and
this
is
not
a
security
issue
so
because
of
the
waste
design.
So
some
of
our
actions
once
again,
where
we
process
user
input
when
we
process
uploads,
when
we
press
this
project
Imports,
where
we
had
a
lot
of
security
issues.
A
If
those
could
happen
inside
an
environment
that
we
don't
care,
if
it's
compromised.
Basically,
that's
really-
and
this
makes
the
architecture
a
lot
harder,
especially
with
our
monolith.
This
is
where
kind
of
micro
services
or
whatever
you
want
to
call
them
shine.
I.
Guess
it's
easy
to
just
put
that
workflow
inside
of
another
machine,
and
there
we
go
like
we
don't
compromise
our
host
the
yeah.
This
is
a
this
is
the
iframe
sandbox
of
the
service.
B
C
B
A
B
C
B
B
These
quality
attributes
are
hopefully
the
things
we're
talking
about
in
code
review,
at
least
in
a
collaborative
way
of
like
how
we're
going
to
maintain
this
in
the
long
run.
What's
the
performance
of
this
gonna
be
like
in
the
long
run,
and
security
is
a
big
one
as
well
that
I
think
for
all
code
reviewers,
hopefully
a
big
takeaway,
isn't
just
that.
B
We
hyper
focus
on
the
functional
bit
of
what
we're
looking
at,
but
we
have
to
look
at
all
the
quality
attributes
here
and
security
is
a
security,
and
performance
tend
to
be
at
odds
with
all
sorts
of
other
quality
attributes
cool.
Well,
thanks
appreciate,
it
appreciate
you
hopping
on
and
contributing
so
much
to
the
conversation.
Dominic
and
everybody
else.
I
will
bid
you
all
a
deal
and
have
a
great
rest
of
the
day.
Adios.