►
From YouTube: Always Allow for Deploying to Production
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
what
we
had
a
couple
of
times
is
where
there's
a
customer
asked
and
it's
about
he.
We
want
to
make
sure
that
we
don't
have
any
vulnerabilities
in
our
production
environment.
Great
like
get
life
should
help
you
do
that.
He
please
make
sure
that
as
soon
as
there's
a
vulnerability,
people
cannot
deploy
the
code
on
their
production
environment.
Like
oh,
that's,
that's
a
very
different
thing
and
it's
important
to
realize.
There's
two
completely
different
things.
For
example,
you
might
have.
A
Detect
a
vulnerability
when
there's
really
not
no
vulnerability,
it
might
also
be
that
you're
not
making
this
situation
worse.
Suppose
you
have
a
library
now
that
has
a
hundred
or
two
known
vulnerabilities
and
you're
changing
something
else
not
related
to
that,
and
now
it
will
block
you
from
doing
that.
So
there's
a
difference
between
kind
of
the
vulnerabilities
and
increasing
vulnerabilities
might
also
be
a
case.
A
We
use
a
library,
let's
say
for
regular
expressions
and
there's
like
an
attack
in
the
wild
that
you've
heard
about,
like
all
the
mailing
lists
are
read
hard
because
hackers
are
exploiting
this
and
you're
replacing
it
for
another
library
and
that
this
is
fresh,
fresh
news
make
the
vulnerability.
Isn't
that
there's
not
even
a
scientist
CV
eat
number
yet
or
maybe
it
is,
and
there
was
a
known
vulnerability
and
the
new
library
you
want
to
use
has
even
more
known
vulnerabilities.
This
is
five
of
them,
but
the
risk
is
way
lower
to
the
organization.
A
So
it's
still
a
right
action
to
kind
of
do
that
I've
I've,
seen
occasions
where
a
website
was
down
and
then
the
was
taken
down
because
of
a
vulnerability
in
the
software
and
after
updating
the
vulnerability
the
QA
tests
had
to
run.
But
at
that
point
the
the
website
was
down
like
nobody
could
use
it.
They
could.
A
A
Every
time
we
get
to
request
like
hey,
make
sure
that
XYZ
always
happens.
We
should
understand
what's
behind
that
request,
and
we
should
make
sure
that
we
that
we
do
the
best
thing.
We
don't
necessarily
do
what
the
customer
asked
for,
but
we
do
what
the
customer
whoa
most
what's
the
best
solution
for
most
of
our
customers,
because
some
some
things
are
easy
to
configure
in
a
way
that
will
require
people
to
work
around
the
tool
and
that's
that's
one.
We've
lost
like
as
soon
as
people
start
working
around
github.
A
We
have
a
problem
and
in
almost
all
cases,
I
see
the
best
solution
was
give
people
a
dashboard
like
warned
them
still
allow
them
to
override
but
give
tippy
give
people
a
dashboard
like
make
it
visible
throughout
the
organization
what
the
statuses
of
things!
So
that's
why
I
want
this
conversation?
I've
thought
I've
seen
a
couple
of
requests
like
hey,
we
really
need
to
enforce
XYZ
I've,
given
Intuit
got
a
major
financial
institution
that
asks
for
hey.
A
Let's,
let
us
do
that
and
it
turned
out
that
the
end
goal
was
compliance
great
we're,
adding
compliance
management
and
get
live.
We're
gonna
do
a
great
job
of
it
and
it's
gonna.
Allow
them
to
do
a
lot
less
themselves,
so,
most
of
these
times
the
the
CI
jobs
people
asking
for
a
work
around
for
some
other
need.
They
have
so
I'd
love
to
discuss
those
needs
because
I've
looked
through
the
issue
and
all
I
could
find
was
they
need
to
run
the
CI
job
in
the
sentence.
A
So
the
question
is
like:
why
do
they
need
to
run
the
CI
job?
And
let's
figure
that
out
and
let's
solve
the
the
underlying
problem,
because
I'm
forcing
that
CI
job
might
have
a
ton
of
unforeseen
consequences?
And
it's
almost
a
thing
that
we
might
not
never
want
to
ship
in
get
map,
because
it's
an
easy
thing
to
turn
on
for
one
person.
But
there
might
be
hundreds
of
people
suffering
throughout
the
organization
because
of
it
and
people
might
start
hating
our
tool.
B
Yeah,
those
are
all
really
valid
points.
Thank
you
for
detailing
that
the
I
think
what
might
be
helpful
is
to
your
point
looking
at
why
customers
are
asking
us
for
these
kind
of
enforced
jobs,
and
it
does
ultimately
come
down
to
a
compliance
posture
of
some
sort,
the
customer
that
you
referred
to,
the
financial
one.
B
A
Reports
that
sounds
like
something
we
should
so
fit:
compliance
and
gitlab.
So
I
think
that
sounds
like
something
we
should
add
to
that
to
get
lab
regarding
the
scans.
What
what
I
see
and
I
realized
I'm,
not
talking
to
the
security
testing
team
here
Gilliam
has
is
like
hey
here.
Are
the
products
with
low
vulnerabilities,
medium
vulnerabilities,
hi
Ron
abilities,
there's
something
missing
there
and
what
is
missing?
There
is
here's.
A
The
projects
that
didn't
get
scanned
in
the
first
place,
that's
even
worse
than
a
high
vulnerability,
because
it's
a
have
an
ability
that
no
one's
seen
so
that
should
be
front
and
center
and
right
now
it's
not
so
that
should
be
in
our
security
sense,
the
second
thing,
but
our
security
scans.
They
give
you
a
count
how
many
security
vulnerabilities
do
you
have?
That
is
not
as
actionable
as
giving.
This
is
how
long
these
security
vulnerabilities
existed
in
the
product.
If
you
have
to
choose
which
one
you
show
you
should
choose,
how
fast
you
respond.
A
A
But
it's
you
will
have
things
you
have
to
remedy
it's
all
about
with
the
speed
with
which
you
do
that
the
companies
that
get
hacked
it's
not
because
one
had
zero
vulnerabilities
and
the
other
one
had
a
thousand
it's,
because
what
is
the
speed
to
remediation
the
best
hacker
one,
our
book,
but
crowd
programs
are
not
the
ones
that
find
zero
vulnerabilities,
the
best
ones.
Are
that
solve
it
quickly,
so
we
should
show
how
faster
solve.
So
that's
regarding
the
security
scans.
We
have
functionality
for
this.
A
You
should
make
sure
that
the
customer
is
able
to
plug
those
scanners
in
and
we
show
this
security
posture
and
if
the
scans
didn't
happen,
that
should
be
higher
than
the
highest
priority.
That
is
a
really
bad
thing.
Fine,
it
does
not
the
same
as
blocking
a
release,
because
if
your
external
security
scanner
is
down
and
the
market
is
failing-
and
you
need
to
deploy
something-
if
not
deploying
for
30
minutes-
can
wreck
companies.
So
in
the
end
most
of
the
things
are
people
game,
and
it
should
never
be
the
computer
over
people.
A
A
To
a
simplistic
way
of
thinking
about
this,
because
then
we'll
make
more
book
will
end
up
exactly
as
all
the
other
deaf
sack
up
stools
and
we
go
into
any
company
and
we
ask
okay,
you
got
the
dev
cycle,
what
percentage
of
products
did
you
brunette
and
for
almost
all,
customers
is
less
than
10%
of
the
projects?
That's
how
we'll
end
up
as
good
lamp.
If
we
do
things
like
this.
B
A
That's
h,
total
sense
like
we
already
have
get
lab
scans
and
we
should
add
functionality
like
if
the
scan
didn't
run.
That's
the
worst
thing
is
worse
than
high-priority
items
and
they
should
be
able
to
say
well.
I
don't
only
want
these
good
laps
cancer
and
I
also
want
this
other
scan
to
run
and
we
should
put
that
on
the
same
footing.
I
think
it's
an
ultimate
feature
to
add
external
fans
scans,
but
that
should
be.
We
should
allow
for
that
and.
B
And
so
my
my
understanding
to
this
point
is
that
you
know,
let's
say
that
we
add
this
ultimate
feature
that
allows
for
the
incorporation
of
these
external
scanners
or
scans.
Rather,
if
a
customer
says
I
want
to
add
this
is
do
you
envision
that
this
is
still
a
reporting,
only
thing
where
I've
added
my
external
scan.
This
job
occurs
for
each
pipeline
and
I
have
an
output
in,
let's
say
the
security
dashboard
and
that's
kind
of
the
end
of
it
like
we're
still
moving
away
from
this
enforcing
that
scan
in
some
way.
A
C
I
was
gonna
jump
in
there,
real,
quick,
just
and
and
thanks
so
much
are
you
saying,
don't
don't
block
the
deploy
to
production,
but
if
it,
if
it
requires
like
four
compliant
I,
mean
for
for
regulation
purposes,
it
requires
this.
You
know,
particular
this
has
to
run
for
auditing
purposes.
We
have
to
be
able
to
show
that
it
ran
XYZ.
A
Almost
every
auditing
thing
will
have
a
yes,
but
there's
there's
a
manual
over
there's
an
overwrite
that
is
possible,
so
maybe
you
need
an
extra
sign-off
just
like
we
need
one
more
approval.
I,
don't
think
any
auditor
will
sign
off
on
like
look.
If
this
tool
is
down,
you
cannot
deploy
to
production.
That
would
be
foolish.
A
There
are
companies
in
the
financial
sector
that
didn't
have
their
CD
pipeline
in
order
that
went
broke
in
30
minutes
because
they
couldn't
replace
the
code
they
they
deployed.
That
was
full
of
errors.
We
can
never
have
get
lab.
Is
the
solution
to
that
and
I
refuse
to
enter
into
a
possibility
that
get
lab
would
be
the
cause
of
that.
B
Yeah
I
think
that's
totally
fair
and
I
agree
with
the
sentiment.
I
guess
I'm
still
trying
to
figure
out,
because
if,
if
a
company
says
hey
here's,
what
we
do
and
one
of
those
things
is,
we
scan
every
change
that
is
made
to
production
if
they're
kind
of
to
Dave's
point.
If
there
are
gaps
in
that
process,
and
the
auditor
says
why.
Why
was
this
cannot
perform
in
this
particular
merger
quest
like
well,
because
we
don't
have
the
ability
to
force
that
for
every
merger
quest
so.
A
C
A
A
B
A
So
the
the
the
reason
they're
asking
for
pipelines
is
because
that's
how
they
do
it
now,
so
we
need
to
change
how
we
talk
about
these
things
and
we
cannot.
It
cannot
be
like
oh
I,
ask
the
customer
awesome
whether
they
really
needed
this
and
they
said
yeah.
They
really
need
this.
That's
not
a
fruitful
conversation
have
to
dive
in
and
think.
Why
do
you
need
this?
How
are
you
solving
today?
What
are
the
audit
requirements
if
we
don't
end
up
talking
to
their
auditors
at
some
point,
we're
doing
it
wrong.
B
Yeah
I
think
those
are
points,
I
think
it's
definitely
worth
and
there's
still
some
work
to
be
done
digging
into
the
parts
of
the
requirements
that
they
have
as
far
as
those
specific
scans
or
reports
and
in
those
types
of
functions,
I'm,
confident
that
we'll
be
able
to
solve
half
or
part
right
part
of
those
requirements.
But
it's
that
other
half
that
it
sounds
like.
We
need
to
do
some
additional
digging
on.