Security has long been top of mind for Wes Wells and his team.
Wells is chief product officer for Instant Connect Software, which makes communications software that enables push-to-talk voice communications that connect mobile, IP, radio, and telephony devices across various private and public networks including LTE, 5G and MANET.
The software enables connections for front-line teams. Its clients are primarily military and government agencies around the world. Commercial companies in oil and gas, mining, manufacturing and logistics also use the software to support mission-critical work.
Given that customer base, the software “needs to be secure on all fronts,” Wells says.
Instant Connect uses Advanced Encryption Standard (AES) and Transport Layer Security (TLS) as part of its product security strategy, Wells says, “so everything is secure, locked down and fully encrypted.”
It complies with the U.S. government’s computer security standard for cryptographic modules as laid out in the Federal Information Processing Standard Publication (FIPS) 140-2; NIST certification of Instant Connect algorithms confirms that they have met or exceeded the FIPS standards.
That’s all required when working with government and military agencies, Wells adds.
So, too, is providing them and other clients with a list of any third-party libraries—a software bill of materials (SBOM)—used in Instant Connect software products.
An opportunity to do better
Despite the company’s commitment to security and its history of working with the government on providing proof of it, Wells says there was an opportunity to do better on detailing and tracking third-party libraries as well as reviewing them for vulnerabilities.
“In the past we had to manually keep track of the libraries we used, what version we used in each of our releases. That then was what we provided to them on a spreadsheet or in response to an RFP,” Wells says. “Now we have a scan, and it’s giving us a very accurate list of all third-party libraries.”
Instant Connect isn’t the only company paying closer attention to third-party libraries, a piece of code created by entities other than the developer building the final software product or platform.
There’s a strong case to be made for that extra attention.
Third-party libraries and open source software are pervasive. The Linux Foundation, for example, cites estimates calculating that Free and Open Source Software (FOSS) constitutes between 70% and 90% of “any given piece of modern software solutions.” Dale Gardner, a senior director analyst at Gartner, says more than 90% of application code contains open source modules.
The practice of using software libraries certainly speeds the pace of software development.
But, as security experts note, any vulnerability in that code is also then pervasive, giving hackers a big opportunity as they can seek to exploit the prevalence of the vulnerability to their advantage.
Case in point: The Apache Log4j vulnerability, identified in late 2021 and found in vast numbers of enterprises, set off a worldwide scramble of security teams rushing to find it in their own organizations so they could address it.
Know your code
The pervasiveness of such code—and, thus, vulnerabilities—is only part of the issue, however.
Many organizations have challenges in tracking which open source code or third-party libraries are being used within the software they’ve deployed. That means they may have vulnerabilities within their systems and not even know it.
Consequently, more entities are making SBOMs a prerequisite for doing business.
That includes the federal government. The White House in May 2021 issued an Executive Order on Improving the Nation’s Cybersecurity, listing the use of SBOMs as one of its many new requirements meant to enhance security in the software supply chain.
Gartner, a tech research and advisory firm, also recommends that organizations take greater steps to understand the code they’re using.
“Growing risks and ubiquitous use of open-source software in development make software composition analysis (SCA) essential to application security,” Gartner researchers state in a 2021 market guide for such tools. “Security and risk management leaders must expand the scope of tools to include detection of malicious code, operational and supply chain risks.”
Gartner researchers estimate that the use of SCA tools will climb significantly, predicting that by 2025 75% of application development teams will implement SCA tools in their workflow, up from the current 40%.
Gardner says SCA products in general “are highly effective at identifying specific open source packages within code, and from that identifying known vulnerabilities in code, possible licensing issues, and—currently to a lesser extent—supply chain risks.”
He adds: “All of these can rapidly and materially have a positive impact on the security of software.”
Improving the process and the product
Wells says he understands both the need for as well as the challenges of tracking the code used in software products.
“We found that developers in the past would use a third-party library but not immediately report it up to me so I can get it added to our product documentation,” he says. He says security checks later in the development process would catch such omissions, but the experience nonetheless demonstrated to him the need for a more robust process.
To do that, Wells implemented CodeSentry, a binary software composition analysis tool from GrammaTech that scans Instant Connect’s own software and produces a detailed SBOM as well as a list of known vulnerabilities.
“By doing this scan, it gives our customers an accurate list of libraries we’re using,” Wells says. “The government has requested it for the past 10 years, and I’ve seen on various RFPs that private companies do sometimes require a list of third-party libraries that are used in products. That’s becoming more common, so having this SBOM that’s generated by CodeSentry does add value to our product.”
Wells says he finds particular value in CodeSentry’s ability to identify whether software developed by Instant Connect has any known vulnerabilities. That feature, he explains, allows his teams to either address the vulnerabilities before its released or alert customers who can determine their best course of action (such as accepting the risk or disabling the feature that contains the vulnerable code).
That approach isn’t new to Instant Connect, Wells says. He explains that before CodeSentry was implemented in 2021, Instant Connect had a manual process for doing such work.
But Wells acknowledges that the manual process was more time-consuming and more difficult to keep up-to-date than the CodeSentry scan.
Furthermore, he says the manual system did not allow for the proactive approach that Instant Connect can now take.
Wells says his workers find the CodeSentry technology easy to use.
Gardner agrees: “Setting aside the work of integrating the tools and establishing policies around the use of open source, using SCA is relatively easy. A scan is performed, results are returned, and generally a fix—such as using an upgraded and repaired version of a problem package—can be suggested and implemented. In most cases, it’s very straightforward.”
Wells says his teams did need to tweak workflow processes to get the optimum benefits from it.
He says one of the top challenges was “figuring out when is the right time to do a scan. You don’t want to do it too early in your development process, because you could run into time-consuming work that doesn’t offer any value.”
The company settled on using CodeSentry to scan software “once the developer feels they have completed development of the feature for any particular client. That’s the first step in our QA testing for that client.” Developers then address any vulnerabilities or deficiencies found before running a scan again before the final release.
“We then take that documentation and the SBOM and make them part of our product offering by making them available to clients,” Wells says.
Copyright © 2022 IDG Communications, Inc.
