►
Description
How’s your Supply Chain with your insecure OSS ingestion? - James Holland, Citi
---
Open source software is pervasive in data centers, consumer devices, and applications. Securing open source supply chains requires a combination of automated tooling, best practices, education, and collaboration.
Join the growing list of organizations supporting the advancement of securing open source technology and funding the development and adoption of OpenSSF initiatives. https://openssf.org/
A
So
I'm
just
going
to
go
through
what
we're
doing
with
supply
chain
and
how
you're
ingesting
software
and
libraries
into
your
ecosystems
now
I'm
not
going
to
go
into.
This
is
what
I'm
going
to
try
and
cover
I'm
not
going
to
go
into
a
huge
detail
about
supply
chain,
I'm
sure,
there's
a
lot
more
people
in
the
room
that
are
know
a
lot
more
about
it
than
I
do
well
those
people
that
was
roughly
there
and
generally
everywhere,
a
little
bit
of
background.
A
We
in
city
of
being
the
whole
supply
chain
area
is
impossible
to
cover
in
here,
as
I
said,
but
we
do.
City
has
a
real
extensive
program
looking
at
supply
chain
program,
and
we
see
this
as
a
real
holistic
problem
that
needs
a
a
a
a
real
tight
look
at
all
the
areas
that
we
need
to
fix,
so
we're
looking
at
fixing
in
several
areas.
These
are
the
problem
areas
that
we
want
to
hit
now.
Obviously,
we've
donated
to
the
line.
Explanation,
the
ssf.
A
What
was
Fresno
or
whatever
it's
called
today,
I
can't
remember
exactly
whose
name
the
next
bit
we're
looking
at
is
what
I
would
call
the
skew
ingestion
or
cssi?
Would
you
want
to
call
it
CSI,
but
of
course
that
can
do
a
few
problems.
A
I
did
joke
with
John
Meadows
that
we
should
call
it
CSI,
Miami
or
something
like
that,
but
I
don't
think
he
looks
great
in
Bermuda
shorts
and
talking
about
John.
He
leads
I
work
for
John
in
the
city
and
he's
leading
the
CNF
working
groups
on
software
supply
chain
working
group
and
he's
also
the
board
member.
So
this
is
all
tied
into
what
we're
trying
to
do
in
city
and
trying
to
actually
help
the
community
and
push
that
back
into
the
community
as
well
and
help
them
okay.
A
But
before
I,
get
on
to
the
meat
of
the
talk,
can
I
ask
a
few
questions
or
raise
of
hands?
How
many
of
you
use
an
artifact
manager
to
deal
with
your
artifacts
within
your
your
organizations
like
Arts,
Factory,
Nexus,
yeah,
quite
a
few
okay,
but
it's
a
bit
half
and
how
many
of
you
are
ingesting,
your
library
straight
into
your
pipelines
straight
from
the
web?
A
A
A
few!
That's
good!
There's
a
few
wavings
I'm,
not
sure.
Okay,
that's
good
to
know
so.
I
think
we're
in
the
right
area
here
to
look
at
Okay.
So
we've
got
a
proposal,
continue
to
secure
software
ingestion,
we're
trying
to
socialize
that
and
we're
looking
for
feedback
on
what
we're
doing.
Is
it
the
right
thing?
Is
it
not
the
right
thing
and
city
is
working
with
our
partners?
You
can
drop
it
in
the
corner
to
produce
something
around
this.
Okay,
a
little
bit
of
the
background.
A
You
know
I
think
we've
already
touched
on
it
in
this
in
a
few
talks
before
with
Crow
and
Martha,
and
also
the
secure
scorecards
talk
given
earlier
on,
you
can't
have
a
supply
chain
with
you
have
no
understanding
of
mature
dependencies.
If
you
don't
know
knowing
what
your
dependencies
are
and
what
their
the
level
of
security
there
are
at
all,
how
old
they
are
or
are
they
may
be
maintained,
I'm,
not
sure
you
should
be
using
them
within
your
applications
and
I.
A
Think
that's
I
think
we
can
all
agree
on
that,
but
what
you
need
to
look
at
and
the
score
has
really
helped
when
Brian
Russell
from
Google,
you
know
using
working
in
conjunction
with
them
on
using
scroll
cars,
but
we're
also
using
other
pieces
of
their
data.
It's
interesting
what
we
should
be
looking
at
so
if
you're
looking
at
things
like
is
the
maintainer
from
a
sanctioned
country.
Now
for
some
organizations
that
might
not
really
matter
for
American
Banks,
it
tends
to
be
a
bit
of
a
problem.
A
You
know
inactivity
on
the
repos
and
we've
all
seen
these
questions
before
you
know.
With
these
there's
no
controls
or
code
views
that
the
latest
one,
the
npm
for
each
package,
the
email
domain
was
taken
over
they
trip
over
the
package,
and
then
they
had
control
of
35
000
packages,
and
only
because
that
person
who
did
that
was
actually
trying
to
protect
it.
It
wasn't
a
nefarious
activity.
So
all
these
things
we
need
to
start
looking
at
to
assess
the
maturity
of
the
libraries
and
I.
A
Think
that's
what
I'm
trying
to
get
to
is.
How
do
you
assess
what,
as
an
organization
I,
should
allow
in
okay,
the
historically
there's
been
no
tools
to
help
you
do
this?
It's
all
been
a
manual
process.
You
know
there's
manual
scorecards
as
I
like
to
call
them
and
there's
a
example
on
the
screen.
I,
don't
know
if
you
can
read
it.
This
is
what
I've
been
using
for
the
last
20
odd
years,
and
this
was
a
colleague
of
mine
when
I
was
at
hid,
called
Francois
Eric
goyamash.
A
We
came
up
with
this
spreadsheet
and
this
is
what
we
use
to
assess
the
maturity
of
libraries.
This
is
what
we
had
to
do
for
Department
of
Defense,
because
they
wanted
to
know
everything,
absolutely
everything
about
what
was
being
used,
and
this
still
wouldn't.
Let
us
use
the
binaries
at
all.
A
Everything
had
to
be
brought
built
from
source
code,
so
we
had
to
take
everything
and
then,
if
you
didn't
trust
it,
you
got
to
justify
every
piece
of
code,
every
single
library,
and
then
you
had
to
write
an
abstractation
layer
on
top
of
it
to
build
it.
Now
you
can
imagine
non-doctorized
environments.
Vms
were
not
really
a
known
thing
quantity,
so
we
were
having
to
build
all
this
source
code
for
Key,
Management
Systems
to
a
Department
of
Defense
and
and
other
organizations,
and
it
was
even
the
article
database
had
to
be
delivered.
A
A
source
code
to
the
dod
I
may
have
to
build
it
from
escrow
and
it
would
take
about
eight
days
to
build
source
code.
So
this
is
another
product
from
my
previous
colleague
is
John
Christopher.
He
built
all
this
around
this
and
it
was
called
active,
Builder
I
still
think
to
this
day.
If
you
sold
that
product
now,
it
would
make
millions
so
I
think
it's
you
know
there
are.
There
are
historic
tools
there.
Are
they
publicly
available?
Not
really
that's
the
problem.
Thank
you.
A
Phil's,
as
I
said
tools
have
evolved.
We
now
have
scorecards.
We
all
now
have
the
best
practices,
badges,
there's
other
Intel
fees.
You
know
this
s-bombs
coming
in
there's
salsa,
there's
Vex,
there's
Kev
and
I
do.
If
anybody
knows
what
Kev
is
non-explodable
vulnerabilities,
you
know
all
these
things
is:
how
do
you
as
an
organization,
decide
in
a
policy
driven
way
to
actually
use
this
stuff
and
actually
action
it
within
your
organization?
A
So,
although
they're
there,
how
do
you
automate
it
and
use
it?
Okay,
and
this
is
more
towards
the
user
and
the
user
experience,
the
user,
endpoint
user
cases
and
that's
what
we're
trying
to
look
at
so
the
tools
do
exist.
There
are
some
tools
out
there
that
do
exist
they're
at
the
moment.
Most
of
them
are
proprieta
property.
You
know
they
have
limited
scorecards
information,
they're
limited
aggregation
because
it's
not
just
one
form
of
scorecard
or
Intel
feed.
A
Okay,
you
want
to
normally
aggregate
across
several
Intel
fields
and
they
might
not
necessarily
allow
you
that
ability,
limited
policies
and
I
mentioned
you
this
about
no
separation
between
pul
policy.
That's
a
very
design
decision.
We
made
moving
on
take
prol
as
the
entry
point
in
and
the
scare
test.
So
sometimes
you
will
want
to
actually,
as
an
organization
say
at
the
top
level.
Actually,
I
want
to
deny
straight
away
this.
A
This
classification
of
Purl
I
want
to
deny
all
Apache
nobody's
going
to
do
that,
but
you
know
that
might
be
the
level
you
want
to
do
it
or
of
a
specific
version
of
a
library
we
have
that
in
city
we
have
our
own
policy
around
that
we
say
strip.
You
cannot
use
this
classification
or
Library
play
at
all.
Okay,
all
from
this
sort,
Source
from
sourceforge
or
from
this
repository
just
that
and
straightforce.
A
So
that's
one
sort
of
policy
and
then
there's
another
sort
of
policy
which
is
the
scan
or
test
that
you're
gonna
run
on
your
libraries
to
do
the
assessments.
That
policy
is
a
little
bit
more
across
the
board
and
it
has
different
implications
which
I'll,
try
and
touch
on
okay,
and
we
want
to
be.
We
want
to
get
rid
of
the
soil.
We
don't
want
to
give
this
to
the
developers
to
make
these
assessments
all
the
time.
It's
if
you
can
have
the
feeds.
A
A
Let
me
just
ship,
the
nuts
I
think
there's
something
else.
I
want
to
say.
So
what
we've
been
working
on
is
automating
the
software
ingestion
and
The
Grooming.
So
this
is
a
continuous
process.
It's
not
just
bring
it
in
I'm
done.
You
know
every
day.
Is
there
a
change
in
the
policy?
Is
there
a
change
in
the
intelligence?
A
Anything
that
trigger
this?
Is
this
might
cause
something
else?
We
need
to
go
through
that
process
again:
okay,
we're
looking
for
a
flexible
way
of
setting
an
acceptable
risk
policy
for
an
organization.
It's
too
difficult
at
the
moment.
For
a
lot
of
Enterprises
to
understand
much
the
license,
that's
a
big
enough
problem
for
them
as
it
is,
and
the
vulnerability
levels.
If
you
start
adding
in
all
these
other
data
points,
it
becomes
really
tricky
for
them
to
know
what
is
the
right
thing
to
do
so,
giving
them
an
ability
to
say
right.
A
This
is
a
standard
set
of
policies.
You
can
change
it
for
your
organization
and
then
you
can
take
that
and
run
with
that.
Okay
eliminates
all
I've
said,
touch
that
replace
Weavers
see
a
lot
of
organizations
are
waivers.
We
can
do
that
with
the
Purl
case.
That's
by
the
separation
of
policy
from
the
assessment
and
I've
already
touched
on
this
as
well.
A
When
we're
changing
any
policy,
we
need
to
re-evaluate
every
time,
and
how
is
that
automated?
What's
the
effect
I'm
testing
that,
if
I
make
a
test,
if
I
make
a
change
to
a
policy,
how
do
I
know
what's
going
to
affect
my
organization
what
libraries
are
going
to
ban
if
I
change
this
policy,
so
I
need
to
be
able
to
run
that?
Okay?
So
that's
what
we're
looking
to
do?
A
Where
am
I?
So
that's
some
of
the
aims
we
had
a
couple
of
problems,
I
would
say
some
of
the
ingestional
top
levels
or
should
we
bring
in
the
full
depository
for
us?
It
didn't
make
a
lot
of
sense,
and
people
out
will
have
different
opinions
on
this,
but
we
thought
if
we're
suddenly
asked
for
react.
Who
should
we
just
bring
in
the
react?
A
Library,
no
I
think
we,
you
can
either
use
react
or
you
can't
use
react
and
if
that's
all,
that
dependence
underneath
it
and
some
of
them
we
can't
use,
and
that
therefore
stops
you
using
it.
We
won't
block
react,
but
we'll
just
say
no.
This
is
a
failure,
because
this
library's
failed
and
give
the
feedback
to
the
developer.
You
can't
use
this
because
of
this
reason
it's
failing
the
policy
on
that
particular
transitive
dependency
and
we
can't
find
an
alternative
for
you.
A
Okay
package
managers
are
a
little
bit
tricky
they
how
they
discover
and
they
Traverse
their
purchase.
So
we've
made
sure
that
our
approach
is
using
a
polyglot
on
the
package
managers
to
identify
the
correct
dependencies
in
the
trees,
and
it
also
comes
into
another
problem
that
we
come
across
about
when
there's
a
range
on
the
transitive
appendices.
We
find
there's
a
couple
of
failures
that
are
occurring
where
the
latest
library
that
we'll
look
at
for
that
range
may
fail.
A
So
we're
trying
to
work
on
the
next
one
that
will
actually
transverse
the
other
alternatives
to
see
if
we
can
get
gets
to
an
acceptable
library
that
the
developer
can
use.
So,
if
it
says,
is
you
know,
you
can
use
versions,
one
two
or
three
and
version
three
has
got
a
known
vulnerability.
You
can't
use
because
it
breaks
policy,
then
we'll
try
and
ingest
two
and
make
sure
that
in
meeting
policy
and
go
yeah,
that's
fine
to
go.
A
Okay,
it's
quite
a
tricky
one
to
do
that,
because
the
package
managers,
don't
necessarily
let
you
do
that
as
a
normal
pull
down
unless
to
explore
that
tree.
Okay
and
one
of
the
big
things
as
well
on
this
in
and
why
it's
driven
us
a
little
bit
within
city
is
the
work
about
looking
at
different
assured
suppliers
of
code,
so
Google
AOS
I
should
open
source
Alpha
Omega.
We
want
to
take
advantage
of
this
okay.
We
want
to
be
able
to
make
a
decision
that
somebody's
ingesting
Apache
local
Jay.
A
A
If
you're
doing
package
replications-
and
you
do
it
under
the
covers
so
you're
hiding
it-
which
some
organizations
do
do-
that
will
cause
problems.
So
we
could,
we
were
discovering
that
we
could
possibly
use
our
Vex
information
to
say
this
is
log4j.
Apache
look
4G
2.14,
it
doesn't
have
this
and
vulnerability
because
of
these
reasons,
we've
actually
transposed
or
relocated.
The
package
from
Google
assured
a
resource
to
the
Apache
one,
because
it's
not
a
fork.
Okay,
that's
going
to
change
over
time.
I
think
that's
a
different
version.
We're
gonna,
they're
gonna,
go
I.
A
Think
to
we
will
put
into
a
different
version,
actually
put
the
audience
back
on
the
developer,
because
it
becomes
a
different
deployment
model
and
different
issues
for
the
deployers
to
say.
Okay
they've
now
told
me
I'm,
using
a
Google
shared
open
source
version,
but
does
that
mean
I
have
to
update
my
package
with
the
new
version
library
and
all
these
problems
so
because
it
can
there's
different
issue
Department
issues
there,
design
decision,
I,
think
I
mentioned
already
the
P
URL
I
think
that's
for
our
use
cases.
That's
what
we
do,
there's
nothing
to
stop.
A
Stopping
anybody
who
wants
to
take
the
project
and
change
that,
but
it
seems
to
be
covers
most
of
the
bases.
What
we
want
to
do
is
with
open
source
libraries,
proprietary,
libraries
and
also
container
container
images
as
well.
Okay
and
I've
mentioned
the
software,
the
separation
policies,
okay,
so
this
is
a
couple
of
the
use
cases
that
we
were
looking
at
and
the
blues.
This
is
the
are
sort
of
our
road
map
of
how
we're
trying
to
draw
this
out
in
the
next
couple
of
months.
A
A
You
want
to
take
it
from
a
developer's
point
of
view
that,
obviously
they
want
to
request
tooling
for
their
standard
tuning.
Okay,
they
want
to
use
their
Maven
package
managers;
they
want
to
use
it
going
to
artifactory,
so
we
don't
want
to
make
them
have
to
go
to
us.
We
want
to
integrate
that
into
how
they're
using
their
tuning
today,
so
they
just
don't
see
it.
A
Okay,
if
that's
that's
the
end,
if
they
want
to
see
why
a
library's
been
rejected,
we
need
to
be
able
to
give
them
access
to
the
evidence
store
to
show
them
why
what
the
status
of
the
scan
is
if
it
takes
a
longer
time
again.
This
leads
to
different
problems,
whether
you
have
a
clean
repo
model
for
production
and
you
have
a
developer
having
access
to
libraries
immediately.
It
comes
with
different
problems
here,
if
you're,
installing
npm
or
python
packages,
what
do
they
do
on
the
install?
A
You
know,
there's
some
issues
there,
so
I
think
the
deployment
model
is
up
to
each
individual
Enterprise.
That
takes
this
on
to
say,
where
they're
going
to
accept
the
delay
or
and
stop
the
developers
working
on
that
Library
immediately
or
are
they
going
to
let
them
carry
on
at
risk
depends
on
how
they
want
to
do
that,
but
I
don't
want
to
we're
not
trying
to
do
force
that
on
to
any
organization,
that's
to
them
to
see
how
that
happens,
we'll
just
give
them
the
tools
to
make
a
decision
themselves.
A
Okay,
notifications,
it's
so
Downstream
systems
can
make
other
decisions
as
well.
So
if
we
come
in,
we
know
we
have
a
lot
of
compliance
reporting
within
City.
That
needs
to
know
if
we've
failed,
the
library,
so
we
can
inform
our
stock
teams,
we
can
put
a
report
on
Downstream
systems
to
say,
go
and
tell
me
everything
else.
That's
using
this
library,
because
we've
now
had
an
Intel
feed
update
that
is
now
telling
us.
A
We
have
to
say
no,
no,
no
you've
got
two
days
to
change.
This
you've
got
seven
days
to
change
this,
so
you've
got
14
days
to
change
us,
depending
on
the
risk
and
scope
of
those
applications.
Okay
and
I
think
that
comes
into
the
interface
and
that
will
obviously
cause
notifications,
but
we'll
get
that
on
there.
The
next
one
we
want
to
do
is
obviously
the
policy
changes.
Prl
policy
changes
and
I'll
go
through
that
in
a
little
bit
in
a
bit
of
detail
and
as
soon
as
a
developer
is.
A
A
We
want
to
make
sure
that,
okay,
if
we
know
where
this
repo
is
and
we
can
get
a
feed
off
there,
we'll
now
start
monitoring
to
see
if
there's
new
releases
are
coming
out.
If
they
come
out,
let's
go
and
fetch
them
and
perform
the
policy
checks
on
beforehand
and
make
sure
they're
in
the
repo
beforehand.
Okay,
there's
some
of
the
tests
we
want
to
do
which
I'll
go
on
the
next
slide
are
a
bit
more,
should
we
say,
long-winded
and
cause
several
hours
delay.
Okay
and
the
other
one
is
about
the
scan
policies.
A
Now,
if
I
change,
when
an
individual
package
layer,
what
the
policy
is
that's
fairly
simple,
listen,
I'm,
a
denying
or
allowing
log
4G
if
I
change,
what
I'm
doing
for
software
composition,
analysis,
I,
say:
I
go
from.
We
only
allow
libraries
in
that.
Don't
have
criticals
to
change
the
policy
to
we
only
load
libraries
in
that
don't
have
highs
and
criticals.
A
Can
you
imagine
the
impact
that
might
have
on
an
organization
if
I
did
that
in
city
I
changed
that
policy
I
would
probably
have
about
a
thousand
bricks
thrown
in
my
head
very
quickly
and
told
where
the
door
is
so
we
need
to
be
able
to
test
test
the
policy
test,
the
policy
so
whatever
changes
you
want
to
make
to
the
scam
policy
unless
any
scam
policy,
you
certainly
code
analysis
package,
explosion,
software
composition,
analysis,
you
know.
A
If
we're
changing
that
policy,
we
need
to
be
able
to
test
it
to
see
what
the
effect
is
on
that
policy
change.
Okay,
and
only
then,
when
that's
accepted,
can
you
then
commit
that
scum
policy
and
that
will
cause
a
massive
rescanning,
because
everything
that
changes
on
it
all
the
effective
policies
on
changes
on
it
will
force
a
re-injection
or
a
re-assessment
of
the
Intel
or
scan
data?
That's
been
harvested
on
the
initial
ingestion,
okay,
we
may
just
force
the
re-ingestion
or
we
just
do
a
re-evaluation
of
the
scan
data.
Okay,.
A
No,
this
is
probably
the
heart
of
the
system,
so
you
know
when
you
ingest,
appear
I'll
speed
up
in
just
a
PRL,
as
a
mentioned
before
I
keep
on
hitting
the
wrong
button.
A
I'm
going
to
look
at
the
policy
and
there's
very
simple
policies
on
PRL
I
would
say:
there's
a
block
polish
flow,
which
I've
mentioned
before
on
my
block
Apache
log
4G.
For
some
reason-
or
this
is
standard
flow
or
there's
an
assured
flow
from
Google
to
shoot
up
the
source
or
wherever
and
then
there's
the
explode
flow.
I
python,
npm
I
come
in
I
can
make
an
initially
said.
If
there's
no
policy
of
a
library,
it's
going
to
go
through
the
standard
flow,
we're
going
to
come
in,
that's
fine
or
it's
not
fine.
A
The
flow
will
be
selected.
It
comes
through
here,
we'll
do
the
standard
flow
go
and
get
to
the
scorecards
it's
Martha
and
talked
about
earlier
on
we're
using
this
heavily.
It
might
not
be
just
scorecards,
it
might
not
be
best
practices
badges.
A
The
aim
we
want
to
hear
was
to
aggregate
across
all
the
fees
that
we
got.
We
have.
We
have
up
to
20
different
feeds
coming
into
the
bank.
We
want
all
of
that
to
be
aggregated.
Okay,
other
providers,
other
providers,
although
I
know
they
have
different
fees
as
well.
Okay,
so
we
want
to
try
and
aggregate
that
came
back.
We
can
go
back.
Look
at
the
policy,
see
what
the
policy
says.
A
B
A
It
might
go
say:
actually
we
might
have
a
policy
come
in
see
you're
gonna
get
this
Lobby
straight
from
Google.
Okay,
we'll
still
do
some
checks
on
it.
The
interesting
ones,
I
would
say,
is
probably
going
to
be
the
more
advanced
flows,
and
that
would
be
the
dash
flows
and
sandboxing
of
this
I
would
like
to
put
all
these
libraries
into
containers
export
them
time
series
them
see
what
happens.
Okay,
npm
python.
They
do
some
funny
things
on
install,
sometimes
sometimes
they
don't,
but
as
a
de-risk
exercise
of
the
bank
and
and
the
process.
A
I
think
that's
something
that
normally
you've
done
manually
I,
don't
think!
That's
something
it's!
We
can
do
this,
so
we
can
monitor
this
in
an
automated
fashion
very
quickly,
especially
thanks
to
Rowan
for
the
suggestion
of
the
Google,
sorry
Linux
time,
namespace
about
you,
know,
changing
the
time
space
and
see
what
happens.
That's
a
great
example
of
what
we
would
like
to
do
and
get
those
ideas
in
okay
and
the
last
and
not
least,
is
building
from
source.
A
This
will
be
hell:
okay,
everything's
different
I'd
love
to
see
this
is
a
real.
This
is
not
me
going
on
to
about
developers
or
reposits.
Not.
This
is
how
difficult
it
is
for
developers,
but
coming
up
with
a
standardized
where
we
can
build
things
that
we
can
pick
up
and
just
build
straight
away.
If
it
was
a
Docker
build
file
within
each
of
the
repos.
That
would
be
fantastic.
We
could
all
do
this
build
from
source,
so
you
don't
necessarily
have
to
trust
the
button
if
you
don't
want
to
and
that
becomes
a
real
problem.
A
I
think
that's
all
I
wanted
to
say
So
currently
we're
in
early
Alpha
I
I
can't
give
you
a
demo,
because
I
can't
get
access
to
kubernetes
on
my
machine.
It's
silly
because
it's
tied
down
everything's
solid
every
time.
I
can't
get
access
to
our
awsc
environments
to
demonstrate
it
because
it's
public,
so
I
can't
do
it
and
I
can't
show
you
the
video,
because
I
couldn't
actually
download
it
onto
my
city
laptop
so
I
do
I
can
give
you
a
link.
A
I'll,
give
you
a
link,
I'll
push
it
out,
but
if
anybody's
interested
mail
me
I'll,
send
you
the
link
to
it,
I
can
do
that.
That's
fine
initial
focus
is
we've
we've
pretty
much
finished
the
alpha
moments:
production
ready
for
npm
we're
looking
to
do
Java,
then
python
is
next
and
yeah.
That's
it!
That's
the
end
of
my
talk
and
any
questions.
A
B
B
A
So
we
have
a
deep
duplication
within
the
our
software,
so
we
we
have
it
on.
A
Composition
analysis,
vendors,
we've
now
got
sneaker
now
giving
us
a
pearl
lookup
on
libraries.
Their
vulnerabilities
blackduck
do
as
well
there's
several
other
sevo.
This
is
osv
as
well.
Has
it
so
you
can
go
and
get
the
vulnerability
information
based
on
per
URL
now
for
most
of
the
vendors
and
actually
that's
baked
into
OS
dependency
track
as
standard.
A
So
let
me
give
you
a
little
indication
of
some
of
the
things
that
we're
doing
as
well,
but
you
can
it's
it's
a
universal
identifier
that
we
can
use
not
only
on
the
vulnerability
systems,
but
also
our
lookup
and
ingestion
systems.
A
Again,
I
think
I
mentioned
I,
really
like
feedback
around
that
you
know
people
to
critique
the
design.
Look
at
how
we
can
improve
it.
We're
really
looking
forward
to
people
actually
giving
us
a
hard
time
and
say:
how
are
we
going
to
improve
it
and
come
in
and
give
some
support?
Okay,
thank
you
for
questioning
anywhere
else.