(continued from page 1)
In Open Source Projects, There's Safety in Numbers
There can be a significant difference in security between projects supported by one person and those that are the product of large communities.
"It is important to regularly check if the GitHub account allows many people to contribute content or if it is a single, well-known entity that owns it," says Mounir Hahad, head of Juniper Threat Labs at Juniper Networks. "If it's the former, never blindly trust an update and download a patch or a new revision without performing code review. It's tedious and complex but a mandatory step and the price to pay for getting access to open-source software."
Bryce Larson, senior SRE at SaltStack, agrees.
"One of the ways open source software stays secure is by having more eyes on the code," he explains. "If you have a project that only has one developer, the chance that one developer realizes that a piece of code is insecure is much lower than if there are many eyes all on that same code. This is one of the reasons why code reviews are a common practice. It gives a greater chance of finding problematic code earlier."
Developers should treat the code they are taking from Github the same as any code they'd use in their production systems. "It should be tested thoroughly for security vulnerabilities," says Timothy Chiu, vice president of marketing at K2 Cyber Security.
Adds KnowBe4'S Jack: "Organizations must treat these repositories in the same way that they would perform development in house; the code should be reviewed, scanned, tested, and no changes should be allowed to happen unless the code review process can happen."
Review Your Health Regularly
If your approach to security in GitHub is to simply make scheduled reviews of security, you will fail at keeping your projects secure, O'Connor says.
"As with many business-critical SaaS applications today, GitHub is a living system. Its configuration constantly changes and does so rapidly," he says. "This creates a challenge for the organization. The risk of posture and configuration drift over time is almost a certainty as users change roles, new collaborations and integrations between teams take shape, and new repositories are created."
The goal -- by constantly being aware of both internal and external threats -- is to minimize the number of threats that make it into production code. After all, explains Alex Uberlis, partner at the Blackstone Law Group, "Data, like toothpaste, is nearly impossible to return to its container once out in the open."