►
From YouTube: OSS-SIRT SIG - Part of BEST WG (August 30, 2022)
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
Oh
yeah
so
I
need
to.
A
I'm
gonna
I'm,
gonna
reuse,
the
the
same
ones
this
last
time,
but
I
need
to
get
you
added.
Okay,
we
have
to.
Let
me
put
this
in
chat.
There
was
an
issue
where
we
had
the
GitHub
I'm.
Sorry,
Google,
Docs,
open
to
anybody
and.
A
B
B
A
A
B
A
B
A
A
A
Looks
like
it's
just
us
for
today,
so
welcome
Joe,
Jasmine
and
Crowe
I'm.
Sure
we'll
we'll
have
some
others
trickling
in
here
soon
good
afternoon,
hey
Joe!
Would
you
like
to
introduce
yourself.
C
My
name
is
Joe
Bussell
I
am
a
lead
in
the
windows
engineering
system
and
my
interest
has
been
on
driving
supply
chain.
Trust
for
primarily
the
windows,
build
tools,
but
then
the
Windows
product,
all
up.
A
And
does
anybody
else
want
to
introduce
themselves
or
I.
B
A
All
right
great,
so
the
the
topic
for
today
and
I
should.
A
So
let
me
let
me
let
me
walk
through
so
I
wanted
to
take
a
first
stab
at
how
a
GitHub
project
would
would
what
they
could
do
with
the
existing
controls
and
existing
open
source
available
that
they
have
to
to
integrate
to
to
meet
some
of
these
controls,
as
we
go
through
these,
it's
important
to
note
that
some
of
these
are,
you
know,
done
out
of
band
they're
they're
not
done
in
the
configuration
of
your
of
your
repo
or
or
anything
like
that.
A
A
This
was
this
was
originally
you
know
designed
with
you
know,
large
teams
in
mind
that
are
that
are
consuming
you
know,
open
source
and
and
so
putting
a
lens
on
an
open
source.
Repo
actually
was
refreshing
in
in
many
respects,
so
so,
let's
walk
through
and
by
the
way,
do
I
need
to
zoom
in.
Is
this
good
for
everybody,
I
zoomed
in
anyways?
Wait.
Wait!
Wait
too.
A
A
So
use
package
managers
trusted
by
your
organization.
This
is
like
hey.
Let's
make
sure
we,
we
always
pull
nougat
packages
from
nougat.org
instead
of
mygets.com,
so
it
depends
on
what
what
project
you
are
and
where
you
would
want
to
be
be
pulling
from,
but
you
would
you
would
define
those
up
front
as
a
participant
in
this
you'd
say
we
only
want
to
pull
packages
from
from
these
kinds
of
locations
with
Linux
as
well.
That
also
becomes
very
because
there's
there's
so.
A
Repositories
out
there,
so
you
know
again
with
the
focus
that
this
is
a
GitHub
open
source,
repo
use,
a
binary
repository
manager
solution,
so
GitHub
packages
can
cache
artifacts
such
as
container
images
as
well
as
npm,
nuget,
Ruby,
and
something
else
I
can't
remember
the
full
list,
and
this
would
be
there
to
protect
you
from
you
make
sure
you
always
have
a
package
cached
locally
in
case
the
Upstream
ever
goes
away,
so
having
a
deny
list
capability
to
block
malicious
OSS.
This
is
actually
really
interesting
because
there
have
been
requests.
A
I've,
seen
like
GitHub
issues
filed
on
on
various
systems
to
say,
can
I.
Please
have
control
over
what
I
block
from
being
installed,
and
so
this
hasn't
been
a
capability,
that's
been
implemented
by
by
any
of
these
package
manager
Solutions.
However,
you
could
effectively
manage
your
own
deny
list
through
the
dependency
review
action
in
GitHub.
A
This
was
mentioned
in
a
blog
announcement
a
few
months
ago,
and
the
biggest
reason
why
you
want
to
have
a
deny
list
is
to
block
these
known,
malicious
things
just
on
the
off
chance
that
they
do
get
con
consumed
after
the
fact,
and
and
so
now,
that
GitHub
is
auto,
creating
cves
for
known
malware.
A
A
So
ing4
this
is,
you
know,
mirror
a
copy
of
all
OSS
source
code
to
an
internal
location.
The
the
whole
point
of
this
was
hey
for
for
native
code.
You
want
to
be
able
to
to
store
it
locally.
A
A
Using
this
framework,
you
would
still
want
to
copy
all
of
that
source
code
because
in
the
event
that
the
code
gets
removed
or
the
package
gets
removed.
If
this
is
a
critical
dependency,
you
want
to
be
able
to
take
ownership
of
that
code
and
continue
to
move
forward.
A
If
it's,
if
it's
a
dependency
that
you
could
easily
switch
away
from,
then
then
maybe
it's
not
so
important
to
you
or
your
team
or
your
company,
to
mirror
all
of
the
the
source
code
to
an
internal
location,
but
for
critical
components.
This
is
recommended,
and
so
there's
there's
guidance
here
on
how
to
on
how
to
do
this.
But
again
this
isn't
something
that
you
would
do
on
a
single
GitHub
project.
A
Hi
Johnson,
thanks
for
joining
we're
just
going
through
a
an
example,
reference
implementation
for
a
GitHub
project
and
feel
free
to
jump
in
with
other
suggestions
or
anything.
A
So
scanning
OSS
for
known
vulnerabilities,
this
is
a
level
one.
This
is
pretty
basic
and
this
is
built
into
the
dependency
graph
in
GitHub.
If
you
are
an
open
source
project,
you
get
this
capability
for
free
if
you're
in
GitHub
Enterprise.
This
comes
with
your
purchase
of
GitHub
Advanced
security
scan
OSS
for
licenses.
This
is
also
done
through
configuring
dependency
review,
and
so
it's
it's
provided
to
you
through
the
insights
tab
when
you're
looking
at
your
organization
and
all
of
the
packages
that
are
consumed
across
your
entire
GitHub
org.
A
B
C
B
It
depends
on
the
project,
they
might
publish
it
as
an
advisory,
they
might
put
it
as
a
blog
entry.
They
could
put
it
on
a
mailing
list.
If
they're
good,
they
would
put
it
into
inside
their
security
policy
MD
file.
They
would
describe
kind
of
what
the
support
expectations
are,
but
yeah.
It's
not
consistent.
This.
C
B
The
security
insights
project
that
Luigi
was
running
what
one
of
the
reasons
for
that
was
to
have
a
structured
way
of
finding
out
these
things.
Obviously,
folks
need
to
use
it
in
order
for
it
to
be
any
value,
but
that
that
would
be
at
least
be
a
way
of
not
you
know,
squirreling
it
away
inside
of
a
block
of
text
in
the
readme
file
and
something
that
you
could
discover
if
it
were
there.
A
A
Package
analysis
does
this
it's
redirecting,
but
it
does
say
that
it
can
detect
malicious
OSS
components
and
there
are
not
a
whole
lot
of
free
tools
out
there.
That
can
do
this.
A
B
You
know
so
I'm
switching
God
knows
what
it's
doing.
Sorry.
A
Okay,
no
worries
so
testing
out
how
to
integrate
this
to
to
Leverage
The
the
OSS
malware
analysis
results
against
the
OSS
that
you're
using
is
is
going
to
be
the
next
step
to
make
sure
that
this
is
feasible.
A
Kind
of
my
my
first
step
here
I
think
mend,
has
a
plug-in
that
does
OSS
malware
analysis,
but
it
only
supports
like
two
ecosystems,
so
that
would
be
like
an
optional
second
thing
to
add.
That's
also
free
to
implement.
A
So
this
is
follow
up
on.
A
Next
is
a
perform,
proactive,
Security
review
of
Open
Source.
This
is
where
proactive
security
scans
will
likely
be
done
out
of
band
from
a
build.
So
so
usually
this
is
this.
Is
you
know,
prior
to
using
something
you
do
some
sort
of
a
Security
review
assessment
to
determine
to
check
it
for
other
things,
other
than
known
vulnerabilities.
A
A
It's
so
I've,
just
kind
of
noted
that
this
is
this
is
usually
done
out
at
a
scope
of
your
build,
and
it's
usually
done
like
if
you've
cloned
the
source.
A
Maintain
an
automated
inventory,
GitHub
dependency
graph.
Does
that
for
you
and
then
you
know
having
an
OSS
incident
response
plan.
Of
course
you
would,
you
would
write
one.
There
are
lots
of
different
incident
response
templates
out
there
that
you
could
Leverage
But.
Ultimately,
it
needs
to
be
focused
on
how
to
roll
back
versions
of
of
OSS.
A
The
the
Assumption
here
is
a
bad
actor
has
compromised
a
given
package
that
given
packages,
usually
the
newest
version
of
that
package,
and
so,
if
you
have
Auto
updated,
for
example,
you
would
want
to
have
your
incident
response
plan
be
able
to
identify.
Are
you
using
the
thing
and
then
the
steps
for
yourself
on
how
to
roll
back
versions.
A
So
this
is
I
had
this
in
here,
because
you
know
level
one
is
supposed
to
represent
a
majority
of
what
everybody
does
today.
Everybody
already
updates
their
OSS
when
they
get
around
to
it.
So
this
one's
kind
of
like
a
like
a
given
it's
a
gimme
like
if
you're
playing
Bingo
and
they
give
you
a
free
spot
like
that's
what
this
is.
A
A
Straight
updates
just
straight
updates,
and
it
has
to
be
a
vulnerability
in
the
GitHub
vulnerability
database.
I
believe.
A
A
B
Know
Adrian
the
bot
you
were
thinking
about
I,
think
renovates.
A
Thank
you,
there's
a
gazillion
Bots
out
there,
and
so
you
know
okay
and
then-
and
so
you
know,
both
of
these
or
I'm
sorry
update,
two
and
update
three
are
are
very
important
to
helping
organizations
patch
their
known
vulnerabilities
faster.
A
A
So
if
you
have
two
person
PR
review
enabled
then,
if
a
contributor
submits
a
pull
request
that
contains
a
vulnerable
dependency,
it
will
raise
that
as
an
issue
as
a
comment
in
the
pull
request
and
the
reviewer
will
see
those
comments
and
will
more
than
likely
not
want
to
accept
the
pr
and
will
ask
the
person
to
go
back
and
address
those
things
before
that
that
all
gets
merged
in
and
so
that's
the
whole
idea.
It's
shifting
everything
left
we're
not
introducing
anything
bad
anymore.
A
Then,
oh
and
so
dependency
review
is,
is
the
other
thing
that
that
allows
you
to
have
that
capability
built
right
into
GitHub,
verify
the
provenance
of
your
OSS,
so
different
people
describe
or
Define
provenance
in
different
ways,
and
so
this
is
one
of
those
things
that
I
think
I
could
probably
do
a
better
job
at
at
improving
the
definition
of
provenance
like
what
is
actually
being
verified
before
I
I
come
up
with
a
recommended
solution
here
for
for
a
GitHub
repo.
A
C
To
me,
but
I
definitely
think
that
there
are
other
answers
that
could
come
from
a
non-get
type
of
Repository.
A
Oh,
this
is
like
the
git
bomb
project.
I
think.
C
This
is
yeah.
This
is
the
provenance
that
we
have
in
our
our
open
source,
s-bomb
tool,
actually
right
right.
A
We
can
we
can
decide
upon
upon
this
if
the
so
one
of
the
great
things
about
the
open
ssf
is
it's
got
this.
You
know,
10
work
stream,
mobilization
plan
and
one
of
those
one
of
those
work
streams
is
the
s-bomb
everywhere
initiative.
I'm
personally
really
excited
about
that.
A
I've
spent
a
great
deal
of
my
time,
working
with
s-bombs,
so
I
can't
wait
for
them
to
be
more
ubiquitous
across
the
board,
but
so
I
I
have
an
action
to
kind
of
come
back
and
and
come
up
with
a
better
recommendation
here,
based
on
a
definition
of
provenance
that
we
can
all
agree
on.
C
Where
you
say
hash
from
whence
it
came
just
to
be
correct,
if
you
don't
mind
putting
commit
hash.
A
So
audit
that
developers
are
consuming
OSS
through
the
approved
ingestion
method.
If
you
have
a
GitHub
project,
you
really
only
need
to
look
at
all
of
the
repos
that
make
up
your
GitHub
project,
so
so
the
the
the
scope
of
auditing
isn't.
Isn't
that
great?
When
you
get
inside
of
a
you
know,
maybe
like
a
large
company.
That's
that
wants
to
be
able
to
do
this.
This
becomes
harder
and
the
idea
is
you're
trying
to
secure
your
supply
chain.
A
So
you
need
to
control
all
the
inputs
of
how
open
source
is
being
consumed
into
a
build,
and
if
you
can
control
the
inputs,
then
you
can
have
the
open
source
be
evaluated
through
your
measures
like
like
vulnerability,
scanning
inventory
and
malware
scanning.
A
But
if,
if
you've
got
your
malware
scanning
configured
and
it
and
it
can
check
only
a
certain
amount
of
things-
you
want
all
of
your
OSS
to
be
consumed
through
this
governed
workflow,
you
don't
want
people
using
wget
and
curl
and,
and
you
know
everything
else-
to
consume
the
open
source
through
some
other
means.
That's
not
a
governed
workflow
and
that's
what
this
is
all
about.
A
So
there's
actually
opportunities
here
to
automate
detection
of
of
ungoverned,
OSS
and
and
the
tool
that
you
want
to
use
to
do
that
auditing
depends
on
how
you
are
choosing
to
force
your
or
enforce
your
secure
consumption
flow.
C
Let's
round
this
one
out
on
an
example,
I
think
we've
all
seen
examples
where
we've
had
to
nudge
someone,
hey
that
looks
familiar
where
they've
introduced
some
open
source
piece,
something
they
found
on
slack
stack,
Overflow
or
whatever
and
they've
introduced
actual
open
source
into
code.
Right
so
are
we
are
we
do
we
have
like
an
index
methodology
to
address
that
basic
that
basic
pass
where
we
could
identify
the
open
sources?
In
fact,
in
the
source
code,
it's
Undeclared.
C
B
I'm
not
aware
of
any
any
good
open,
source
or
kind
of
common
methods
for
doing
that.
I
am
optimistic
that
the
future
of
Sig
store
will
have,
and
probably
maybe
get
bomb
as
well
will
have
essentially
artifact
lookup
by
file
hash.
So
if
you
took
a
bunch
of
files
from
log4j,
renamed
them
or
maybe
maybe
didn't
rename
all
of
them,
you
you'll
you
in
the
future.
You
should
like
you
know
you.
B
Should
the
capability
should
be
there
if
you're
just
copying
a
couple
lines
of
code
from
stack,
Overflow,
good
luck
to
you
I!
You
know
you
need
to
kind
of
index
the
world
and
then
look
it
up,
but
that's
hard.
A
Yeah,
it
is
hard,
I
know
that
you
know
within
within
Microsoft
there's
there's
a
few.
Certain
I'll
call
him
an
anti-pattern
that
that
we're
looking
for
and
as
we
build
out
tooling,
to
help
us
identify
those
at
scale.
A
You
know
we'll
look
into
open
sourcing
those
those
tools.
You
know
no
promises,
but
you
know
that's
the.
The
intention
is
to
make
these
tools
available
to
others
that
that
have
the
same
problem
and
and
hopefully
they
can
help
at
least
identify
specific
scenarios.
B
I
I
will
say
just
kind
of
anecdotally
just
searching
for
copyright,
and
not
your
company
name
is
really
effective
in
in
starting
these
things
on
a
large
code
basis.
So
you
know
there
probably
is
a
80
20
Rule
and
in
getting
getting
good
enough
straightforward.
B
A
Validate
the
Integrity
of
the
OSS
that
you
consume
into
your
build,
this
is
usually
performed
by
the
language
packet
package,
client,
so
like
with
with
npm
or
nuget
exe.
These
are
usually
done
during
the
install
I
would
have
to
go
in
and
check
if,
if
there's
any
client
out
there,
that
that
doesn't
do
this
natively
by
default.
A
And
if
this
is
kind
of
handled
natively
by
by
default
across
the
board,
then
I
might
want
to
reduce
this
to
like
level
one
or
something.
A
However,
with
with
things
like
Sig
store,
as
and
and
other
signing
Technologies,
to
become
easier
for
the
open
source
Community
to
take
advantage
of.
There
may
be
future
tooling
required
to
be
validating
those
signatures.
A
Validate
the
s-bombs
of
the
OSS
that
you
consume
into
your
build,
so
this
is
a
level
four
item
level.
Four
is
largely
inspirational
in
nature,
and
this
is
kind
of
like
assuming
a
world
where
you
know.
If
you
do
consume
some
open
source
into
your
build
that
comes
with
an
s-bomb
you
can
you
can
leverage
that
that
s-bomb
to
double
check
the
the
Identity
or
the
provenance
et
cetera,
Etc.
B
A
B
A
The
way
I'm
not
sure
I
where's.
B
A
A
Your
package
source
file
is,
is
all
about
the
dependency
confusion
attack
that
happened
a
year
ago,
and
if
you
are
a
team,
that's
using
a
dependency
config
file
and
you
pull
from
multiple
different
sources
like
like
a
public
Source
like
nougat.org,
plus
an
internal
feed
source
and
you're
combining
private
packages
with
public
packages.
A
Whoever
responds
first
wins
and
that's
how
the
dependency
confusion
attacker
can
have
their
external
malicious
package
with
the
same
name,
but
higher
version
be
fed
to
your
feed
instead
of
your
intended
internal
only
version,
and
so
you
should
follow
so
this
was
a
guide
that
we
ended
up
publishing
as
a
result
of
that
that
announcement
of
that
new
technique
on
ways
to
to
mitigate
this,
and
so
these
are
certain
configuration
things
that
you
can
do
depending
on
what
ecosystem
you're
in
to
to
tighten
down
your
your
config
foreign
level
2.
A
A
A
So
if,
if
the
thing
that
we
care
about
the
most
is
make
sure
that
this
openssf
package
analysis
malware
scan
is
being
run
every
time
we
do
a
build,
then
you
can
create
a
a
pull.
A
branch
policy
rule
that
says
make
sure
that
this
was
run.
If
it
was
run,
then
you
can
allow
the
merge-
and
so
that's
a
way
to
to
enforce
this,
for
your
GitHub
project.
A
A
The
the
idea
is,
if,
if
we
always
have
our
our
ingestion
gates
for
lack
of
a
better
term
validating
the
sources
that
we're
bringing
in
and
they're
coming,
they
have
to
come
through
this
path.
In
order
for
all
of
these
checks
and
security
capabilities
to
run
whatever
that
path
is
that's
the
thing
we
need
to
enforce.
We
need
to
enforce
it.
All
OSS
is
coming
through
that
path,
and
if
it's
being
consumed
outside
that
path,
then
that's
bad,
so
yeah
Vex
could
be
added
to
this
list.
A
So
with
with
rebuild
the
OSS
in
a
trusted
build
environment
again,
this
framework
is
not
describing
the
requirements
for
what
a
trusted
build.
Environment
should
be,
but
that's
a
prerequisite,
but
this
these
are
these
level.
A
Four
items
are
reserved
for
the
most
sophisticated
attacks,
such
as
build
time
attacks
where
you
know,
nation-state
actors
obtain
a
presence
on
the
build
machine
and
are
manipulating
code
as
the
software
is
being
built
and
so
they're,
silently
contributing
their
their
malware
or
backdoor
to
the
piece
of
code,
and
that
is
where
you
would
want
to
either
have
a
reproducibly
built,
binary,
I'm,
sorry
for
for
OSS,
you
would
want
to
be
consuming
something
that
you
know
can
be
reproducibly
built
or
you
could
potentially
rebuild
these
things
yourself
and
again.
A
A
Then
then
these
are
the
extra
measures
that
you
can
take
to
make
sure
that
you
can
trust
these
critical
components
in
your
software.
C
C
B
B
Perhaps
it'd
be
better
to
State
vet
or
validate
tools
included
into
your
pipeline.
That
way
it
would
that
would
account
for
both
closed
and
open
source.
I
like
that.
B
A
Foreign
yeah,
we
definitely
have
some
thoughts
about
that
and
what
what
what
we're
working
on
I
know
salsa
also
has
their
own
list
for
for
build
integrity.
A
I
think
this
meeting
has
reached
its
end.
I
think
this
was
a
45
minute.
A
B
Done
with
this
exercise
and
my
friend
Xavier
from
the
GitHub
security
Labs
would
Echo
me,
but
you
need
to
also
provide
other
repositories
as
your
as
reference
architectures
lab
generic
kit
other,
because
Xavier
is
one
of
the
most
fierce
reminders
that
we
need
to
be
neutral
if
you're
working
with
a
open
source,
ecosystem,
GitHub.
A
A
D
I
mean
we
can
go
the
full
hour.
This
is
a
so
remember
before
we
had.
We
were
just
restricted
to
40
45
minutes
because
we
were
using.
We
were
using
Zone
Zoom
locally,
but
since
we've
gotten
some
good,
some
good
zoom
links
from
from
the
openness
itself,
we
take
the
full
hour
if
required,
otherwise,
there's
nothing
else.
We
could.
We
could
yeah.
A
The
thanks
for
the
reminder,
Jay
on
my
calendar.
It's
it's
only
45
minutes
and
somebody
chose
to
schedule
a
15-minute
meeting
with
me
right
now.
Yeah
I
have
to
jump
any
other
final.
B
D
Actually
crab,
we
were
waiting
on.
You
I
think
I.
Think
that
last
meeting,
that
was,
you
would
pull
political
orchestrate
us
getting
in
front
of
all
three
I
think
that
I
think
the
best
practices,
the
end
users
groups
together
pulling
those
groups
together
so
that
we
can
just
do
one.
D
One
presentation
to
all
three
I
think
was
best
practices.
I
think
it
was
then
uses
that
well
I
want
to
say
the
education
sake
for
some
reason,
but
I
can't
I.
Can't
I
can't
remember
that
that'll.
B
Be
a
challenge
since
we
all
have
pretty
distinct
schedules,
but
I
will
do
my
best,
the
best
practices
group
and
why
I
asked
is
we're
meeting
tomorrow.
If
you
and
we
had
some
time
on
the
docket
before
we
start
our
backlog,
triage.
D
Yeah
I
think,
let
me
let
me
check
the
calendar
there
Adrian,
you
know
what,
while
we
do
this
after
we
get
off
the
call,
Adrian
and
I
will
check
the
calendar,
see
if
we
can
make
that
job
come
on
I'm,
I'm,
good
to
go
or.
B
Shoot
me
a
note
with
the
other
groups,
aside
from
end
user.
If
you
remember
what
the
third
one
was
and
I'll
try
to
start
a
thread
and
include
you,
you
know
what
I'm
at
to.
B
Doodle,
when
fantastic.
A
Thanks
Rob
welcome,
okay
I
will
see
you
all
later
have
a
great
day.