DEV Community: Safety Cybersecurity

Software Supply Chain Security for Python Developers - Part 2

Robin Birney — Tue, 26 Sep 2023 17:12:19 +0000

Securing the Software Supply Chain for Python Developers

Welcome back to our series on Software Supply Chains, this time focusing on software supply chain security for Python developers. In this installment, we’ll discuss various tools and techniques to secure your software supply chain.

Why is Software Supply Chain Security Crucial?

Considering the vast integration of open-source software (OSS) packages in over 90% of codebases, ensuring the security of your supply chain is more important than ever.

Possible consequences of an insecure supply chain include unauthorized access to sensitive data, disrupted services, and compromised software integrity, potentially causing long-lasting financial and reputational damage.

We recommend implementing a well-rounded security strategy to minimize your project’s risks, including code vulnerability checks, dependency analysis, installation policies, and continuous monitoring.

Historical Context: Software Supply Chain Breaches

To understand the criticality of maintaining software supply chain security, we can learn from instances where lapses led to severe repercussions.

SolarWinds Orion: One of the most severe software supply chain attacks occurred in 2020 involving the SolarWinds Orion software. An alteration in the update mechanism of the SolarWinds Orion platform enabled threat actors to inject malicious code into the platform’s builds. This code acted as a backdoor, affecting over 18,000 customers worldwide - including several Fortune 500 companies and US government departments. This case underscores the severity of supply chain attacks, which can infiltrate and compromise even the most secure entities through unnoticed entry points.

The Log4j vulnerability: More recently, in December 2021, a critical vulnerability - coined Log4Shell and subsequently Log4j - was discovered in Apache’s Log4j, an open-source logging library widely used in enterprise applications. The exploit leveraged the JNDI (Java Naming and Directory Interface) to run arbitrary code remotely, offering hackers comprehensive control over the impacted system. This flaw impacted countless applications across industries, proving that even seemingly minor elements in a software supply chain can be exploited to dreadful degrees.

Event-Stream and NPM: Another infamous incident involves the JavaScript library event-stream on the Node Package Manager (NPM). Unknown to the developer community, maintainership of the widely used library had been transferred to an anonymous developer who unsurprisingly introduced a malicious version affecting users at large. This attack primarily affected the Bitcoin wallet application Copay, which had a dependency on event-stream.

Lessons from these incidents cannot be ignored. They stress the importance of constant vigilance in identifying and mitigating risks associated with software supply chains. At Safety, we equip you with tools and strategies to identify vulnerabilities early, helping you safeguard your software ecosystem.

Remember, the best defence against these risks is ongoing, multi-layered security that integrates seamlessly with your development processes. Through techniques like updating dependencies, regular vulnerability scanning at all stages of the development lifecycle, and employing reliable security tools like Safety, your Python projects can remain secure despite a rapidly evolving threat landscape.

Security Best Practices for Python Developers

Use the latest version, where possible: Regularly update your Python dependencies and libraries to the latest stable release to benefit from enhanced security and performance improvements.

Monitor security vulnerabilities: Utilize tools like Safety to monitor your codebase for known vulnerabilities across all dependencies.

Shift Left Security: Monitoring at CI/CD and beyond is often too late. By using Safety to identify vulnerabilities at the developer machine level, we help to prevent vulnerabilities from reaching CI/CD or Production.

Limit the use of unpopular packages: Minimize dependency on unverified third-party libraries to mitigate potential security risks. By employing Safety Gateway, we can set policies that prevent the installation of malicious packages or packages that don’t meet the security criteria of your organization.

Enforce access management: Establish proper authentication and authorization mechanisms and manage user roles within your development process.

Embrace code peer reviews: Encourage your development team to review each other’s code, helping to identify security vulnerabilities and improve code quality collectively.

As Python developers, securing your software supply chain must be a top priority. You can ensure a secure development environment by combining best practices with powerful tools like Safety. In an upcoming series on security best practices, we’ll dive into this topic in much more detail.

Tools and Techniques for Enhancing Software Supply Chain Security

Safety: Leveraging the industry’s leading database of vulnerabilities and malicious packages, Safety streamlines the process of detecting vulnerabilities and outdated packages within your Python projects.

Safety Platform combines severity, exploitability, reachability, and project health factors into a single risk score. The result is a 90% reduction in vulnerability noise compared to other platforms, allowing developers to prioritize those that really matter.

