shlibs does not include any compiled parts in it’s structure. The application contains only folders and text files (most of them shell scripts) which are easily editable at any level.
Given the fact that shlibs parts are easily editable, malicious actions could be added in shlibs packages hosted at other locations. For this reason it is critical to verify downloaded packages against the checksums displayed at shlibs.org /shlibs.org especially if shlibs was downloaded from non-official locations.
shlibs (core and the official libraries) does not bring in anything compiled to your system and instead makes use of and assumes POSIX tools are available and are acting as required by the standard POSIX® IEEE® Std 1003.1-2017. Internal tests are performed and errors are handled when operating with these tools. This means that on a fresh and secure installation of an OS, you should be able to use a verified release of shlibs without any concerns regarding security.
On systems already in use it is sometimes possible that the POSIX tools expected by shlibs might be tempered with or replaced by other tools using the same names at the same standard locations. If you know or suspect your system’s POSIX tools are not acting as required by standard POSIX® IEEE® Std 1003.1-2017 it is better to try and run the application on a different system because shlibs makes extensive use of POSIX standard tools.
Security audits can be easily performed on release versions of shlibs. Once such audit passes, a developer/company can decide to add own libraries and distribute for internal use the updated package and updated checksums.
While it is still better to use shlibs from internal storage devices, it is also a great idea to keep shlibs on a portable storage device and use it on the go.
shlibs it’s designed to run properly from a portable storage device when using default settings (keep SHLIBS_MAX_RESULTS_MEM default or high in value unless the system has a seriously low amount of memory available).