GrammaTech Makes Finding Vulnerabilities in Binaries Simpler
GrammaTech this week updated its CodeSentry software composition analysis (SCA) tool to make it simpler to identify specific types of vulnerabilities within application binaries.
In addition, the company is also now making CodeSentry 4.2 available in three editions, starting with a software bill of materials (SBOM) edition that is available for free for a limited time. That edition generates an SBOM that identifies open source risks and any associated licensing issues.
The other two options are a Security Edition that identifies component n-day vulnerabilities, provides security scoring for application risk assessment, assesses exploitability across components and supports additional deployment and application programming interface (API) options and an Advanced Security Edition that also detects zero-day vulnerabilities, support for advanced scanning to detect advanced n-day weaknesses and packaging security assessments.
Walter Capitani, director of product management for GrammaTech, said CodeSentry is designed primarily for security teams that are trying to assess security after an application has been deployed. The SBOMs created support multiple formats and include a common platform enumeration (CPE) dictionary field and standard machine-readable formats for encoding names of IT products and platforms to meet federal IT security compliance requirements.
GrammaTech is also making it easier for cybersecurity teams to track down specific vulnerabilities such as Log4j/Log4Shell, he added. GrammaTech built a database that tracks more than 2,300 vulnerabilities and 3,800 software components that it updates daily. Vulnerability intelligence can be easily shared via a report that comes in a CycloneDX format.
Finally, GrammaTech has added a visualization dashboard to provide a comprehensive overview of artifact scanning and results.
In contrast to other source code-focused tools that most cybersecurity teams are not going to be able to access, the GrammaTech tools focus on the application binaries that are deployed in production environments. The goal is to make it simpler for cybersecurity teams to address application security issues without waiting for development teams to identify every instance of a discovered vulnerability. Cybersecurity teams can then work with developers to prioritize which vulnerabilities to remediate based on the actual level of threat they represent.
Historically, application security has been problematic because cybersecurity teams tended to assume development teams were responsible for it. Unfortunately, most developers have little to no cybersecurity expertise, so the number of vulnerabilities in applications that have already been deployed is staggering. It’s usually the responsibility of the cybersecurity teams to discover those vulnerabilities before they are exploited. The good news is that as organizations embrace DevSecOps best practices for building and deploying applications, fewer vulnerabilities are finding their way into production environments. As a result, developers are getting more adept at building and applying patches to remediate vulnerabilities.
In the meantime, hopefully, the historic divide that has existed between cybersecurity teams and application developers will continue to narrow. Developers are, in many cases, the root cause of many of the issues that keep cybersecurity teams up at night. The only way to resolve those issues, however, is for cybersecurity teams to engage developers in ways they can easily appreciate and understand.
