“It’s often hard to spot because it’s not as simple as just running a vulnerability scanner, or checking a product version number,” said

Jeff Macko,

a senior director in consulting firm Kroll Holdings Inc.’s cyber risk business. Special tools for analyzing software are often required to find out whether Log4j or other vulnerable open-source parts are present.

Mr. Macko said he expects to be dealing with Log4j vulnerabilities for the next three to five years.

This lack of visibility into the guts of corporate software has given new urgency to an old idea—a complete inventory of what is inside software packages, including which open-source components programmers used during development. While such components are commonly used, open-source projects are sometimes maintained only by a handful of volunteers and often aren’t vetted by security teams, opening a company’s systems to attack.

Making such an inventory, known as a software bill of materials, or SBOM, has been promoted by the U.S. Cybersecurity and Infrastructure Security Agency as a way to shorten the time it takes to respond to new vulnerabilities. The Commerce Department is also an advocate, developing guidance on how to construct such an inventory in line with President Biden’s May 2021 executive order on cybersecurity.

CISA Director Jen Easterly said in a statement last month that the Log4j vulnerability “underscores the urgency of building software securely from the start and more widespread use of Software Bill of Materials.”

Building an SBOM that covers all technology at a company could be difficult. Large organizations such as major banks might run thousands of legacy applications, meaning that going through every piece to find open-source components is a daunting task.

“Frankly, legacy software without an SBOM is like a can of food from the 1920s without an ingredient label. Consume at your own risk,” said

Sounil Yu,

chief information security officer at Morrisville, N.C.-based cybersecurity company JupiterOne Inc.

Companies that can provide SBOMs demonstrate a mature software-development process, said Mr. Yu, who was previously chief security scientist at Bank of America Corp.

Software providers, in particular, are likely to come under significant pressure to produce SBOMs, he said, as client security teams are unlikely to endure long waits for vulnerability notifications from their suppliers while they figure out what is inside their products. In the Log4j case, tech providers rushed to develop patches to fix the flaw in their own products and to notify customers.

Companies have two basic options for discovering whether the software they use contains open-source components, said

Tim Mackey,

principal security strategist at

Synopsys Inc.,

a Mountain View, Calif.-based software-testing company. If the source code is available, it can be compared with open-source libraries for common components. Alternatively, the program itself can be run through a binary analysis process, where it is dissected to determine its parts, although the results might not be as clear as using the source code.

Still, Mr. Mackey said, bespoke software projects developed by teams outside a company’s technology division can complicate efforts to build comprehensive SBOMs, as they might not go through the usual checks and balances or even be known to technology staff.

Kroll’s Mr. Macko warned that component inventories won’t counteract inherently weak security. Implementing network security that watches for odd behavior from applications and following basic cybersecurity hygiene will help to mitigate the impact of attacks.

“It’s painful that we have to learn our lessons by getting a bloody nose first,” he said.

Write to James Rundle at james.rundle@wsj.com