Companies in a rush to put applications to market can make compromises between security and market availability. With vulnerabilities such as Log4j hiding in open source, the tradeoff is riskier than ever before. 

Agencies like the National Institute of Standards and Technology have provided application and software best practices for years, but now software is just too complex and developers work under a time crunch, said Paul Bentz, director of government and industry programs at the Consortium for Information & Software Quality, while speaking during the virtual Software Intelligence Forum Tuesday. 

"You cannot do any more visual control of your code," because applications are too complex, he said. The complexity doubles because applications combine technologies, which requires a more holistic approach to best practices, he said. 

"I think that all IT people know that all your components can be good according to the rules. But for some strange reason they don't work together," Bentz said. 

While companies employ safeguards to detect flaws and security hazards in applications, the likelihood of organizations running a complete database of all the places a vulnerability lives is slim. Software intelligence inventories and diagnoses, at the very least, provide companies with a head start in locating widespread issues like Log4j. But software intelligence is not a complete cybersecurity solution on its own. 

Standalone security solutions, such as static scanning or dynamic strategies, when paired with software intelligence have a better chance of detecting exploitable flaws in open source code, according to David Golding, senior managing director at Accenture, speaking during the forum. "Structural flaws in code, the way that databases are accessed, may not necessarily be picked up by a security scan." 

The boundaries of software intelligence and cybersecurity is currently challenging industry, particularly in regulations "where these technologies will start and end," he said. For now, software intelligence and security solutions should be "synergetic." 

Companies with large IT environments are prone to complexity, especially with applications. It is one of the top challenges CIOs and CISOs face in software, according to Bentz. Companies of any size typically run undocumented code. 

Open source hiccups 

When companies adopt applications from third parties, they retain the differences in attitude and approaches to security. 

Especially when developers use open source, they have to know what components and versions they use, where it's located, and how it interacts with other applications in the tech stack, said Cengiz Şahin, head of core development and product line manager at Deutsche Automobil Treuhan, during the forum. Third-party libraries pulled into open source software have a "black box nature," complicating how to identify and patch vulnerabilities. 

In 2012, Deutsche Automobil Treuhan underwent business changes, which resulted in multiple software development departments. It was relatively successful except for the inadvertent divergence of the code base. 

Applications were created with minimum "insight on composition, or criticality of the software," said Şahin. "We literally were producing one application after the other, which raised the complexity over and over." To regain control of its code, the company began to conduct manual code scans

"Open source software is great, but it comes with no claims or legal obligations, for security and community support, informing you how to implement it securely," said Şahin. "The developers responsible for creating software are often not security experts, and may not understand how to implement these practices." 

One practice for developers to watch is copying and pasting select pieces of open source code, as opposed to the whole component, according to Şahin. 

It's a security risk — taking only sections of code "makes it impossible for you to track the code" for licensing or security reasons, he said. "You'll never know whether you have portions of a restrictive open source component inside your source."

Resources, including the Open Web Application Security Project and the National Vulnerability Database, help the open source community but often lack security instructions for vulnerability mitigation. 

If companies can establish open source policies, and sometimes companies will find it's impossible to uncover complete information about a version of open source software. In these instances, knowledge of vulnerabilities in a particular component will remain unclear or unknown. 

Multiple teams or developers can run multiple versions of the same component, which could lead to licensing or security conflicts. 

"Unlike third-party proprietary software, which has built in controls to prevent the use of multiple or incompatible versions, open source components typically rely on the user to verify proper use," Şahin said.