Together, Safety’s suite of products - Safety Platform, Safety CLI Scanner, Safety DB, and Safety Gateway - provide the only truly end-to-end solution for Python supply chain security.

GitHub Dependabot: This automated tool from GitHub scans your dependencies for known vulnerabilities and creates pull requests to update them. The downside? Dependabot contains just 12% of the vulnerabilities tracked by Safety, meaning you will have an unclear picture of what vulnerabilities may impact your dependencies.

Snyk: Snyk is an open-source security platform designed for larger enterprises, providing an all-in-one DevSecOps solution. As with Dependabot, Snyk contains fewer vulnerabilities and is regarded as overkill for most organizations. Its primary disadvantage is that it only caters to larger enterprises with a more extensive set of needs. For smaller organizations or individual developers, Snyk could appear quite overwhelming and unnecessarily complex. Additionally, compared to Safety, Snyk falls short in its vulnerabilities database. It covers fewer vulnerabilities, meaning developers could potentially miss out on detecting several threats that can compromise their software supply chain.

Anaconda: a distribution platform offering tools and libraries for Python and R. However, the strength of its package management tools comes with corresponding demands. Anaconda requires dedicated personnel for its management, becoming a resource-intensive option for teams with constrained or limited resources. Anaconda’s complexities can render it less adaptable and user-friendly, particularly for smaller teams or projects with shorter timelines. Anaconda may seem more cumbersome and less efficient than Safety Gateway, a lightweight, easy-to-deploy package proxy. Safety Gateway offers a lighter-weight, easier-to-deploy package proxy to achieve the same result.

Software supply chain security is of paramount importance. As Python developers, taking proactive steps toward securing your software supply chain has an immediate and lasting impact on the reliability and integrity of your applications. By leveraging robust tools like Safety and adhering to best practices, you can enhance your security posture, reduce risk, and protect your valuable data. Remember, the efficiency of your defence mechanisms is contingent upon their seamless integration into your development workflows and the continuous evolution of your strategies in response to the changing threat landscape.

We hope this article has helped to improve your understanding of software supply chain security. For more information on Safety or any content discussed in this series, please get in touch with us at info@safetycli.com.

An Introduction to Software Supply Chains for Python Developers - Part 1

Robin Birney — Tue, 26 Sep 2023 17:05:11 +0000

Welcome to the first installment in our series dedicated to software supply chains, their role in open-source software development, and security.

This post is intended for Python developers and non-developers of all experience levels.

Overview of Open Source Software and Software Supply Chains

Open Source Software (OSS) is like a community recipe book for coding. Imagine a cookbook to which anyone can read, use, and even add their recipes—that’s what open-source software is like. In the tech world, developers share the “source code,” or the original programming instructions so that anyone can read, use, or modify it. This contrasts with “closed source,” where only the original creators can alter the code. With OSS, the more people who can look at and work with the code, the better it often becomes in terms of features and security.

Now, let’s talk about Software Supply Chains. Think of building software like building a car. A car has many parts—engine, tires, airbags—from various suppliers. Similarly, a software project uses different “parts,” which might be chunks of code or software libraries, many of which come from open-source projects. Just like in a car supply chain, where you’d want every part to be safe and reliable, in a software supply chain, you want to ensure that all the components are secure and function as expected.

The concept of a Software Supply Chain becomes especially important in the context of Open Source Software. Since many people can modify OSS, knowing where your ‘parts’ are coming from is crucial. Are they secure? Are they updated? Are their known vulnerabilities? What licensing requirements do they have?

Open Source Software (OSS) is essential in modern software development and data analysis. A staggering 90% of codebases used globally integrate at least some OSS components. It is, therefore, crucial to all projects - from a single project managed by a Data Scientist to a business-critical application used by millions of users - to understand what your software supply chain looks like and the risks that come with that.

Dependencies, Packages, Libraries: Understanding the Python Supply Chain Ecosystem

The Python ecosystem is built around interdependencies of dependencies, packages, and libraries, forming the foundational structure of open-source software projects.

Packages are Python software modules that have been built and released to the open-source community. These can be installed and used to perform specific roles in your software project instead of writing that code from scratch. For example, pandas is a popular package choice for data exploration and manipulation that would take a long time to build from scratch.

Libraries, on the other hand, are comprehensive collections of Python modules. A prime example is Python’s standard library - a one-stop shop for diverse modules ranging from file I/O to system calls. Another example is PyTorch, Meta’s extensive collection of machine-learning tools that can be installed as a single library.

