5 Techniques to Protect Open Source Software

0

Open source software brings many benefits to the modern business environment. And, in terms of security, the more developers involved in open-source software, the better – arguably, there is a better overall security baseline if there are more eyes to spot flaws. As such, software supply chain issues and vulnerabilities around popular open source packages continue to be common concerns.

I recently sat down with Ian Tien, CEO and co-founder of Mattermost, to understand some general techniques organizations should consider to protect modern open source software. According to Tien, who recently spoke on this subject at Collision Conference, open source shines with its resilience, transparency and efficiency. Yet any useful system has its share of vulnerabilities. Below, we’ll look at five ways IT can work to ensure its commitment to open source software to create more secure end systems and applications.

Organizations have an ethical responsibility to contribute to the open-source projects they consume. Not only that, but there is a business imperative to maintain the integrity of your software supply chain whenever vulnerabilities are detected.

So if you see something in a project that seems loose, it’s important to do the right thing and actively report the issue, Tien says. For example, he recounts how the Mattermost team spent months preparing a coordinated disclosure around important vulnerabilities discovered by the team in Golang. For organizations with the necessary resources, being an active open source consumer means helping to maintain project security.

2. Encourage knowledge sharing

The power of open source shines when the the community works together. Thus, knowledge sharing is an integral part of cybersecurity practices, where only a coordinated response can enable many organizations to actively respond to critical vulnerabilities and exposures simultaneously. According to Tien, being a good open source player is the economically correct thing to do – “the more you give, the more you keep”.

3. Have a responsible disclosure policy

“No useful system can ever be completely secure – there will always be vulnerabilities,” Tien said. “You can only move them.” Because vulnerabilities are a pervasive threat, the best approach is to accept that your platform or application contains them and streamline ways for third parties to report them.

Therefore, Tien advocates that all software vendors, whether startups or enterprises, have a Responsible Disclosure Policy (RDP). This policy can define a standard mechanism for security researchers to report bugs. This can take the form of an incentive bug bounty program or simply describe the best way to disclose threats to those not looking for profit. Either way, having an RDP is a first step to ensuring that any software consumer can easily report any unknown holes.

4. Know your attack surface

You can’t protect what you don’t know. And unfortunately, most large companies have a high degree of technological debt, phantom computing and Zombie APIs which may not be fully taken into account. Therefore, to protect all digital assets, an organization must comprehensively consider its potential attack surface and create data flow diagrams, Tien explains.

Tien points out that the “Gold Standard of Security” is composed of authorization, authentication and auditing. Auditing your Surface is fundamental to cybersecurity, and organizations will want to use tools to analyze and identify problem categories, Tien says. Software component auditing is becoming an increasingly important target as pressure mounts for software vendors to release software bills of materials (SBOMs) to partners.

5. Use a fully contained SecOps War Room

A small number must coordinate a rapid remediation response when a vulnerability is discovered in an open source package. This could be fixing a bug or issuing a disclosure report to a consumer base. In these high-stress situations, the last thing a team needs is a breach of privacy, Tien says. As such, he advocates that security researchers use a fully contained “war room” to carry out their coordination.

“There should be a black tent that you can put up, and only you and the people you choose can go inside the tent to hear what you have to say,” Tien said. He describes that such a self-hosted encrypted war room would be the ultimate “foil hat” to ensure no man-in-the-middle or AI scanners pick up confidential information. Sometimes security researchers can literally deal with nation-state level security secrets, amplifying the need for discretion.

While some security operations may seek to meet in person, the recent trend towards remote working has certainly displaced the need for a digital war room for incident management. “When you need it, you can have full privacy and control on your own terms,” ​​Tien said. Another benefit is that such a tactic can loop remote researchers based around the world to the same dashboard.

Reasons to Protect Open Source

The strategies above only scratch the surface of what it takes to secure open source software. Ultimately, we can reduce the number of vulnerabilities present in open source packages, but we cannot eliminate them all. “The number of things people can trust without fail is decreasing,” Tien said.

That being said, there are ways for software vendors to navigate the endless barrage of new exploits. One way is to strengthen their commitment to the open source software community through increased security awareness and reporting. This commitment becomes truly non-negotiable since 90% of IT managers in companies use open-source. Open source packages are also widely exploited in cloud-native architecture.

And while the effort to conduct security research and prepare for a disclosure may seem extensive and without direct commercial benefit, the big picture is so big that it makes sense, as Tien describes. Contributing to open source security can differentiate a company in the market and present added value to customers, he says.

Share.

About Author

Comments are closed.