Developers, The Enterprise, and Open Source Security
Five thought leaders discuss the underrated skills developers and enterprises need to interact with open source software, and improving open source security.
Join the DZone community and get the full member experience.Join For Free
Inspired by the 2019 All Things Open conference, this series details the thoughts of five DevOps, open source, and security thought-leaders to gain a better sense of how developers and enterprises should be interacting with open source software, what they should keep in mind, and the role of community and knowledge-sharing in open source spaces.
What Developers Need to Know
Developers interact with open source software on a daily basis, whether through their hobbyist pursuits on Github or through the open source components that comprise the foundation of their workplace stacks. With near-daily interaction with open source software, what skills do developers and enterprises as entities need to know to work effectively with OS components?
Check the Expiration Date
One of the first skills that developers should be honing before they start integrating open source components into their stacks is developing a sense of just how reliable that component may be in terms of longevity. retest CEO and founder Jeremias Roessler, says, "In my experience with enterprise customers, it's very important to have the software they use, if they embed it in their product, be maintained for a couple of years, at least."
In a world where there has been a 68% increase in open source use since 2018, and a predicted increase in use of 59% in 2020 in the United States alone, it is clear why the longevity of essential open source components should be a concern to developers and enterprises as a whole.
When asked what developers should look to as indicators of reliable open source components as opposed to those that are either "immature" or may soon be discontinued, Roessler advises developers to look toward two key indicators: community and documentation.
Looking through the history of a project and seeing how many people are working on or using the project, as well as the details of the documentation, can show "if they've put their heart and sweat and blood into it, or if it's just a side project that's probably going to being abandoned or has been abandoned already."
Practice Soft Skills, Please
The next skill is simple: play nice with others. The successful development of open source technology and projects is as much dependent on the ability of developers to collaborate as it is on actual coding. When asked his opinion on the skills developers need to pay attention to, Okta's Micah Silverman said, "I think many, many developers struggle to interact with other developers and work on teams, especially on teams with strangers on an open source project.
"Open source communities and projects, especially the ones that develop into bigger projects that benefit the developer community as a whole (think Kubernetes or Envoy) require the good-faith participation of everyone involved in the project; that should show in the commit histories and pull requests. And that means, if something like a pull request getting rejected happens, developers should be "able to navigate that in a professional way, and I think that can sometimes be challenging."
Make Time for Security and Stay Woke
On the more technical side, Derek Weeks and Brian Fox, Vice President and CTO of Sonatype, respectively, say that developers should be making more time for the security best practices that are sorely needed in the world of open source.
According to Weeks, 50% of the developers that were surveyed over the last three years as part of Sonatype's annual State of the Supply Chain report stated, "I know [security] is important, but I just don't have time to spend on it." And this may very well be true; one of the primary concerns about security is that, not only does it take a significant amount of time to get right, but it usually involves a whole other team.
But there is hope: "In the past couple of years, what we've really seen is more development tools that give developers insight into security-related information," Weeks says. "You don't necessarily have to be a security expert. You can rely on some tooling to help bring you some of that information into the fold of your development practices."
A greater sense of what's behind your components is also necessary. According to Fox, "[Developers should have] a general awareness of all of the attributes of the components besides what features and bugs they have." As complex as open source technology is, having a sense of the security, hygiene, licensing, and general upkeep of software is key.
Securing Open Source in the Age of Breaches
Next, we discuss a topic that is becoming a growing concern for developers and enterprises using open source software: security. How can both parties do a better job of securing their open source components and making security a priority in the age of highly-publicized security breaches?
Pay the Cost Now or Later
If you're reading this, chances are you have a phone, and if you have a phone, chances are that it is running on either Apple's iOS or Google's Android, which source applications from the App Store and the Play Store, respectively. What does this have to do with open source? According to Jeremias Roessler, both of these mobile app stores have one thing in common that can teach developers and enterprises a simple, powerful lesson when it comes to maintaining open source security: update, and update frequently.
"The big ones like Google and Apple and others, recognize that you need to constantly update your software. And they are doing that for you. You need to do the same thing with your APIs and everything, all the software components that you're using," says Roessler.
It's no big secret: with processes like DevOps standing on principles of, among others, continuous deployment and continuous delivery, the idea of enterprises and developers updating the software they use quickly shouldn't be a surprise.
If you balk at the idea of the cost of enterprise-wide upgrades, you'll pay the price eventually. "So if you do develop software, people will tell you how to do it right, how to use the right architecture, right patterns, and adapt to the newest, cutting-edge that's out there. And you can either do that and pay the price for that, or you don't do it and then you pay the price in additional risk and in additional maintenance, and technical debt So if you fix something quick and dirty, it might last, but then you pay the price like five years later by, you know, not being able to update to the newest version, or having security breaches."
A Culture of Identity Protection
Aside from the security of the software itself, protecting your identity through the use of your open source software cannot be overlooked. Micah Silverman encourages developers to invest in two components to accomplish this: two-factor authentication and a password vault.
As a professional software developer, Silverman says that there are certain things that need to be invested in, and if you use open source technology through repositories, a lot of your identity is wrapped up in your use of repos like GitHub. Paying for memberships like a GitHub Pro account that includes two-factor authentication is a necessary and worthy investment.
Password vaults are another way to ensure privacy that quite literally means that you can forget your passwords. "I use a password vault, so I don't memorize any passwords anymore because they're all generated. They're all as strong as they can be, depending on what the requirements are for the website. That's super important."
When asked about enterprises and what they need to do to fuel security within their processes that include open source software, Silverman says that it's all about the culture of the enterprise encouraging developers to employ measures like two-factor authentication. This doesn't have to be a continuous significant effort, either, but it should include even the smallest actions: "Even if I'm sharing a document or using another tool like Trello, I can just insist, hopefully in an automated way, that that certain security procedures be in place like two-factor authentication."
A Bug by any Other Name
Echoing earlier sentiments from Micah Silverman, Brian Fox agreed that the primary issue with security in open source stems from developers being averse to updating their components. But it's not just stubbornness; it's a systemic issue.
"I think the people that have a challenge with the security dimension specifically are likely the same ones that are having a challenge with just the ability to update components in an Agile, continuous fashion," says Fox. "So in other words, security issues are certain types of bugs, right. But for some reason, people tend to want to treat them differently."
Not only is the issue systemic, according to Fox, but the historical nature of software development has made developers distrustful of the need to consistently update their software. The culture of the "shiny new tool" is one of the culprits, and using static code analysis as an example, Fox described a scenario in which developers are told that urgent changes are needed to make their software safe, only for those changes to introduce real vulnerabilities where few, if any, existed previously.
Additionally, from an enterprise perspective, development teams conflate the idea of introducing more secure practices with an additional workload when security comes around, even though they're making similar updates themselves. "I kind of have to remind [security teams] very frequently that developers are making changes to dependencies all the time. They're doing it because they need new features, they're doing it because they have bugs. And yet when the security guy comes around and asks them to do it, they will say no. So security tends to think a lot that these updates are super hard and it never happens. And that's actually that's not true."
The solution? "So that's why I try to tell people to think about security updates as just bugs."
Know What You're Using and Where
What do Equifax, Apple, the Canadian Revenue Agency, and the Indian government identification agency Aadhaar all have in common? Each of these enterprises has been the target of an Apache Struts-related breach in the past decade. Struts, an open-source web framework for Java EE applications, is a well-established component in many application stacks, which makes news of Struts-related breaches all the more worrisome. And what is the first question enterprises ask when confronted with news of a vulnerability?
"After a vulnerability is made public through the notification channels, an organization has to say, 'Did we ever use that open source component? And if we did, where did we use it?'" says Derek Weeks.
"If you're not putting some practice in place to understand what are you using, and where you are using those components, when a vulnerability is announced today, in Struts or jQuery or Log4j or whatever it might be, if you don't have a record of where you've used the things and what you've used, then you're on a scavenger hunt. And that scavenger hunt means that you're going to spend weeks, maybe even months, trying to track down where those components were used and if you're vulnerable to attacks through that vulnerability."
To avoid such a scavenger hunt, closer attention has to be paid to the open-source components that are being used throughout a company's software or service. Recalling a previous conversation with a colleague who worked at a large financial institution, Weeks stated that the company, while using 10% more open source components year-over-year, had reduced their use of components with known vulnerabilities by 50%.
Depending on Automation
Here's what Dodds had to say:
"Let's say take an average application, I think it's something like over 50% of most applications in the world are open source. And not like the source code that you deploy to production, over 50% of that is open source code that you don't particularly manage. A vast majority of that code is actually code that you didn't install yourself. It's transitive dependency, dependencies of your dependencies, so you have no idea that those things are even installed or used. And so you could spend all day long, going through the process of auditing every line of code that's going into production, and you'd never ship."
That's the problem statement, and it's a significant one for medium and large enterprises that have dependencies that number well into the thousands or tens of thousands, each with multiple connections to others. Thankfully, the solution to this issue isn't a novel one, but it is one that many organizations aren't availing themselves of enough: security automation. Here are the statistics for the percentage of companies that have adopted automation for security according to the 2019 State of DevOps report:
Low-performing companies: 15%
Medium-performing companies: 28%
High-performing companies: 28%
Elite companies: 35%
Even among elite companies, that's less than half. But Dodds says that automation is not a nice-to-have, but a necessity. "What I'm suggesting is automating as much of that process as possible. And you know, there's only so much that you really can do with automation, but it does have an end is actively working on helping with this problem. And they have a lot of automation tools available or for developers...And so, if somebody wants to implement that kind of, you know, regular security process, which I think is a good idea, then automation is the only path forward for that."
Opinions expressed by DZone contributors are their own.