Dependencies are the complex webs of interconnected external software packages your projects or applications rely upon to operate. For instance, TensorFlow, a commonly used machine learning library, is often a necessary dependency for machine learning projects. By installing TensorFlow, however, you are also installing more than 20 other packages simultaneously, upon which TensorFlow relies.

As a result, you have just added 21 packages and libraries to your software supply chain that are linked together. A vulnerability in one is effectively a vulnerability in all. Fear not, though! We’ll cover Supply Chain Security in part 2 of this series.

Package Installation via Pip, Pipenv, Poetry

Python offers a variety of streamlined mechanisms for package installation. The three key players are pip, pipenv, and poetry.

Pip, or “Pip Installs Python,” is the foundation. It straightforwardly facilitates installing Python packages, such as with the command pip install safety.

Pipenv is a step ahead, merging dependency management with environment handling. Running pipenv install pandas installs the pandas package while updating your Pipfile.

Poetry is an advanced tool providing an all-in-one solution for dependency resolution, package management, and packaging process. It simplifies tasks like versioning and publishing packages.

The Security Perspective: Unveiling Software Supply Chain Security

Despite the efficiency they offer, software supply chains also pose distinct security risks. Threat actors often exploit these chains, resulting in dire consequences such as data breaches, malware distribution, and even system-wide vulnerabilities.

When embracing open-source software, the importance of security cannot be stressed enough. Our research has illuminated critical vulnerabilities like ReDoS (Regular expression Denial of Service) that can reside in widely used Python packages that pose significant risks to projects and the organizations who own them.

Understanding software supply chains and their respective security issues is vital in the current digital era. Here at Safety, we believe in streamlining Python dependency security, reducing vulnerability noise, and effectively integrating it into your security workflows. In our next article in this series, we dive deep into Software Supply Chain Security and security best practices.

To learn more about Safety, ask questions about this article, or provide feedback, please get in touch with us at info@safetycli.com.

Beyond CVSS: Project Context, Exploitability, and Reachability of Vulnerabilities - Part 2

Robin Birney — Mon, 25 Sep 2023 18:34:47 +0000

In this two-part series, we look at the importance of Severity when assessing software supply chain vulnerabilities and outline how Safety combines Severity, Project Context, Reachability, and Exploitability to deliver end-to-end software supply chain security without the noise.

Welcome back to Part 2 of our series on assessing vulnerabilities in the software supply chain. In Part 1, we explored the Common Vulnerability Scoring System (CVSS), its mechanics, benefits, and limitations.

In this post, we will discuss why assessing vulnerabilities based on severity alone is inadequate and introduce Safety's multi-dimensional approach, which offers a more comprehensive evaluation of threats.

The Limitations of Severity Alone

CVSS severity is not a good predictor of which vulnerabilities that actually impact security
‍
While CVSS can provide some useful data, it solely focuses on a vulnerability's severity and, most often, is not a good predictor of which vulnerabilities actually impact security at most organizations. Evaluating a vulnerability's impact on a project requires considering not just the potential damage but also the likelihood of that damage being done, the relevance of the specific vulnerability in the project, and the potential scope of the damage within the active project's specific context.‍

Consider a critical-severity vulnerability found in a library referenced by your project, but that is neither exploitable at all within your specific use of it nor is the vulnerability known to be exploitable in the wild. In this case, the vulnerability does not pose the level of risk to your project or organization at all despite its critical severity score.

Alternatively, consider a medium-severity vulnerability in a vital component of your project that is exploitable and, if exploited, could result in massive financial or reputational damage. Despite its relatively lower severity score, this vulnerability presents a much more real and immediate threat that should be addressed.

With the huge growth in the number of vulnerabilities the industry is seeing today, to effectively assess and triage vulnerabilities, startups and organizations must look to contextual analysis in a consistent and data-driven manner.

Safety's Four Pillars of Vulnerability Assessment

To address massive growth in vulnerabilities and the ineffectiveness of CVSS severity, Safety combines multiple assessment criteria to calculate a single vulnerability risk score based on project context.

The four criteria used by Safety to evaluate vulnerabilities are as follows:
‍

1. Severity:
Leveraging CVSS data and our team of Cybersecurity Analysts' research, Safety provides more comprehensive severity data than other providers. We manually vet every vulnerability to ensure accurate severity ratings, even if maintainers and package authorities haven't updated the details.

