Open-source security summit shows way to deal with threats, expert says

Open-source software solutions are a part of every IT team’s day-to-day, and that means security solutions are essential.

That’s why Paul Davis, JFrog field CISO, attended the Open Source Security Foundation hosted its Policy Summit in Washington, DC, on Mar. 4. Featuring speakers from OpenSSF, Linux, GitHub, and other organizations, the summit provides a place for people who share goals to talk openly, Davis told IT Brew.

“I found it personally reinvigorating, and it also showed me the world of open-source risk management is maturing,” Davis said.

Summiting. For Davis, an IT executive with over two decades of experience, the summit also spoke to an issue of fundamental importance—the evolving security risks at play as software evolves and “people and processes” play catchup. That’s part of the maturity at play, he told IT Brew, and the responsibility of security advocates.

“We have to work in harmony with the business and the people and encourage them, persuade them that security is actually going to make their life easier,” Davis said.

Danger list. By its nature, open source is susceptible to hacks and attacks. Open–source developers noted in December that they were being spammed by AI-generated bug reports. Kubernetes, the open-source container system, said in January that it was going to change certain aspects of its management of Dynamic Resource Allocation.

This came about a month after Unit42 discovered a misconfiguration in the system that “could allow attackers to gain persistent access as shadow administrators” over internal services.

Internal sources. In that context, IT teams may well be concerned about the software, and Davis said he understands. But there are ways to ensure that your information is protected, primarily by keeping tabs on how data is generated in the internal open-source software development cycle. That way you’re able to track back the inventory properly.

“I remember hearing one story about a customer…when they had an incident, it took them five days to work out who wrote the software; this is just scary crazy,” Davis said. “If you’re doing federal stuff, sometimes you only have a deadline of 20 days to report that root cause analysis report, and the five days of that time is spent finding out who actually wrote the software.”

Open-source software has always been considered safe in large part because it’s assumed that the broad user base is working on assessing vulnerabilities, Davis told IT Brew. Internal open-source software, on the other hand, raises the possibility that a mistake might be made.

“There are tools there that can also help with that,” Davis said. “But the biggest thing is just providing the data to the team.”