►
From YouTube: Sec Section PM / Field sync - January 2023
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
All
right
thanks
everyone
for
joining
our
monthly
at
this
point,
I
guess
would
be
the
secure,
slash,
govern
slash
field
team,
sync,
not
a
whole
lot
going
on
at
the
moment.
I
know
everybody
is
busy
with
many
early
your
things.
You
know
the
product
team
we're
scrambling
to
get
Gartner,
Season,
O,
analyst
AST.
A
Magic
quadrant
information
pulled
together
couple
of
things
to
note
here,
so
a
reminder
we
have
16.0
fast
approaching.
We
are
currently
in
the
15.8
milestone
with
16.0
in
currently
for
May
22nd,
that's
going
to
come
with
a
number
of
breaking
changes.
A
So
we
are
working
separately
with
the
alliance
team
to
make
sure
that
all
of
our
official
integration
partners
are
duly
aware.
So
deprecation
notices,
of
course,
went
out
earlier
in
the
year.
This
is
a
an
opportunity
for
them
to
upgrade
their
scheme.
As
we
do
know,
there
are
a
few
that
are
using,
in
some
cases,
some
pretty
old
versions.
A
This
is
more
important
for
if
you
have
any
customers
or
accounts
where
you
are
aware
that
they
may
have
integrated
a
tool
themselves
where
they
may
be
using
something
internally
if
they
have
been
ignoring
those
warnings
on
all
the
pipelines
where
they
have
the
old
schemas,
those
are
going
to
start
breaking
if
they
upgrade
to
16.0.
So
we
don't
want
anybody
to
be
caught
unaware,
something
to
keep
in
mind.
B
A
So
there
are
versions
of
gitlab
where
new
schema
support
has
been
introduced.
It's
just.
It
is
a
little
confusing
to
talk
about
16.0,
we're
deprecating,
the
14.x
schemas
and
going
to
the
15.0,
so
I
wanted
to
call
that
up.
But,
yes,
the
plan
is
going
forward,
so
this
is
also
the
first
time
where
we're
actually
doing
a
we're,
having
a
real
sort
of
defined
process
for
how
we're
adding
new
schema
support
and
deprecating
and
then
eventually
removing
old
schemas.
A
This
has
been
largely
an
effort
over
the
last
year
across
all
of
the
basically
all
of
sec
to
clean
up
some
of
the
data
challenges
that
we've
had
some
of
the
very
early
schema
reports
had
some
fields
that
maybe
didn't
make
sense
and
had
non-enforcement
of
certain
areas
which
cause
problems
when
it
hit.
The
database,
like
you,
know,
like
optional
null
values,
things
of
that
nature
so
going
forward.
A
What
we're
going
to
try
to
do
is
support
two
schema
versions
with
each
gitlab
major
version,
so
we'll
basically
have
current
and
then
one
back
or
if
we
introduce
a
new
schema,
we'll
maintain
support
for
the
previous
major
schema
version,
at
least
until
the
next
major
git
live
iteration.
So
we'll
have
this
kind
of
rolling
two
schema
support
window.
B
A
It's
it
is
not
so
the
reason
that
they're
separate
is
it
gives
the
analyzer
teams
the
flexibility
to.
If
we
need
to
add
new
things
to
the
schema
as
we
go
forward,
we
can
do
that
at
any
point,
with
really
with
any
git
lab
minor
release
as
long
as
it
is
a
backwards
compatible.
You
know,
non-breaking
change
things
of
that
nature,
so
we
can
evolve
gitlab
the
platform
and
then
the
security
formats
independently
of
one
another
from
a
versioning
perspective.
A
I
guess
we'll
always
have
to
maintain
that
parity
with
you
know
compatibility
of
the
platform,
but
this
is
probably
more
important
for
the
self-managed
customers,
especially
ones
that
are
not
taking
the
upgrades
frequently.
So
if
they
want
to
use
the
16.0
or
16.1
as
an
excuse
to
jump
forward
versions.
This
may
be
something
that
could
bite
those
folks
if
they
have
those
integrated
tools
that
are
not
on
the
latest
schema
formats.
If
they're
taking
the
gitlab
analyzers
when
they
hit
that
they'll
have
the
right
schema,
so
that
won't
be
a
problem.
A
C
I,
don't
believe
so
I
guess
it
is
worth
noting
that
we
released
the
browser-based
dust
analyzer
as
GA
in
the
previous
release
in
1507.
So
that
is
out.
It
is
not
the
default
for
das
right
now,
but
it
is
GA,
so
you
know
everybody
can
use
it
without
fear
of
it
being
in
beta,
but
otherwise
I,
don't
think
I
have
anything
else
to
call
out.
A
C
That's
a
good
question,
so
it's
enabled
via
an
environment
variable
in
your
gitlab
CI
yaml
file,
so
browser
base
set
it
to
true
browser-based
test.
I,
can't
remember
the
exact
variable,
but
it's
in
the
documentation.
We
also
updated
the
docs
to
split
off
the
the
old,
the
Legacy
dashed
into
a
separate
section
in
the
browser-based
test
into
its
own
section.
C
So
it's
a
lot
clearer
when
you
get
to
the
the
Das
docs,
exactly
where
you
need
to
go
to
fill
out
the
different
variables
but
yeah
you
just
set
it
to
true
in
the
in
the
gitlab
ciml
file.