The ‘S’ in SBOM Isn’t for Security
Nowadays, Software Bill Of Materials (SBOM) is hailed as the solution to managing cybersecurity. It brings transparency to the used software components and allows you to check if published vulnerabilities may be present in your system. This is great, but SBOM leaves many aspects of product security unaddressed.
Protecting sensitive data is essential for security, but the SBOM does not provide much information on whether it is done. It does not tell what data is collected, stored, or transmitted, and the lack of proper encryption is not visible. Even when a respectable cryptography library is present in the SBOM, it may not be used or misused. The system must be inspected at run-time to resolve how it behaves. The same applies to authentication and access control; observing that its components are present does not tell how it works. As authentication is often a custom implementation, an SBOM may not give insight into it. Further, handling certificates, key generation, etc., cannot be inspected from the SBOM alone.
Input validation problems commonly cause security vulnerabilities, especially for C and C++-programmed systems. An SBOM does not tell anything about these problems, but their testing needs dynamic testing, like fuzzing or static code analysis. The operating system (OS) often provides security hardening features, but they can be used or ignored, which is not visible in a list of components. This applies to defence-in-depth features in general; you must inspect the system components and architecture to probe their security posture. SBOM also fails to tell about software updates, audit logging, usability of security features, etc.
SBOM is an excellent tool for examining security. However, knowing which third-party components are included in the product is not the whole story. SBOM must be augmented with dynamic and static system analysis for a comprehensive view. Ideally, we should cover devices, gateways, frontends, backends, and mobile applications where applicable.