In fact, Safety now has detailed and accurate Severity data for over 12,600+ vulnerabilities tracked in Safety DB.

2. Project Context: Different software projects have varying significance. Some projects and components are critical for business operations, while others are less important. The same vulnerability can have hugely different implications depending on the project in which it exists. Safety allows developers and DevSecOps teams to define the Project Context for each project in their organization. This customization ensures that vulnerability severity carries the appropriate impact on the overall risk score across an organization. Project Context consists of four constituent ratings:

Lifecycle: The stage of the software development life cycle (SDLC) in which the project resides (e.g., development, CI/CD, production).
Business Criticality: The project's importance to business operations and the potential financial or reputational impact if a high-severity vulnerability is exploited.
Data Sensitivity: The degree of access the project has to sensitive or valuable data. For example, publicly accessible information may have minimal risk if exposed.
Network Exposure: The project's accessibility to networks, both internal and external. Restricted access through mechanisms lowers the risk of vulnerability exploitation by internal actors.

3. Exploitability:
This factor considers whether a vulnerability has actually been known to be exploited in reality and how easy it is to exploit. Some vulnerabilities may be theoretically damaging but are complex to exploit and, as a result, not often or even used in any successful exploits. Other vulnerabilities are widely known to be used and are easier for attackers to leverage, making them more dangerous in practice. Safety utilizes the Exploit Prediction Scoring System (EPSS) in conjunction with CVSS data to assess risk more accurately.

4. Reachability:
This criterion determines whether an attacker can access the vulnerable part of the dependency within the project’s actual codebase. Suppose a package has a vulnerability in a specific component, function or use case, but the project does not use that component, function or use case. In that case, the vulnerability is not relevant and not reachable.

In this example, the vulnerability has a high CVSS score (8.5). Safety further raises the risk score because the Reachability score is 100, meaning potential attackers can easily reach the vulnerability in the current project. Combined, the Safety score indicates that this vulnerability should be addressed in the context of the project in which it is used.

Comprehensive Vulnerability Assessment

By incorporating project context, exploitability, and reachability data, in addition to severity ratings, Safety reduces vulnerability noise by up to 90%.

By focusing on relevant vulnerabilities, development teams can allocate their time more efficiently, prioritizing fixes based on real-world risk rather than only theoretical severity ratings.‍

This approach results in

Fewer false positives and unnecessary alerts.
Targeted fixing of the most critical threats.
Huge savings in development time.
Safety's Approach with Machine Learning and Research Techniques
Safety combines Machine Learning and proprietary research techniques to conduct in-depth analyses of vulnerabilities, considering not just their severity but also their exploitability and reachability. Our extensive database provides more detailed information than other providers, empowering our customers to make informed decisions and take effective action.

The Future of Vulnerability Assessment

In an ever-evolving digital landscape, developers must not only be aware of vulnerabilities but also understand their real-world implications within their project's context.

By moving beyond severity scores and adopting a multi-dimensional approach to vulnerability assessment, Safety ensures that developers can confidently code, knowing that their projects are protected from all angles.‍

To learn more about our approach, connect with one of our software supply chain experts or email us at info@safetycli.com.

Severity and the Common Vulnerability Scoring System (CVSS) - Part 1

Robin Birney — Tue, 12 Sep 2023 14:24:58 +0000

In part one of this two-part series, we explore the importance of CVSS severity when assessing software supply chain vulnerabilities. We also explain how Safety combines severity, project context, reachability, and exploitability to enhance software supply chain security and reduce vulnerability noise.

What is CVSS?

CVSS, or the Common Vulnerability Scoring System, is a standardized rating system for software vulnerabilities. Since its creation in 2005, CVSS has become a widely used standard across programming ecosystems. It employs quantitative measures to assess the severity of security flaws in software.

How CVSS Works

CVSS utilizes multiple metrics divided into three primary groups, with scores ranging from 0 to 10 (10 being the highest):

Base Score Metrics: These metrics evaluate inherent vulnerability characteristics, such as exploitation techniques, required access, and resultant impacts.

Temporal Score Metrics: These metrics consider factors like the ease of exploiting a vulnerability or the availability of solutions.

Environmental Score Metrics: These metrics focus on specific environmental features, such as system susceptibility or the business impact of a vulnerability.

Example:
Let's analyze a CVE (Common Vulnerabilities and Exposures) and examine the CVSS details associated with it:
‍

