Those who work with open source in the mainframe understand how critical security is. Deploying open workflows without compromising the security of your enterprise is certainly a great challenge. Malware is always a dangerous threat, but the consequences are even worse when they compromise the critical processes that run on mainframes.
In his Open Mainframe Summit 2021 session, Joe Bostian, lead of Open Mainframe’s Ambitus and Senior Software Engineer at IBM, talked about how to avoid installing open-source malware in your enterprise. If you missed it, watch it or read the recap below:
[embedyt] https://www.youtube.com/watch?v=5EL7CYJfm84[/embedyt]Open Source Attacks in the News
Open source attacks have been getting more attention in the news recently. Among many types, dependency confusion made the headlines several times in 2021. It’s a widely used attack that can affect almost any package manager repository. This attack doesn’t require the exploit of any vulnerability. Instead, it uses the perfectly valid behavior of repositories to attack weaknesses built into the DevOps pipelines.
The process is simple:
- You create a package with the same name as a real, popular open-source package.
- Load it with malware.
- Give it a number version of latest + 1.
- Finally, post it to an open-source package repository.
Automated pipelines then wrongly detect this as a new version of a legitimate package and download it.
Most of the popular open source package repositories implement defenses against dependency confusion, but it’s up to each user to leverage those defenses.
Is Open Source Compatible With Secure Environments?
Can open source even operate in a scenario where security is the most pressing issue? That’s a legitimate question to ask. As a member of the Open Mainframe Project, Joe Bostian believes that yes, that’s possible. However, that doesn’t come by default. It takes effort in order to create such a secure and resilient environment.
When it comes to open-source development, popularity is key: if no one notices your project, then it’s not going anywhere. In order to make your project usable and accessible, you want to provide ease of use, compatibility with tried-and-true DevOps processes, and accessibility from the most popular package repositories.
Security is always a critical concern for the open-source community. It can’t thrive any other way. To create a secure open-source environment, you must use a set of tools and components that are available to everyone. That requires discipline that many users lack, but it can be done.
On the other hand, the mainframe community has a lot to offer to the open-source world in terms of mature processes and better componentry, including tried-and-true and pervasive encryption capabilities, and a mindset that involves security in every single decision.
Layered Security Infrastructure
Open-source developers often rely on platforms such as GitLab and GitHub. Both offer tools to detect and automatically tell users about vulnerabilities in the packages they use. Container registries such as Quay scan each image on upload, generating reports that are easily accessible. Commercial OSS repositories such as Nexus or Artifactory offer vulnerability scanning as part of their commercial offerings.
All of that combined creates a layered security infrastructure that broadcasts and warns developers when things go wrong so the developer community can react quickly to mitigate potential security exploits. When used to its fullest extent, this infrastructure can be highly effective.
Security Best Practices
What are the best practices a mainframe manager can leverage in order to ensure security in their enterprise? The specific answer is unique to each enterprise and depends on the policies they implement.
However, in most cases, many enterprises already have security policies in place that are adequate to accommodate open-source. Considering the standard practice of providing developers a staging area to test and develop in, a workflow could look like this:
- Administrator researches OSS software available.
- If a package is acceptable, the administrator pulls it to the internal repository.
- The internal repository can be OS versions of the curated channel.
- Content is vetted further and tested in the user environment in the outside world.
Realities for the Mainframe
Though the mainframe world and the open-source can certainly work together, there are some realities that need to be acknowledged. First, many OSS communities don’t build for the mainframe, often due to not enough bandwidth. There’s also a trust issue in place, since many mainframes don’t trust the open source community, which results in barriers to innovation.
Through the Open Mainframe Project, IBM is working to bridge that gap and foster curated, safe open source content that can be leveraged by the enterprise.
Summary
Before wrapping up, here are a few suggestions to avoid security problems with OSS:
- Choose trustworthy channels.
- Keep current. Always use up-to-date versions of packages because they contain fixes to vulnerabilities.
- Know the version you want. Locking the exact version instead of pulling the latest can prevent you from pulling malicious packages.
- Use all available information. Leverage metadata, tags, and badges in order to detect evidence of fraud.
This has been recap of Open Mainframe Summit 2021. If you’d like to learn more about Open Mainframe Summit 2022, hosted in Philadelphia, PA on September 21-22, please click here: https://events.linuxfoundation.org/open-mainframe-summit/ .
This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.
