[Open-scap] anything from stock repo is fair game?

[Šimon Lukašík]

Hello Peter,

Your findings are correct more details bellow.

Peter Collins <peter.collins at processionsec.com> writes:

> Hello
>
> I searched for this but was unsuccessful.
>
> Question is: As long as a piece of software was installed from a Repo that
> originally came with Redhat, or the software was installed when the OS was
> installed, are its vulnerabilities covered by the open-scap scanner?

All the software bits that come from Red Hat (and still within support
life-cycle) Red Hat Product Security tracks existing vulnerabilities. As
a result multitude of data feeds are available under

 - https://www.redhat.com/security/data/metrics/ds/v2/ (DataStream files)
 - https://www.redhat.com/security/data/oval/v2/ (OVAL files that are
   referenced by ComplianceAsCode or scap-security-guide)

>
> And then software from other sources, like ones needing compiling, or
> coming from other repos that get installed on the system, are not covered
> by the scanner?
>

No, there is basically no way of auditing this thoroughly and reliably.

Let me explain in detail. Many software stacks come with their own
package management system:
 - Rust has cargo
 - Ruby has gems
 - Python has pip
 - Golang has go-get
 - etc.

Nevertheless, the packages in the given language system will often
depend on packages outside of it. As an example consider ruby's nokogiri
library. It depends on libxml2 and libxslt. When you install nokogiri by
ruby gem system (gem install nokogiri) it will usually re-build and
bundle one of these libraries. You can try yourself and see the install
log and bits installed on system. It will contain another version of
libxml.

Now, consider scenario there is vulnerability in libxml, auditing
software will find system wide installation of libxml that come from yum
or dnf, but audit can hardly find the version we just bundled with
nokogiri, because it can be installed in *any* location on your disk.

When you install packages from your software vendor, they are usually
well formed and hence nokogiri shipped in various Red Hat products won't
bundle its own libxml, it will depend on the single version installed by
yum. This both reduces install size and maintenance burden.

Of course there are exceptions to this rule, but in rare cases where
software is ever bundled in rpms is usually temporary and it is known so
it can be assessed for.

Kind regards,
--
Šimon Lukašík
Member of technical staff
Office of the Chief Technologist
Red Hat Public Sector