Sonar today revealed it will at the end of May add an offering that combines its Static Application Security Testing (SAST) tool with the software composition analysis (SCA) tools it gained with the acquisition of Tidelift late last year. Tidelift continues to operate as a unit of Sonar.
Tidelift CEO Donald Fischer said SonarQube Advanced Security will make it possible for DevSecOps teams to better secure the code they write and third-party code developed, for example, by an open source contributor.
The SCA tool developed by Tidelift streamlines the tracking, managing and mitigating known vulnerabilities in third-party software, including dependencies, in addition to allowing organizations to monitor usage of software components based on the type of licensing model associated.
That data can then also be used to create a software bill of materials (SBOM) that makes it simpler for organizations to comply with any regulatory requirement.
With the launch of SonarQube Advanced Security, those capabilities are being made available in an integrated offering to more than 400,000 organizations that are already using the Sonar SAST tool, said Fischer.
While the amount of scanning of code as it is developed remains uneven, integrating SAST and SCA tooling should make it simpler for organizations to ensure software is as secure as possible as it is being developed, he added.
Regardless of the current level of commitment to DevSecOps and code scanning, it’s only a matter of time before more stringent regulations require organizations to ensure that routine vulnerabilities don’t find their way into production applications. Organizations will need to be able to demonstrate that reasonable efforts were made to protect the software supply chain that was relied on to build and deploy software.
As a result, most organizations will continue to revisit software supply chain security in the months ahead, before or shortly after those regulations go into effect.
In the meantime, securing application software in an era where the dependencies on third-party code provided by maintainers of open-source repositories remains a major concern. The challenge now is finding a way to secure applications regardless of who, or what, in the case of coding tools infused with artificial intelligence (AI) coding tools, created the code that drives them.
Hopefully, AI will become more widely relied on to surface security issues long before any of that code ever makes it into a production environment. The issue is there may be a significant gap before AI is routinely used to achieve that goal, and adoption of AI coding tools that were trained using flawed code, that might be replicated into code that developers are then copying and pasting into an application.
The one thing that is certain is the sheer volume of code that is being produced will overwhelm most of the existing DevSecOps workflows. As such, DevSecOps teams will need to identify more issues as far left in the software development lifecycle (SDLC) as possible. Even then, however, it’s still possible for vulnerabilities to be introduced across multiple phases of the SDLC so, as always, the price of security is eternal vigilance.
