►
From YouTube: Sec PM / Security Department Monthly Sync Up
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).
B
The
first
one
is
really
just
an
fyi.
Last
quarter.
We
there's
a
couple
of
projects
that
are
newer,
that
we
didn't
complete,
but
last
quarter
we
had
as
like
a
kr
to
integrate
all
of
the
secure
products
into
repos
as
appropriate,
depending
on
you
know
where
they
fit,
and
we
got
that
done
this
quarter.
Our
new
guy
michael,
is
going
to
be
he's
working
on
getting
secret
detection
in
since
it
was
split
out.
B
So
we
have
pretty
good
coverage
and
a
in
about
15
to
20
repos
that
feed
directly
into
omnibus
with
all
of
the
secure
products
in
them.
So
that's
just
a
heads
up
there.
The
second
one
is
package
hunter,
which
is
a
product.
You
know
a
project
that
dennis
has
been
working
on
to
do
dynamic,
malicious
dependency
detection.
B
I've
linked
a
number
of
things,
the
main
link
there
is
his
his
kr
issue
for
the
quarter,
but
what
he
did
last
quarter,
but
what
he
did
last
quarter
was.
He
was
able
to
integrate
it
into
the
pipeline,
so
it
runs
on
master
now
and
actually
gets
feeds.
The
data
into
the
dashboard
as
dependency
scanning
unknown
right
now.
B
This
is
just
a
really
cool
thing
that
he's
been
working
on.
It
extends
our
current
dependency
dependency
scanning
and
that
it
allows
you
to
identify.
You
know
new
packages
that
might
be
that
might
have
been
taken
over
or
something
like
that.
This
quarter
he's
he's
really
working
on
proving
out
and
validating
that.
You
know
this
will
help
catch
things.
The
latest
package
that
was
released
the
twilio
and
pm
package.
B
It
would
have
caught
that
if,
if
we
had,
you
know
if
we
had
tried
to
install
the
package
at
the
time,
so
it's
not
quite
like
you
know
to
you,
know
operational
product
readiness
state
yet,
but
I
did
want
to
bring
it
to
your
attention
because
it
it
can
be
a
differentiator
for
gitlab
there.
There
aren't
too
many
products
out
there
that
are
doing
real-time
analysis
of
dependencies
to
identify
them.
So
I
just
wanted
to
get
that
in
front
of
you
and
answer
any
questions
you
might
have
now.
B
If
you
have,
some
dennis
did
give
a
demo
monday,
olivier
guns,
from
composition,
analysis.
He
was
there
and
asked
some
questions
and
stuff
so
he's
looking
at
it
a
little
bit.
The
demo
also
shows
like
how
it
runs
and
stuff
like
that.
So.
B
So
what
like,
I
said
this,
this
quarter,
we're
sort
of
focusing
on
validating
it.
We
do
know
that
it
like,
especially
if
things
are
making
like
outbound
calls
network,
calls
that
it
definitely
works
it.
Doesn't
it
it
really.
You
know
it
focuses
on
things
that
are
run
at
like
install
time
so
either
like
post
pre
or
post
install
scripts.
B
So
if
it
has
some
tricky
magic
in
it,
that
only
runs
in
certain
environments.
You
know
under
certain
conditions,
then
that
would
fall
back
to
the
protect
stage
in
the
real
time
analysis,
but
this
is
really
to
help
identify
things
before
they
get
to
you
know
a
production
or
an
environment
at
all,
so
yeah.
B
C
Point
just
a
quick
question:
did
you
have
you
talked
with
the
dependency
proxy
team
at
all,
because
it
sounds
like
this
technology
that
you're
working
on
would
fit
really
well
into
that
solution.
B
We
have
not
that's
a
good
idea.
I
hadn't
thought
of
that.
B
Okay,
yeah
we've
talked
about
different
ways
with
felipe
about
different
ways
that
it
might
be
productized
like
right
now,
it's
just
sort
of
run
in
a
pipeline
as
just
another
job,
but
you
know
here:
we've
had
philippe
has
talked
a
little
bit
about
like
just
having
a
back
end
service
that
monitors
the
dependency
repos
and
has
a
database
of
this
sort
of
stuff.
You
know
maybe
using
that
so
yeah
I'll
reach
out
to
dependency
proxy
as
well.
D
I'm
adding
one
more
issue
to
the
discussion
at
the
bottom
of
the
thread
here
we
are
discussing
of
also
using
what
we
use
for
container
security
in
protect
akf
fileco
to
automatically
monitor
the
behavior
of
the
containers
that
we're
going
to
push
to
production,
not
sure
we're
going
to
be
able
to
talk
food
because
we're
not
using
any
gitlab
manage
apps
to
deploy
to
production,
at
least
the
gitlab
project.
D
A
Yeah,
so
thanks
for
that
update,
that's
great
to
know,
I'm
wondering
if
this
would
be
a
good
place
to
dog
food,
the
approach
where
we
just
provide
security
in
the
cluster.
A
D
So
actually,
the
missing
piece
in
there
is
not
actually
how
to
manage
falco
on
or
or
how
to
set
a
falco
in
the
gitlab
instance,
but
more
like
how
do
we
manage
the
alerts
that
falco
will
raise
we're
going
to
have
a
lot
of
alerts,
especially
when,
when
we
start,
because
we
have
no
idea
of
the
the
behavior
the
expected
behavior
of
the
application?
So
we
expect
to
have
a
lot
of
first
positives
and
we
need
something
to
manage
all
of
this.
D
So
I
guess
for
me
the
missing
part
here
would
be
a
way
to
gather
all
dialogues
in
a
single
place
could
be
a
dashboard
or
something
like
that,
but
at
least
having
this
ability
to
try
all
of
this
and
manage
that
pretty
much
like
vulnerabilities.
But
it's
not
exactly
the
same,
because
this
is
more
real-time
than
what
we
would
do
with
vulnerabilities.
A
Yeah,
so
we've
been
working
on
an
alert
dashboard
to
do
that
exact
thing
I
don't
know
if
you've
been
following
this
at
all,
but
we
would
love
to
get
feedback.
So
I
was
not
aware
that
this
was
under
consideration
in
the
security
team.
A
The
individuals
that
I
talked
with
seemed
unaware
of
it
when
we
reached
out,
but
it's
a
big
team,
I'm
sure
I
just
reached
out
to
the
wrong
group
of
people.
So
if
there
are,
if
those
discussions
are
happening,
I
would
love
to
be
a
part
of
them
we're
working
on
a
dashboard
to
help
triage
those
alerts.
Right
now,
awesome.
D
Yeah
we
haven't,
we
haven't
reached
out
to
you,
because
this
is
just
from
this
week
we're
just
starting
to
think
about
it
with.
I
personally
thought
it
was
more
for
the
seer
team,
so
the
previous
security
operations
team,
but
apparently
it's
going
to
fall
under
upset.
It's
correct
me
if
I'm
wrong
there,
but
we
have
someone
that
might
work
on
that
very
soon.
Right.
B
Well,
I
think
like
when
it
becomes
operational.
Real-Time
analysis
will
be
under
cert
because
they'll
be
the
ones
consuming,
but
it
will
be
a
partnership
that
the
proving
you
know
finding
what
works
for
us.
You
know
trying
things
out
or
probably
going
to
be
a
partnership
between
appsec
for
sec,
research
and
cert
it'll
be
a
cross-team
sort
of
thing.
A
Okay,
great
well
as
soon
as
you
have
individuals
that
are
whoever's
thinking
about
that,
and
if
they
can
share
feedback
on
that
alert
dashboard,
we
would
love
to
hear
it.
Please
connect
them
with
me
or
you
know
either
send
me
their
names
or
they
can
just
schedule
a
meeting
on
my
calendar
or
whatever's
convenient.
D
E
Cool,
I
guess
the
next
one,
one's
mine,
just
kind
of
a
question,
the
app
tech
office
hours
are
those
still
a
thing.
It's
on
my
calendar.
I
imagine
that,
because
it
auto
records
there's
at
least
a
couple
of
the
youtube
videos
of
just
me
popping
in
and
then
immediately
shutting
my
camera
off
for
four
minutes.
B
Well,
within
security,
they
sort
of
changed
it
to
be
like
a
security
department
office
hours.
So
we-
I
is
it
on
the
team
calendar
because,
like
it's
off
of
my
calendar,.
B
Think
so
you
know
we
we
actually
don't
have
it
every
two
weeks
anymore
with
that
said,
that's
a
good
data
point
to
know
that
someone
is
joining,
and
maybe
you
know
like
the
idea
was
that
what
was
happening
was
like
each
team
was
having
their
own
office
hours
and
no
one
was
going
to
any
of
them
ever
and
so,
and
so
as
a
department,
we're
sort
of
like
well
let's,
why
don't?
B
We
have
like
a
security
office
hours
at
some
point,
but
I
need
to
figure
out
when
that
the
next
one
is
going
to
be.
I
know
it's
less
frequent,
but
with
that
said,
like
you
know,
if
there's
like
you
know
particular
questions
or
something
like
that,
please
pop
into
the
appsec
channel,
you
know
and
we're
you
know
we
can
always
engage
from
there.
If
we
need
to
have
a
call,
we
can
do
that
too.
You
know.
E
Yeah,
it
was
actually
quite
the
opposite.
I
was
using
that,
as
I
know,
we
had
had
some
really
good
feedback
from
your
team
when
there
was
a
light
agenda
in
the
past,
so
I
was
more
sort
of
joining
to
hear
what
the
questions
were
and
be
available
for
any
feedback
or
questions
from
your
team.
I
guess
hilariously.
If
that
meeting
got
deleted,
the
zoom
certainly
still
works,
as
does
the
auto
record.
B
D
A
D
D
D
A
Well,
I
guess
sam
looks
like
you
got
the
last
one,
all
right
so
yeah.
This
is
a
lower
priority
and
it's
only
a
subset
of
the
people
here.
So
if
you
want
to
drop
off
till
through
to
but
ethan
and
philippe,
I
just
wanted
to
run
this
by
you.
This
is
a
discussion
that
matt
and
I
have
been
having
for
a
while
and
figured.
It
wouldn't
hurt
to
get
your
input
on
this
right
now,
they're
kind
of
when
we
think
about
vulnerabilities
and
findings.
A
Most
of
what
we
do
in
gitlab
today
are
application
vulnerabilities,
where
they're
actually
in
the
code
in
some
way,
shape
or
form.
You
know
we're
finding
things
that
a
developer
needs
to
go
fix,
so
whether
it's
a
fast
scan
or
a
dependency
scan,
or
what
have
you?
Those
are.
You
know
those
are
typically
things
that
we
identify
as
part
of
a
pipeline
job.
A
The
vulnerability
is
actually
in
code,
that's
in
the
repository
and
it's
a
developer
that
needs
to
fix
the
problem
on
the
other
end
of
the
spectrum.
We
don't
really
do
anything
around
this
today,
but
you
know
we
also.
There
are
also
vulnerabilities
that
belong
more
with
an
infrastructure
type
team
things
that
you
would
find
with
a
network
port
scan
against
your
production
environment,
or
you
know,
perhaps
a
misconfiguration
in
the
system
operating.
You
know
the
operating
system
of
your.
You
know:
production
server.
A
You
know
those
would
typically
belong
to
an
infrastructure
team
rather
than
a
developer
team,
to
fix
what
we're
trying
to
figure
out
right
now
is
there's
a
gray
area
where
some
vulnerabilities
might
be
discovered
in
a
production
environment,
for
example,
if
you
run
a
dash
scan
against
code
in
a
production
environment
and
get
some
results
there,
you
know,
what
do
you
do
with
those
findings?
Do
you
route
those
to
the
application
team?
You
have
those
the
infrastructure
team.
A
You
know
where
do
you
surface
those
up
in
gitlab
and
would
love
to
hear
your
unguided
thoughts
on
on
that.
B
Well,
I
would,
I
guess
I
would
always
have
them
in
the
security
dashboard.
The
problem
is,
is
that
different
teams
might
function
differently.
You
know
like
if
it's
true
full
devops,
then
the
developer
would
want
to
see
it
right
because
they
might
probably
are
in
charge
of
their
own
environment
whereas,
like
you
know,
if
there's
more
of
just
an
operations
team,
they
might
have
something
different.
I
don't
know
I
was
sort
of.
B
A
A
Not
all
customers
operate
that
way.
You
know,
and
some
have
even
years
of
a
gap
between
that
event
where
they
push
from
master
into
production,
and
so
there
can
actually
be
a
pretty
large
discrepancy
in
what
you
find
between
the
two
that
makes
sense
down
at
the
project
level
or
even
group
level
like
to
put
it
in
with
the
environments.
What
about
when
you
bubble
that
up?
You
know
if
you're
wanting
to
see
things
across
your
instance
of
that
nature.
E
From
the
groups
it's
something
different,
it
was
also
it's
probably
my
fault
poorly
named.
It's
not
actually
at
the
instance
level.
It's
at
the
root
group
so.
B
E
B
Well,
I'm
wondering
so
you
have
here,
you
have
like
a
security,
dashboard
vulnerabilities,
I'm
just
wondering
if
you
can,
like
you
know.
I
don't
know
if,
like
on
the
left
hand
side,
if
you
had
like
environments
as
well
or
something
like
that,
I
don't
know
how
you
would
do
it,
but
like
there
would
have
to
be
some
way
that
you
could
differentiate,
something
that
was
identified
or
is
in
you
know,
actually
running
as
opposed
to.
A
D
Sense
trying
to
match
that
with
the
current
process
that
we
have
because,
right
now,
if
we
have
a
bug
report
in
nike,
one,
for
example,
on
something
that
is
related
to
the
infrastructure,
that
would
land
definitely
in
the
gitlab
project
first
and
then
we
would
investigate
and
eventually
create
some
more
issues
or
some
more
merge
questions
various
projects
linked
to
that,
but
we
always
link
even
if
it,
if
it's
related
to
a
specific
environment,
especially
production,
we
always
want
to
link
that
to
a
portion
of
code
or
at
least
a
project.
D
So
it's
never
something
that
will
lie
somewhere
without
any
connection
to
what
we're
doing.
Even
if
it's
a
port
that
is
open,
that
is
not
to
be
supposed
to
be
open,
then
we
will
find
the
terraform
project
or
maybe
the
the
the
chef
portion
of
code
that
would
open
that
port
and
we
will
open
an
issue
to
fix
that.
So,
at
the
end
of
the
day,
we
always
have
an
issue
or
vulnerability
for
that
we
would
like
to
have
a
vulnerability
all
the
time.
D
That's
why
we
are
testing
this
perk
import,
but
it's
it's
a
kind
of
tedious
process
like
yesterday
we
had
someone
reporting
something
that
was
brought
to
us
and
to
our
attention.
That
was
a
problem
with
tls
and
the
first
part
of
the
workflow.
Is
you
need
to
open
an
issue?
So
we
are
this
person
is
opening
an
issue.
Then
we
will
create
a
vulnerability
based
on
that
issue.
We're
going
to
link
that
vulnerability
to
issue
so
we're
going
back
and
forth
in
the
process.
D
Instead
of
you
know,
going
downstream
from
vulnerability,
and
I
know
we're
going
to
be
able
to
create
vulnerabilities
directly
very
soon,
but
I
still
have
the
at
the
feeling
that
the
process
is
a
bit
more
complex
than
it
has
to
be.
D
With
this
duplication
of
vulnerabilities
and
issues.
That's
that's
not
easy,
but
yeah.
We
want
to
have
everything.
A
Yeah,
that
makes
sense,
I
mean
as
soon
as
you
start
scanning
production
environments,
though
you
know,
there's
always
a
chance
that
the
code
for
whatever
you're
scanning
does
not
reside
in
git
loud.
You
know
the
application
could
have
been
deployed
through
git
lab
or
could
just
you
know,
there's
a
myriad
of
ways
that
that
application
could
have
ended
up
in
production.
The
way
it
is
could
even
you
know,
come
from
get
lab.
A
You
know
three
years
ago
and
get
lab's
code
has
evolved,
and
so
it's
really
you
know
technically
it
might
point
back
at
a
three-year-old
commit
that
you
know
was
in
get
loud.
It
gets
really
tricky
to
map
that
back.
You
know
you
can
make
good
educated
guesses
if
things
are
tied
up,
but
you
can
always
associate
it
back
with
an
environment
because
that's
how
we
would
have
access
to
the
environment
in
the
first
place
to
scan
it,
but
it
becomes
really
tricky
to
start
tying
that
back
to
the
actual
code
in
gitlab.
D
But
you're
implying
that
the
different
environments
might
have
a
different
security
posture,
which
is
generally
not
the
case
because
they
are
sharing
the
same
configurations
exactly
so
this.
What
you,
if
you
spot
something
on
staging,
I
mean
you
should
probably
spot
that
on
on
production,
the
only
difference
would
be.
C
D
The
code
version
that
you're
running,
so
you
might
spot
something
a
bit
earlier
on
staging,
but
do
we
want
to
create
something
that
complex
in
the
process,
at
least
for
us,
I'm
not
sure
for
our
customers?
I
don't
know
how
many
different
environments
they
are
using
for
us.
The
staging
environment
might
even
disappear
in
a
few
years.
D
A
Sense,
well,
I
know
we're
coming
up
on
time,
thanks
for
your
feedback
in
that
area,
we're
trying
to
work
through
it
right
now,
we're
leaning
towards
some
sort
of
a
tabbed
approach,
probably
where
we
separate
out
the
vulnerabilities
that
came
from
production
versus
the
vulnerabilities
that
came
from
your
repository,
but
we're
working
through
it
right
now.
So
thanks
for
that
input,
I
appreciate
it.
B
No,
I'm
just
I'm
just
thinking
about
it.
It's
something
I
hadn't
thought
about
before
so
I
mean
yeah.
I
guess
that
would
be
one
way
of
doing
it
just
like
differentiating
by
tool.
You
know.
So.
If
a
tool
only
runs
in
the
environment,
then
you
could
have
like
operational
security
tools,
and
you
know
development,
security
tools
or
something
like
that,
but
also
would
also
help
just.