klss777/Adobe
Stock
Endor
Labs,
a
software
firm
that
facilitates
the
security
and
maintenance
of
open-source
software,
has
released
a
report
identifying
the
top
10
security
and
operational
risks
in
open-source
software
in
2023.
Carried
out
by
the
Endor
Labs’
Station
9
team,
the
report
featured
contributions
from
more
than
20
industry
chief
information
security
officers
from
notable
companies
including
Adobe,
HashiCorp,
Discord
and
Palo
Alto
Networks.
According
to
Endor
Labs,
the
over-reliance
on
open-source
software
has
recorded
some
known
vulnerabilities,
captured
as
Common
Vulnerabilities
and
Exposures;
these
vulnerabilities
are
often
overlooked
and
could
be
exploited
by
attackers
if
not
fixed.
“Open-source
software
represents
a
goldmine
for
application
developers,
but
it
needs
security
capabilities
that
are
equally
effective,”
said
Henrik
Plate,
lead
security
researcher
at
Endor
Labs.
“In
an
environment
where
more
than
80%
of
the
code
in
new
applications
can
come
from
existing
repositories,
it
is
clear
there
are
serious
risks
Involved.”
Top
open-source
risks
of
2023
Highlighted
below
are
the
key
takeaways
of
Endor
Labs’
report
about
the
top
10
open-source
risks
of
2023.
1.
Known
vulnerabilities
The
report
revealed
that
an
open-source
component
version
may
contain
vulnerable
code
accidentally
introduced
by
its
developers.
The
vulnerability
can
be
exploited
within
the
downstream
software,
potentially
compromising
the
confidentiality,
integrity
or
availability
of
the
system
and
its
data.
2.
Compromise
of
legitimate
package
According
to
Endor’s
report,
attackers
can
target
legitimate
resources
from
an
existing
project
or
distribution
infrastructure
to
inject
malicious
code
into
a
component.
For
example,
they
can
hijack
the
accounts
of
legitimate
project
maintainers
or
exploit
vulnerabilities
in
package
repositories.
This
type
of
attack
can
be
dangerous
since
the
malicious
code
can
be
distributed
as
part
of
a
legitimate
package
and
can
be
difficult
to
detect.
3.
Name
confusion
attacks
Attackers
can
create
components
with
names
that
resemble
those
of
legitimate
open-source
or
system
components.
The
Endor
Labs
report
revealed
that
this
could
be
done
through:
-
Typo-squatting:
The
attacker
creates
a
name
that
is
a
misspelling
of
the
original
component’s
name. -
Brand-jacking:
The
attacker
suggests
a
trustworthy
author. -
Combo-squatting:
The
attacker
plays
with
common
naming
patterns
in
different
languages
or
ecosystems.
These
attacks
can
be
used
to
trick
users
into
downloading
and
using
malicious
components
they
believe
are
legitimate.
4.
Unmaintained
software
Unmaintained
software
is
an
operational
issue,
according
to
the
Endor
Labs
report.
A
component
or
version
of
a
component
may
no
longer
be
actively
developed,
which
means
patches
for
functional
and
non-functional
bugs
may
not
be
provided
promptly
or
not
at
all
by
the
original
open-source
project.
This
can
leave
the
software
vulnerable
to
exploitation
by
attackers
who
target
known
vulnerabilities.
5.
Outdated
software
For
convenience,
some
developers
use
an
outdated
version
of
a
code
base
when
there
are
updated
versions.
This
can
result
in
the
project
missing
out
on
important
bug
fixes
and
security
patches,
leaving
it
vulnerable
to
exploitation.
6.
Untracked
dependencies
Project
developers
may
not
be
aware
of
a
dependency
on
a
component
for
several
reasons:
-
It
is
not
part
of
an
upstream
component’s
software
bill
of
materials. -
Software
composition
analysis
tools
are
not
run
or
do
not
detect
it. -
The
dependency
is
not
established
using
a
package
manager,
which
can
lead
to
security
issues,
as
vulnerabilities
in
the
untracked
dependency
may
go
unnoticed.
7.
License
and
regulatory
risk
A
component
or
project
may
not
have
a
license
or
may
have
one
that
is
incompatible
with
the
intended
use
or
whose
requirements
are
not
or
cannot
be
met.
Using
components
in
accordance
with
their
license
terms
is
crucial.
Failing
to
do
so,
such
as
using
a
component
without
a
license
or
not
complying
with
its
terms,
can
result
in
copyright
or
license
infringements.
In
such
cases,
the
copyright
holder
has
the
right
to
take
legal
action.
Additionally,
violating
legal
and
regulatory
requirements
can
limit
or
impede
the
ability
to
address
certain
industries
or
markets.
8.
Immature
software
An
open-source
project
may
not
follow
development
best
practices,
such
as
using
a
standard
versioning
scheme,
having
a
regression
test
suite,
or
having
review
guidelines
or
documentation.
This
can
result
in
an
open-source
component
that
does
not
work
reliably
or
securely,
making
it
vulnerable
to
exploitation.
Relying
on
an
immature
component
or
project
can
pose
significant
operational
risks.
For
instance,
the
software
that
depends
on
it
may
not
function
as
intended,
leading
to
runtime
reliability
issues.
9.
Unapproved
changes
(mutable)
When
using
components
that
are
not
guaranteed
to
be
identical
when
downloaded
at
different
times,
there
is
a
significant
security
risk.
This
is
demonstrated
by
attacks
such
as
the
Codecov
Bash
Uploader,
where
downloaded
scripts
are
piped
directly
to
bash
without
verifying
their
integrity
beforehand.
The
use
of
mutable
components
also
poses
a
threat
to
the
stability
and
reproducibility
of
software
builds.
10.
Under/over-sized
dependency
The
Endor
report
pointed
out
that
over/under-dependency
on
components
can
be
an
operational
risk.
For
instance,
small
components,
such
as
those
that
contain
only
a
few
lines
of
code,
are
vulnerable
to
the
same
risks
as
larger
components.
These
risks
include
account
takeovers,
malicious
pull
requests,
and
continuous
integration
and
continuous
development
pipeline
vulnerabilities.
On
the
other
hand,
huge
components
may
have
accumulated
many
features
that
are
not
necessary
for
standard
use
cases.
These
features
increase
the
component’s
attack
surface
and
may
introduce
unused
dependencies,
resulting
in
bloated
ones.
Steps
to
take
to
mitigate
these
open-source
risks
Here
are
tips
from
Endor
Labs
on
how
software
developers
and
IT
managers
can
mitigate
these
open-source
risks.
Regularly
scan
code
to
spot
compromised
packages
Preventing
compromised
packages
is
a
complex
issue
because
there
is
no
one-size-fits-all
solution.
To
address
this,
organizations
can
refer
to
emerging
standards
and
frameworks
such
as
the
OpenSSF
Secure
Supply
Chain
Consumption
Framework
(S2C2F).
They
can
select
and
prioritize
the
safeguards
that
best
suit
their
requirements
based
on
their
specific
security
needs
and
risk
tolerance.
Check
whether
a
project
follows
development
best
practices
To
assess
a
project’s
quality
and
currency,
check
its
documentation
and
release
notes
for
completeness
and
timeliness.
Look
for
badges
that
indicate
test
coverage
or
the
presence
of
CI/CD
pipelines
that
can
detect
regressions.
In
addition,
you
can
evaluate
a
project
by
checking
the
number
of
active
maintainers
and
contributors,
how
frequently
new
releases
are
made,
and
the
number
of
issues
and
pull
requests
that
are
opened
and
closed.
It
is
also
crucial
to
look
up
information
on
a
project’s
maintenance
or
support
strategy
—
for
example,
the
presence
and
dates
of
long-term
support
versions.
Keep
dependencies
up
to
date
and
check
code
characteristics
before
using
them
To
ensure
code
security,
checking
both
code
and
project
characteristics
is
important.
Examples
of
code
characteristics
to
check
include
pre-
and
post-installation
hooks
and
encoded
payloads.
For
project
characteristics,
consider
the
source
code
repository,
maintainer
accounts,
release
frequency
and
the
number
of
downstream
users.
One
way
to
keep
dependencies
up-to-date
is
to
use
tools
that
generate
merge
or
pull
requests
with
update
suggestions.
It’s
also
important
to
make
dependency
updates
and
recurring
backlog
items
a
priority.
Evaluate
and
compare
software
composition
analysis
tools
Security
teams
should
ensure
SCA
tools
are
capable
of
producing
accurate
bills
of
materials,
both
at
the
coarse-granular
level,
such
as
for
dependencies
declared
with
the
help
of
package
management
tools
like
Maven
or
npm,
and
fine-granular
level,
such
as
for
artifacts
like
single
files
included
“out
of
band”
without
using
package
managers.
Use
components
in
compliance
with
open-source
license
terms
IT
leaders
should
ensure
their
software
developers
avoid
using
open-source
components
without
a
license,
as
this
could
create
legal
risks.
To
ensure
compliance
and
avoid
potential
legal
issues,
it’s
important
to
identify
acceptable
licenses
for
components
used
in
software
development.
Factors
to
consider
include
how
the
component
is
linked,
the
deployment
model
and
the
intended
distribution
scheme.
Once
you’ve
identified
acceptable
licenses,
comply
with
the
requirements
stated
in
those
open-source
licenses.
Read
next:
Top
cybersecurity
threats
for
2023
(TechRepublic)
About Author
