It
is
an
interesting
time
for
everyone
concerned
with
open
source
vulnerabilities.
The
U.S.
Executive
Order
on
Improving
the
Nation’s
Cybersecurity
requirements
for
vulnerability
disclosure
programs
and
assurances
for
software
used
by
the
US
government
will
go
into
effect
later
this
year.
Finding
and
fixing
security
vulnerabilities
has
never
been
more
important,
yet
with
increasing
interest
in
the
area,
the
vulnerability
management
space
has
become
fragmented—there
are
a
lot
of
new
tools
and
competing
standards.
In
2021,
we
announced
the
launch
of
OSV,
a
database
of
open
source
vulnerabilities
built
partially
from
vulnerabilities
found
through
Google’s
OSS-Fuzz
program.
OSV
has
grown
since
then
and
now
includes
a
widely
adopted
OpenSSF
schema
and
a
vulnerability
scanner.
In
this
blog
post,
we’ll
cover
how
these
tools
help
maintainers
track
vulnerabilities
from
discovery
to
remediation,
and
how
to
use
OSV
together
with
other
SBOM
and
VEX
standards.
Vulnerability
Databases
The
lifecycle
of
a
known
vulnerability
begins
when
it
is
discovered.
To
reach
developers,
the
vulnerability
needs
to
be
added
to
a
database.
CVEs
are
the
industry
standard
for
describing
vulnerabilities
across
all
software,
but
there
was
a
lack
of
an
open
source
centric
database.
As
a
result,
several
independent
vulnerability
databases
exist
across
different
ecosystems.
To
address
this,
we
announced
the
OSV
Schema
to
unify
open
source
vulnerability
databases.
The
schema
is
machine
readable,
and
is
designed
so
dependencies
can
be
easily
matched
to
vulnerabilities
using
automation.
The
OSV
Schema
remains
the
only
widely
adopted
schema
that
treats
open
source
as
a
first
class
citizen.
Since
becoming
a
part
of
OpenSSF,
the
OSV
Schema
has
seen
adoption
from
services
like
GitHub,
ecosystems
such
as
Rust
and
Python,
and
Linux
distributions
such
as
Rocky
Linux.
Thanks
to
such
wide
community
adoption
of
the
OSV
Schema,
OSV.dev
is
able
to
provide
a
distributed
vulnerability
database
and
service
that
pulls
from
language
specific
authoritative
sources.
In
total,
the
OSV.dev
database
now
includes
43,302
vulnerabilities
from
16
ecosystems
as
of
March
2023.
Users
can
check
OSV
for
a
comprehensive
view
of
all
known
vulnerabilities
in
open
source.
Every
vulnerability
in
OSV.dev
contains
package
manager
versions
and
git
commit
hashes,
so
open
source
users
can
easily
determine
if
their
packages
are
impacted
because
of
the
familiar
style
of
versioning.
Maintainers
are
also
familiar
with
OSV’s
community
driven
and
distributed
collaboration
on
the
development
of
OSV’s
database,
tools,
and
schema.
Matching
The
next
step
in
managing
vulnerabilities
is
to
determine
project
dependencies
and
their
associated
vulnerabilities.
Last
December
we
released
OSV-Scanner,
a
free,
open
source
tool
which
scans
software
projects’
lockfiles,
SBOMs,
or
git
repositories
to
identify
vulnerabilities
found
in
the
OSV.dev
database.
When
a
project
is
scanned,
the
user
gets
a
list
of
all
known
vulnerabilities
in
the
project.
In
the
two
months
since
launch,
OSV-Scanner
has
seen
positive
reception
from
the
community,
including
over
4,600
stars
and
130
PRs
from
29
contributors.
Thank
you
to
the
community,
which
has
been
incredibly
helpful
in
identifying
bugs,
supporting
new
lockfile
formats,
and
helping
us
prioritize
new
features
for
the
tool.
Remediation
Once
a
vulnerability
has
been
identified,
it
needs
to
be
remediated.
Removing
a
vulnerability
through
upgrading
the
package
is
often
not
as
simple
as
it
seems.
Sometimes
an
upgrade
will
break
your
project
or
cause
another
dependency
to
not
function
correctly.
These
complex
dependency
graph
constraints
can
be
difficult
to
resolve.
We’re
currently
working
on
building
features
in
OSV-Scanner
to
improve
this
process
by
suggesting
minimal
upgrade
paths.
Sometimes,
it
isn’t
even
necessary
to
upgrade
a
package.
A
vulnerable
component
may
be
present
in
a
project,
but
that
doesn’t
mean
it
is
exploitable–and
VEX
statements
provide
this
information
to
help
in
prioritization
of
vulnerability
remediation.
For
example,
it
may
not
be
necessary
to
update
a
vulnerable
component
if
it
is
never
called.
In
cases
like
this,
a
VEX
(Vulnerability
Exploitability
eXchange)
statement
can
provide
this
justification.
Manually
generating
VEX
statements
is
time
intensive
and
complex,
requiring
deep
expertise
in
the
project’s
codebase
and
libraries
included
in
its
dependency
tree.
These
costs
are
barriers
to
VEX
adoption
at
scale,
so
we’re
working
on
the
ability
to
auto-generate
high
quality
VEX
statements
based
on
static
analysis
and
manual
ignore
files.
The
format
for
this
will
likely
be
one
or
more
of
the
current
emerging
VEX
standards.
Compatibility
Not
only
are
there
multiple
emerging
VEX
standards
(such
as
OpenVEX,
CycloneDX,
and
CSAF),
there
are
also
multiple
advisory
formats
(CVE,
CSAF)
and
SBOM
formats
(CycloneDX,
SPDX).
Compatibility
is
a
concern
for
project
maintainers
and
open
source
users
throughout
the
process
of
identifying
and
fixing
project
vulnerabilities.
A
developer
may
be
obligated
to
use
another
standard
and
wonder
if
OSV
can
be
used
alongside
it.
Fortunately,
the
answer
is
generally
yes!
OSV
provides
a
focused,
first-class
experience
for
describing
open
source
vulnerabilities,
while
providing
an
easy
bridge
to
other
standards.
CVE
5.0
The
OSV
team
has
directly
worked
with
the
CVE
Quality
Working
Group
on
a
key
new
feature
of
the
latest
CVE
5.0
standard:
a
new
versioning
schema
that
closely
resembles
OSV’s
own
versioning
schema.
This
will
enable
easy
conversion
from
OSV
to
CVE
5.0,
and
vice
versa.
It
also
enables
OSV
to
contribute
high
quality
metadata
directly
back
to
CVE,
and
drive
better
machine
readability
and
data
quality
across
the
open
source
ecosystem.
Other
emerging
standards
Not
all
standards
will
convert
as
effortlessly
as
CVE
to
OSV.
Emerging
standards
like
CSAF
are
comparatively
complicated
because
they
support
broader
use
cases.
These
standards
often
need
to
encode
affected
proprietary
software,
and
CSAF
includes
rich
mechanisms
to
express
complicated
nested
product
trees
that
are
unnecessary
for
open
source.
As
a
result,
the
spec
is
roughly
six
times
the
size
of
OSV
and
difficult
to
use
directly
for
open
source.
OSV
Schema’s
strong
adoption
shows
that
the
open
source
community
prefers
a
lightweight
standard,
tailored
for
open
source.
However,
the
OSV
Schema
maintains
compatibility
with
CSAF
for
identification
of
packages
through
the
Package
URL
and
vers
standards.
CSAF
records
that
use
these
mechanisms
can
be
directly
converted
to
OSV,
and
all
OSV
entries
can
be
converted
to
CSAF.
SBOM
and
VEX
standards
Similarly,
all
emerging
SBOM
and
VEX
standards
maintain
compatibility
with
OSV
through
the
Package
URL
specification.
OSV-Scanner
today
also
already
provides
scanning
support
for
the
SPDX
and
CycloneDX
SBOM
standards.
OSV
in
2023
OSV
already
provides
straightforward
compatibility
with
established
standards
such
as
CVE,
SPDX,
and
CycloneDX.
While
it’s
not
clear
yet
which
other
emerging
SBOM
and
VEX
formats
will
become
the
standard,
OSV
has
a
clear
path
to
supporting
all
of
them.
Open
source
developers
and
ecosystems
will
likely
find
OSV
to
be
convenient
for
recording
and
consuming
vulnerability
information
given
OSV’s
focused,
minimal
design.
OSV
is
not
just
built
for
open
source,
it
is
an
open
source
project.
We
desire
to
build
tools
that
will
easily
fit
into
your
workflow
and
will
help
you
identify
and
fix
vulnerabilities
in
your
projects.
Your
input,
through
contributions,
questions,
and
feedback,
is
very
valuable
to
us
as
we
work
towards
that
goal.
Questions
can
be
asked
by
opening
an
issue
and
all
of
our
projects
(OSV.dev,
OSV-Scanner,
OSV-Schema)
welcome
contributors.
Want
to
keep
up
with
the
latest
OSV
developments?
We’ve
just
launched
a
project
blog!
Check
out
our
first
major
post,
all
about
how
VEX
could
work
at
scale.
About Author
