►
Description
Presented by Rimas Silkaitis, Senior Director, Product Management
Lothar Schulz, Engineering Manager, Moovel Group GmbH
Anna Debenham, Director of Product, Snyk
Per Ploug, Open Source Community Manager, Zalando SE
Tracy Miranda, Director of Open Source Community, CloudBees
With always-evolving open source software and growing dependencies within it, staying on top of security can feel like an impossible task. That’s why it’s vital for any organization to have the right people and products for the job.
The speakers in this panel will explore different roles within development teams that keep code safe and how the open source community can work together to prioritize and collaborate on security solutions.
About GitHub Satellite 2019
A community connected by code
Explore our interconnected community—and how collaboration turns ideas into innovations.
Join us in November at San Francisco's Palace of Fine Arts for GitHub Universe - https://githubuniverse.com/
A
A
Hello,
everyone
I'm
super
excited
to
be
here.
My
name
is
Rima:
silk
itis
and
today
we've
got
a
panel
of
guests.
Here.
Let
me
tell
you
a
little
bit
about
myself:
I'm
a
senior
product
manager,
a
senior
director
of
product
management
here
at
github,
I'm,
mostly
concerned
with
how
teams
and
individuals
on
those
teams
actually
work
through
the
entire
software
development
lifecycle
and
today,
on
our
panel,
we're
gonna
talk
about
this
intersection
between
DevOps,
the
software
development,
lifecycle
developers
and
security
and
we're
mainly
gonna
circle
around
the
question.
A
A
C
A
D
B
A
Okay,
Anna
I'm
gonna
start
with
you
first
because
your
company
is
recently
released
or
they
actually
released
yearly.
This
state
of
open
source
security
kind
of
survey
right
in
that
report
there
were
two
metrics
that
really
kind
of
stood
out
to
me.
The
first
being
there's
been
an
88
88
percent
increase
in
application
library
vulnerabilities
over
the
last
two
years
and
81
percent
of
users
believe
that
developers
should
be
responsible
for
open
source
security.
So
my
question,
but
first
one
is
like
when
you
say
developers
like
need
to
be
responsible.
A
E
C
C
Well,
our
state
of
open
source
security
report
found
the
only
70%
of
open-source
maintainer
x',
wouldn't
feel
comfortable.
I
wouldn't
feel
like
they
had
the
knowledge
to
be
able
to
fix
a
vulnerability
in
their
code
and
actually
have
like
a
personal
story
of
this.
I
years
ago,
I
set
up
a
an
open
source
repository
which
contained
a
framework
that
I'd
written,
which
was
a
design
system,
and
it
got
kind
of
quite
a
bit
of
publicity
yeah.
C
There
were
quite
a
few
people
using
it
and
a
few
days
after
I
published
it,
I
was
checking
Twitter
and
someone
was
pointing
out
that
there
was
a
massive
under
ability
in
it
and
yeah
I
found
out
about
this.
It
was
a
weekend
and
they
wouldn't
tell
me
what
it
was.
It
would
just
say:
it's
really
really
bad,
so
I
kind
of
asked
a
few
of
my
friends
like.
Can
you
take
a
look?
What
are
they
talking
about
and
we
found
out?
C
It
was
a
basically
anyone
who
hosted
that
framework
on
their
server
ended
up,
basically
opening
it
up
to
the
world
like
any
public
server
and
could
kind
of
like
suddenly
access
it.
I'd,
basically
written
this
massive
vulnerability
and
I
was
really
embarrassed.
I
felt
like
I,
you
know,
should
I
have
published
this
in
the
first
place.
I
didn't
and
didn't
have
the
skills
to
fix
it.
But
what
was
really
nice
was
that
people
stepped
in
to
help
so
they
stepped
in
they
provided
their
knowledge.
They
wrote
a
fix.
C
They
helped
me
write
a
kind
of
practice,
release,
doing
responsible
disclosure
and
the
way
that
I
found
out
about
it
was
actually
quite
typical.
48%
of
people
who
have
their
like
who
do
open
source
find
out
about
a
vulnerability
in
their
code
via
a
public
channel
like
Twitter,
which
really
sucks,
but
at
the
end
of
the
day
the
code
is
fixed
and
as
far
as
I
know,
there
were
no
exploits,
but
it
really
kind
of
sunk
home
to
me
about
you
know:
I'm,
a
front-end,
developer
and
I
I'm,
not
confident
that
I
can
release
code.
C
That's
cure,
so
I
think
in
that
situation
we
don't
want
to
put
people
off
writing
code
and
publishing
code.
It's
really
important
that
they
feel
confident
in
doing
that.
So
I
think
it's
kind
of
up
to
everyone.
Everyone
who
consumes
open
source
packages
to
be
a
kind
of
responsible
citizen
and
follow
kind
of
disguise
of
processor
sort
of
thing
so.
A
C
I
didn't
ask:
I
was
immediately
offered,
you
know
easily.
We
found
it
first
of
all,
they
had
a
go
at
the
person
who
publicly
disposed
it
without.
You
know
giving
a
heads
up
first
yeah,
but
they
then
helped
me
fix
it.
They
knew
immediately
what
the
problem
was.
It
was
quite
a
simple
fix,
but
then
the
whole
process
of
telling
people
about
it
making
sure
that
they
were
on
the
latest
version
that
really
opened
my
eyes,
and
that
was
actually
what
kind
of
encouraged
me
to
join
a
security
company
interesting.
A
B
Absolutely
and
like
working
with
the
Jenkins
community,
which
is
you
know,
the
scale
of
it,
is
huge
in
terms
of
like
users,
there's
millions
of
users,
lots
of
developers
working
on
different
plugins.
So
this
there's
definitely
challenges
there,
because
when
you
have
an
exploit
in
something
like
Jenkins,
which
everybody
is
using,
the
scale
is
ridiculous.
So
a
lot
of
people
had
seen
of
like
a
couple
of
years
back
there
was
this
exploit
where
it
was
like.
The
biggest
Bitcoin
mining
exploit
was
something
like
they'd
made
three
million
of
unpatched
Jenkins
servers.
B
They
were
out
there
because
they
run
on
these
really
powerful
machines.
So
I
think
the
challenge
we
have
it's
like
the
community
will
help
and
they
will
do
things,
but
just
getting
the
message
out
like
patch
your
servers
and
people
get
into
this
habit.
You
know
they'll
just
ignore
the
updates
on
on
the
jenkins
dashboard.
That
says
you
know
this
is
you
know,
they'll
be
like
I?
Don't
want
things
to
break
now?
I
can't
handle
this
so
I'm
just
gonna
leave
it.
B
A
You're,
providing
you
know,
assistance
in
the
interfaces,
they're
saying
hey,
you
know
you
do
this
thing
and
there's
this
like
natural
inclination
to
say
well,
maybe
not
because
I
have
other
things
they
could
take
care
of
and
there's
like
a
concern.
I
might
break
something
in
that.
So
you
know
to
take
the
kind
of
internal
view.
I'm
gonna,
look
to
like
one
of
you.
Both
are
her
on
the
on
the
inside
of
that.
How
do
you
like
help
folks
inside
companies
say
like
yeah?
Let's,
let's
go
and
do
it.
E
E
D
E
I'd
rather
like
to
focus
on
give
give
them
incentives
right,
try
to
try
to
build
a
community
within
the
company,
as
you
do,
outside,
with
open
source
communities
as
well
and
within
a
vivid
community.
Those
pushes
are
not
needed
anymore.
People
are
interested
and
they're
are
proud
of
what
they
do,
and
then
they
have
a
big
incentive
to
fix
it
themselves
without
letting
me
know-
and
there
is
also
no
need
to
notify
me
about
it
in
order
to
have
that,
you
have
to
set
up
such
a
community,
and
this
this
is
small
steps.
A
E
From
pair
of
course,
we've
been
together
at
solando,
and
this
was
great
and
and
being
a
role
model
trying
trying
to
actually
do
what
you
ask
others
to
do,
helps
show
that
you
do
not
know
everything.
You
are
vulnerable,
you,
you
do
not
know
every
technology,
but
there
are.
There
are
certain
ideas
and
things
that
work
for
others
that
you
can
give
a
try,
and
if
that
works
for
you
as
well
in
your
organization,
why
not
try
to
spread
the
word?
Why
not
try
to
make
that
broader
in
the
whole
organization
and
push
the
community?
E
A
E
I
say
we
don't
have
direct
incentives,
there
are
more
indirect,
so
there
are.
There
are
a
lot
of
opportunities
to
speak
up.
There
are
conference
like
internal
formats
where
you
can
present
and
there
are
syllable
showing
up,
and
this
this
helps,
apart
from
all
the
Twitter
likes
like
like
technology
that
you
have
in
any
company
anyway,
right.
A
Understood
so
para
I
wanted
to
ask
you
a
question
now
so
as
part
of
your
work,
you
know
you
kind
of
you
know
you
help
the
company
both
consume
external
open-source,
as
well
as
organized
how
the
company
publishes
its
own
open
source
projects.
You
know
how
do
those
concepts
of
open
source
security
and
responsibilities
apply
with
you
know,
with
the
work
that
you're
doing
for
the
folks
that
that
do
that
kind
of
work,
yeah
the
company
and.
D
So
solando
is
a
company
that
very
much
relies
on
like
customer
trusts.
If
they
don't
trust
that
our
store
is
secure,
they
don't
want
to
buy
anything
from
us.
So
ever
say
everyone
depends
on
our
customers,
trusting
us
and
so
far
for
the
way
we
release
things.
We
don't
specifically
talk
about
security
with
our
developers,
but
more
we
we
talk
about
responsibility
and
taking
responsibility
for
what
we
release
as
open
source
projects,
because
we
do
not
just
want
to
throw
code
over
the
fence
and
just
leave
it
there.
D
Yes,
it's
great
yeah,
take
it
up
there
and
then
you're
the
writer,
and
so
we
asked
several
questions
during
this
release
process
where
I
would
say
the
three
most
crucial
ones
here
are.
First
of
all,
why
do
you
want
to
open
source
this?
What
is
the
value
and
the
motivation
for
you
as
a
developer?
What
is
the
motivation
for
solando
as
a
company?
What
do
we
actually
get
out
of
it
and
we
asked
a
specific
question
not
to
be
a
gate
keeper,
but
actually
to
ensure
that
there's
a
long
term
motivation?
D
If
you
have
a
motivation,
you
take
responsibility,
for
you
take
ownership
of
it.
Just
one
part,
the
other
part
is,
is
asking
the
specific
questions
of
how
many
work
hours
have
you
actually
been
granted
to
maintain
this
project?
Do
you
actually
have
company
time
to
maintain
it,
and
how
many
maintain
is?
Are
you
actually
on
this
team?
Are
you
just
a
one
guy
operation?
If
not
you
do
it,
because
that
is
too
fragile
that
that
one
person
leaves
the
company
and
that
project
is
basically
just
deserted,
even.
D
It's
too
still
too
fragile,
because
we
see
that
a
lot
of
open
source
projects
are
run
by
a
core
group
of
people
who
care
very
much
about
this
project,
but
a
lot
of
the
reason
why
they
actually
care
about.
It
is
because,
in
the
context
of
their
work
at
least
force
Atlanta,
because
we
use
a
lot
of
this
open
source
quote
inside
our
store,
and
so
when
they
leave
for
another
job
at
another
company,
they
stop
caring
about
it
because
it's
not
part
of
their
work
anymore.
D
So
so
these
are
the
things
we
need
to
ensure
happens
during
the
release
process
that
we
take
responsibility
for
resources
being
available
to
our
developers
that
we
have
time
and
people
on
it
and
that
we
actually
have
a
long-term
motivation
to
maintain
it.
Otherwise
we
will
lose
interest
and
eventually
tell
the
developers
to
do
something
else.
That's
just
how
it
works
and
again
that
is
those
to
take
long
term
ownership,
because
if
we
don't
have
that
ownership,
we
will
not
fix
the
box.
There
will
be
no
one
in
that
inbox.
That
gets
that
per
request.
A
D
Yeah,
it
goes
way
beyond
security,
because
it
is
also
about
how
do
we
interact
with
the
people
actually
approaching
us
that
might
just
be
a
design
fix
for
a
piece
of
bit
could
also
might
as
well
be
a
crucial
piece
of
information
about
a
vulnerability.
It
doesn't
really
matter.
We
have
to
be
responsible
for
a
community
around
these
things
as
well,
so.
A
Let
me
take
that
again:
go
back
to
the
outside
approach
to
this
and
Tracy
I'm
gonna
go
back
to
you
with
me
like
distributed
nature
of
Jenkins
and
all
the
plugins
that
work
with
that
yeah.
How
do
you
deal
with
that
kind
of
responsibility
concept?
You
know
in
the
world
that
you're
in
today
it
does
that
exist.
Does
it
not
or
is
it
just
a
community,
come
and
help
us
out
yeah.
B
It
definitely
has
its
challenges
and
again
similar
to
like,
as
the
company
cloudBees,
we
kind
of
at
the
company
level
get
involved
with
with
the
project.
So
a
lot
of
Jenkins
security
team
work
at
cloudBees
and
the
things
we're
seeing
there
that
make
it
really
challenging.
As
that,
the
whole
security
area
has
become
really
professionalized
recently,
which
is
a
very
good
thing
for
the
industry,
but
what
that
means
for
open-source.
B
So
if
you
take
the
example
of
Jenkins,
we
in
the
history
of
the
project,
there
have
been
eight
security
vulnerabilities
which
were
reported
with
coordinated
disclosure
dates,
so
you're
getting
the
report
and
you've
got
a
ticking
clock
and
those
all
happened
in
2018.
So
now,
if
you're
getting
a
vulnerability,
you
know
there's
a
time
countdown.
So
how
do
you
do
that
when
you've
got
a
community
where
that
vulnerability
could
be
in
a
plug-in
that
an
individual
wrote
or
even
if
it's
in
a
company,
the
team
is
focused
on
something
else
and
all
of
a
sudden?
B
It's
like
okay
drop
everything
and
deal
with
this.
So
it's
something
we
think
a
lot
about
like
a
cloud
ease.
We
can.
We
have
to
keep
that
trust
with
the
customer
like
you're
saying,
but
we're
also
looking
at
how
do
we
solve
this
in
a
in
a
bigger
fashion
and
it
has
to
be
everybody's
responsibility
and
we
can't
throw
open-source
developers
under
the
bus
so
well.
How.
B
A
B
That
is
so
we
can
take
this
long-term
view
of
you
know.
How
can
we
focus
on
cross-cutting
issues
like
security,
so
the
hope
there
is
we
can
have
you
know.
Working
groups
focused
on
these
best
practices
approach
it
from
a
way
that
we
can
use
this
community
to
spread
the
message,
extend
best
practices
and
get
everybody
involved.
Open
source
projects,
companies,
individuals-
so
just
just
be
more
organized
about
it,
because
I
think
that's
what
it
takes
and.
B
A
E
B
It
and
in
some
cases
or
you,
give
the
community
permission
or
the
security
team
permission
to
push
out
fixes
to
your
repository,
and
you
know
I
really
like
the
features
announced
at
the
keynote
today,
because
we
can
start
to
think
about.
Okay.
These
now
we
have
the
tooling
tooling,
is
another
big
part
of
it.
So
how
do
we
use
that?
Thank.
A
Yes,
so
yeah
I
mean
with
all
the
stuff
that
we
launched
at
the
Keene
at
the
keynote
today,
like
I,
think
a
lot
of
that
can
be
valuable
to
this
concept
of
like
taking
responsibility
and
like
reducing
the
friction
for
developers
on
your
team
or,
if
you're,
even
working,
an
open
source
to
get
those
vulnerabilities
patched
as
soon
as
possible,
because
it
sounds
like
it
is
really
a
team
effort
right.
We
talked
about
interconnected
community
and
it's
kind
of
important
for
all
of
us
to
you
know
chip
in
on
that
front,
I'm
kind
of
curious.
A
You
know
and
I
want
to
ask
you
again.
So
you
know,
have
you
ever
run
into
situations
or
you
know,
even
based
on
your
state
of
open
source
security
report
where
developers
are
kind
of
pointing
to
one
another
and
saying
like
hey,
you're,
responsible,
you're,
responsible
and
never
really
like
taking
care
of
the
thing
just
like
is
that
show
up
in
your
report?
I
think.
C
C
A
C
C
Sign,
it's
really
good
sign
the
the
people
take
it
seriousiy
and
it's
also
really
great
to
see
things
like
having
a
security.
Dome
defaul
really
increases
like
by
a
massive
proportion.
The
number
of
reports
that
you
will
get
versus
not
having
one
at
all,
but
as
soon
as
you
could
put
a
security
md
file
up,
then
you're
going
to
get
much
more
private
disclosure,
as
opposed
to
tweets,
saying
that
your
code
is
vulnerable
and.
A
C
A
bit
of
a
trickle
effect,
we've
got
$0.78
of
vulnerabilities,
are
in
direct
indirect
dependencies,
so
not
your
direct
dependencies.
It's
the
other
packages
that
use
so
it
needs
more
kind
of
people
taking
ownership,
more
people
auditing
their
code.
They're
like
it's
Nick.
We
have
a
plugin
for
ideas.
We
have
you
know
CI
tools,
we
have
a
CLI
there's
every
single
stage
of
the
development
lifecycle.
We
have
a
way
for
you
to
monitor,
find
and
fix
vulnerabilities,
and
that's
that's
crucial.
We
can't
have
it
like
I.
Imagine
the
most
of
you
in
the
audience
work.
B
C
Security
team
can't
be
just
blocking
bills,
you
know
they're,
not
they
don't
want
to
be
the
gatekeeper
they
want
to
be.
They
want
to
be
the
superheroes,
not
the
villains,
whereas
developers
want
to
feel
empowered.
You
know
they
own
the
code.
They
don't
want
some
telling
them.
No,
you
can't
merge
this.
C
A
C
It's
really
important
for
those
developers
who
aren't
confident,
and
you
know
that
70%
of
open-source
maintainer
x'
he
said
they
don't
feel
confident
fixing
vulnerabilities
in
their
code
that
they
have
the
tools
in
place.
I
mean
that
they
don't
have
to
have
that
knowledge
it
just
it's
self-healing
it
does
it
for
them.
I
think
that
is
the
only
way
we're
going
to
get
kind
of
reducing
the
vulnerabilities
and
code.
Okay.
A
E
E
And
I
would
like
to
underline
that
just
you
know
those
those
teams
and
those
quotes
in
our
case,
if
they
don't
own
the
service,
the
code,
then
this
is
just
a
job
for
them,
but
we
want
them.
We
want
to
change
parts
of
the
world
and
we
want
them
also
to
be
with
us
on
the
journey
and
with
their
service
to
help
us
to
change
parts
of
the
world,
and
once
this
ownership
applies,
then
that
there
is
no
finger-pointing.
There
is
no
question.
Is
it
yours
or
is
it
my
problem?
E
They
come
up
with
so-called
tech
talks,
so
there
are
bi-weekly
iterations,
where
the
whole
team
meets
together
and
we'll
talk
about
all
those
technical
aspects.
That
may
not
be
so
much
focus
on
when
talking
about
business
requirements
and
so
on
and
so
forth,
and
this
is
this
is
the
squad's
way
to
make
sure
all
those
technical
considerations
are
also
end
up
in
tickets,
as
well
as
business
requirements
to
end
up
in
tickets
and
have
to
be
provided
by
school
on
an
ongoing
basis,
understood.
A
D
D
So
these
teams
get
get
notified
and
it's
it's
a
good
good
process
for
the
team,
because
then
they
can
work
it
into
the
sprint
planning
and
so
on.
Then
there's
the
more
critical
things
which
actually
reaches
into
production
actually
reaches
our
in
customers
and
our
security
operations
center
work
with
companies
like
hacker
one
and
pentesters,
and
we
discover
these
a
lot
of
these
vulnerabilities
ourselves
and
then
it
goes
through
like
an
internal
process
saying
this
is
this
is
affecting
our
customers
affecting
customer
trust,
so
this
must
be
fixed,
so
those
it's
like
a
hard
mandate.
D
So
that's
not
a
lot
of
finger-pointing
here.
It
just
must
be
fixed,
so
I
think
remediation
is
is
interesting
in
itself,
but
first,
that's
rather
simple,
because
it
just
must
be
done.
I
think
for
us.
The
more
interesting
question
is:
how
do
you
avoid
getting
to
that
point?
How
can
you
be
more
proactively
aware
about
what
is
when
you
adopt
the
dependency?
D
For
instance,
if
you
look
at
an
open
source
dependency,
that
typically
happens
in
the
team
itself,
they
have
complete
autonomy
to
do
so,
and
they
typically
go
on
and
github
and
they
look
at
the
project's.
They
look
at
the
readme
and
say
this
looks
nice
and
then
they
adopt
it
and
it
becomes
part
of
what
they're
building
and
then
it
goes
into
production.
And
then
the
alerts
start
coming
so.
D
And
I
think
I
think
the
again
I
would
also
like
to
mention.
The
keynote
is
very
nice
to
see
things
are
getting
done,
but
I
think
the
key
thing
that's
missing
here
is
to
be
able
to
assess
this
before
you
adopt
the
dependency
developers
have
very
little
knowledge
and
very
little
noise
is
exposed
to
them
when
they
look
at
a
project
on
github.
It's
all
about
all
the
great
things
that
it
can
do,
but
it
doesn't
actually
talk
about
the
risks.
So
a
developer
is
not
really
in
a
position
to
assess
the
risk
of
it.
D
Dependencies
he's
about
to
well
depend
on
and
live
with
for
a
long
time.
So
I
think
that
that
that
part
is
still
missing
and
well
I
think
here
the
only
actor
in
the
open
source
world
that
can
do
that
and
lift
that
burden.
It
is
github
because
you
are
very
central
piece
of
that
ecosystem
and
could
provide
this
information.
Yeah.
A
I
mean
I
think
the
way
that
we
look
at
it.
Its
github
is
like
you
know
we
yeah.
We
can
be
central
to
a
lot
of
where
the
developer
works
like,
and
you
know
my
you
know
interests
especially
along
the
entire
software
development
lifecycle
right.
But
you
know
there
are
things
and
other
companies
that
provide
services
as
well,
that
can
plug
into
that
entire
lifecycle
that
we're
still
very
important
to
making
sure
developers
can.
A
D
And
this
is
not
to
say
what's:
Nick
is
doing,
is
not
good.
It's
great
I,
just
think.
I
would
just
love
to
know
these
things
way
earlier.
Then,
when
it
gets
into
my
CI
I
would
love
to
have
that
developers
have
this
knowledge
before
they
actually
do
npm
install
that's
where
I
think
that's
the
most
valuable
thing,
the
longer
you
get
into
the
developer
journey,
the
more
expensive
will
it
be
to
fix
these
security
issues
they'll
pop
up
eventually.
C
A
I
think
you
should
be
talking
if
you're,
not
a
customer,
you
might
want
to
figure
okay,
so
Tracy
I
want
to
ask
you
again
so
I
want
to
go
to,
like
you
know,
kind
of
the
broader
community.
Are
you
noticing
any
trends
you
know
regarding
security?
Like
you
know,
it's
been
a
hot
topic
and
you
know
given
today's
keynote,
it
was
one
of
the
three
pillars
that
we
had
up
there.
A
B
I
think
we
have
to
acknowledge
that
up
to
now
the
way
as
an
industry
we've
dealt
with
security
has
been
just
a
trash
fire.
It's
just
horrendous,
so
I
think
it's
really
good
that
we
are
having
these
conversations.
I.
Think
the
the
fact
that
people
are
starting
to
highlight
it
is
it's
a
good
start,
but
there's
a
lot
of
ground
to
make
up,
but
again,
as
we're
saying
it's
getting
more
professionalized,
which
is
good,
I
think
once
we
start
doing
that,
then
we
start
saying:
okay.
B
Well,
how
do
we
do
this
and
then
it
comes
down
to
you
know
open
source,
and
how
are
you
going
to
fund
the
people
who
are
maintaining
it
so
I
think
that's
the
other
side
of
it.
You
know
just
making
sure
all
these
open
source
projects
which
we
depend
on
can
be
sustained
in
the
face
of
you
know
these
vulnerabilities
with
ticking
clocks
and
software
in
everything
so
I
think
it's
a
good
start
and
I
think
if
we
keep
going
like
taking
it
seriously
and
working
together,
it
just
has
to
happen
that
way.
So.
A
C
It's
really
great
what
github
is
doing.
It's
really
important
that
security
becomes
kind
of
the
default
like
you
have
to
go
in
and
turn
off
the
alerts
you
you
they
were
on
by
default.
It's
telling
you
about
them.
I
think,
there's
still
a
way
to
go
and
like
what
I
said
earlier
about
transitive
vulnerabilities
so
for
an
ability
to
are
in
your
indirect
dependencies
as
well
as
making
sure
that
we
don't
make
it
too
noisy.
So
if
we
make
it
too
noisy,
then
people
will
turn
it
off
or
they'll
ignore
it.
C
A
C
I
had
like
the
stats
off
the
top
of
my
head,
but
generally,
if
it's
not
actionable,
then
people
went
to
do
anything
about
it.
I
would
love
to
hear
that
we're
saying
earlier
about
all
of
the
kind
of
issues
that
have
been
opened.
All
of
the
kind
of
notifications
that
they'd
send
about
vulnerabilities,
I'd
love
to
know
how
many
of
those
were
actually
resolved
afterwards.
C
So
I
think
as
long
as
you
make
it
easy
as
long
as
it's
kind
of
just
part
of
the
life
cycle,
either
you
click
on
a
button
to
fix
it
or
it
just
fixes
itself
opens
pull
requests.
That
sort
of
thing
then
I
think
it's
going
to
it's
got
more
chance
of
catching
on
and
being
kind
of
the
standard
part
of
developers,
workflow
and.
D
I
get
the
Lando
engineering
teams
are
largely
autonomous
about
how
they
prioritize
their
work,
but
there
is
a
shared
understanding
that
Security's
importance.
It
does
assist
among
the
teams.
How
are
you
going
to
attack
these
problems
but
yeah?
If
we
have
something
that
has
customer
impacts,
then
it
is,
is
priority
one.
That's.
A
D
They
don't,
and
that
is
the
only
honest
answer.
We
don't
have
a
company
policy
that
says
like
prioritize
all
books.
We
don't
have
that
we
try
to
do
in
a
different
way
saying
when
you
have
a
project
like
this
sighs.
What
is
the
time
you
need
for
this?
How
much
time
do
you
want
to
privately
have
for
this,
like
in
company
time
to
make
sure
that
it
gets
done?
Then
it's
your
responsibility
to
maintain
it,
but
we
grind
you
the
time
to
do
it
and
the
resources,
so
you
can
do
it
in
company
time.
D
A
D
Yeah,
that
is
the
answer,
because
it's
only
the
team
who
can
actually
assess
it
properly.
It's
also
the
team
that
know
the
context
of
their
projects.
It's
also
the
team
that
knows
their
entire
backlog
and
the
importance
of
that
area
of
the
business.
So
it
must
be
up
to
the
team
again
certain
level
it
must
be
mandated.
There
are
certain
things:
that's
too
important
to
be
ignored,
but
again
it
is
the
team's
responsibility
to
take
care
of
this.
D
D
A
My
like
umbrella
perspective,
so
even
though
we're
saying
you
know
it's
your
responsibility
developer
to
go.
Do
this
thing.
There
are
still
like
processes
that
exist
that
you
know
you
kind
of
look
at
these
things
and
say
you
know,
based
on
these
variables
or
characteristics
it
kicks
off
another
conversation
which
I
think
from
a
product
manager
perspective
that
says.
Oh,
maybe
I
should
prioritize
this
thing
for
the
team,
because
you
know
we
are
getting
called
out
on
this
and
maintainability
is
in
question
yeah
and.
D
E
Yes,
but
for
me
it's
all
about
context
and
options
right,
so
I
don't
see
a
distinction
between
the
product
manager
and
the
team.
I
think
he's
part
of
the
team
right
and
he
he
should
his
or
her
view
on
security
or
business
features,
and
it's
for
the
team
about
options.
So
in
case
there
are
even
lower
lower
prioritized
bugs
like
bugs
to
be
privatized
not
taken
care
of.
E
This
will
have
consequences
and
the
team
should
be
aware
of
the
consequences
and
should
deal
with
them,
and
you
should
also
take
responsibility
in
the
ownership
about
either
the
consequences
of
fixing
or
not
fixing
it,
and
this
is
part
of
the
ongoing
engineering
effort
that
happens
hopefully
in
every
company,
and
so
this
is
the
way
we
we
try
to
do
that
and
in
terms
of
context.
I
want
to
add
another
perspective,
which
is
zero,
friction
and
seamless,
and
I
mentioned
that
already
so
those
developers
I,
observe
and
I
work
with
their.
E
There
are
mainly
working
in
free
environments,
it's
either
the
terminal
or
their
IDE,
or
the
source
code
management
system,
and
we
and
I
try
to
reduce
the
context
switches
as
much
as
often
so
I
try
to
not
approach
them
in
person,
I
try
to
select
them
and
they
pick
up
the
slack
message
whenever
it
feels
appropriate
for
them
same
with
security
alerts.
Right.
Imagine
those
happen
in
the
context
that
you
are
working
on.
You
don't
need
to
go
to
a
certain
website
or
to
some
service
to
do
experience.
Those,
and
there
are.
E
There,
was
so
frictionless
actionable
that
you,
maybe
just
do
one
click
or
you
to
just
issue
one
command
and
10
of
those
gets
fixed
by
reasonable
recommendations.
This
is
this:
is
the
division
I
have.
This
is
even
a
I
see
that
vision
and
happening
today,
with
with
the
news
today
and
I,
see
even
more
steps
to
what
as
seamless
fully
integrated
options
for
for
the
engineers,
hopefully
having
soon
okay.
A
D
Yes,
I
think
the
topic
of
security
fits
into
the
larger
story
about
open-source
sustainability
as
well.
A
lot
of
the
securities
that
we
see
is
also
because
maintainer
lose
interest
or
don't
have
the
time
and
don't
have
the
resources
to
maintain
the
projects
that
all
of
us
depend
on
so
I
think
not
just
security,
but
sustainability
of
open
source
and
general
is
important
in
this
aspect.
I
think.
B
A
Takeaway
from
today's
panel
is
I've
learned
that
there's
a
bunch
of
intrinsic
or
extrinsic
levers
for
folks
that
you
know
on
this
path
of
security
that
you
can
use
as
an
engineering
matter,
eat
engineering
managers,
developer
yourself
or
even
within
the
community,
to
say:
hey,
there's
some
things
that
you
can
do
and
by
doing
X.
You
know
this
is
the
outcome
on
the
other
side
right
and
then
the
other
part
of
this
is
like
really
reducing
friction
and
helping
developers
understand
and
assessing
risk
earlier
on,
and
the
software
development
lifecycle.