All Parts Are Not Created Equal

According to the recent DevSecOps Community survey, 80 - 90% of a modern application is assembled using open-source and third party components. This is true whether you develop in Java, .NET, Ruby, Python or any other language. While these components dramatically improve the efficiency and velocity of development, they are often consumed without enough knowledge of underlying dependencies, license requirements, or potential security vulnerabilities.

In fact, the same survey noted that only 57% of organizations had policies in place that guided developer choices on open-source component usage -- basically asking them to use the “good” and not the “bad” components. As most of us know, open-source components used in development can vary by many different attributes, including features, performance, integration ease, age, licenses, security issues, etc. The challenge is that while we all know these differences exist, identifying them is not that easy when we are using hundreds of components to build a single application.

Good Py, Bad PI

The PyPI package named “requests” versions 2.1.0 to 2.5.3 have a known security vulnerability with handling cookies or redirects. A cookie without a host value set would use the hostname for the redirected URL exposing requests users to session fixation attacks and potentially cookie stealing. While this vulnerability was fixed in v2.6.0, you might not know unless you read the project’s release notes. This vulnerability issue with “requests” is one of the thousands like it across different PyPI projects where both good versions and bad versions exist, and developers would be better off to select the good versions.

This is a common issue for many developers who don’t have time to read every release note for every package they want to use. The default behavior is likely, “it worked last time, I will use the same version that I know works again this time.” While that is the easy path, if the last version of requests you used was 2.1.0, your application could be vulnerable to attack.

Goodbye, Bad PyPI

Today, Sonatype’s Nexus Firewall announced support for PyPI packages will be delivered before the end of Q2 2017. This means that development teams can now evaluate every PyPI package they download from public repositories for licenses, security, and other risks. Nexus Firewall allows good components through, and bad components get stopped and quarantined at the front door. Nexus Firewall also supports this same capability for Java, .NET, and npm components used frequently by development teams.

In Gartner’s September 2016 report, DevSecOps: How to Seamlessly Integrate Security into DevOps, Gartner analysts Neil MacDonald and Ian Head wrote that development organizations should “Implement an OSS firewall” to proactively prevent developers from downloading known vulnerable code from Maven, GitHub, and other OSS code repositories by policy. It just so happens that Nexus Firewall is the first and only OSS Firewall solution available today. The concept is rather simple, the technology behind it is innovative, and the benefits of using the solution are immediate.

You can learn more about Nexus Firewall and request a free trial of the solution here.

PyPI for Nexus Repository

In September 2016, Sonatype announced the support of PyPI packages within its Nexus Repository solution. This feature is available in both the free and commercial versions of Nexus Repository. If you are a Python developer and are not familiar with the benefits of using a repository manager, you can find out more in this whitepaper “Concepts and Benefits of Repository Management.”

Want to Learn More?

To learn more about Nexus Firewall and its support for PyPI packages, please check out the following resources:

• Join our webinar discussing PyPI for Nexus Firewall and other new product integrations on May 10th
• Watch Block and Quarantine Vulnerable Open-Source Components and Artifacts with Nexus Firewall
• Read the 2017 DevSecOps Community Survey Report
• Download the Gartner’s DevSecOps: How to Seamlessly Integrate Security into DevOps that recommends the use of an “OSS Firewall” as an industry best practice.