►
From YouTube: How to deal with Vulnerability state changes?
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
Just
recorded
here
all
right,
so
we're
here
to
discuss
the
possible
possible
approaches
to
how
do
we
track
the
state
of
the
vulnerability
and
how
we
change
it
in
the
in
time,
mostly
due
to
the
problem
that
we
only
expose
comments
when
we
dismiss
the
vulnerability,
the
main
the
main
question,
now
that
I
have
I
outlined
three
approaches:
do
we
have
anyone
who's
like
in
favor
of
something
else
than
creating
a
separate
model
to
track
the
state
changes?
B
Yeah
one
is
one,
is
actually
just
like
creating
the
vulnerabilities
on
the
fly
whenever
there
is
a
user
action
like
dismissing
the
finding
through
pipeline
security,
tab
or
creating
an
issue
or
or
creating
a
merge
request.
So
if,
if
we
just
create
the
vulnerability
on
the
fly,
we
don't
really
need
any
hack
like
we
don't
really
need
the
feedback
model
at
all.
We
can
just
create
the
vulnerability
and
set
the
state
accordingly.
B
Just
one
problem,
though,
like
imagine,
you
have
a
finding
which
is
not
persistent
yet
right,
it's
it's
in
the
pipeline
for
for
a
future
branch,
and-
and
you
dismiss
that
vulnerability,
you
dismiss
that
finding
I
mean
it's
really
mind-blowing
like
we
have
vulnerability
finding.
B
So
imagine
you're
dismissing
that
finding.
So
if
we
follow
this
approach,
we
need
to
create
a
vulnerability
and
then
dismiss
that
vulnerability
accordingly
right.
What
happens
when
you
undismiss
that
finding
again
so,
oh
okay,
then
do
we
need
to
delete
that
vulnerability
is
created
or
or
just
like
what
we
can
do.
A
C
B
Is
other
than
having
sparse
ids
in
the
table?
I
don't.
I
don't
really
think
like
there's
a
there's,
a
huge
disadvantage.
C
Yes,
but
like
when
I
was
reading
your
like
comment
on
the
issue
I
was
feeling
like
that
could
be
a
cleaner
way
because,
like
if
you're
introducing
other
like
ad-hoc
things
every
time,
it's
like,
I
don't
think
it
will.
It
will
stop
in
future
like
every
time
we
will
get
something.
We
will
add
another
thing
we
will
add
another
thing:
yeah.
B
B
B
A
Okay,
when
I
propose
the
idea
of
creating
a
model
just
to
track
the
state
changes
of
a
vulnerability,
I
was
also
taking
into
consideration
the
fact
that
matt
did
say
that
customers
want
to
have
an
audit
trail
for
the
vulnerability
changes.
A
So
my
reasoning
was
twofold:
that
if
we
I
keep
the
feedback
model,
we
have
to
keep
it
for
now
because,
like
replacing
it
entirely
in
one
milestone
is
not
doable.
So
my
idea
was
to
create
a
state
chain
stay
model
representing
a
vulnerability
state
change
that
we
would
be
able
to
basically
have
a
comment
on.
A
So
every
state
change
in
a
vulnerability
could
have
its
own
command.
So
we
would
get
the
feature
that
andy
has
implemented
in
the
ux
and
we
would
get
the
audit
trail
that
customers
want
and
we
would
be
able
to
keep
the
feedback
model
to
to
a
minimum
to
a
bare
minimum.
By
by
minimum
I
mean
what
magmat
said
that
we
would
use
it
only
to
keep
findings
dismissed
if
they
are
to
keep
vulnerabilities
dismissed.
A
D
E
Yeah,
so
here's
what
I
was
thinking
about
the
notes
I
mean,
because
that
would
that
would
create
an
audit.
Do
we
need
to
be
able
to
track
very
quickly
when
these
things
occurred
or
just
keep
them
as
or
can
we
just
keep
them,
as
notes
like
because
the
current
state
is
the
most
important
state
right
like?
E
A
Yeah
they
will
be
there
but
the
main
problem.
I
I
see
two
problems
with
that
approach.
The
first
one
is
that
they
are
essentially
free
form
text,
which
means
that
if
let's
say
I,
I
have
no
idea
what
would
happen,
but
let's
say
we
we
add
an
additional
attribute
along
with
the
state
change.
Maybe
it's
comment,
maybe
so
I
don't
know.
A
E
I
I
get
it
and
I
I
think,
with
the
you
know,
I
I
didn't
see
the
I
think
about
the
audit
before
this
meeting
and
so
yeah
with
with
the
net
requirement
to
audit
these
things.
A
D
B
Yeah,
I
see
so
actually
this
this
pattern
is
called
event:
sourcing.
Okay,
okay,
I
don't
know
like
I
think
we
are
discussing
two
different
problems.
Right,
one
is
like
being
able
to
like
audit
the
changes
for
the
vulnerabilities.
A
Yes,
the
actual
problem
is
that
when
you
dismiss
a
vulnerability
now
you
have
the
ability
to
put
down
a
comment.
A
Like
reason
for
dismissal,
andy
said
that
what
they
actually
had
in
mind
is
that
any
action
on
a
vulnerability
like
confirming
it
resolving
it
or
dismissing
it.
You
should
be
able
to
put
down
a
comment
as
well.
A
E
Yeah
yeah
yeah.
We
either
way
we're
gonna,
have
to
add
some
additional
like
we're.
Either
gonna
have
to
go
in
there
and
make
some
modifications
to
the
feedback
model,
yes,
which
I
I
want.
I
don't
like
the
feedback
model.
D
So
straight
up
with
that
yeah
I.
E
C
C
He's
like
he's
like
it
was
super
complex,
and
I
I
was
I'm
just
trying
to
add
like
so.
There
are
two
problems,
the
problems
you
are
talking
about
me.
How
like
need
to
put
comments
for
every
action
like
confirm,
resolve
and
other
things,
so
in
the
other
issue,
matt
and
thiago
commented
that
we
are
going
forward
so
that
nothing
is
blocking
that
issue,
because
we
are
now
going
for
now
only
for
dismissed
comment.
C
A
B
B
Yeah,
but
the
biggest
problem
is
right:
now
we
have
two
sources
for
the
state
information.
One
is
the
feedback
model.
One
is
the
vulnerability
model
itself,
so
we
need
to
actually
like
get
rid
of
one
of
them
and-
and
if
you
do
so
like
I
am,
my
five
cents
goes
for
getting
rid
of
the
feedback
model
and
and
keeping
the
state
only
in
the
vulnerable
model
itself.
A
D
E
E
D
C
Yes,
but
this
is
this-
is
this:
is
the
forum
I
can
confirm
my
like
small
knowledge
like
because
I
was
going
through
the
code,
so
finding
return
the
state
on
basis
of
first
with
the
feedback
and
then
go
for
the
vulnerability
state
check
because
like
if
there
is
a
dismissal
feedback,
it
returns
automatically
like
dismissed
state
other
than
it
will
go
through
the
vulnerability
state.
If
there
is
a
vulnerability-
and
yesterday
was
I-
I
saw
that
it
doesn't
track
the
vulnerability
detected
state.
So
there
is
a
bug
for
that.
E
E
Still,
we
don't
necessarily
say
that
they're
confirmed
or
anything
with
their
issues
or
mrs,
we
just
have
those
things.
It
may
not
be
confirmed
on
the
vulnerabilities.
A
E
B
B
E
So
if
we
were
to
go
with
a
new
model,
we
would
probably
need
to
link
that
to
the
vulnerability
finding
as
much
as
and
which
makes
which
kind
of
makes
sense
what
the
long-term
goal
originally
was
with.
The
vulnerabilities
was
that
vulnerability
was
supposed
to
have
multiple
findings
and
that
that
it
was
really
originally
a
one-to-many
relationship
that
was
planned
for
the
future.
Vulnerabilities
have
many
findings
that
was
never
really
fleshed
out,
but
it
would
make
sense
that
an
individual
finding
is
the
thing
that
is
dismissed
or
confirmed
right.
B
C
D
B
There's
another
problem
that
I
want
to
highlight
so
like
right
now
we
are
creating
feedback
for
findings
right
through
through
the
pipeline
security
tab
and
it
can
be
either
issue
feedback
or
mr
feedback
or
dismissal
feedback
and
and
later
once
this
finding
merged
into
the
master
branch
like
default
branch,
it
becomes
a
standalone
vulnerability
and
then
we
have
the
problem
right
now.
Sometimes
we
forget
to
create
the
issue
links
for
the
actual
finding
actual
vulnerability.
Yes,
there
is
a
if
there's
an
issue
of
feedback
for
the
family.
B
B
So,
like
I,
I
think
what
we
should
discuss
right
now
is
like
what
is
the
best
way
like
to
to
manage
the
state
of
vulnerability
rather
than
like
having
the
event
sourcings
implemented,
because
we
can.
We
can
later
implement
event
sourcing
when
it's
needed
like
when
the
product
manager
actually
asks
for
it.
B
E
B
It's
a
there's,
an
attribute
in
the
vulnerability
model
dismissed
by
this.
D
D
B
Yeah
and
it's
definitely
not
like
tracking
the
history,
it's
just.
D
C
I
I
I
agree
with
that,
because
it's
like
I'm
new,
just
it's
my
two
cents.
I
agree
with
that.
Whatever
I
saw
is
like.
I
think
we
should
go
forward
to
the
thing
where
we
can
see
that
it
will
easy
to
like
combine
both
finding
and
vulnerability.
I
think
that's
a
closer
step
like
if
I
we
get
rid
of
my
feedback.
E
We
definitely
have
to
have
a
structure
in
place
to
replace
some
of
what
we
do
with
the
feedback
because,
like
we
talked
about
with
things
in
the
pipeline,
not
having
a
vulnerability,
so
we
would
have.
We
would
need
to
be
able
to
link
still
be
able
to
link
things
up
between
the
findings
and
the
mrs
and
the
issues
which
I
think
is
done
right
now
through
feedback.
A
B
A
B
Issue
or
the
mr
and
then
the
thing
is
like
like
for
an
issue
and
for
nmr.
If
you
create
an
issue
or
nmr,
it
means
it's
kind
of
how
you
say
triaged
right,
so
it
should
be
actually
in
the
in
the
security
dashboard.
There
is
no
way
to
like
delete
the.
Is
there
a
way
to
delete
the?
Is
there
a
way
to
delete
the
issue
or
the
mr.
A
A
If
you
have,
if
you
have
maintainer
access,
I
think
to
the
project
or
group
level,
you
can
delete
issues
manually,
it
wouldn't
get
rid
of
the
link
but
yeah.
B
So
I
mean
I'm
asking
because
like
if
you
are
creating
an
issue
or
nmr
like
there
is
no
easy
way
to
undo
your
action
right.
So
we
don't
really
need
to
delete
the
vulnerability,
like
recently
created
vulnerability
for
those
cases
only
for
the
dismissal
and
undismissal
action
we
would
need
to
delete
the
recently
created
vulnerable.
B
E
A
A
E
I'm
just
talking
out
thinking
out
loud
here
talking
out
loud
if
we
had
a
field
in
the
in
the
findings
that
would
indicate
that
it
is
like
a
temporary
like
like
we
create
a
finding
it
we
create,
and
if
we
create
an
issue,
we
create
it
as
a
temporary
finding,
if,
once
that
pipeline
gets
removed
or
a
new
pipeline
gets,
replaces
it
or
something
like
that
being
able
to
go
back
and
remove
all
the
temporary
findings.
E
Well,
we
wouldn't
want
to
remove
the
temporary
findings
if,
if
we
create
an
issue
from
them,
but
in
some
way
being
able
to
market
the
finding
is
temporary.
E
And
right
now
like
like,
because
I
was
looking
at
the
vulnerability
finding
like
you
know,
for
the
ones
for
if
we
create
an
issue
being
able
to
move
that
over
the
finding
over
to
a
a
real
vulnerability
and
getting
everything
to
persist.
If
we
create
something
off
of
a
pipeline
rather
than
the
default
one
going
through,
like
you
actually
have
to
like
sort
through
all
the
reports
to
actually
link
things
back
up,
which
is
admittedly
painful
so.
But
I
think
I
think
we
have
a.
E
I'm
sorry,
I'm
I'm
trying
to
sort
through
the
spaghetti
in
my
head
and
it's
just
not
it's
not
working
right
right
now.
It's
just
it's
just
a
complex
issue
trying
to
figure
out
how
to
how
to
link
up
these
temporary
findings
that
have
an
issue
related
to
them
and
then
moving
them
to
a
vulnerability.
But
I
don't
think
we.
I
don't
think
we
want
to
create
an
actual
vulnerability
until
that
finding
is
or
that
that
branch
is
merged
into
the
master
branch.
B
A
E
I
mean
you
think
about
that.
You
think
about
something
like
git
lab
that
has
so
many
pipelines
that
are
constantly
reading
and
writing,
and
I
know
that
this
this
topic
has
come
up
before
about
creating
a
finding
for
every
pipeline
and
then
removing
those
findings.
Once
that
pipeline
is
is
done,
you
know
we're
removed
or
that
that
branches
is
is
removed.
E
Wait
that
I
feel
like,
although
I
feel
like
that's
starting
to
get
down
to
a
path
that
this
does
not
relate
to
but
like.
If
this
I
do,
I
do
wanna
just
make
sure
that
we're
sticking
with
the
idea
of
tracking
state
changes
making
sure
that
we
solve
that
problem
at
this
meeting,
because
there's
there's
so
many
things
we
can
discuss
yeah.
What
are
problems
with
the
vulnerabilities.
A
E
A
D
E
B
E
E
B
A
I
I
I
want
to
discuss
how
we
are
going
to
handle
this,
because
we
will
have
to
handle
this
and
if,
if
actually
taking
some
time
before
doing
the
audit
trail,
to
remove
the
finding
sorry
to
remove
the
feedback
is
the
best
approach.
Then
we
should
remove
feedback
first
and
then
build
on
top
of
the
vulnerability
as
a
single
source
of
truth.
B
We
should
definitely
do
that
otherwise,
like
we
will
be
building
new
features
based
on
previous
technical
debt
and
and
it
will
make
it
even
harder
to
maintain
in
the
future
it
will
like
it
will
just
like
couple
the
feedback
model
more
and
more
into
the
logic
that,
even
if,
in
the
future,
we
want
to
get
rid
of
the
feedback,
but
we
won't
be
able
to
get
rid
of
it.
So,
first
we
need
to
get
rid
of
it.
A
Yeah
is
there
any
okay?
Let
me
let
me
try
proposing
something.
Is
there
any
obvious
disadvantage
of
creating
vulnerabilities
when
a
user
interacts
with
them,
provided
we
mark
them
as
not
coming
from
the
default
branch?
Like
say
we
add
a.
We
had
a
boolean
column
from
the
default
branch
on
the
vulnerability
table
itself,.
B
I
can't
I
can't
see
any
any
big
problem
I
mean,
even
though,
even
without
having
a
boolean
flag
on
the
vulnerability
table,
we
can
still
understand
if
the,
if
the
finding
is
in
the
default
branch
because
to
reduce
to
the
pipe,
but
it
will
not
perform
very
well.
E
We
would
have
to,
we
would
have
to
track
when
that
branch
gets
merged.
A
E
E
C
E
Here's
here's
here's
where
it
might,
here's
where
it
might
happen
and
might
be
needed,
say
you
have
the
default
branch.
E
A
E
A
What
correct
me
if
I
wrong,
but
what
would
happen
in
this
case
that
you
create
a
future
branch.
You
create
rumors
requests
for
this.
My
play
runs,
finds
10
vulnerabilities,
you
go
to
the
pipeline
security
widget,
you
see
what
vulnerabilities
there
are
and
you
like
say
fix
one
of
them.
You
don't
you,
don't
you
don't
interact
with
them?
You
just
basically
you
see,
there
is
a.
A
There
is
an
sql
injection,
you
fix
it
without
doing
any
interaction
on
github.com
and
another
pipeline
runs,
and
there
are
now
nine
vulnerabilities
so
that
solves
the
problem
of
there
is
no.
There
is
no
problem,
because
if
you
want
to
iterate
on
the
official
branch,
the
ability
still
is
still
there
yeah
the
problem.
As
I
understand
it
is
now
you
you
create
a
branch.
A
There
are
10
vulnerabilities,
discovered
in
the
feature
branch
you
go
to
the
security
widget,
you
create
an
issue
or
you
dismiss
the
vulnerability,
and
if
you
re-run
the
pipeline,
the
finding
will
still
be
there
and
we
will
have
a
vulnerability
object
created
for
it,
but
the
vulnerability
object
created
will
not
be
shown
anywhere.
That's
the
problem.
B
I
don't
really
understand
the
problem,
because,
right
now,
what
what
we
are
doing
is
whenever
there
is
an
artifact
report
artifact.
We
have
many
findings
in
it
and
and
after
passing
the
artifact
and
building
the
finding
poor
or
plain
old
ruby
objects.
We
are
also
checking
the
existing
vulnerabilities
for
those
findings
and
and
setting
the
state
of
the
finding
based
on
the
existing
vulnerability.
B
A
A
A
A
B
A
E
So
something
else
we
need
to
consider
with
showing
finding
like
created,
findings
and
vulnerabilities
on
the
security
tab
is
that
all
those
security
findings
come
from
the
are
pulled
from
the
report.
So
we
need
to
be
able
to
filter
out
those
parts
of
the
report
that
already
have
a
finding
created.
So
we
can
actually
show
the
finding
right.
A
E
Yeah,
the
uuid,
so
we
just
have
to
we
have
to
filter
out
the
the
report
or
the
findings
or
or
matched
up
the
findings.
The
parts
of
the
report
that
or
the
from
the
finding
on
the
report
match
the
actual
finding
in
the
database
using
the
uuid
but
just
make
sure
now.
A
E
B
Yeah,
yes,
when
we
pass
the
report
artifact,
we
are
creating
the
university
because.
B
A
Uid
version
five
is
basically
includes
a
prefix
and
we
have
the
components
we
calculate
already
version
five
out
of
components,
which
means
that
if
the
report
type
project
finger,
sorry,
location,
fingerprint
and
primary
identifier,
fingerprint
and
the
project
id
are
the
same,
then
the
resulting
qid
will
be
the
same.
If
any
of
this
component
changes,
then
a
different
uid
will
be
generated.
Okay.
A
A
Then
we
can
ensure
that
the
vulnerability
model
remains
as
a
single
state
of
truth
for
the
state
of
the
given
vulnerability.
If
wait.
Okay,
so
we
now
got
the
single
state
of
truth
for
this
for
this
state
now,
the
question
is:
how
do
we
ensure
that
we
can
comment
on
the
state
changes
and
this
this
is.
This
is
the
another
thing
that
we
should
build
on
top
of
that
so
first.
C
D
C
So
we
need
to
show
sorry
me:
how
do
you
need
to
show
the
comment
of
the
last
state
or
like
do
we
need
to
show
all
the
comments
that
user
did
like
once
the
confirmed
one
again
coming
back
to
the
detected
or.
E
E
A
C
A
A
D
C
A
I
don't
recall
anything
of
the
sorts
that
said,
I
didn't
use
enterprise
until
now
until
I
started
working
on
gitlab,
so
there
might
be
some
areas.
B
We
have
the
audit
events,
sorry
under
the
security
and
compliance
tab.
There
is
a
there's,
a
link.
D
C
E
But
there's
nothing
where
we
say
like
well,
I
guess
no,
I
was
I
was
thinking
like,
even
if
we
like
close
an
issue,
if
we
close
an
issue
with
like,
if
we
put
a
comment
in
there
and
then
we
say
close
and
comment,
come
on
and
close,
those
are
two
separate
things
in
the
database
like
the
comment
is
not
related
to
the
close.
A
B
E
A
From
from
what
I'm,
basically
understanding
is
that
here
that
andy
andy
said.
E
C
But
if,
if
we
need
to
track
state
and
comment
together
right
now,
so
we
are
not
solving
entirely
right
by
introducing
vulnerability,
we
still
need
to
do
more.
A
A
D
A
a
time,
you
know
a
time
stamp,
a
comment
and.
B
Yeah
why
we
are
not
creating
an
epic
right
now
I
mean
one
of
or
maybe
later.
A
B
B
A
B
A
Okay,
so
if
I'm
understanding
this
correctly
back
to
the
back
to
the
comment,
thingy
andy
andy
wanted
for
users
to
be
able
to
submit
a
comment
on
any
status
change,
and
now
we
don't
have
the
ability
to
do
that
and
later
on,
matt
matt,
yes,
matt
chimed
in
that
not
being
able
to
definitely
retire.
A
comment
to
a
status
change
could
be
a
big
problem
for
customers.
Looking
for
a
robust
audit
trail,
I
can't
recall
exactly,
but
I
am
fairly
certain.
E
A
Cannot
imagine
any
compliance
frameworks,
not
wanting
you
not
wanting
audit
trail
for
vulnerabilities
in
total.
C
A
A
I
mean
doing
what
magnet
proposed,
which
basically
means
creating
vulnerabilities
on
the
fly
from
findings
when
user
interact
with
them.
Okay,
if
there
is
no
interaction
from
the
user,
we'll
be
creating
anything
if
there
is
an
interaction
from
the
user
like
create
an
issue
or
dismiss
it,
we
would
have
to
create
a
vulnerability
for
this
wait.
A
No,
actually,
no,
because
there
is
additional
step
which
I
mentioned,
but
I
forgot
right
away
is
that
we
have
the
auto
remediations
features,
which
means
that
merge
requests
get
open
automatically.
But
this
means
we
could
open
a
vulnerability
for
the
merge
request
as
well.
D
E
E
E
So
so
we
probably
need
mr
links
or
at
least
a
way
to
to
to
note
what
the
mr
id.
D
A
A
E
C
A
Okay,
if
it's
simpler
to
implement
that
model
ourselves
that
introduce
a
dependency
and
might
I
think
the
choice
is
obvious.
I
don't
think
we
need
paper
trail
for
this,
because
it's
not
not
complicated
enough
for
paper
to
I'm
not
sure
paper
trail,
for
example,
supports
adding
comments.
The
state
changes.