GrammaTech today updated its CodeSentry code inspection platform to include the ability to create a software bill of materials (SBOM) by analyzing application binaries.
Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.
The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.
There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.
That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.
Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.
GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.
Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.