CVE-2019-0708
This vulnerability in Microsoft Windows Remote Desktop Service allowed for remote code execution. In simpler terms, an attacker could gain control of the system without any user interaction.

‍CVSS Score: 9.8 (Critical)
‍Base Score Metrics:
Attack Vector: Network
Attack Complexity: Low
User Interaction: None

In this example, the CVSS score indicates that the vulnerability is severe, posing a high risk of network-based attacks without requiring user action.

The Role of Developers, Maintainers, and CNAs

CVSS relies on various groups within the software development community to ensure its effectiveness. These include:

Developers: Developers and end users are often the first to discover vulnerabilities. By identifying these flaws, developers contribute to the broader community by swiftly enabling software maintainers to implement workarounds and patches. This collaborative approach is fundamental in the Open Source Software community.

Maintainers: Developers responsible for creating and maintaining impacted software use CVSS scores to prioritize vulnerability fixes and release appropriate updates. CVSS holds maintainers accountable as vulnerabilities are publicly available.

CNAs (CVE Numbering Authorities) are organizations authorized to assign identifiers to new vulnerabilities. This process can take time, often leading to erroneous data being gathered and documented about the CVE. As you’ll see, Safety vets every CVE that we track to ensure accuracy.

National Vulnerability Database (NVD): The NVD serves as the US government's vulnerability management data repository. It provides comprehensive information about vulnerabilities, including their associated CVSS scores. New vulnerabilities receive a CVE identifier and are cataloged in the NVD.

The Pros and Cons of Using CVSS

Pros:
Universal, Standardized Metrics: CVSS provides a globally recognized scale, fostering a unified security dialogue.
Prioritization: Scores can help facilitate the identification of immediate threat areas based on severity (although CVSS severity is not the best way to triage or prioritize vulnerabilities, more on this later)
Transparency: Publicly accessible CVSS scores enlighten users and developers about software safety.

Cons:
Speed of Identification and Updates: CVSS scores are only available for registered CVEs, and the accuracy of the data depends on the community's information gathering and submission. Therefore, many vulnerabilities remain undocumented for weeks or even months, and others contain outdated information.

Inaccuracies: Despite everyone’s best efforts, the CVSS scoring system is under strain and cannot keep up with the volume of vulnerabilities across the global software ecosystem. As a result, CVEs and their CVSS scores can sometimes be incorrect or inaccurate.

Lack of Context: CVSS scores alone overlook many important vulnerability aspects. And they are not the best way for organizations to triage and prioritize vulnerabilities. High or critical CVSS severity scores are not good predictors for those vulnerabilities that actually impact security at most organizations. An overemphasis on quantifiable measures neglects other crucial considerations, such as project context and exploitability, which will be explored in Part 2 of this series.

Complexity: CVSS may appear overwhelming at first due to the abundance of data, advisories, and impacted configurations. The example above demonstrates the significant effort required to understand how each vulnerability affects a project, especially when dealing with large numbers of vulnerabilities across multiple dependencies.

CVSS severity is not a good predictor of which vulnerabilities that actually impact security‍

‍Safety Cybersecurity adopts a unique approach to utilizing and applying CVSS data for vulnerability assessment. Our dedicated team of cybersecurity analysts manually verifies every vulnerability in our industry-leading vulnerability database to ensure the accuracy and completeness of severity information, including CVEs.

Additionally, Safety employs machine learning and proprietary research techniques to identify new vulnerabilities in over 550,000 Python packages that are not CVEs yet or would not be covered by the CVE system. These vulnerabilities are then assessed for severity using the same criteria as CVSS. There are multiple times more vulnerabilities in the open source software ecosystem than those listed as CVEs, and at Safety we track and index these using a variety of techniques.

The result is our Safety DB, which tracks eight times more vulnerabilities than other platforms like Dependabot, OSV, and PipAudit. This comprehensive database provides Safety customers with unparalleled protection and insights into vulnerabilities that may impact their projects.

Beyond CVSS and Reducing Vulnerability Noise

In this post, we delved into the workings of CVSS, its pros and cons, and how Safety leverages CVSS data for comprehensive vulnerability assessment.

Although CVSS data can be used for assessing vulnerabilities based on severity alone, it has many downsides and limitations.

In the next part of this series, we will delve further into Safety's approach to mitigating the limitations of CVSS and reducing vulnerability noise. We will explore how we combine CVSS severity data with additional vulnerability data, such as project context, exploitability, and reachability.