GrammaTech Adds SBOM Analysis Capability to CodeSentry

GrammaTech today updated its CodeSentry code inspection platform to include the ability to generate a SBOM by analyzing application binaries.

Walter Capitani, director of technical product management at GrammaTech, said CodeSentry 3.0 takes advantage of algorithms the company uses to analyze binary software configuration to enable organizations to better address software supply chain concerns in the wake of a series of notable vulnerabilities.

The tool can be applied to both commercial software and open source components through integration with Risk Based Security’s VulnDB database, which was 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 use only the software that comes with the SBOM. However, most organizations are not provided with access to the source code used in the applications they use. GrammaTech enables organizations to address this issue by analyzing the binary code within an application to generate an SBOM.

Capitani said that this report not only identifies all components in the application, but also lists all known vulnerabilities associated with the version of the components used. CodeSentry will also list other popular software products and versions that may be affected by the same vulnerabilities, along with versions of the software that addressed the problem or versions of a component that were not affected by these vulnerabilities.

Almost all software applications include external components and open source components that create blind spots within software supply chains. In fact, this problem is what makes addressing zero-day vulnerabilities for applications so difficult; Especially when they are caught, for example, in a log management tool like Log4j that is widely used in Java applications.

GrammaTech makes a case for a binary software configuration analysis (SCA) tool that enables DevOps teams to address vulnerability issues before an application is deployed in a production environment. However, at the same time, security and compliance teams can now use the same tool to determine the level of risk an organization may be exposed to once the application is deployed in production. This latter ability is particularly important because zero-day vulnerabilities are often discovered only long after the application has been deployed in a production environment, Capitani noted.

Regardless of the approach, the need to better secure software supply chains is now one of the major IT issues that should eventually encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not only to embrace the need for those practices but also to provide developers with the tools they will actually use to implement those practices. The success or failure of these efforts is due not only to the effectiveness of the tool, but also to its relevance to the overall developer experience. After all, the greatest tool in the world would still be weakened if it were too difficult for the average developer to employ.

Leave a Comment