►
From YouTube: Pipeline Security team meeting APAC 2023-06-01
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
Hi
everyone:
this
is
pipeline
security,
APAC
team
call.
This
is
June
1st
today
in
the
agenda,
we
have
a
couple
of
announcement.
First,
one
is
about
the
team
of
site
that
is
planned
across
the
globe,
so
we
have
different
issues
in
America,
Europe
and
APAC.
So
it's
an
opportunity
for
team
member
to
meet
in
person.
A
A
Next
thing
is
the
code
on
a
retro,
so
looks
like
we
are
all
settled
here
and
we
will
use
the
current
code
owner
within
verify
that
we're
using
now
so
now
every
change
is
to
verify
backend.
Our
front-end
change
would
require
a
verified
approval
to
get
merge.
A
A
And
the
next
point
is
mine,
which
is
like
a
new
subgroup
subgroup
that
I've
created
for
front-end
and
back-end.
So
we
can
ping
dedicated
people
on
specific
issue
because
it
was
a
bit
annoying
to
being
like
the
entire
team,
sometimes
like.
We
don't
need
to
bring
the
front-end
Engineers
or
like
the
back-end
engineers.
So
you
can
use
that
new
gitlab
handle
now.
A
And
that's
it
for
the
announcement
on
the
weekly
recording
things.
Eric
recorded
a
great
presentation
of
how
the
skip
copy
work
is
working
and
you
can
watch
the
presentation
on
the
gitlab
issue
and
there's
also
the
slides
with
it.
Explaining
in
depth
like
how
everything
is
working.
A
A
So
the
goal
is
that
in
the
next
three
weeks,
we're
gonna
dedicate
some
time
every
week,
like
an
hour
or
two
to
help
vitica
and
provider
feedback
on
some
helpful
things
that
we
think
a
design
sorry
secret
manager
should
look
like-
and
this
is
just
to
give
the
heads
up
that
it's
it's
coming
soon
and
that
please
allocate
some
time
in
the
next
three
weeks.
For
this
any
question
on
that.
C
A
I
think
video
provided,
like
all
the
contexts
in
the
different
issues,
so
first
one
is
the
the
main
issue
is
broke
down
into
in
three
tasks.
First,
one
is
preparation
to
gain
context
about
like
what
we
want
to
build
and
how
we're
planning
to
build
it
and
then
the
following
week.
We
have
task
one
to
complete
like
the
scenario
scenarios
and
task
2
for
the
next
put
it
following
week
after
where
we
want
to
bring
the
best
feature
together.
A
So
she
will
ask
us
questions
such
as
when
you
are
on
this
page
of
Performing
this
action.
What
should
happen
next,
so
we
will
all
collaborate
on
that
together
to
kind
of
build
the
solution
together.
It's
an
opportunity
for
everyone
to
to
bring
their
own
voice
to
the
table
and
I,
don't
think
we
already
participate
in
such
an
exercise
before.
E
A
E
Yeah,
it's
kind
of
like
competitive
and
analysis,
but
this
time
we're
now
focusing
on
like
visualizing
what
we
want
our
solution
to
be
like,
and
then
we
will
all
just
be
pitching
our
own
ideas
of
what
it
would
look
like.
So
that's
how
we
did
the
it
was
like
a
brainstorming
session
for
the
CI
catalog
for
pipeline
authoring.
So
I
think
this
is
how
it's
gonna
be
for
the
secrets
manager
as
well.
E
E
For
the,
how
we
did
it
for
sea
Academy,
I
guess
so
to
give
you
an
example
of
how
we
did
it
but
yeah.
If.
D
Have
they
did
it
in
pipeline?
Authoring
was
kind
of
like
don't
don't
look
at
other
people's
papers.
Type
thing
like
do
your
own,
so
you
so
you're
not
biased
about
what
other
people
saw
so
that
there
could
be
kind
of
some
independent
ideas
that
that
are
unique,
that
that
people
would
come
up
with
if
you
work
on
your
own
and
then
vitica
can
look
at
them
all
and
and
kind
of
pick
out
the
best
ideas
and
make
a
a
hybrid
solution.
B
A
Okay,
so
next
topic
is
from
me
again,
where
I've
noticed
something
that
petlandering
is
doing
again.
A
That
we
can
take
some
inspiration
from
is
that
they
don't
interrupt
the
engineering
team
for
waiting
issue
during
the
Milestone
and
they
have
like
a
dedicated
week
where
they
focus
on
waiting
issues,
which
is
usually
the
first
seven
days
of
the
months,
and
this
process
allowed
them
to
avoid
Interruption
during
their
their
work
for
like
a
given
Milestone
and
allows
them
to
weight
a
lot
of
issues
in
in
those
seven
days
and
wanted
to
get
your
thoughts
on
that.
E
Issues
are
prioritized
in
the
board,
and
everyone
like
for
that
week
for
that
first
week
of
the
month,
everyone
would
just
look
at
the
planning
breakdown
board
and
whatever's
on
the
top
that's
relevant
for
front
and
their
back
end.
If
no
one's
winning
them
yet,
then
you
would
assign
it
to
yourself
to
get
it
made.
E
So
basically,
we
do
the
way
with
the
part
of
the
process
where
managers
would
be
pinging
Engineers
to
like
specifically
issues
or
likes
yeah.
For
saying
these
specifics,
these
issues
will
be
made
by
this
specific
person.
So
that
was
how
the
process
went
for
pipeline
authoring.
E
Introduced
a
number
of
things
for
me
so
I
enjoyed
it
I'm,
also
but
I
like
I
personally
I'm
fine
with
either
process.
So
it's
up
to
the
team
I
think.
A
F
E
F
E
It's
like
just
giving
a
dedicated
time
to
say:
okay,
we
have
to
make
sure
that
some
to
set
aside
this
this
specific
time
to
weigh
issues
so
that
for
the
next
Milestone
or
the
Milestones.
After
that,
we
have
like
refined
all
the
issues
that
we're
gonna
do
for
the
future.
So
it
was
mostly
to
reduce,
pains,
I.
Think
if
I
remember
it
correctly,
it
was
mostly.
There
was
a.
E
There
was
a
lot
of
context,
switching
in
pipeline
Authority
in
the
past,
so
this
was
one
of
the
ways
we
reduced
the
number
of
things
within
the
team,
which
is
a
common
complaint.
Back
then.
C
A
D
I
vaguely
remember
that
was
there
something
like
like
there
was
like
there
was
a
long
list,
so
so
it's
kind
of
like
so
for
16.2,
for
example
like
these
are
the
ones
that
kind
of
have
to
be
weighted,
and
hopefully,
as
a
group,
everyone
can
and
then
but
below
that.
If
you
you've
got
free
time,
you
can
kind
of
grab
some
at
the
bottom
as
well
to
get
ahead
for
the
next
Milestone
right.
Something
like
that.
E
Or
maybe
a
different
team
yeah,
it
was
set
up
like
that,
so
the
pipe
in
the
in
the
board,
the
the
great
pipeline
authoring
did
it
was
the
planning
breakdown
column
is
where
you'll
get
all
the
issues
that
you
want
to
weigh
and
it's
priority
it's
arranged
by
priority.
So
the.
E
Top
are
the
ones
for,
let's
say,
16.2
and
then
the
ones
below
that
are
like
scheduled
for
the
next
one
for
16
16.3
or
something
that
probably
needs
more
refinement
or
like
breaking
down.
So
that's
and
then
like
whoever's
when
you're
free
for
that
week,
you
just
pick
whatever
issues
there
that
are
not
yet
assigned
to
someone
for
refining
or
breaking
down
and
then
yeah.
That's
how
we
did
it.
E
Yeah
I
think
they
made
a
separate
board
just
for
this,
like
just
for
waiting,
but
it
is
it'll
still
be
reflected
anyway
in
the
in
the
actual,
the
main
board,
with
all
the
with
the
work
in
development,
etc,
etc.
E
It's
hold
on.
Let
me
find
it.
B
On
that
yeah,
it
looks
to
be
that
a
time
consuming
part
all
right.
This
seven
laces
should
we
spent
on
the
investigation.
Is
that
right
wait
rather
than
just
filling
the
numbers.
E
B
B
Oh
yeah
I
think
we
can
try
that
perhaps
we
can
like
call
it
like
refinement
instead
of
just
waiting.
We.
D
E
The
way
I
did
it
is
I
did
both
like
it
like
in
that
week.
I
would
still
be
coding,
I
just
made
sure,
like
maybe
20
of
that
week.
I
had
time
to
so
it's
kind
of
like
the
normal
way.
We
do
things
now.
E
It's
just
really
doing
away
with
pinging
individual
people,
so
for
that
week,
I
would
prioritize
the
refinement
of
the
issues
and
then,
if
I
still
have
time
for
the
day,
then
I'll
like
continue
with
my
deliverables
or
like
whatever
else
I'm
doing
as
usual,
because
it's
still
like
the
waiting
process
or
the
refinement
process
is
still
what
we're
doing.
Now.
Anyway,
it's
just
we
assign
people
which
issues
to
be,
and
the
assignment
part
is
the
one
where
this
process
trying
to
do
away
with.
A
E
Kind
of
yeah,
yeah
and
I
guess
it's
everyone's
since
everyone's
refining
it
like,
if
you
need
like,
for
example,
if
I'm
wearing
a
branded
issue
and
I
need
input
from
ux
or
from
back
end
or
I'm
gonna,
say:
oh,
this
is
too
big.
We
might
need
like
a
new
query
or
something
so
there's
also
like
the
expectation
that
everyone
everyone
in
that
week
would
probably
like
be
talking
more
to
each
other
about
the
next
thing.
E
To
do
so,
there's
an
expectation
that
you'll
be
disturbed
or
you
will
have
to
look
at
a
lot
of
issues
in
that
week
and
for
context
also,
because
when
we
did
this
because
pipeline
authoring
owned
like
Secrets
as
well
as
like
the
what
they
were
they
on
now
and
the
CI
catalog.
So
the
context
switching
part
was
also
because
pipeline
authoring
owned
a
lot
of
domains
and
that's
why
we
did
all
this
breaking
breaking
down
of
that
domains.
But
yeah.
A
F
These
are
not
directly
tied
to
like
just
one
month
right
like
that:
the
mouse
over
the
other
round,
their
cut-off
date
for
emerging
stuff
for
around
18th
I
think
so
you'll
be
like
probably
going
to
be
working
on
stuff
already
for
that
next
Milestone
19
onwards,
and
then
around
the
first
of
the
next
month.
You'll
have
to
like
switch
context
again
forget
about
the
stuff
that
you
work
or
heavily
work
on
Parallel
with
grading
and
then
the
stuff
that
you
already
started
during
the
last
few
days
of
the
previous
month.
F
A
A
B
Yeah
I
just
have
a
question
on
what
is
our
definition
for
static,
Dynamic
and
application
secrets.
So
we
have
a
handbook
page
that
categorizes
these
three,
but
it's
not
very
clear
to
me
and
I'm,
not
sure
if
everyone
else
also
follows
so
it
seems
to
be
defining
three
is
distinct
groups
of
Secrets
of
first
line
static.
Second,
one
is
dynamic.
Third,
one
is
application
yeah,
so
I'm
not
clear,
so
it
seems
so
static
and
dynamic
should
already
cover
all
the
secrets.
B
E
I
actually
also
am
confused
about
it,
but
from
what
I
understood
in
the
same
doc
like
there
were
like
two
categories,
the
the
one
application
Secrets
is
the
one
where
the
secret
just
operates
within
the
same
system
and
then
there's
this
other
category
that
we
didn't
name
very,
which
is
about
accessing
a
third-party
system,
and
then
both
of
them
can
be
static
and
dynamic.
That's
how
I
understood
it
I'm,
not
sure
why
they
are
categorized
in
three,
but
it
yeah.
D
So
for
me,
because
I'm
confused
so
would
we
would
we
say
static.
Secrets
would
be
essentially
like
a
variable
that
someone
set
somewhere
and
a
dynamic
secret
would
be
like
a
token
that's
generated
on
the
fly
to
access,
something
and
then
yeah
the
applications.
If
that's
okay,
that
helps
me
but
yeah
I
I
have
no
idea
for
application
secrets.
D
D
B
Makes
sort
of
makes
sense,
I
think
like
it
or
it
doesn't
change
unexpectedly.
Well,
okay,
I
think
what
makes
an
area
explain
makes
sense
like
a
dynamic
is
like
a
one-time
thing
or
very
short
time,
shortlist
item
and
then
it's
created
or
generated
by
that
the
system
itself
like
like
Vault,
for
example,
if
it
sounds
like
it,
generates
a
secret
for
you
to
use,
whereas
the
static
one
is
something
that
you
take
from
it
somewhere
else
and
then
story
I,
don't
know.
D
C
Yeah
most
confusing
for
me
is
application.
Secretes,
it's
placed
on
the
same
level
of
specification
like
static
and
Dynamics.
That's
confusing.
B
Yeah
yeah:
let's
do
that.
I
I
want
to
hear
what
everyone
else
have
to
say
in
the
other
meeting.
First:
okay,
that's
good
and
probably
I'll
also
put
this
into
that
document
that
I
created
last
week.
B
F
We'll
know
maybe
I'm
kind
of
like
thinking
the
applications
that
could
be
something
that
can
still
be
used
like,
for
example,
if
we're
gonna
offer
our
native
secrets
storage
service,
then
maybe
an
application
secret
would
be
something
that
if
I
would
use
gitlab
as
my
secret
storage
on
my
rails,
app
I
would
fetch
those
secrets
from
that
the
git
lab
Vault
or
storage,
but
that
will
only
be
used
within
the
wheels
app,
for
example
like
encrypting
columns
and
whatnot.
F
So
maybe
that's
what
the
the
handbook
says.
Maybe
this
is
more
for
how
users
should
like
identify
their
secrets
or
like.