Hello Peter, Your findings are correct more details bellow.
Peter Collins <peter.coll...@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 _______________________________________________ Open-scap-list mailing list Openemail@example.com https://www.redhat.com/mailman/listinfo/open-scap-list